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]