--- 1/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt 2006-02-04 22:56:36.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt 2006-02-04 22:56:36.000000000 +0100 @@ -1,71 +1,82 @@ -CCAMP Working Group J. Drake (Calient) +CCAMP Working Group J. Drake (Boeing) Internet Draft D. Papadimitriou (Alcatel) Proposed Category: Standard Track A. Farrel (Old Dog Consulting) D. Brungard (ATT) Z. Ali (Cisco) A. Ayyangar (Juniper) H. Ould-Brahim (Nortel) D. Fedyk (Nortel) -Expiration Date: January 2005 July 2004 +Expiration Date: August 2005 February 2005 Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) - draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt + draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. 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 + 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. + This Internet-Draft will expire on August 22, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + Abstract This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document + +D.Papadimitriou et al. - Expires August 2005 1 "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON)." In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in this document are applicable to any environment (including multi-area) and for any type of interface: - -D.Papadimitriou et al. - Expires January 2005 1 packet, layer-2, time-division multiplexed, lambda or fiber switching. 1. Table of Content Abstract ......................................................... 1 - 1. Table of Content .............................................. 3 + 1. Table of Content .............................................. 2 2. Conventions used in this document ............................. 3 3. Introduction .................................................. 3 3.1 Comparison with Previous Work ................................ 4 3.2 Applicability ................................................ 5 3.2.1 Network-Network Interface (I-NNI and E-NNI) ................ 6 3.2.2 User-Network Interface (UNI) ............................... 8 4. Fulfilling ASON Requirements for GMPLS Signaling .............. 8 4.1 Soft Permanent Connection (SPC) .............................. 8 4.2 Call/Connection Separation .................................. 8 4.3 Call Segments ................................................ 9 @@ -87,88 +98,86 @@ 6.1.3 Short Call ID Encoding .................................... 13 6.2 LINK_CAPABILITY Object ...................................... 14 6.3 Revised Message Format ...................................... 14 6.3.1 Notify Message ............................................ 15 6.4 ADMIN_STATUS Object ......................................... 15 7. Procedures in Support of Call and Connections ................ 16 7.1 Call/Connection Setup Procedures ............................ 16 7.2 Independent Call Setup ...................................... 17 7.2.1 Accepting Independent Call Setup .......................... 18 7.2.2 Rejecting Independent Call Setup .......................... 19 + +D.Papadimitriou et al. - Expires August 2005 2 7.3 Adding a Connection to a Call ............................... 19 7.3.1 Adding a Reverse Direction Connection to a Call ........... 20 7.4 Simultaneous Call/Connection Setup .......................... 20 7.4.1 Accepting Simultaneous Call/Connection Setup .............. 20 7.4.2 Rejecting Simultaneous Call/Connection Setup .............. 21 7.5 Call-Free Connection Setup .................................. 21 7.6 Call Collision .............................................. 21 7.7 Call/Connection Teardown .................................... 22 7.7.1 Removal of a Connection from a Call ....................... 22 7.7.2 Removal of the Last Connection from a Call ................ 23 7.7.3 Teardown of an "Empty" Call ............................... 23 - -D.Papadimitriou et al. - Expires July 2004 2 7.7.4 Teardown of a Call with Existing Connections .............. 23 7.7.5 Teardown of a Call from the Egress ........................ 23 7.8 Control Plane Survivability ................................. 24 8. Applicability of Call and Connection Procedures .............. 25 8.1 Network-initiated Calls ..................................... 25 8.2 User-initiated Calls ........................................ 25 8.3 External Call Managers ...................................... 26 8.3.1 Call Segments ............................................. 26 9. Non-support of Call ID ....................................... 26 9.1 Non-support by External Call Managers ....................... 26 9.2 Non-support by Transit Nodes ................................ 27 9.3 Non-support by Egress Nodes ................................. 27 10. Security Considerations ..................................... 28 10.1 Call and Connection Security Considerations ................ 28 11. IANA Considerations ......................................... 28 12. Acknowledgements ............................................ 29 - 13. Intellectual Property Considerations ........................ 29 - 14. References .................................................. 29 - 14.1 Normative References ....................................... 30 - 14.2 Informative References ..................................... 30 - 15. Author's Addresses .......................................... 31 + 13. References .................................................. 29 + 13.1 Normative References ....................................... 30 + 13.2 Informative References ..................................... 30 + 14. Author's Addresses .......................................... 31 Appendix 1. Analysis of G.7713.2 against GMPLS RSVP-TE Signaling - Requirements in Support of ASON.................................. 33 + Requirements in Support of ASON.................................. 32 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 [RFC2119]. In addition, the reader is assumed to be familiar with the - terminology used in [RFC3471] and [RFC3473]. + terminology used in [RFC3471], [RFC3473] and [RFC3945]. 3. Introduction This document describes how GMPLS RSVP-TE signaling [RFC3473] can be used and extended in support of Automatically Optical Switched Networks (ASON) as specified in the ITU-T G.8080 recommendation [G.8080]. Note, however, that the mechanisms that it describes and references have a larger scope than the one described in this document. +D.Papadimitriou et al. - Expires August 2005 3 [ASON-REQ] identifies the requirements to be covered by the extensions to the GMPLS signaling protocols to support the capabilities of an ASON network. The following are expected from the GMPLS protocol suite to realize the needed ASON functionality: a) support for soft permanent connection functionality b) support for call and connection separation c) support for call segments d) support for extended restart capabilities during control plane failures - -D.Papadimitriou et al. - Expires July 2004 3 e) support for extended label association f) support for crankback capability. This document is aligned with the [RSVP-CHANGE] process, which requires evaluation of existing protocol functionality for achieving the requested functionality and justification for any requested changes or new extensions. In this context, the following summarizes the evaluation made: 1. Signaling across the internal network-network interface (I-NNI) @@ -198,32 +207,31 @@ in [G.7713]. While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key differences from the problem statement in [ASON-REQ] and the solution it provides. These differences result from the development of a fuller and clearer set of requirements in [G.8080] after the time that [G.7713.2] was published and [ASON-REQ] considerations for compatibility aspects with GMPLS [RFC3473]. These differences are enumerated below and detailed in Appendix 1. +D.Papadimitriou et al. - Expires August 2005 4 1. As described in [G.8080], there are various models and multiple methods of achieving connections across multiple domains. [G.7713.2] is similar to a cooperative connection model between domains, that is, there is no overall coordination, and it uses point-to-point external NNI (E-NNI) signaling between inter- domain border controllers (i.e. single-hop LSP). Additionally, it requires address resolution at both border controllers regardless of the address space used. Recent enhancements to [G.8080] include end-to-end network capabilities based on flexible (end- to-end) path selection to support optimal route selection i.e. - -D.Papadimitriou et al. - Expires July 2004 4 source-based re-routing and crankback. To provide for these enhancements and future capabilities (e.g., VPNs), [ASON-REQ] is based on an inter-domain model using an end- to-end call model, modeling multiple domains as one virtual network, and optional one-time (ingress) address resolution (optional, if multiple address families are needed). Note that this model is the same model used by [RFC3471], [RFC3473] and [GMPLS-OVERLAY]. @@ -253,32 +261,32 @@ 5. [G.7713.2] does not support call segment signaling mechanisms, as required in [G.8080] and [G.7713]. 6. [G.7713.2] defines control plane restart capabilities that are incompatible with those described in [RFC3473]. 7. [G.7713.2] does not support crankback signaling mechanisms [GMPLS-CRANK], as required in [G.8080] and [G.7713]. +D.Papadimitriou et al. - Expires August 2005 5 + 3.2 Applicability The requirements placed on the signaling plane of an optical network to support the capabilities of an Automatically Switched Optical Network (see [ASON-REQ]) apply at both the network-network interface (NNI) and the user-network interface (UNI). Some extensions to the core signaling features (see [RFC3473]) are required in support of some of the ASON requirements. [GMPLS-OVERLAY] defines a common set of standard procedures at the user-network - -D.Papadimitriou et al. - Expires July 2004 5 interface (UNI). Other documents referenced in specific subsections of this document define specific protocol extensions in support of specific ASON requirements. 3.2.1 Network-Network Interface (I-NNI and E-NNI) At the NNI, the ingress and egress core nodes play a full part in the GMPLS network from a signaling point of view. Applicability of GMPLS RSVP-TE signaling at the I-NNI is implicitly detailed in [RFC3471] and [RFC3473]. Routing information is fully or partially distributed @@ -309,85 +317,86 @@ its Node ID, or by one or more un/numbered TE links that interconnect core-nodes. A core node need only to know (and track) the interface addresses and/or Node IDs of client nodes to which incoming messages are directed. Links may be either numbered or unnumbered. Further, links may be bundled or unbundled. See [BUNDLE] and [RFC3477], respectively. (IF_ID) RSVP_HOP object processing at E-NNI boundaries follows the rules defined in [RFC3473]. +D.Papadimitriou et al. - Expires August 2005 6 2. ERO Processing An ingress core node MAY receive and potentially reject a Path message that contains an ERO. Such behavior is controlled by (hopefully consistent) configuration. If an ingress core node rejects a Path message due to the presence of an ERO it SHOULD return a PathErr message with an error code of "Unknown object class" toward the sender. This causes the path setup to fail. -D.Papadimitriou et al. - Expires July 2004 6 Further an ingress core node MAY accept EROs which include a sequence of []. This is to support explicit label control on the egress core node interface. Incoming EROs may also include a combination of the latter with sequence of loose ingress core node addresses and/or AS numbers. If an ingress core node rejects a Path message due to the presence of an ERO not of the permitted format it SHOULD return a PathErr message with an error code of Bad Explicit Route Object as defined in [RFC3209]. - Path Message without ERO: when an ingress core node receives a Path message from an egress core node that contains no ERO, it MUST - calculate a route to the destination and include that route in a ERO, - before forwarding the PATH message. One exception would be if the - egress core node were also adjacent to this core node. If no route - can be found, the ingress core node SHOULD return a PathErr message - with an Error code and value of 24,5 - "No route available toward - destination". + calculate a route to the destination and include that route in a + ERO, before forwarding the PATH message. One exception would be if + the egress core node were also adjacent to this core node. If no + route can be found, the ingress core node SHOULD return a PathErr + message with an Error code and value of 24,5 - "No route available + toward destination". - Path Message with ERO: when an ingress core node receives a Path message from an egress core node that contains an ERO, the ingress core node SHOULD verify the route against its topology database - before forwarding the PATH message. If the route is not viable, then - a PathErr message with an error code and value of 24,5 - "No route - available toward destination" should be returned. + before forwarding the PATH message. If the route is not viable, + then a PathErr message with an error code and value of 24,5 - "No + route available toward destination" should be returned. 3. RRO Processing An egress or an ingress core node MAY include an RRO and MAY remove the RRO from the received Path message before forwarding it. Further an egress or an ingress core node MAY remove the RRO from a Resv message before forwarding it. Such behavior is controlled by (hopefully consistent) configuration. Further an ingress core node MAY edit the RRO in a Resv message such that it includes only the subobjects from the egress core node through the ingress core node of a neighboring E-NNI. This is to allow the ingress core node to be aware of the selected link and labels on the far end of the connection traversing this network. 4. Notification An ingress core node MAY include a NOTIFY_REQUEST object in both the Path and Resv messages it forwards. An ingress node MAY remove the NOTIFY_REQUEST object from the Path and Resv message before + +D.Papadimitriou et al. - Expires August 2005 7 forwarding it. An egress node MAY remove the NOTIFY_REQUEST object from the Path and Resv message before forwarding it. Core nodes may send Notification messages to ingress/egress core nodes, which have included the NOTIFY_REQUEST object. Note: the use of the Notify message for independent Call setup as defined in this document extends the one specified in [RFC-3473]. 3.2.2 User-Network Interface (UNI) -D.Papadimitriou et al. - Expires July 2004 7 At the UNI, the ingress and/or the egress nodes are not full players in the GMPLS network. Signaling information may be filtered and substituted by the network. This process is described in [GMPLS- OVERLAY]. Routing information leaked to the ingress/egress nodes is very limited. The ingress node may initiate an LSP setup/teardown request to the network using standard GMPLS procedures. The modifications to behavior described in [GMPLS-OVERLAY] apply to the nodes within the network (in particular, the network edge nodes) and not ingress or @@ -418,30 +427,30 @@ LSP setup) - Support of virtual concatenation with diverse path component LSPs - Multiple LSP association with a single call (note aspects related to recovery are detailed in [GMPLS-FUNCT] and [GMPLS-E2E]) - Facilitate control plane operations by allowing operational status change of the associated LSP. +D.Papadimitriou et al. - Expires August 2005 8 Procedures and protocol extensions to support Call setup, and the association of Calls with Connections are described in sections 5 and onwards of this document. 4.3 Call Segments Call segments capabilities MUST be supported by both independent call setup and simultaneous call/connection setup. -D.Papadimitriou et al. - Expires July 2004 8 Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support call segments are described in sections 8.4.1 of this document. 4.4 Control Plane Restart Capabilities Restart capabilities are provided by GMPLS RSVP-TE signaling in case of control plane failure including nodal and control channel faults. The handling of node and control channels faults is described in [RFC3473] Section 9. No additional RSVP mechanisms or objects are @@ -472,30 +481,31 @@ Crankback mechanisms for (GMPLS) RSVP-TE signaling are covered in a dedicated companion document [GMPLS-CRANK]. That document is intended to fulfill all the corresponding ASON requirements as well as satisfying any other crankback needs. 4.7 Additional Error Codes Error codes corresponding to the mechanisms defined in this document are specified along each section and summarized in Section 11. +D.Papadimitriou et al. - Expires August 2005 9 + 5. Concepts and Terms The concept of a Call and a Connection are discussed in the ASON architecture [G.8080]. This section is not intended as a substitute for that document, but is a brief summary of the key terms and concepts. 5.1 What is a Call? -D.Papadimitriou et al. - Expires July 2004 9 A Call is an agreement between endpoints possibly in cooperation with the nodes that provide access to the network. Call setup may include capability exchange, policy, authorization and security. A Call is used to facilitate and manage a set of Connections that provide end to end data services. While Connections require state to be maintained at nodes along the data path within the network, Calls do not involve the participation of transit nodes except to forward the Call management requests as transparent messages. @@ -525,29 +535,30 @@ - LSP IDs are unique within the context of a Tunnel. Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent call establishment. Throughout the remainder of this document, the terms LSP and Tunnel are used interchangeably with the term Connection. The case of a Tunnel that is supported by more than one LSP is covered implicitly. +D.Papadimitriou et al. - Expires August 2005 10 + 5.3 Exchanging Access Link Capabilities It is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the egress node. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities. -D.Papadimitriou et al. - Expires July 2004 10 In particular, this may be used to achieve end-to-end spectral routing attribute negotiation for signal quality negotiation (such as BER) in photonic environments where network edges are signal regeneration capable. Similarly, it may be used to provide end-to-end spatial routing attribute negotiation in multi-area routing environments, in particular, when TE links have been bundled based on technology specific attributes. Call setup may provide a suitable mechanism to exchange information for this purpose, although several other possibilities exist. @@ -579,30 +590,30 @@ defined that provide this function. 5.3.3 Utilizing Call Setup When IGP and EGP solutions are not available at the UNI, there is still a requirement to have, at the local edge nodes, the knowledge of the remote edge link capabilities. The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted. + +D.Papadimitriou et al. - Expires August 2005 11 The LINK CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [GMPLS-RTG]). 6. Protocol Extensions for Calls and Connections This section describes the protocol extensions needed in support of Call identification and management of Calls and Connections. - -D.Papadimitriou et al. - Expires July 2004 11 Procedures for the use of these protocol extensions are described in section 7. 6.1 Call Identification As soon as the concept of a call is introduced, it is necessary to support some means of identifying the call. This becomes particularly important when calls and connections are separated and connections must contain some reference to the call. @@ -634,30 +645,30 @@ this field MAY be the object of further formatting depending on the naming convention(s). However, [RFC3209] defines the "Session Name" field as a Null padded display string, and that any formatting conventions for the Call ID must be limited to this scope. 6.1.2 Short Form Call Identification The connections (LSPs) associated with a call need to carry a reference to the call - the Call ID. Each LSP MAY carry the full long Call ID in the "Session Name" of the SESSION ATTRIBUTE object to + +D.Papadimitriou et al. - Expires August 2005 12 achieve this purpose. However, existing (and future) implementations may need to place other strings in this field (in particular, the field is currently intended to provide the Session Name). To allow for this possibility a new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs. The new field is a 16-bit identifier (unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the - -D.Papadimitriou et al. - Expires July 2004 12 Sender_Address) that MUST be exchanged during Call initialization and is used on all subsequent LSP setups that are associated with the Call. This identifier is known as the short Call ID and is encoded as described in Section 6.1.3. When relevant, the Call Id MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies. This does not generate any backward compatibility issue since the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt. In the unlikely case of short Call_ID exhaustion, local node policy @@ -689,28 +700,27 @@ IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209]) Call_ID: 16 bits A 16-bit identifier used in the SESSION object that remains constant over the life of the call. The Call_ID value MUST be set to zero when there is no corresponding call. Tunnel ID: 16 bits (see [RFC3209]) +D.Papadimitriou et al. - Expires August 2005 13 Extended Tunnel ID: 32 bits/128 bits (see [RFC3209]) 6.2 LINK_CAPABILITY object The LINK CAPABILITY object is introduced to support link capability exchange during Call setup. This optional object includes the bundled - -D.Papadimitriou et al. - Expires July 2004 13 link local capabilities of the call initiating node (or terminating node) indicated by the source address of the Notify message. The Class Number is selected so that the nodes that do not recognize this object drop it silently. That is, the top bit is set and the next bit is clear. This object has the following format: Class-Num = TBA (form 10bbbbbb), C_Type = 1 @@ -741,31 +751,32 @@ Note: future revisions of this document may extend the above list. This object MAY also be used to exchange more than one bundled link capability. In this case, the following ordering MUST be followed: one identifier subobject (Type 1, 2 or 4) MUST be inserted before any capability subobject (Type 64 or 65) to which it refers. 6.3 Revised Message Formats - One message (the Notify message) is enhanced to support Call - establishment and teardown of Calls that operate independent of LSPs. - See section 7 for a description of the procedures. + The Notify message is enhanced (and referred thereby to as an + unsolicited Notify message) to support Call establishment and + +D.Papadimitriou et al. - Expires August 2005 14 + teardown of Calls that operate independent of LSPs. See section 7 for + a description of the procedures. 6.3.1 Notify Message The Notify message is modified in support of Call establishment by the optional addition of the LINK CAPABILTY object. Further, the SESSION ATTRIBUTE object is added to the sequence to - -D.Papadimitriou et al. - Expires July 2004 14 carry the long Call ID. The presence of the SESSION ATTIBUTE object MAY be used to distinguish a Notify message used for Call management. The MAY be used to setup simultaneously multiple Calls. The format of the Notify Message is as follows: ::= [ ] [[ | ]...] [ ] @@ -798,28 +809,28 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit - see [RFC3471] Testing (T): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471] Deletion in progress (D): 1 bit - see [RFC3471] +D.Papadimitriou et al. - Expires August 2005 15 Call Management (C): 1 bit This bit is set when the message is being used to control and manage a Call. The procedures for the use of the C bit are described in section 7. -D.Papadimitriou et al. - Expires July 2004 15 Note that the use of the C bit may appear as redundant since Call setup can be distinguished by the presence of the SESSION ATTRIBUTE object in a Notify message or an non-zero short Call ID value in a Path message. However, in the case of lost messages and node restart, this further distinction is useful to distinguish Path messages that set up Calls from Path messages that belong to calls. 7. Procedures in Support of Calls and Connections 7.1 Call/Connection Setup Procedures @@ -850,30 +861,30 @@ - A Connection may be established without any reference to a Call. This encompasses the previous LSP setup procedure. Note that a Call MAY NOT be imposed upon a Connection that is already established. To do so would require changing the short Call Id in the SESSION OBJECT of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications. +D.Papadimitriou et al. - Expires August 2005 16 Call and Connection teardown procedures are described later in Section 7.7. 7.2 Independent Call Setup It is possible to set up a Call before, and independent of, LSP setup. A Call setup without LSPs MUST follow the procedure described in this section. -D.Papadimitriou et al. - Expires July 2004 16 Prior to the LSP establishment, Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call and hence only once for the set of LSPs associated with a Call. The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination @@ -904,30 +915,30 @@ the Sender_Address from the SENDER TEMPLATE object (see below). Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent call establishment. The Tunnel_ID of the SESSION object is not relevant for this procedure and SHOULD be set to zero. The Extended_Tunnel_ID of the SESSION object is not relevant for this procedure and MAY be set to zero or to an address of the ingress node. - The SESSION ATTRIBUTE object contains priority flags. Currently no use of these flags is envisioned, however, future work may + +D.Papadimitriou et al. - Expires August 2005 17 identify value is assigning priorities to Calls; accordingly the Priority fields MAY be set to non-zero values. None of the Flags in the SESSION ATTRIBUTE object are relevant to this process and this field SHOULD be set to zero. The Session Name field is used to carry the long Call Id as described in Section 6. - The SENDER_TEMPLATE object includes as Sender Address any of the call initiating (ingress) node's IPv4/IPv6 routable addresses. The - -D.Papadimitriou et al. - Expires July 2004 17 LSP_ID is not relevant and SHOULD be set to zero. - The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt and SHOULD be set to zero when sent. Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message. @@ -958,28 +969,29 @@ - The responder removes any LINK CAPABLITY object that was received and MAY insert a LINK CAPABILITY object that describes its own access link. - The ADMIN STATUS object is sent with only the C bit set. All other bits MUST be set to zero. The responder MAY use the Message ID object to ensure reliable delivery of the response. If no Message ID Acknowledgement is received after the configured number of retries, the responder should + +D.Papadimitriou et al. - Expires August 2005 18 continue to assume that the Call was successfully established. Call liveliness procedures are covered in section 7.8. 7.2.2 Rejecting Independent Call Setup Call setup may fail or be rejected. -D.Papadimitriou et al. - Expires July 2004 18 If the Notify message can not be delivered, no Message ID acknowledgement will be received by the sender. In the event that the sender has retransmitted the Notify message a configurable number of times without receiving a Message ID Acknowledgement (as described in [RFC3473]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see section 7.7). It is also possible that a Message ID Acknowledgement is received but no Call response Notify message is received. In this case, the initiator MAY re-send the Call setup request a configurable number of @@ -1012,28 +1024,28 @@ LSPs for different Calls can be distinguished because the Call ID is unique within the context of the source address (in the SENDER TEMPLATE object) and the destination address (in the SESSION object). Ingress and egress nodes may group together LSPs associated with the same call and process them as a group according to implementation requirements. Transit nodes need not be aware of the association of multiple LSPs with the same Call. +D.Papadimitriou et al. - Expires August 2005 19 The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call and the "Session Name" MAY still be used to distinguish between virtually concatenated LSPs belonging to the same Call. Thus, there is not necessarily a one-to- one mapping between the "Session Name" of an LSP and the short Call_ID. -D.Papadimitriou et al. - Expires July 2004 19 The C bit of the ADMIN STATUS object MUST NOT be set on LSP messages. 7.3.1 Adding a Reverse Direction LSP to a Call Note that once a Call has been established it is symmetric. That is, either end of the Call may add LSPs to the Call. Special care is needed when managing LSPs in the reverse direction since the addresses in the SESSION and SENDER TEMPLATE are reversed. However, since the short Call ID is unique in the context of a given @@ -1066,30 +1078,29 @@ the SESSION object as described above. The reserved value of zero is used when the LSP is being set up with no association to a Call. 7.4.1 Accepting Simultaneous Call/Connection Setup A Path message that requests simultaneous Call and Connection setup is subject to local authorization and policy procedures applicable to Call establishment in addition to the standard procedures associated with LSP setup described in [RFC3473]. +D.Papadimitriou et al. - Expires August 2005 20 If the Call and LSP setup is to be accepted, a Resv message is returned. The Resv message MUST carry the ADMIN STATUS object with the R bit clear and the C bit set. Other bits may be set or cleared according to the requirements of LSP setup. The D bit MUST NOT be set. The Call ID MUST be reflected in the SESSION object. -D.Papadimitriou et al. - Expires July 2004 20 - 7.4.2 Rejecting Simultaneous Call/Connection Setup The Path message that is sent to set up a Call and Connection simultaneously may fail or be rejected. Failures may include all those reasons described in [RFC3473]. Additionally, policy and authorization reasons specifically associated with Call setup may cause the Path message to be rejected. The PathErr message is issued to signal such failures and no new @@ -1121,29 +1132,29 @@ a response, itself receives a Call setup request with the same long Call ID and matching source/destination addresses it should process as follows. - If its source address is numerically greater than the remote source address, it MUST discard the received message and continue to wait for a response to its setup request. - If its source address is numerically smaller than the remote source address, it MUST discard state associated with the Call + +D.Papadimitriou et al. - Expires August 2005 21 setup that it initiated, and MUST respond to the received Call setup. In the second case, special processing is necessary if simultaneous Call and Connection establishment was being used. Firstly, the node that is discarding the Call that it initiated MUST send a PathTear message to remove state from transit nodes. Secondly, this node may - -D.Papadimitriou et al. - Expires July 2004 21 want to hold onto the Connection request and establish an LSP once the Call is in place since only the Call that it was trying to establish has been set up by the destination - the Connection may still be required. A further possibility for contention arises when Call IDs are assigned by a pair of nodes for two distinct Calls that are set up simultaneously. In this event a node receives a Call setup request carrying a short Call ID that matches one that it previously sent for the same address pair. The following processing MUST be followed. @@ -1176,29 +1187,29 @@ described in [RFC3473]. 7.7.1 Removal of a Connection from a Call An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3743]. No special procedures are required. Note that it is not possible to remove an LSP from a Call without deleting the LSP. It is not valid to change the short Call ID from + +D.Papadimitriou et al. - Expires August 2005 22 non-zero to zero since this involves a change to the SESSION object, which is not allowed. 7.7.2 Removal of the Last Connection from a Call When the last LSP associated with a Call is deleted the question arises as to what happens to the Call. Since a Call may exist - -D.Papadimitriou et al. - Expires July 2004 22 independently of Connections, it is not always acceptable to say that the removal of the last LSP from a Call removes the Call. If the Call was set up using independent Call setup (that is, using a Notify message) the removal of the last LSP does not remove the Call and the procedures described in the next section MUST be used to delete the Call. If the Call was set up using simultaneous Call/Connection establishment, the removal of the last LSP does remove the Call and @@ -1231,29 +1242,30 @@ rejected with the Error Code "Call Management" (TBD) and Error Value "Connection Still Exists" (TBD). 7.7.5 Teardown of a Call from the Egress Since Calls are symmetric they may be torn down from the ingress or egress. If the Call was established using simultaneous Call/Connection setup the removal of the last LSP deletes the Call. This, regardless of + +D.Papadimitriou et al. - Expires August 2005 23 whether the LSP is torn down by using a PathTear message (for an egress-initiated LSP) or by using a PathErr message with the Path_State_Removed flag set (for an ingress-initiated LSP). If the Call was established using independent Call/Connection setup and the Call is "empty" it may be deleted by the egress sending a Notify message just as described above. -D.Papadimitriou et al. - Expires July 2004 23 Note that there is still a possibility that both ends of a Call initiate a simultaneous Call deletion. In this case, the Notify message acting as teardown request is interpreted by its recipient as a teardown response. Since the Notify messages carry the R bit in the ADMIN STATUS object, they are responded to anyway. If a teardown request Notify message is received for an unknown Call ID it is, nevertheless, responded to in the affirmative. 7.8 Control Plane Survivability @@ -1286,28 +1298,27 @@ A node that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time. Failure to receive a refresh Notify request has no specific meaning. If it receives no response to a refresh Notify request (including no Message ID Acknowledgement) a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call. +D.Papadimitriou et al. - Expires August 2005 24 In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call - -D.Papadimitriou et al. - Expires July 2004 24 setup never materializes the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr) with the error code "Call Management" (TBD) and Error Value "Unknown Call ID" (TBD). 8. Applicability of Call and Connection Procedures This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This @@ -1340,29 +1351,29 @@ allow the inclusion of the LINK CAPABILITY object. Further, the first node in the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first network node which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is + +D.Papadimitriou et al. - Expires August 2005 25 known from the SESSION object). Similarly, the first network node may be responsible for generating the long and short Call IDs for inclusion in Path messages that have the C bit set in the ADMIN STATUS object. Further, when used in an overlay context, the first core node is allowed (see [GMPLS-OVERLAY]) to replace the Session Name assigned by - -D.Papadimitriou et al. - Expires July 2004 25 the ingress node and passed in the Path message. In the case of Call management, the first network node MUST in addition 1) be aware that the name it inserts MUST be a long Call ID and 2) replace the long Call ID when it returns the Resv message to the ingress node. 8.3 External Call Managers Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but @@ -1395,29 +1406,28 @@ 9.1 Non-Support by External Call Managers It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager including the first network node, if that node does not support Call setup. A node that receives an unexpected Call setup request will fall into one of the following categories. +D.Papadimitriou et al. - Expires August 2005 26 - Node does not support RSVP. The message will fail to be delivered or responded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up. - Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then - -D.Papadimitriou et al. - Expires July 2004 26 give up. - Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails the Notify message may be discarded in which case the initiator will retry and then give up, alternatively a parse error may be generated and returned in a Notify message which will indicate to the initiator that Call management is not set up. @@ -1449,29 +1459,29 @@ It is unlikely that an attempt will be made to set up a Call to remote node that does not support Calls. If the egress node does not support Call management through the Notify message it will react (as described in Section 9.1) in the same way as an external Call manager. If the egress node does not support the use of the C bit in the ADMIN STATUS object or the Call ID in the SESSION object, it MAY respond + +D.Papadimitriou et al. - Expires August 2005 27 with the fields zeroed in which case the initiator will know that the Call setup has failed. On the other hand, it is possible that the egress will respond copying the fields from the Path message without understanding or acting on the fields. In this case the initiator will believe that the Call has been set up when it has not. This occurrence can be - -D.Papadimitriou et al. - Expires July 2004 27 prevented using the independent Call setup procedures, but is, in any case, detected when a Notify message is sent to keep the Call alive. 10. Security Considerations Please refer to each of the referenced documents for a description of the security considerations applicable to the features that they provide. 10.1 Call and Connection Security Considerations @@ -1504,86 +1514,53 @@ C-Type = 1 (TE Link Capabilities) New RSVP Error Codes and Error Values are introduced o Error Codes: - Call Management (value TBA) o Error Values: +D.Papadimitriou et al. - Expires August 2005 28 - Call Management/Call ID Contention (value TBA) - Call Management/Connections still Exist (value TBA) - Call Management/Unknown Call ID (value TBA) 12. Acknowledgements -D.Papadimitriou et al. - Expires July 2004 28 The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash and Kireeti Kompella for their very useful input and comments to this document. -13. Intellectual Property Considerations - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -13.1 IPR Disclosure Acknowledgement - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - -14. References +13. References -14.1 Normative References +13.1 Normative References [ASON-REQ] D.Papadimitriou, et al., "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON)," Work in progress, Oct'03. [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling in MPLS Traffic Engineering," Work in Progress. [GMPLS-CRANK] A.Farrel (Editor) et al., "Crankback Routing Extensions for MPLS Signaling," Work in progress, - Jun'03. + Oct'04. [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., "Generalized MPLS Recovery Functional - -D.Papadimitriou et al. - Expires July 2004 29 - Specification," Work in Progress, Sep'03. + Specification," Work in Progress, Oct'04. [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the - Overlay Model," Work in Progress, Apr'04. + Overlay Model," Work in Progress, Oct'04. [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing Extensions in Support of Generalized MPLS," Work in Progress, Oct'03. [LMP] J.P.Lang (Editor) et al. "Link Management Protocol (LMP) - Version 1," Work in progress, Oct'03. [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, Oct'96. @@ -1591,20 +1568,21 @@ [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, Mar'97. [RFC2205] R.Braden et al., "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification," RFC 2205, Sep'97 [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," RFC 2402, Nov'98. +D.Papadimitriou et al. - Expires August 2005 29 [RFC2406] S.Kent and R.Atkinson, "IP Encapsulating Payload (ESP)," RFC 2406, Nov'98. [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, Dec'01. [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - Signaling Functional Description," RFC 3471, Jan'03. [RFC3473] L.Berger (Editor) et al., "Generalized MPLS @@ -1613,92 +1591,95 @@ [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)," RFC 3477, Jan'03. [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. + [RFC3945] E.Mannie, Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October + 2004. + [RSVP-CHANGE] K.Kompella and J.P.Lang, "Procedures for Modifying RSVP," Work in Progress, draft-kompella-rsvp-change- 01.txt, Jun'03. -14.2 Informative References +13.2 Informative References -D.Papadimitriou et al. - Expires July 2004 30 [RFC3474] Z.Lin (Editor), " Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)," RFC 3474, Mar'03. [RFC3476] B.Rajagopalan (Editor), "Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling," RFC 3476, Mar'03. [G.7713] ITU-T, "Distributed Call and Connection Management," Recommendation G.7713/Y.1304, Nov'01. [G.7713.2] ITU-T, "DCM Signalling Mechanisms Using GMPLS RSVP- TE," Recommendation G.7713.2, Jan'03. +D.Papadimitriou et al. - Expires August 2005 30 [G.8080] ITU-T, "Architecture for the Automatically Switched Optical Network (ASON)," Recommendation G.8080/ Y.1304, Nov'01 (and Revision, Jan'03). -15. Author's Addresses +14. Author's Addresses Dimitri Papadimitriou (Alcatel) Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be - John Drake (Calient) - 5853 Rue Ferrari, - San Jose, CA 95138, USA - Phone: +1 408 972-3720 - EMail: jdrake@calient.net + John Drake + Boeing Satellite Systems + 2300 East Imperial Highway + El Segundo, CA 90245 + EMail: John.E.Drake2@boeing.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com -D.Papadimitriou et al. - Expires July 2004 31 Arthi Ayyangar (Juniper) 1194 N.Mathilda Ave Sunnyvale, CA 94089, USA EMail: arthi@juniper.net Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA - Email: dwfedyk@nortelnetworks.com + Email: dwfedyk@nortel.com -D.Papadimitriou et al. - Expires July 2004 32 +D.Papadimitriou et al. - Expires August 2005 31 Appendix 1: Analysis of G.7713.2 against GMPLS RSVP-TE Signaling Requirements in support of ASON Informational RFC [RFC3474] (and [RFC3476]) documents the code points for the signaling extensions defined in [G.7713.2] to meet the requirements of ASON Distributed Call and Connection Management (DCM) as specified in [G.7713]. While [G.7713.2] make use of GMPLS RSVP-TE signaling, there are key @@ -1740,21 +1721,21 @@ Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION that remains constant over the life of the tunnel. Normally set -D.Papadimitriou et al. - Expires July 2004 33 +D.Papadimitriou et al. - Expires August 2005 32 to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IP address here as a globally unique identifier. IPv4 (or IPv6) tunnel sender address IPv4 (or IPv6) address for a sender node LSP ID @@ -1795,21 +1776,21 @@ A ----- B -- ... -- I ----- J -- .. -- M ----- N -- ... -- Y ----- Z At node I, the GMPLS compliant [RFC3473] Path message would include the following information in the IP header, the SESSION and SENDER_TEMPLATE objects: Source IP address (Header): Node I IP Controller Address Dest. IP address (Header): Node J IP Controller Address Tunnel End-point Address: Routable Node Z IP Address -D.Papadimitriou et al. - Expires July 2004 34 +D.Papadimitriou et al. - Expires August 2005 33 Tunnel ID: 16 bit (selected by the sender) Extended Tunnel ID: optionally set to Node A IP Address Tunnel Sender Address: Routable Node A IP Address LSP ID: 16 bit (selected by the sender) At node I, the [G.7713.2] Path message would include the following: Source IP address (Header): Node I IP Controller Address Dest. IP address (Header): Node J IP Controller Address Tunnel End-point Address: Node J IP Controller Address @@ -1829,49 +1810,49 @@ 1. For a given connection, the [G.7713.2] point-to-point signaling interface leads to a sequence of at least N different identifications of the same connection when crossing N signaling interfaces (due to the setup and maintenance of N distinct LSP tunnels). 2. The information included in the RSVP message header and in the SESSION/SENDER_TEMPLATE objects, is redundant in [G.7713.2]. 3. [G.7713.2] allows only for single-hop LSP tunnels and mandates - the processing of a new object (i.e. the GENERALIZED_UNI object) + the processing of a new object, i.e. the GENERALIZED_UNI object, for the definition of the source and destination connection end- point addresses (A and Z in the above example). - 4. The processing of the signaling Path message (in particular, the - EXPLICIT ROUTE object) mandates the processing of the + 4. The processing of the signaling Path message, in particular, the + EXPLICIT ROUTE object (ERO), mandates the processing of the GENERALIZED_UNI object at E-NNI reference points and at UNI reference points, for the connection end-point addresses (A and Z, in the above example). 5. Connection end-point addresses A and Z are allowed by [G.7713.2] to be from different address spaces (for instance, IPv4 source and IPv6 destination or an IPv4 source and NSAP destination). - Address resolution, management of addresses (e.g. for - uniqueness), and impact evaluation on processing performance, are + Address resolution, management of addresses, e.g., for + uniqueness, and impact evaluation on processing performance, are not provided in these RFCs (considered out of scope). Note: the [ASON-REQ] addressing model of supporting only IP addressing is aligned with ITU-T G.7713.1 (PNNI) which only uses NSAP addresses, multiple address families are not supported. -D.Papadimitriou et al. - Expires July 2004 35 +D.Papadimitriou et al. - Expires August 2005 34 6. [G.7713.2] defines an incompatible and redundant addressing mechanism with [RFC3473] to support IPv4, IPv6, and NSAP addresses. [RFC3473] is part of a GMPLS protocol suite based on use of IPv4 and IPv6 addresses. The use of NSAP addresses with [RFC3473] is supported by established procedures defined in [RFC1884] "IPv6 Addressing Architecture", and only requiring - support by border entities (e.g., DNS). Any other support for + support by border entities, e.g., DNS. Any other support for NSAP addressing is redundant with IETF supported procedures. [G.7713.2] provides no guidance on the operational aspects resulting from this modified procedure which uses a non-standard object, the GENERALIZED_UNI object, to support. Use of the GENERALIZED_UNI object requires every entity to support multi- address family resolution, e.g., for ERO processing, and in the case of multi-region path setup. Requiring multi-address family resolution at all entities severely impacts performance, scaling, and introduces unnecessary complexity for operations. This limitation is well recognized, e.g. [G.7713.2] use in demos has @@ -1904,21 +1885,21 @@ the network. [G.7713.2] mandates the use of the GENERALIZED_UNI subobjects (End- point Connection Address and SPC_LABEL) to support SPC capability. Thus, in addition to suffering from the problem described in Section 4, it mandates the processing of an object where it should never occur. This is because SPCs do not assume the existence of a UNI signaling interface between the source and the destination user-to- network interface. Note also that the SPC_LABEL as defined in -D.Papadimitriou et al. - Expires July 2004 36 +D.Papadimitriou et al. - Expires August 2005 35 [G.7713.2] does not comply with the generalized label C-Type definition of [RFC3473] meaning that an implementation adhering to [RFC3473] cannot be the "soft" side of the connection. This requires the mandatory usage of dedicated connection end-point addresses by the ingress and egress nodes for SPC capability support. The existing RECORD_ROUTE object and its capabilities get corrupted by the use of the dedicated end-point address subobjects falling outside of the corresponding EXPLICIT ROUTE object. @@ -1959,21 +1940,21 @@ Thus, with the introduction of the call concept, it is necessary to support a means of identifying the call. This becomes important when calls and connections are separated and a connection must contain a reference to its associated call. The following identification enables this hierarchy: - Call IDs are unique within the context of the pair of addresses that are the source and destination of the call. - Tunnel IDs are unique within the context of the Session (that is the destination of the Tunnel) and Tunnel IDs may be unique within -D.Papadimitriou et al. - Expires July 2004 37 +D.Papadimitriou et al. - Expires August 2005 36 the context of a Call. - LSP IDs are unique within the context of a Tunnel. For this purpose, [G.7713.2] introduces two new objects: a CALL_ID and a CALL_OPS object to be used in the Path, Resv, PathTear, PathErr, and Notify messages (note: additional requirements for ResvErr and ResvTear messages' support are not addressed). The CALL_OPS object is also referred to as a "call capability" object, since it specifies the capability of the call. These objects belongs to the range 224-255 defined as "RSVP will silently ignore, but @@ -2014,21 +1995,21 @@ - Does not allow for call support *independently* of the initiating/ terminating nodes (the CALL_ID is attached to the ingress node) thus restricting the flexibility in terms of call identifiers. - Requires the inclusion of the CALL ID and CALL OPS objects in PathErr messages that may be generated at transit nodes, which do not implement [G.7713.2] and so do not support these objects. 4. Call Segments -D.Papadimitriou et al. - Expires July 2004 38 +D.Papadimitriou et al. - Expires August 2005 37 [G.7713.2] cannot, by definition, support call segments signaling mechanisms, as required in [G.8080] and [G.7713], since [G.7713.2] does not support full call/connection separation. 5. Control Plane Restart Capabilities Restart capabilities are provided by GMPLS RSVP-TE signaling in case of control plane failure including nodal and control channel faults. The handling of node and control channels faults is described in [RFC3473] Section 9. No additional RSVP mechanisms or objects are @@ -2068,33 +2049,64 @@ the security considerations applicable to the features that they provide. Note that although [RFC3474] is an informational RFC it does document new protocol elements and functional behavior and as such introduces new security considerations. In particular, the ability to place authentication and policy details within the context of Call establishment may strengthen the options for security and may weaken the security of subsequent Connection establishment. Also the -D.Papadimitriou et al. - Expires July 2004 39 +D.Papadimitriou et al. - Expires August 2005 38 potential to subvert accidentally or deliberately a soft permanent connection by establishing the soft part of the connection from a false remote node needs to be examined. However, [RFC3474] has a minimal security considerations section. -D.Papadimitriou et al. - Expires July 2004 40 +D.Papadimitriou et al. - Expires August 2005 39 -Full Copyright Statement +Intellectual Property Statement - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78 and - except as set forth therein, the authors retain all their rights. + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. -D.Papadimitriou et al. - Expires July 2004 41 +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +D.Papadimitriou et al. - Expires August 2005 40