GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3496

Network Working Group A. G. Malis Request for Comments: 3496 T. Hsiao Category: Informational Vivace Networks

                                                            March 2003
Protocol Extension for Support of Asynchronous Transfer Mode (ATM)
      Service Class-aware Multiprotocol Label Switching (MPLS)
                        Traffic Engineering

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 This document specifies a Resource ReSerVation Protocol-Traffic
 Engineering (RSVP-TE) signaling extension for support of Asynchronous
 Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching
 (MPLS) Traffic Engineering.

Table of Contents

 1.  Overview......................................................2
 2.  Extended RSVP-TE Path Message Format..........................2
     2.1 PATH Message Format.......................................3
 3.  ATM_SERVICECLASS Object.......................................3
 4.  Handling the ATM_SERVICECLASS Object..........................4
 5.  Non-support of the ATM_SERVICECLASS Object....................4
 6.  Security Considerations.......................................4
 7.  IANA Considerations...........................................5
 8.  References....................................................5
 9.  Authors' Addresses............................................5
 10. Full Copyright Statement......................................6

Malis & Hsiao Informational [Page 1] RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003

1. Overview

 This document defines a Resource ReSerVation Protocol-Traffic
 Engineering (RSVP-TE) 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 Label Switched Routers
 (LSRs) 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.

Malis & Hsiao Informational [Page 2] RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003

2.1 PATH Message Format

 The format of the extended PATH message is as follows:
 <PATH Message> ::=      <Common Header> [ <INTEGRITY> ]
                              <SESSION> <RSVP_HOP>
                          <TIME_VALUES>
                          [ <EXPLICIT_ROUTE> ]
                          <LABEL_REQUEST>
                          [ <SESSION_ATTRIBUTE> ]
                          [ <DIFFSERV> ]
                          [ <ATM_SERVICECLASS> ]
                          [ <POLICY_DATA> ... ]
                          [ <sender descriptor> ]
 <sender descriptor> ::=  <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
                          [ <ADSPEC> ]
                          [ <RECORD_ROUTE> ]

3. ATM_SERVICECLASS Object

 The ATM_SERVICECLASS object format is as follows:
 Class Number = 227, C_Type = 1
  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

Malis & Hsiao Informational [Page 3] RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003

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].
 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 an ATM_SERVICECLASS object (whether the PATH message
 contained an 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.

Malis & Hsiao Informational [Page 4] RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003

7. IANA Considerations

 The IANA has registered a new RSVP Class Number for ATM_SERVICECLASS
 (227).  (See http://www.iana.org/assignments/rsvp-parameters).

8. References

 [DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
             P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-
             Protocol Label Switching (MPLS) Support of Differentiated
             Services", RFC 3270, May 2002.
 [RSVP]      Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
             Jazmin , "Resource ReSerVation Protocol (RSVP) -- Version
             1 Functional Specification", RFC 2205, September 1997.
 [RSVP-TE]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
             and G. Swallow, "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. Authors' 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 Informational [Page 5] RFC 3496 ATM Service Class-aware MPLS Traffic Engineering March 2003

10. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Malis & Hsiao Informational [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3496.txt · Last modified: 2003/03/03 23:40 (external edit)