Internet Draft Andrew G. Malis Document: draft-malis-diff-te-serviceclass-01.txt Tony Hsiao Expires: December 2002 Vivace Networks June 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 signaling extension for support of ATM Service Class-aware MPLS Traffic Engineering. Table of Contents 1. Overview......................................................2 2. ATM Service Class-Aware Traffic Engineering-related RSVP Message Format...........................................................2 2.1 PATH Message Format.......................................2 3. SERVICECLASS Object...........................................3 4. Handling the SERVICECLASS Object..............................3 5. Non-support of the SERVICECLASS Object........................4 6. Security Considerations.......................................4 References.......................................................4 Author's Addresses...............................................5 Malis, Hsiao Expires - December 2002 [Page 1] ATM Service Class-Aware MPLS Traffic Engineering June 2002 1. Overview draft-ietf-tewg-diff-te-proto-00.txt [DS-MPLS-TE] defines protocol additions for support of Diff-Serv-aware MPLS Traffic Engineering. Similarly, this document defines an RSVP-TE protocol addition to support ATM Service Class-aware MPLS Traffic Engineering. 2. ATM Service Class-Aware Traffic Engineering-related RSVP Message Format One new RSVP Object is defined in this document: the 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 SERVICECLASS Object in PATH messages used to establish LSP Tunnels in accordance with [RSVP-TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object. Restrictions defined in [RSVP-TE] for support of establishment of LSP Tunnels via RSVP 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 SERVICECLASS object is optional with respect to RSVP so that general RSVP implementations not concerned with ATM Service Class-aware traffic engineering MPLS LSP setup do not have to support this object. An LSR supporting ATM Service Class-aware traffic engineering in compliance with this specification MUST support the SERVICECLASS Object. It MUST support Class-Type value 1, and MAY support other Class-Type values. 2.1 PATH Message Format The format of the PATH message is as follows: ::= [ ] [ ] [ ] [ ] [ ] [ ... ] [ ] Malis, Hsiao Expires - December 2002 [Page 2] ATM Service Class-Aware MPLS Traffic Engineering June 2002 ::= [ ] [ ] [ ] 3. SERVICECLASS Object The 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 SERVICECLASS Object To establish an LSP tunnel with RSVP, 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]. If the LSP is associated with an ATM Service Class, the sender LSR must include the 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 SERVICECLASS objects, only the first one is meaningful; subsequent SERVICECLASS object(s) must be ignored and must not be forwarded. Malis, Hsiao Expires - December 2002 [Page 3] ATM Service Class-Aware MPLS Traffic Engineering June 2002 Each LSR along the path that is SERVICECLASS-aware records the SERVICECLASS object, when present, in its path state block. The destination LSR responds to the PATH message by sending a RESV message without a SERVICECLASS object (whether the PATH message contained a SERVICECLASS object or not). 5. Non-support of the SERVICECLASS Object An LSR that does not recognize the 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 SERVICECLASS object Class Number but does not recognize the 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 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. References [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- ietf-mpls-diff-ext-09.txt, April 2001 [DS-MPLS-TE] Le Faucheur et al, ôProtocol extensions for support of Diff-Serv-aware MPLS Traffic Engineeringö, draft-ietf-tewg-diff-te- proto-00.txt, work in progress [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 Malis, Hsiao Expires - December 2002 [Page 4] ATM Service Class-Aware MPLS Traffic Engineering June 2002 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 - December 2002 [Page 5]