Himanshu Shah Ciena Corp Ping Pan HammerHead Systems PWE3 Working Group Internet Draft Hamid Ould-Brahim Nortel Networks February 2005 Chris Metz Expires: August 2005 Cisco Systems Qos Signaling for PW draft-shah-pwe3-pw-qos-signaling-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document discusses how a tail-end PE can signal the Quality of Service parameters of the local Attachment Circuit to the head-end PE for appropriate Pseudowire generation from head to tail end PE. Shah, et al. Expires August 2005 1 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt The Pseudowires traditionally provide connectivity between two Attachment Circuits that are on the edges of a service providerÆs network. A service provider assigns specific QOS parameters (i.e. via manual configuration or dynamic signaling) to these Attachment Circuits based on the service sold to the customer. In order to interconnect and maintain the same level of service parameters across the service provider network, it is prudent that the Provider Edge devices that are endpoints of the Pseudowires, select or create a suitable transport path that meets the PseudowireÆs quality of service requirements. It is also possible that a PE may use appropriate policing for traffic entering Pseudowire that match remote Attachment CircuitÆs capabilities as well as perform an admission control check to ensure that the PE can indeed support the desired QOS. In order to accomplish an integrated service delivery it becomes necessary that each PE understand the QOS requirements of the remote Attachment Circuit. This draft proposes an extension to the PWE3 control signaling to enable a PE to exchange QOS parameters of the local Attachment Circuit at the time of the PW establishment. With advent of recent interest in multi-segmented Pseudowire signaling the Pseudowire specific QOS requirements through multiple PSN domains has become an important step in procuring the right resources through intermediate PEs that perform Pseudowire stitching. In this revision we have added some more parameters that address some of the requirements placed by Multi-hop Pseudowire Signaling. 1.0 Specification of Requirements 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. 2.0 Introduction The [PWE3-CONTROL] draft describes how two PEs signal PW-FEC to each other in order to establish a pseudowire. The PW-FEC is exchanged over the targeted LDP session and contains Pseudowire signaling information that includes interface parameters of the local Attachment Circuit. This draft describes a mechanism whereby additional information, such as QOS parameters of the local Attachment Circuit can be dispatched with the VC-FEC in a backward compatible fashion. This document specifies QOS TLV that can be included in the initial Label Mapping Message and subsequently in LDP notification message for conveying up-to-date information about the Pseudowire. Shah, et al. Expires August 2005 2 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt This proposal is orthogonal to the type of PW-FEC used. Both PWid FEC (value 128) and Generalized ID FEC (value 129) can make use of the new additions. In the case of PWid FEC the signaled QOS information can be related to the GROUP_ID value when this field is used in signaling. The term VC-FEC and PW-FEC is used interchangeably in this document and refers to both the FEC Ids. It is expected that capability of exchanging QOS information dynamically would facilitate various applications to optimize the use of core resources effectively. For example, a PE may use this signaling for backpressure when æforward congestionÆ is detected on its local AC. 3.0 Capability Learning for QOS exchange For the purpose of learning remote end capabilities and for the purpose of signaling to the remote end the local capabilities, this draft suggests that the QOS TLV be included initially in the Label Mapping message and particularly in the Optional Parameter field of Label Mapping Message. When subsequent updates are required (after the PW is established), the sender PE will use the LDP notification message to convey an update of the new information. Note that the mechanism described in this draft allows a given PE that does not support the QOS TLV to be able to establish a Pseudowire using normal operations. Indeed, the PEs that are upgraded with such new functionality, examine the optional parameters and note QOS TLV to learn the capability of the sending peer. The sender must include the QOS TLV that it intends to use later as an update, in the Label Mapping message that is used to setup the FIB. Typically, such Label Mapping message is either the first Label Mapping message or the one right after the Label Withdraw/Release message and is referred to in this document as a ôLearning Label Mappingö message. The absence of a given TLV in the Learning Label Mapping message indicates to the receiver that the sending PE is either not capable of processing such TLV or does not wish to engage in dynamic update exchange for that TLV. The absence of QOS TLV indicates to the receiving PE that normal PW signaling procedures should be used to establish the PW (i.e., no inclusion of the optional TLVs in the reverse label mapping). Similarly, the receiving PE that has not been upgraded with the new TLVs and receives a label mapping with the new TLVs will just ignore these TLVs during label mapping processing phase. The capability learning aspect of the PW QOS is only applicable for the use of QOS TLV for dynamic update notifications. It does not change the need to send the initial QOS TLV, irrespective of whether remote PE is capable of processing the optional TLV or not. Shah, et al. Expires August 2005 3 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt It is also possible that the receiving PE is capable of processing QOS TLV and uses unacceptable QOS requirement as a criterion to release the VC-FEC. In such event, a status TLV is defined to be included in the optional parameter field of the label release message that informs the remote PE about the reasons for the rejection. 4.0 Pseudowire QOS TLV The pseudowire QOS TLV is used to notify the remote PE about Quality of Service requirements of the local Attachment Circuit. As stated earlier, this information can also be passed as an update. It is possible that receiver may either adjust QOS parameters of the existing tunnel or may respond to the update by first withdrawing the advertised PW label and re-advertise new PW label with same VC- FEC. It is possible to send more than one QOS TLVs. The Flag field in the QOS TLV provides the context for each TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW QOS TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Information Rate (CIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Information Rate (PIR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Burst Size (PBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |R|D| Number of Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (1-n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Traffic Engineering Parameters Each TE parameter is encoded as a 32-bit IEEE single precision floating-point number. The CIR and PIR are in units of bytes per second while CBS and PBS are in units of bytes. Flags This field contains set of flag. There are two flags bits are defined currently. They are, D û Direction flag. The value zero in Direction Flag means Forward direction. The forward direction typically represents the direction from the advertiser to the receiver. The value 1 in Shah, et al. Expires August 2005 4 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt Direction flag means Reverse direction. The reverse direction typically represents the return path to the advertiser. R û Request/Available flag. The value zero in Request/Available flag means Requested QOS by the advertiser. The value one means what is available. In multi-segment PW signaling intermediate PEs can adjust the available QOS when propagating the signal towards the destination PE. The rest of the bits in the Flag field are reserved. They should be set to zero on send and ignored on receive. Number of Sub-TLVs This field identifies the number of Sub-TLVs that follow. In absence of any Sub-TLVs, this field should be set to zero. This field is mandatory. Sub-TLVs (1-n) The n number of Type-Length-Value fields where ænÆ is equal to æNumber of Sub-TLVsÆ field. The presence of field facilitates future/proprietary extensions 5.0 New LDP Status Codes The PW Status TLV described in this document is the status code point that may be used by the receiving PE to inform the sender the specific reasons for not accepting the Label Mapping message. The status TLV should be included in the æoptional parameterÆ field of the Label Release message. Shah, et al. Expires August 2005 5 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt The format of the PW Status TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the status code is a 4 octet bit field is specified in the PW IANA Allocations document [13]. According to Section 4.4 in RFC3036, we can define new status codes in the range of 0x20000000-0x3effffff. Here are the new status codes: - 0x20000003 "TC is OK" - 0x20000004 "Cannot accept the TC parameters" - 0x20000005 "Preempted due to TC processing" 6.0 General Procedures The PW QOS TLV is included in the Optional Parameter Field of the Label Mapping Message and the LDP Notification Message. In case of Label Mapping Message, Optional Parameter Field follows the Label TLV object. In LDP Notification Message, Optional Parameter Field must include PW-FEC TLV before QOS-TLV. As described above, exchange of QOS TLV in Notification Message is determined by the capability learning during the initial Label Mapping exchange. The PW QOS TLV conveys Quality of Service parameters that advertising PE would like remote PE to consider when selecting/creating appropriate transport tunnel to carry the Pseudowire from remote PE to the advertising PE. The Quality of Service parameters can also be used by the receiving PE to select appropriate policer for his Attached Circuit or perform an admission control check. The QOS TLV is optional. The received PE uses this information as a suggestion. Note that use of PW QOS exchange helps utilize core resources effectively in the following manner. . Head end PE selects a transport tunnel that best suits remote Attachment CircuitÆs QOS requirement . More PWs can be multiplexed over a transport tunnel . Transport tunnel can be right-sized with various upsize and downsize thresholds Shah, et al. Expires August 2005 6 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt . Eliminates the wastage of packet forwarding resources in the core when received traffic exceeds the Attachment Circuit QOS criteria at the tail end. 7.0 The role of PW QOS in multi-hop PW signaling In a multi-segmented Pseudo-wire, each intermediate PE stitches two pseudo-wire segments in order to create a pseudo-wire from source PE to destination PE through multiple PSN domains. In this topology it becomes necessary that each PE hop æknowsÆ what the QOS requirements are for this multi-segmented pseudo-wire so that it can procure the correct network resources in each direction. It is expected that source PE may include a set of QOS TLVs, one for each direction, requested and available QOS parameters in the initial Label Mapping message. Each intermediate PE then uses this QOS information to acquire network resources and if unsuccessful, to reject the multi-hop Pseudo-wire generation through that PE hop. The Available QOS TLV could be adjusted at each PE hop in order for the destination PE to determine the suitability of the end-to-end Pseudo-wire path. The details for signaling PW QOS and itÆs processing at each hops as well as at the source and destination PE would be discussed in the future revision of this document. 8.0 Security Considerations The security aspects of this solution will be discussed at a later time. 9.0 References [PWE3-CONTROL] Martini et. Al., ôTransport of Layer 2 Frames Over MPLSö, draft-ietf-pwe3-control-protocol-14.txt, December 2004 (work in progress) Acknowledgement Author's Address Himanshu Shah Ciena Corp 35 Nagog Park Acton, MA 01720 Email: hshah@ciena.com Shah, et al. Expires August 2005 7 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt Ping Pan HammerHead Systems Email : pingpan@cs.columbia.edu Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7, Canada Email: hbrahim@nortelnetworks.com Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 Email: chmetz@cisco.com IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any licence under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETFÆs procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full copyright statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR Shah, et al. Expires August 2005 8 Internet Draft draft-shah-pwe3-PW-Qos-Signaling-01.txt IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shah, et al. Expires August 2005 9