CCAMP Working Group L. Ong (Ciena) Internet Draft J. Sadler (Tellabs) Category: Informational E. Varma (Lucent) D. Pendarakis (IBM Research) Expiration Date: May 2004 Nov 2003 Interworking of RFC 3473 and 3474 draft-ong-ccamp-3473-3474-iw-00.txt 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. 1. Abstract This document defines interworking procedures between [RFC 3473] (Generalized MPLS (GMPLS) RSVP-TE) and [RFC 3474] (GMPLS RSVP-TE Usage and Extensions for ASON) signaling. RFC 3474 extensions are used in ITU-T Recommendation [G.7713.2]. Two basic interworking scenarios are discussed. RFC 3474 was intended to use the same basic mechanisms as and to be backwards compatible to RFC 3473. Some objects in 3474 are carried transparently over an RFC 3473 network, in accordance with RSVP procedures for unrecognized objects. Other objects must be mapped or generated at the interworking point. The mechanisms described in this document are applicable to any types of interfaces common to RFC 3473 and Recommendation G.7713.2, esp. time-division multiplexed, lambda or fiber switching interfaces. L. Ong et al - Expires May 2004 1 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 2. Conventions used in this document 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. In addition, the reader is assumed to be familiar with the terminology used in [RFC-3471] and [RFC-3473]. 3. Introduction This document defines interworking procedures between [RFC 3473] (Generalized MPLS (GMPLS) RSVP-TE) and [RFC 3474] (GMPLS RSVP-TE Usage and Extensions for ASON) signaling. RFC 3474 extensions are used in ITU-T Recommendation [G.7713.2]. The terms I-NNI (Internal Network-Network Interface) and E-NNI (External Network- Network Interface) are taken from ITU-T Recommendation [G.8080]. It should be noted that some interworking procedures described have been implemented by multiple parties, although further interoperability testing may be needed. 3.2 RFC 3473 to RFC 3474 Interworking The 3473-3474 interworking scenario occurs where a 3473 Overlay interface is supported by either an RFC 3474 network or a node with a 3473 Overlay interface is connected across multiple domains using RFC 3474 at the E-NNI. This is shown in Figures 1 and 2. /----------\ //// \\\\ +---+ |+---+ +---+ +---+ +---+ | A |---------+-| X |---| Y |---| Z |+--------| C | +---+ |+---+ +---+ +---+ +---+ RFC 3473 \\\\ //// RFC 3473 Overlay \----------/ Overlay RFC 3474 I-NNI Figure 1: 3473-3474 Interworking Case 1 L. Ong et al - Expires May 2004 2 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 +---+ +----+ +----+ +---+ | A |-----------| N1 |-----------| N2 |----------| C | +---+ +----+ +----+ +---+ RFC 3473 RFC 3474 RFC 3473 Overlay E-NNI Overlay Figure 2: 3473-3474 Interworking Case 2 These interworking cases may occur, for example, where networks supporting RFC 3474 internally or at the E-NNI interface to neighboring networks also support 3473 Overlay to an IP client system. 3.2 RFC 3474 to RFC 3473 Interworking The 3474-to-3473 interworking case is where a network using RFC 3473 internally supports RFC 3474 interfaces at its border nodes, as shown in Figure 3 below. In this case, RFC 3474 is supported across an RFC 3473 network or domain. ------------- //// \\\\ // \\ +---+ +---+ +---+ +---+ +---+ | A |----------+| X |------| Y |------| Z |+----------| C | +---+ +---+ +---+ +---+ +---+ \\ // RFC 3474 \\\\ //// RFC 3474 UNI/NNI ------------- UNI/NNI RFC 3473 I-NNI Figure 3: 3474-to-3473 Interworking This may be a typical application, for example, if the client nodes A and C are not IP nodes or are identified by non-IP addresses. RFC 3474 supports a client address (TNA) which is separate from the 3473 addressing range and can convey non-IP address formats such as NSAP. It also allows full overlap of the client address range with the address range used in the network, since separate objects are used for each. L. Ong et al - Expires May 2004 3 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 The interworking point between 3474 and 3473 is required to perform resolution of the TNA to the corresponding destination node in the 3473 network. 3.3 Mapping of General 3474 Capabilities RFC 3474 also identifies four specific requirements generating the extensions defined: a) support for call and connection separation b) support for soft permanent connection c) support for extended restart capabilities d) additional error codes/values As RFC 3473 does not support call and connection separation or soft permanent connection, there are currently no additional interworking requirements beyond transparent transport of related objects (see 5.4). However, future study may be required for support of features such as a call with no connections. (c) is a local procedure and has no interworking implications (d) is strictly a support item for the preceding requirements. 4. Procedures for 3473-3474 Interworking 4.1 Interworking of Session Object For RFC 3473, the Session Object contains the tunnel endpoint address, i.e., in Figure 1 the IP address of node C. For RFC 3474, which treats the tunnel as a concatenation of tunnels linking multiple domains and domain boundaries, the Session Object contains the endpoint of the local tunnel, i.e., in Figure 1 the 3474 Session Object created by Node X would carry the address of Node Z as the local tunnel endpoint. For interworking purposes, the node receiving RFC 3473 RSVP must map the tunnel endpoint address of the Session Object into the Destination TNA sub-object of the GENERALIZED_UNI object that is defined in RFC 3476 and used in 3474, since this carries the end-to-end tunnel endpoint. That ingress node then generates an appropriate RFC 3474 Session Object. At the egress RFC 3474 node, the RFC 3473 Session Object must be regenerated from the TNA and passed across the terminating RFC 3473 interface to the destination client. 4.2 Interworking of Sender_Template For RFC 3473, the Sender_Template contains the tunnel sender, i.e., in Figure 1 the IP address of node A. For RFC 3474, the L. Ong et al - Expires May 2004 4 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 Sender_Template contains the sender of the local tunnel, i.e., in Figure 1 the address of Node X at the X-Y interface. For interworking purposes, the node receiving the RFC 3473 message must map the Sender_Template address into the Source TNA sub-object of the GENERALIZED_UNI object from 3476, which carries the corresponding information in RFC 3474/3476. At the egress interface, the egress node uses the Source TNA to regenerate the Sender_Template tunnel sender address. 4.3 Response Messages The inverse mapping is required for messages sent from the tunnel endpoint back to the tunnel source, before the corresponding message is sent across the RFC 3473 interface to the end-to-end tunnel source. 4.4 Other Objects Other objects are unchanged in their significance between RFC 3473 and RFC 3474. 5. Procedures for 3474-3473 Interworking 5.1 Addressing One significant difference between RFC 3474 and RFC 3473 is in the use of identifiers or address objects. RFC 3474 creates a separate client interface address using the TNA (Transport Network-Assigned Address), which is a globally unique identifier that may use Ipv4, Ipv6 or NSAP formats. It should be noted that a common application for RFC 3474 may be for the access of systems that do not support IP addressing. In this case, the end-to-end tunnel source/endpoint may use non-IP addresses that cannot be supported by RFC 3473 objects. RFC 3474-3473 interworking would get around this issue by carrying the actual tunnel source/endpoint identifiers in a separate object and using IP format identifiers within the 3473 domain. 5.2 Interworking of Session Object The ingress node (i.e., node X of Figure 3) maps the Destination TNA sub-object found in the received GENERALIZED_UNI object into the IP address of the local tunnel endpoint within the 3473 domain, i.e., node Z of L. Ong et al - Expires May 2004 5 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 Figure 3. This is then used in the RFC 3473 Session object sent to other nodes within the 3473 domain. The GENERALIZED_UNI object is otherwise passed unchanged across the 3473 domain. It is passed transparently at nodes that support RFC 3473 only. The egress RFC 3473 node (i.e., node Z of Figure 3) then uses the Destination TNA sub-object to determine the destination client interface. 5.3 Interworking of the Sender_Template The ingress node is itself the local tunnel source within the 3473 domain, and therefore puts its own IP address in the RFC 3473 Sender_Template object. 5.4 Other Objects Other objects may be received at the 3474/3473 interface, esp. the Call_ID and Call_OPS objects defined in RFC 3474. These are passed transparently across the 3473 domain. 6. Evolution Considerations If the additional requirements that generated RFC 3474 are accepted to be requirements that 3473 networks must also support, interworking can be simplified by incorporating protocol extensions from RFC 3474 that provide needed functions, e.g., the Call_ID object, rather than attempting to duplicate these functions in alternative ways. 7. Informative References RFC 3209 RSVP-TE RFC 3473 RSVP-TE Extensions for GMPLS RFC 3474 RSVP-TE Usage and Extensions for ASON RFC 3476 LDP and RSVP-TE Extensions for Optical UNI Signaling ITU-T Recommendation G.7713.2, "Distributed Call and Connection Management: Signalling Mechanism Using GMPLS RSVP-TE" ITU-T Recommendation G.8080, "Architecture for the automatically switched optical network (ASON)" 8. Acknowledgements The authors would like to thank Erning Ye, Zhi-Wei Lin, Nic Larkin, Saikrishna Kotha and Manohar Ellanti for their comments and suggestions. L. Ong et al - Expires May 2004 5 draft-ong-ccamp-3473-3474-iw-00.txt November 2003 9. Author's Addresses L. Ong J. Sadler Ciena Tellabs 5965 Silver Creek Valley Rd 1415 W. Diehl Road San Jose, CA 95138 Naperville, IL 60563 lyong@ciena.com jonathan.sadler@tellabs.com E. Varma D. Pendarakis Lucent IBM Research 101 Crawfords Corner Rd 30 Saw Mill River Rd Holmdel, NJ 07733 Hawthorne, NY 10532 evarma@lucent.com dimitris@us.ibm.com Expires May 2004 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.