Internet DRAFT - draft-jimmy-pppext-priority-mux
draft-jimmy-pppext-priority-mux
pppext Jimmy Vincent
Internet-Draft Nokia Siemens Networks
Intended status:Experimental Sanjeev Kumar Sharma
Expires: March 21, 2012 Nokia Siemens Networks
September 21, 2011
September 21, 2011
Priority PPP MMultiplexing
draft-jimmy-pppext-priority-mux-00
Status of this Memo
This document is an Internet Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2011.
Copyright Notice
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Jimmy Vincent, et al. Experimental [Page 1]
Internet-Draft Priority PPP MMultiplexing September 21, 2011
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Abstract
PPP multiplexing is a technique to encapsulate and carry multiple
subframes inside a single PPP superframe as defined in RFC3153. With
the existing Muxing mechanism, the carrier superframes waits for
certain time for the incoming frames to be multiplexed, but this
wait period may have impact on the delay constrains for the
subframes. On the other hand lesser wait period for superframes so
as to reduce the delay means lesser multiplexing efficiency. This
document describe a method to achive maximum multiplexing efficiency
for PPP Multiplexing over a link especially during low and medium
traffic scenarios with out effecting the delay constraints required
for different types of traffic over that link.
With priority multiplexing technique delay for real time traffic
during Multiplexing can be reduced, still assuring maximum
Multiplexing efficiency
1. Description
The Priority Multiplexing is implemented by having multiple PPP
superframe carriers initiated simultaneously towards destination
node. Each of the superframe waits for incoming subframes to be
multiplexed until its ready to be transmitted. With this mechanism,
the waiting period, which is one of stopping criteria of
multiplexing as defined in RFC 3153, is different for each
superframe, wait period can be based on delay constraints for each
sub frame. This method also defines different priorities for each
subframe type which is inturn based on the traffic it carries. The
subframe with maximum delay constraint is assigned with highest
priority. The waiting period of a superframe is as described in RFC
3153 for PPP multiplexing Section 1.2.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7].
2. Subframe Mux Delay
This is defined as the amount of time a subframe could spend during
Jimmy Vincent, et al. Experimental [Page 2]
Internet-Draft Priority PPP MMultiplexing September 21, 2011
the multiplexing procedure such that there is no impact on the real
timeness of frame as seen by higher layers which processes this
subframe. This can also be considered as the extra time due to PPP
multiplexing procedure.
Different traffic types has different mux delays based on the delay
constraints of the traffic it carries. Traffic types having same
delay constrains has same mux delay and should be considered with
same subframe mux delay time value.
Sub frame priority:
The subframe priority is inversely related to its mux delay, thus
muxing delay time value inversly indicates the priority of the
subframe traffic as per the traffic types. Eg: if the subframe is an
IP packet, then the DSCP field details in IP header which determines
its priority can be given to the multiplexing module to determine the
mux delay.
For each mux delay values of subframes there should be a
corresponding superframe defined with a wait period(as defined in
section 3.1) same or less than the mux delay.
3. States of Superframe
This method defines two states for the superframe at the sender side
before it is transmitted to the peer.
3.1 Wait State
When the superframe is created by transmitter,as defined in section
4.2, it should start in wait state . During this state it waits for
the subframes for multiplexing.
Wait Period:
This is defined by the time superframe is in wait state once it is
created until it is ready to be transmitted towards peer. During the
implementation the delay constraints of the of sub frame traffic
packets types may be used to derive the waiting period of a
superframe. For each subframe mux delay value(described in section
2)defined there must be a superframe wait period determined and one
superframe is assigned with it, also there should not be any other
superframes defined with the same wait period.
However this doesn't mean that subframes with particular subframe mux
delay is always carried by superframes having the corresponding wait
period. This superframe wait period just assures that this particular
Jimmy Vincent, et al. Experimental [Page 3]
Internet-Draft Priority PPP MMultiplexing September 21, 2011
sub frame traffic type do not wait for more than its mux period
during multiplexing procedure.
Remaining wait period:
This is defined as the time remaining for a superframe to transcends
into ready state from a particular point of time in wait state. The
superframe with least remaining wait period must be the next ready to
be transmitted superframe towards the destination or the next frame
to enter to ready state.
3.2 Ready State
If a superframe is met with the stopping criteria of multiplexing as
defined in RFC3153 section 1.2 then it transcends to ready state from
wait state.
4. Procedure
One of the stopping criteria for existing PPP multiplexing
concatenation mechanism(as described in RFC 3153 for PPP multiplexing
Section 1.2) is the usage of timer to implement a waiting period for
the PPP multiplexed frame. This is relevant if the incoming subframes
are of lesser rate. Limiting this waiting period to lesser values
could assure that the delay constraints are met for the sub frames,
but reduces the concatenation capability and in turn the multiplexing
efficiency. On the other hand if we increase the waiting period for
the PPP Multiplexed frame for better multiplexing efficiency then
delay requirements needed for the sub frame types may not be met. The
priority multiplexing method here assures the delay requirements of
the sub frame types with better multiplexing efficiency.
The mechanism described here is only applicable to the sender side
and have no impact to the receiver, so there is no separate
negotiations required for this method during NCP setup for
PPPMultiplexing and is independent whether this method is supported
at receiver or at sender side.
The implementation should have certain number of superframes
initiated at a time towards the destination each of them with
different wait periods defined, based on the number of mux delays
defined for the subframes. This means number of waiting period levels
defined for superframes should be equal to the number of mux delay
levels defined for subframes.
The method describes scheduling and transmission procedures.
Scheduler ensures the waiting period of a subframes to be with a
certain limit based on its delay requirements. Further the
Jimmy Vincent, et al. Experimental [Page 4]
Internet-Draft Priority PPP MMultiplexing September 21, 2011
transmitter procedure ensure that the superframes transmitted are
multiplexed to maximum possible level thus ensuring maximum muxing
efficiency.
4.1 Scheduler procedure
Scheduler determines the superframe for an incoming subframe, to do
this scheduler determines the subframe-mux delay of incoming
subframes, based on the mux delay of subframe scheduler multiplexes
the subframe with a superframe in wait state having a certain
remaining wait period in such a way that remaining wait period of the
superframe to which it is multiplexed is always less than or equal to
the subframe-mux delay for that subframe.
With this method the superframe for a particular incoming subframe is
determined such a way that the subframe with highest priority should
concatenated with the superframes which is latest to be transmitted
towards destination or the one having the least remaining wait
period. Also the subframes with next higher level of priority are
carried in superframes which is next latest to be transmitted and so
on.
4.2 Transmitter procedure
Once superframe transcends to ready state, if space still exists for
more subframes to be multiplexed, then the initial subframes of the
superframe, which is in wait state, having least remaining wait
period are re-concatenated to the superframe which is ready to be
transmitted, thus having maximum multiplexing efficiency. The number
of subframes thus transferred from the frame having least wait period
to superframe in ready state depends on the subframe sizes of the
source superframe and space availability at the target superframe.
On initiating a re concatenation procedure towards the superframe in
ready state, if more than one superframe in wait state has the same
least remaining wait period then it is recommended to take the
initial subframes of the superframe having least waiting period.
Once the superframe is transmitted to peer a new superframe with the
same wait period is initiated.
5. Security Considerations
This document does not impose additional security considerations
beyond those that apply to PPP and header-compression schemes over
PPP.
6. Acknowledgements
Jimmy Vincent, et al. Experimental [Page 5]
Internet-Draft Priority PPP MMultiplexing September 21, 2011
7. References
[1] R. Pazhyannur, Ed., "PPP Multiplexing", STD 51, RFC 3153, August
2001.
[2] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Author's Addresses
Jimmy Vincent
Nokia Siemens Networks
Bagmane Tech Park, C V Ramannagar
Bangalore-93
Karnataka India
Phone: (+91-080-)42214422
EMail: jimmy.vincent@nsn.com
Sanjeev Kumar Sharma
Nokia Siemens Networks
Bagmane Tech Park, C V Ramannagar
Bangalore-93
Karnataka India
Phone: (+91-080-)42214310
EMail: sanjeev.kumar_sharma@nsn.com
Jimmy Vincent, et al. Experimental [Page 6]
