Internet Draft Andrew G. Malis Document: draft-malis-diff-te-serviceclass-04.txt Tony Hsiao Expires: April 2003 Vivace Networks October 2002 Protocol Extension for Support of ATM Service Class-aware MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 specifies an RSVP-TE (Resource ReSerVation Protocol- Traffic Engineering) signaling extension for support of ATM (Asynchronous Transfer Mode) Service Class-aware MPLS (Multiprotocol Label Switching) Traffic Engineering. Table of Contents 1. Overview......................................................2 2. Extended RSVP-TE Path Message Format..........................2 2.1 PATH Message Format.......................................2 3. ATM_SERVICECLASS Object.......................................3 4. Handling the ATM_SERVICECLASS Object..........................3 5. Non-support of the ATM_SERVICECLASS Object....................4 6. Security Considerations.......................................4 7. IANA Considerations...........................................4 9. References....................................................5 10. Author's Addresses...........................................5 Malis, Hsiao Expires û April 2003 [Page 1] ATM Service Class-Aware MPLS Traffic Engineering October 2002 1. Overview This document defines an RSVP-TE (Resource ReSerVation Protocol- Traffic Engineering) protocol addition to support ATM (Asynchronous Transfer Mode) Service Class-aware MPLS (MultiProtocol Label Switching) Traffic Engineering. This protocol addition is used with all MPLS LSRs (Label Switched Routers) and link types (including, but not restricted to, Packet over SONET, Ethernet, and ATM links) to signal traffic engineered paths that can support the ATM service classes as defined by the ATM Forum [TM]. This document does not specify HOW to actually implement the functionality in the MPLS LSRs to emulate the ATM Forum service classes (such as necessary queuing and scheduling mechanisms), only how to signal that the TE path must support the ATM Forum service classes. A useful application for such paths is the carriage of ATM cells encapsulated in IP or MPLS packets in order to use MPLS networks as functional replacements for ATM networks. 2. Extended RSVP-TE Path Message Format One new RSVP-TE Object is defined in this document: the ATM_SERVICECLASS Object. Detailed description of this Object is provided below. This new Object is applicable to PATH messages. This specification only defines the use of the ATM_SERVICECLASS Object in PATH messages used to establish LSP (Label Switched Path) Tunnels in accordance with [RSVP-TE]. Such PATH messages contain a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and a LABEL_REQUEST object. Restrictions defined in [RSVP-TE] for support of establishment of LSP Tunnels via RSVP-TE are also applicable to the establishment of LSP Tunnels supporting ATM Service Class-aware traffic engineering. For instance, only unicast LSPs are supported and Multicast LSPs are for further study. This new ATM_SERVICECLASS object is optional with respect to RSVP- TE so that general RSVP-TE implementations not concerned with ATM Service Class-aware traffic engineering MPLS LSP setup do not have to support this object. 2.1 PATH Message Format The format of the extended PATH message is as follows: ::= [ ] Malis, Hsiao Expires û April 2003 [Page 2] ATM Service Class-Aware MPLS Traffic Engineering October 2002 [ ] [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 3. ATM_SERVICECLASS Object The ATM_SERVICECLASS object format is as follows: Class Number = TBD, C_Type = 1 (This will use an official Class Number in the range 224-255, which are assigned by IANA using FCFS allocation. At the time of this writing, the next available number in this range is 227.) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 29 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. SC : 3 bits Indicates the ATM Service Class. Values currently allowed are: 0: UBR (Unspecified Bit Rate) 1: VBR-NRT (Variable Bit Rate, Non-Real Time) 2: VBR-RT (Variable Bit Rate, Real Time) 3: CBR (Constant Bit Rate) 4-7: reserved 4. Handling the ATM_SERVICECLASS Object To establish an LSP tunnel with RSVP-TE, the sender LSR creates a PATH message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also include the DIFFSERV object as per [DIFF-MPLS]. Malis, Hsiao Expires û April 2003 [Page 3] ATM Service Class-Aware MPLS Traffic Engineering October 2002 If the LSP is associated with an ATM Service Class, the sender LSR must include the ATM_SERVICECLASS object in the PATH message with the Service-Class (SC) field set to signify the desired ATM Service Class. If a path message contains multiple ATM_SERVICECLASS objects, only the first one is meaningful; subsequent ATM_SERVICECLASS object(s) must be ignored and must not be forwarded. Each LSR along the path that is ATM_SERVICECLASS-aware records the ATM_SERVICECLASS object, when present, in its path state block. The destination LSR responds to the PATH message by sending a RESV message without a ATM_SERVICECLASS object (whether the PATH message contained a ATM_SERVICECLASS object or not). 5. Non-support of the ATM_SERVICECLASS Object An LSR that does not recognize the ATM_SERVICECLASS object Class Number must behave in accordance with the procedures specified in [RSVP] for an unknown Class Number with the binary format 11bbbbbb, where b=0 or 1 (i.e. RSVP will ignore the object but forward it unexamined and unmodified). An LSR that recognizes the ATM_SERVICECLASS object Class Number but does not recognize the ATM_SERVICECLASS object C-Type, must behave in accordance with the procedures specified in [RSVP] for an unknown C-type (i.e. it must send a PathErr with the error code 'Unknown object C-Type' toward the sender). In both situations, this causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly might take action to retry reservation establishment without the ATM_SERVICECLASS object. 6. Security Considerations The solution is not expected to add specific security requirements beyond those of Diff-Serv and existing TE. The security mechanisms currently used with Diff-Serv and existing TE can be used with this solution. 7. IANA Considerations The document calls for IANA to register a new RSVP Class Number in the range 224-255, which are assigned by IANA using FCFS allocation, as discussed in http://www.iana.org/assignments/rsvp- parameters . Malis, Hsiao Expires û April 2003 [Page 4] ATM Service Class-Aware MPLS Traffic Engineering October 2002 8. References [DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002 [RSVP] Braden, R. et al, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [TM] ATM Forum Traffic Management Specification Version 4.0, af-tm- 0056.000, April 1996 9. Author's Addresses Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com Tony Hsiao Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Tony.Hsiao@VivaceNetworks.com Malis, Hsiao Expires û April 2003 [Page 5]