CCAMP Working Group L. Ong (Ciena) Internet Draft J. Sadler (Tellabs) Category: Informational E. Varma (Lucent) D. Pendarakis (IBM Research) S. Shew (Nortel) Expiration Date: Sept 2004 Feb 2004 Interworking of RFC 3473 and 3474 draft-ong-ccamp-3473-3474-iw-01.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 ITU-T Recommendation [G.7713.2]. The ITU-T Recommendation uses codepoints allocated via associated RFCs [RFC 3474, RFC 3476]. Two basic interworking scenarios are discussed. G.7713.2 was intended to use the same basic mechanisms as and to be backwards compatible to RFC 3473 when using RFC 3473 as an Interior Network-Network Interface (I-NNI) protocol. Some objects are required to be carried transparently, but are allocated codepoints from the range for transparent forwarding of unrecognized objects in accordance with existing RSVP. 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 1 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 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 ITU-T Recommendation [G.7713.2]. G.7713.2 codepoint allocation is documented in [RFC 3474] (GMPLS RSVP-TE Usage and Extensions for ASON) signaling. 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.1 ASON Model It is impossible to understand the extensions defined in G.7713.2 without also understanding the underlying ASON network model. The ASON model allows a carrier network to consist of multiple domains, consistent with the architecture of transport networks defined in ITU-T Recommendation G.805 [G.805]. Client devices may attach to the network at the User-Network Interface (UNI) reference point, while peer-level domains meet at the Network-Network Interface (NNI) reference point. Each transport layer is considered separately as a layer network. A layer network can be recursively partitioned into subnetworks, which partitioning is based on network policy. Subnetworks are defined to be completely contained within higher level subnetworks. Transport networks typically do not have a single backbone, and regulatory concerns may affect the partitioning of the network and the routing of calls across the network. Each subnetwork or domain may utilize a different protocol or even different control architecture (e.g., one domain may use distributed control while another peer domain may use centralized control). The control protocols used across the NNI reference point are required to be independent of the protocol used within the domains. Figure 1 shows an abstract representation of an ASON network model. L. Ong et al 2 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 ---------- /---------\ //// \\\\ //// \\\\ -- | +--+ +--+ | | +--+ +--+ | -- | |:::::::| |------| |===============| |---| |::::::::::| | -- | +--+ +--+ | | +--+ +--+ | -- \\\\ ||/// \\\\ //// ---------|| \---------/ Domain 1 || Domain 2 :: UNI || == E-NNI /-++--------\ -- I-NNI //// || \\\\ | +--+ +--+ | -- | | |---| |:::::::::::| | | +--+ +--+ | -- \\\\ //// \-----------/ Domain 3 Figure 1: ASON Network Example 3.2 Use of Call vs. Connection Concept The ASON model employs the concept of a call to which zero or more connections may be associated. In signalling protocols, it is useful to distinguish between attributes that are call related versus connection related because connection handling entities in the network generally do not have to understand or deal with call objects. The three new objects that RFC3474 and RFC3476 introduce are all call objects. Having distinguished between call and connection objects, TLVs should be designed so that they do not mix call and connection objects. This makes it easier for entities that only deal with connections as just mentioned. 3.3 Analysis of G.7713.2 Extensions to RFC 3473 Given the requirements of ASON on call and connection control, which are documented in more detail in ITU-T Recommendation G.7713 [G.7713], a limited number of extensions were made to the base RSVP-TE signaling defined in RFC 3473. This section analyzes the impact of these extensions. 3.3.1 Overall Extent of Changes Messages: No new messages were defined in G.7713.2. Use of some messages was considered not necessary as discussed in section 3.3.2. Objects: Two new objects are used in G.7713.2, the Gen_UNI object defined in the OIF UNI, and a Call_ID object. L. Ong et al 3 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 In addition, the Call_OPS object is defined in an Appendix of G.7713.2. (3 out of approximately 20-25 objects used in GMPLS) C-Types: New C-Types were added for UNI and ENNI Session, plus 5 new C-Types within G_UNI and 2 within Call_ID. (11 out of approximately 80 or so used in GMPLS) Procedures: The main changes to procedures was the elimination of ResvErr and ResvTear, discussed below in section 3.3.2. New object and C-Type codepoints are allocated in [RFC 3474, 3476]. 3.3.2 ResvTear/RevErr Concern has been raised as to whether a problem is introduced because the ResvTear and ResvErr messages are not used in G.7713.2 (sometimes called the "fatal flaw"). The procedures supported by ResvTear and ResvErr were felt to be inconsistent with the desired behavior of connection establishment in transport networks, as they result in a requirement for exchange of multiple messages in order to teardown the connection in case of failure during connection setup. ResvTear and ResvErr allow the exchange of error information without teardown of the connection, however no case needing this function has been identified in the call/connection control requirements for ASON [G.7713]. If such a case is identified in the future the associated procedures can be added as an extension to G.7713.2. It should be noted that no protocol violation occurs if a ResvTear or ResvErr generates PathTear in the opposite direction, as the protocol allows for this case. In particular, ResvTear and ResvErr can be used within a domain, so long as the interworking point at the edge of the domain supports the appropriate interworking behavior. 3.3.3 Use of Non-standard objects As discussed above, the new objects defined for G.7713.2 are the G_UNI, Call_OPS and Call_ID, all of which are transparent except at the terminating tunnel endpoint, based on the codepoint range assigned for the objects. L. Ong et al 4 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 3.3.4 Duplication of standard objects/procedures As far as is known, the only duplication of procedures may occur with SPC services, where RFC 3473 is not clear about support of specification of an egress label. This issue is now being addressed via a supplementary document. However, the use of an SPC_Label subobject within the G_UNI object has some advantages over the use of the ERO for this purpose, esp. that ERO may not always be allowed across an administrative boundary, whereas G_UNI is carried transparently. As a result, use of an SPC_Label subobject may avoid some error cases for the SPC service. In addition, SPC_Label unambiguously identifies the type of service being supported for the call, whereas an egress label specification within the ERO could be a result of either an originating UNI request or an SPC service request. 3.3.5 New Session objects Concern has been raised that the incorporation of new Session object C-Types for UNI and ENNI causes a backwards compatibility issue with RFC 3473. Actually the reverse is true: the use of specific C-Types for UNI and ENNI allow the receiving entity to unambiguously distinguish when signaling received is for a G.7713.2 UNI or ENNI interface. Such signaling received at a RFC 3473 interface will be rejected due to the unrecognized Session C-Type. When used as an I-NNI protocol, G.7713.2 uses the same Session object format and C-Type as RFC 3473 and functions in the same way, i.e., the Session object value is not changed as it traverses INNI reference points. 3.3.6 Terminology confusion Some terminology confusion has been suggested and should be clarified by further discussion. 3.3.7 Addressing Concern has been raised that the introduction of the TNA subobjects in G_UNI will require every system to be able to process different types of addresses and address formats. L. Ong et al 5 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 However, the TNA subobject, as a content of the G_UNI object, is only processed at tunnel endpoints, and the choice of address formats supported will be an option of the carrier. A similar situation occurs in IP with the understanding of exterior addresses. Only boundary nodes are required to support routing based on such addresses, not all nodes. It was noted that Ipv6 includes a mechanism for support of NSAP format addresses. This could potentially be used to eliminate one sub-type of the TNA, noting that this would not affect the actual processing of addresses required, only the manner of carrying them. 3.3.8 SPC Services Discussed in section 3.2.4 above. 3.3.9 Session paradigm Concern has been raised that the use of the multi-session approach to RSVP-TE connection control violates basic paradigms of RSVP. In the modeling of the Session object, ITU-T have treated this as a connection-related identifier. Using the separation of call and connection control, an end- to-end call consists of potentially multiple concatenated call segments. In the same way, each call segment may have associated connection segments, hence the Session object would contain the destination endpoint for that connection segment, rather than the call endpoint. While this may be incompatible with some implementations of RSVP, the necessary information to identify a connection is still present using the combination of TNA and Session object. A possible mechanism to support implementations that rely solely on the Session object is to use a unique value of the extended tunnel ID within the Session object in order to distinguish between connection segments, as described in [RFC 3209]. L. Ong et al 6 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 3.3.10 Backwards Compatibility Concerns have been raised as to the backwards compatibility of G.7713.2 to RFC 3473. It should first be pointed out that backwards compatibility to RFC 3473 was not a primary goal of the work on ASON signaling, although it may be a more important goal for work in IETF. G.7713.2 I-NNI can be deployed in a network of nodes supporting RFC 3473 without requiring some interworking. However, G.7713.2 UNI or E-NNI deliberately cannot. This being said, G.7713.2 does support the three principles of backwards compatibility identified in [RSVP-ASON]: 1) pre-ASON connections supported unchanged - this is true, as G.7713.2 is only used at the UNI or E-NNI boundaries for a domain relying on RFC 3473 as its I-NNI. 2) transit switches do not need to be upgraded to support new functionality - this is true, as transit switches are only required to pass the G_UNI and Call_ID objects transparently, which will naturally occur based on the codepoint range. 3) a message received at a non-capable switch will be rejected - for the UNI and ENNI interfaces this is true due to the use of distinct C-Types for UNI and ENNI Session objects. Since these C-Types are not recognized by a switch that does not support a G.7713.2-based interface, the switch will reject the message, with no way to process the unrecognized Session object type. 4. Interworking Specifications 4.1 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 2 and 3. L. Ong et al 7 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 /----------\ //// \\\\ +---+ |+---+ +---+ +---+ +---+ | A |---------+-| X |---| Y |---| Z |+--------| C | +---+ |+---+ +---+ +---+ +---+ RFC 3473 \\\\ //// RFC 3473 Overlay \----------/ Overlay RFC 3474 I-NNI Figure 2: 3473-3474 Interworking Case 1 +---+ +----+ +----+ +---+ | A |-----------| N1 |-----------| N2 |----------| C | +---+ +----+ +----+ +---+ RFC 3473 RFC 3474 RFC 3473 Overlay E-NNI Overlay Figure 3: 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. 4.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 4 below. In this case, RFC 3474 is supported across an RFC 3473 network or domain. L. Ong et al 8 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 ------------- //// \\\\ // \\ +---+ +---+ +---+ +---+ +---+ | A |----------+| X |------| Y |------| Z |+----------| C | +---+ +---+ +---+ +---+ +---+ \\ // RFC 3474 \\\\ //// RFC 3474 UNI/NNI ------------- UNI/NNI RFC 3473 I-NNI Figure 4: 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. 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. L. Ong et al 9 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 5. Procedures for 3473-3474 Interworking 5.1 Interworking of Session Object For RFC 3473, the Session Object contains the tunnel endpoint address, i.e., in Figure 2 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 2 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. 5.2 Interworking of Sender_Template For RFC 3473, the Sender_Template contains the tunnel sender, i.e., in Figure 2 the IP address of node A. For RFC 3474, the 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. 5.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. 5.4 Other Objects Other objects are unchanged in their significance between RFC 3473 and RFC 3474. L. Ong et al 10 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 6. Procedures for 3474-3473 Interworking 6.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. 6.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 Figure 4. 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. 6.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. 6.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. L. Ong et al 11 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 7. 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. 8. 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 [G.7713.2] ITU-T Recommendation G.7713.2, "Distributed Call and Connection Management: Signalling Mechanism Using GMPLS RSVP-TE" [G.8080] ITU-T Recommendation G.8080, "Architecture for the automatically switched optical network (ASON)" [G.805] ITU-T Recommendation G.805, "Generic functional architecture of transport networks" [G.7713] ITU-T Recommendation G.7713/Y.1704 (2001), "Distributed Call and Connection Management (DCM)" [UNI] OIF Implementation Agreement OIF-UNI-01.0, "User Network Interface (UNI) 1.0 Signaling Specification", October 2001 9. Acknowledgements The authors would like to thank Erning Ye, Zhi-Wei Lin, Nic Larkin, Saikrishna Kotha and Manohar Ellanti for their comments and suggestions. 10. 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 S. Shew PO Box 3511 Station C Ottawa ON K1Y 2H7 sdshew@nortelnetworks.com L. Ong et al 12 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 Appendix A Analysis of RFC 3474 Backwards Compatibility Draft-ietf-ccamp-gmpls-ason-reqts-04.txt identifies three basic requirements for backwards compatibility: 1)in a mixed network of nodes, it must be possible to set up conventional connections. Use of any extensions must not perturb existing conventional connections. 2) when transit nodes are in the path of a call/connection, extensions must allow transit nodes to participate by passing information unmodified. 3) when a transit node or egress node must support a new function but does not, extensions should be capable of being rejected in a way that is not detrimental to the network as a whole. The extensions defined in RFC 3474/ITU-T G.7713.2 satisfy the three conditions as can be seen in the following: A.1 Conventional Connections In the model of RFC 3474/ITU G.7713.2, RFC 3474 may be used to support an E-NNI interface or UNI interface to a network of RFC 3473 nodes. Within the network of RFC 3473 nodes, conventional connections may be set up without change. Connections between a source RFC 3474 node and destination RFC 3474 node do not perturb existing connections. Border nodes supporting an RFC 3474 E-NNI or UNI interface may continue to support origination, termination or transit of connections between RFC 3473 source and destination nodes as a matter of node implementation and carrier deployment. A.2 Transit Nodes As discussed in the interworking procedures above, transit nodes are not required to implement extensions in order to support connections between RFC 3474 source and destination as the extension objects are in the range that are passed transparently by transit nodes. The extension objects defined in RFC 3474 are only processed at the source and destination endpoints of a particular LSP tunnel. A.3 Rejection Signaling using G.7713.2/RFC 3474 will utilize the UNI or ENNI Session Object C-Type when used at the borders of a domain that is strictly RFC 3473-based. Signaling messages received incorrectly at an RFC 3473 interface will be rejected due to the Session object format being unrecognized. L. Ong et al 13 draft-ong-ccamp-3473-3474-iw-01.txt February 2004 Expires September 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.