CCAMP Working Group S. Belotti Internet Draft D. Papadimitriou Document: draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Alcatel N. Larkin Data Connection Z. Lin Lucent D. Pendarakis Tellium Expiration Date: December 2002 June 2002 Generalized MPLS (GMPLS) RSVP-TE Usage and Extensions For Automatically Switched Optical Network (ASON) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 1 GMPLS RSVP-TE for ASON June 2002 introduces additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T in support of ITU's ASON standardization effort. 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 [2]. 3. Introduction The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs), and for setting up connections with monitoring capabilities. However, there are certain capabilities that are needed to support applications as described in ITU-T ASTN (Automatically Switched Transport Networks) Requirements [G807], ASON (Automatically Switched Optical Networks) Architecture and Requirements [G8080], Distributed Connection Management [G7713] and Automatic Discovery [G7714]. These include generic capabilities such as call and connection separation and more specific capabilities such as support of soft permanent connections. This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It introduces extensions to GMPLS RSVP-TE to support the capabilities as specified in the above referenced documents. Specifically, this document assumes the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [GMPLS-SIG], [GMPLS-RSVPTE], [GMPLS-SDHSONET], [GMPLS-SDHSONETEXT], [GMPLS-OTN] and [OIF-UNI1] as the basis for the protocols, with extensions in addition to those already defined by these referenced documents. 3.1 Relationship of ASON to GMPLS The Automatic Switched Optical Network (ASON) architecture (as specified by various ITU-T Recommendations) describes the application Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 2 GMPLS RSVP-TE for ASON June 2002 of an automated control plane for supporting connection management services for the transport/data plane. The ASON architecture is described based on the functions supported, and the interactions of various functions with each other. These include specification of the call and connection controllers, as well as link resource managers (for a detailed description see [G8080]). The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments (e.g., inter-carrier, intra-carrier), supporting different interface models between networks (e.g., Interior NNI (I- NNI), Exterior NNI (E-NNI), UNI). The modeling framework provided in ITU-T may be used as a foundation for developing and/or extending the protocols to support specific functions of ASON. A full description of the relationship of ASON to GMPLS may be found in [IPO-RQTS] in addition to more details concerning some of the terms used in this document. Automation of the connection management services may be realized in a number of ways, including the use of the suite of GMPLS protocols to support distributed connection management. 3.2 Applicability of GMPLS to ASON Most of the applicability statements regarding how the GMPLS suite of protocols may be applied to the ASON architecture may be found in [IPO-RQTS], which includes a summary of the key requirements from the ITU-T ASON Recommendations, as well as a discussion of the applicability of the GMPLS protocol suite. In addition to the above referenced document, [ASSESS] provides a detailed assessment of requirements against the GMPLS RSVP-TE protocol. In general, as currently defined the GMPLS RSVP-TE protocol is applicable to the ASON model. The purpose of this document is to define the additional methods and objects (i.e. the delta) to fulfill some of the specific requirements of the ASON model. 3.3 Soft Permanent Connection (SPC): A Synopsis An SPC is a combination of a permanent connection at the source user- to-network side, a permanent connection at the destination user-to- network side, and a switched connection within the network. Establishment of the switched connection within the network is typically initiated by an EMS or NMS, which communicates with the ingress node and instructs it to set-up the connection using the distributed signaling protocol (in this case GMPLS RSVP-TE signaling Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 3 GMPLS RSVP-TE for ASON June 2002 is used to set up the connection between ingress and egress network node). For the SPC, the communication method between the EMS/NMS and the ingress node is not the subject of standardization and is, thus, beyond the scope of this document. The user end-to-end connection is thus created by associating the incoming interface of the ingress network node with the switched connection within the network and the outgoing interface of the egress network node. An SPC connection is illustrated in the following Figure, which shows user's node A connected to a provider's node B via link #1, user's node Z connected to a provider's node Y via link #3, and a (abstract) link #2 connecting provider's node B and node Y. +---+ +---+ +---+ +---+ | A |--1--| B |-----2-//------| Y |--3--| Z | +---+ +---+ +---+ +---+ In this instance, the connection on link #1 and link #3 are both provisioned, i.e., they are set up by means beyond the distributed control plane. In contrast, the connection over link #2 is set up using the distributed control plane. Thus the SPC is composed of the concatenation of link #1, #2 and #3. 3.4 Call: A Synopsis A call may be simply described as: "An association between endpoints that supports an instance of a service" [G8080]. Thus it provides an abstract relationship between two users, where this relationship describes (or verifies) the extent to which the users are willing to offer (or accept) service to each other. A call therefore does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which future connections may be made. A property of a call is its ability to contain multiple connections, where each connection may be of different types and where each connection may exist independently of other connections within the call, i.e., each connection is setup and released with separate Path/Resv messages. For example, a call may contain a mix of basic connection, virtual concatenated connections and contiguous concatenated connections (see [GMPLS-SDHSONET] for corresponding connection signaling extensions). Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 4 GMPLS RSVP-TE for ASON June 2002 The concept of the call is needed in order to allow for a better flexibility in how users set up connections and how service providers offer services to users. In essence, a call allows: - Support for a general case of virtual concatenation where each connection can travel on different diverse paths - Better upgrading strategy for service provider control plane operation, where a call control (service provisioning) may be separate from switches and connections (where the connection control may reside) - Verification and authentication of a call (with both network call controller as well as destination user) prior to connection, which may result in less wasted resources - General treatment of multiple connections which may be associated for the purpose of protection and restoration; for example a pair of primary and backup connections may belong to the same call. There is a relationship of the CALL_ID to the CIRCUIT_ID as presented in [LBM-TDM]; however note that a call may contain multiple circuits, and as such has wider scope than the circuit ID. Consequently, a call (referenced by a CALL_ID) may include more than one circuit (referenced by CIRCUIT_ID), i.e., a call can encompass several contiguously concatenated connections and virtually concatenated connections. 4. Support for Soft Permanent Connection In the scope of ASON, to support soft permanent connection (SPC) for RSVP-TE, one new sub-type for the GENERALIZED_UNI is defined. The GENERALIZED_UNI object is defined in [OIF-UNI1]. This new sub-type has the same format and structure as the EGRESS_LABEL (the sub-type is the suggested value for the new sub-object): - SPC_LABEL (Type=4, Sub-type=2 [TBA]) 5. Support for Call 5.1 Call Identifier and Call Capability 5.1.1 Call Identifier Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 5 GMPLS RSVP-TE for ASON June 2002 To identify a call, a new object is defined for RSVP-TE. The CALL_ID object carries the call identifier. The value is globally unique, and may be assigned by the call originator (the Class-num is the suggested value for the new object): CALL_ID (Class-num = 227 [TBA], C-type = 1) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (227)| C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call identifier | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the following C-types are defined: - C-type = 1: generic [Length*4-32]-bit identifier An example structure for the call identifier (to guarantee global uniqueness) is to concatenate the tuple (source address, destination address, local identifier) or (source address, local identifier) as the call identifier. As an example, the address may be 160-bit field. The minimum length of the call identifier is 4 octets. The value of the call identifier is assigned by the originating call controller. 5.1.2 Call Capability This document does not cover extensions to support the call capability. Such support may be provided in a separate draft. This document only provides extensions to support logical call and connection separation. 5.2 What Does Current GMPLS Provide The signaling mechanism defined in [RFC2961], [RFC3209] and [GMPLS- SIG] supports automatic connection management; however it does not provide capability to support the call model. A call may be viewed as a special purpose connection that requires a different subset of information to be carried by the messages. This information is Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 6 GMPLS RSVP-TE for ASON June 2002 targeted to the call controller for the purpose of setting up a call/connection association. 5.3 Support for Basic Call and Connection To support basic call capability, a call identifier is introduced to various message sets. This basic call capability helps introduce the call model; however, additional extensions may be needed to fully support the canonical call model. For example, in a global network, supporting a call model requires agreements on global naming and addressing structure used for call endpoints, as well as various call capability sets. Within the context of this document, every call (during steady state) may have one (or more) associated connections. A zero connection call is defined as a transient state, e.g., during a break-before-make restoration event. In the scope of ASON, to support a logical call and connection separation, a new call identifier is needed as described above. The new CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and Notify message. The new CALL_ID object (along with other objects associated with a call, e.g., GENERALIZED_UNI) is processed by the call controller, while other objects included in these messages are processed by the connection controller as described in [GMPLS- RSVPTE]. Processing of the CALL_ID (and related) object is described in this document. Note: unmodified message formats are not listed. 5.3.1 Modification to Path Message <Path Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <RSVP_HOP <TIME_VALUES [ <EXPLICIT_ROUTE ] <LABEL_REQUEST <CALL_ID [ <PROTECTION ] [ <LABEL_SET ... ] [ <SESSION_ATTRIBUTE ] Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 7 GMPLS RSVP-TE for ASON June 2002 [ <NOTIFY_REQUEST ] [ <ADMIN_STATUS ] [ <GENERALIZED_UNI ] [ <POLICY_DATA ... ] <sender descriptor The format of the sender descriptor for unidirectional LSPs is: <sender descriptor ::= <SENDER_TEMPLATE <SENDER_TSPEC <ADSPEC [ <RECORD_ROUTE ] [ <SUGGESTED_LABEL ] [ <RECOVERY_LABEL ] The format of the sender descriptor for bidirectional LSPs is: <sender descriptor ::= <SENDER_TEMPLATE <SENDER_TSPEC <ADSPEC [ <RECORD_ROUTE ] [ <SUGGESTED_LABEL ] [ <RECOVERY_LABEL ] <UPSTREAM_LABEL 5.3.2 Modification to Resv Message <Resv Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <RSVP_HOP <TIME_VALUES <CALL_ID [ <RESV_CONFIRM ] <SCOPE [ <NOTIFY_REQUEST ] [ <ADMIN_STATUS ] [ <POLICY_DATA ... ] <STYLE <flow descriptor list <flow descriptor list is not modified by this document. Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 8 GMPLS RSVP-TE for ASON June 2002 <flow descriptor list ::= <FF flow descriptor list | <SE flow descriptor <FF flow descriptor list ::= <FLOWSPEC <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] | <FF flow descriptor list <FF flow descriptor <FF flow descriptor ::= [ <FLOWSPEC ] <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] <SE flow descriptor ::= <FLOWSPEC <SE filter spec list <SE filter spec list ::= <SE filter spec | <SE filter spec list <SE filter spec <SE filter spec ::= <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] 5.3.3 Modification to PathTear Message <PathTear Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <RSVP_HOP <CALL_ID [ <sender descriptor ] <sender descriptor ::= (see earlier definition) 5.3.4 Modification to PathErr Message Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 9 GMPLS RSVP-TE for ASON June 2002 <PathErr Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <CALL_ID <ERROR_SPEC [ <ACCEPTABLE_LABEL_SET ] [ <POLICY_DATA ... ] <sender descriptor <sender descriptor ::= (see earlier definition) 5.3.5 Modification to Notify Message Note that this message may include sessions belonging to several calls. <Notify message ::= <Common Header [<INTEGRITY] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <ERROR_SPEC <notify session list <notify session list ::= [ <notify session list ] <upstream notify session | <downstream notify session <upstream notify session ::= <SESSION <CALL_ID [ <ADMIN_STATUS ] [<POLICY_DATA...] <sender descriptor <downstream notify session ::= <SESSION <CALL_ID [<POLICY_DATA...] <flow descriptor list descriptor Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 10 GMPLS RSVP-TE for ASON June 2002 6. Support For Behaviors during Control Plane Failures Various types of (combinations of) failures may occur within an automatically switched optical network. These failures may impact the control plane as well as the data plane. As described in [GMPLS-RSVP- TE], current GMPLS restart mechanisms allows support to handle all of these different scenarios, and thus no additional extensions are required. However, in the scope of the ASON model, several optional procedures may take place in order to support the behaviors (as per [G7713] and [IPO-RQTS]) within the control plane. - A control plane node should provide capability for persistent storage of call and connection state information. This capability allows each control plane node to recover the states of calls/connections after recovery from a signaling controller entity failure/reboot (or loss of local FSM state in memory). Note that although the restart mechanism allows neighbor control plane nodes to automatically recover (and thus infer) the states of calls/connections, this mechanism can be used for verification of neighbor states while the persistent storage provides the local recovery of lost state. In this case, per [GMPLS-RSVP-TE], if during the Hello synchronization the restarting node determines that a neighbor does not support state recovery, and the restarting node maintains its state on a per neighbor basis, the restarting node should immediately consider the Recovery as completed - A control plane node detecting a signaling channel failure should request the management system for further instructions during signaling channel failure, with a default control plane behavior to enter self-refresh (i.e. preservation) of the call/connection states. As an example, possible management system instructions may be to remain in self-refresh mode, or to release RSVP states of certain connections - A control plane node detecting that one (or more) connections cannot be re-synchronized with its neighbor (e.g., due to different states for the call/connection) should request the management system for further instructions on how to handle the non-synchronized connection. As an example, possible management system instructions may be to keep the current RSVP state for the connection. Specifics of the interactions between the control plane and management plane are beyond the scope of this document - A control plane node (after recovering from node failure) may lose information on forwarding adjacency. In this case the control plane node should request an external controller (e.g., the management system) for information to recover the forwarding Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 11 GMPLS RSVP-TE for ASON June 2002 adjacency information. Specifics of the interactions between the control plane and management plane are beyond the scope of this document 7. Support For Label Usage Labels are defined in GMPLS to provide information on the resources used for a particular connection. The labels may range from specifying a particular timeslot to a particular wavelength. In the context of the automatic switched optical network, the value of a label may not be consistently the same across a link. For example, the figure below illustrates the case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected across two non-GMPLS/ASON-enabled nodes (B and C), where these nodes are all SDH/SONET nodes providing, e.g., a VC-4 service. +-----+ +-----+ | | +---+ +---+ | | | A |---| B |---| C |---| Z | | | +---+ +---+ | | +-----+ +-----+ Labels have an associated structure imposed on them for local use based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is transmitted across an interface to its neighboring control plane node, the structure of the local label may be not significant to the neighbor node since the value used for the local label and the remote label may not necessarily be the same. This issue does not present a problem in a simple point-to-point connections between two control plane-enabled nodes where the timeslots are mapped 1:1 across the interface. However, in the scope of the ASON, once a non-GMPLS capable sub-network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots) label scoping becomes an issue. There is an implicit assumption that the non-control-plane connections already exist prior to any connection request and that, e.g., node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS-SONETSDH]) may be mapped onto node B's outgoing VC-4's timeslot #6 (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the request from node A with label=[1,0,0,0,0], the node Z's local label and the timeslot no longer corresponds to the received label and timeslot information. Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 12 GMPLS RSVP-TE for ASON June 2002 As such to support the general network case, the scope of the label value is considered local to a control plane node. A label association function can be used by the control plane node receiving a request to map the received (remote) label into a locally significant label. The information necessary to allow mapping from received label value to a locally significant label value may be derived in several ways: - Via manual provisioning of the association - Via discovery of the association Either method may be used. In the case of dynamic association, this implies that the discovery mechanism operates at the timeslot/label level. Note that in the simple case where two nodes are directly connected, no association may be necessary. In such instances, the label association function provides a one-to-one mapping of the received to local label values. 8. Security Considerations This draft introduces no new security considerations. 9. IANA Considerations There are multiple fields and values defined within this document. IANA is requested to administer assignment of these new values. All values should be allocated through an IETF Consensus action. This document makes suggestions on the assignments given below. 9.1 Assignment of New Messages No new messages are defined to support the functions discussed in this document. 9.2 Assignment of New Objects Three new objects are defined: - CALL_ID; this object should be assigned an object identifier of the form 11bbbbbb. A suggested value is 227 [TBA]. Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 13 GMPLS RSVP-TE for ASON June 2002 - CALL_OPS; this object should be assigned an object identifier of the form 11bbbbbb. A suggested value is 228 [TBA]. - GENERALIZED_UNI; this object is defined in [OIF-UNI1] with a class-num of the form 11bbbbbb. A suggested value is 229 [TBA]. 9.3 Assignment of New Sub-Objects (and Sub-types) One new sub-object is defined under the GENERALIZED_UNI object: - SPC_LABEL; this sub-object is part of the GENERALIZED_UNI object, as a sub-type of the EGRESS_LABEL sub-object. A suggested value is sub-type=2 [TBA]. 9.4 Assignment of New Error Code/Values No new error codes are required. The following new error values are defined, with the suggested values. Note that certain values were defined with the suggested values in [OIF-UNI1] and are included here for completeness. For error values that have already been assigned by IANA, then those assigned values take precedence over the suggested values below; otherwise the values below are suggested to be used for the error types as described. 02/100 [TBA]: unauthorized source 02/101 [TBA]: unauthorized destination 24/100 [TBA]: diversity not available 24/101 [TBA]: service level not available 24/102 [TBA]: invalid/unknown connection ID 24/103 [TBA]: no route available toward source 24/104 [TBA]: unacceptable interface ID 24/105 [TBA]: invalid/unknown call ID 24/106 [TBA]: invalid SPC interface ID/label 10. Acknowledgements The authors would like to thank Lyndon Ong, Greg Bernstein, and Osama Aboul-Magd for their comments and contributions to the draft. 11. References Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 14 GMPLS RSVP-TE for ASON June 2002 11.1 Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the Automatically Switched Optical Network (ASON), November 2001 [G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection Management (DCM), November 2001 [OIF-UNI1] OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling Specification [RFC2205] RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, September 1997 [RFC2961] RFC 2961, RSVP Refresh Overhead Reduction Extensions, April 2001 [RFC3209] RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels, December 2001 [GMPLS-SIG] P. Ashwood-Smith, Generalized MPLS - Signaling Functional Description, draft-ietf-mpls-generalized-signaling-08.txt, April 2002 [GMPLS-RSVPTE] P. Ashwood-Smith, Generalized MPLS Signaling - RSVP- TE Extensions, draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002 [GMPLS-SDHSONET] E. Mannie and D.Papadimitriou (Editors), GMPLS Extensions for SONET and SDH Control, draft-ietf-ccamp-gmpls-sonet- sdh-05.txt, June 2002 [GMPLS-OTN] D. Papadimitriou, GMPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709- 01.txt, June 2002 [LBM-TDM] E. Mannie, D.Papadimitriou et al., GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH, draft-mannie-ccamp-gmpls-lbm-tdm- 03.txt, May 2002 Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 15 GMPLS RSVP-TE for ASON June 2002 11.2 Informative References [G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched Transport Networks (ASTN), July 2001 [GMPLS-SDHSONETEXT] E. Mannie and D.Papadimitriou (Editors), GMPLS Extensions to Control Non-Standard SONET and SDH Features, draft- ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt, June 2002 [IPO-RQTS] O. Aboul-Magd, Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols, draft-ietf-ipo-ason-02.txt, March 2002 [ASSESS] ANSI T1X1.5/2002-064, Assessment of GMPLS RSVP-TE to Support ASON, April 2002 (ftp://ftp.t1.org/T1X1/X1.5/2x150640.doc) 12. Author's Addresses Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy Email: sergio.belotti@netit.alcatel.it Nic Larkin Data Connection 100 Church Street, Enfield Middlesex EN2 6BQ, UK Email: npl@dataconnection.com Zhi-Wei Lin Lucent 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: zwlin@lucent.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Email: Dimitri.Papadimitriou@alcatel.be Dimitrios Pendarakis Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 16 GMPLS RSVP-TE for ASON June 2002 Tellium 2 Crescent Place Oceanport, NJ 07757-0901 Email: dpendarakis@tellium.com Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 17 GMPLS RSVP-TE for ASON June 2002 Appendix I. Non-Normative Extensions for Supporting Complete Separation of Call and Connection This section describes the optional capability to support complete separation of call and connection. To support complete separation of call and connection, a call capability object is introduced. I.1 Call Capability A call capability is used to specify the capabilities supported for a call. For RSVP-TE a new CALL_OPS object is defined to be carried by the Path, Resv, PathTear, PathErr, and Notify message. The CALL_OPS object also serves to differentiate the messages to indicate a "call- only" call. In the case for logical separation of call and connection, the CALL_OPS object is not needed. The CALL_OPS object is defined as follows (the Class-num is the suggested value for the new object): CALL_OPS (Class-num = 228 [TBA], C-type = 1) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (228)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Call ops flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two flags are currently defined for the "call ops flag": 0x01: call without connection 0x02: synchronizing a call (for restart mechanism) I.2 Complete Separation of Call and Connection (RSVP-TE Extensions) A complete separation of call and connection implies that a call (during steady state) may have zero (or more) associated connections. A zero connection call is a steady state, e.g., simply setting up the user end-point relationship prior to connection setup. I.2.1 Modification to Path Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 18 GMPLS RSVP-TE for ASON June 2002 <Path Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <RSVP_HOP <TIME_VALUES [ <EXPLICIT_ROUTE ] <LABEL_REQUEST <CALL_OPS <CALL_ID [ <NOTIFY_REQUEST ] [ <ADMIN_STATUS ] [ <GENERALIZED_UNI ] [ <POLICY_DATA ... ] <sender descriptor The format of the sender description for unidirectional LSPs is: <sender descriptor ::= <SENDER_TEMPLATE <SENDER_TSPEC [ <RECORD_ROUTE ] The format of the sender description for bidirectional LSPs is: <sender descriptor ::= <SENDER_TEMPLATE <SENDER_TSPEC [ <RECORD_ROUTE ] <UPSTREAM_LABEL Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not required for a call; however these are mandatory objects. As such, processing of these objects for a call follows the following rules: - These objects are ignored on receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message. I.2.2 Modification to Resv <Resv Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 19 GMPLS RSVP-TE for ASON June 2002 [ <MESSAGE_ID ] <SESSION <RSVP_HOP <TIME_VALUES <CALL_OPS <CALL_ID [ <RESV_CONFIRM ] [ <NOTIFY_REQUEST ] [ <ADMIN_STATUS ] [ <POLICY_DATA ... ] <STYLE <flow descriptor list <flow descriptor list is not modified by this document. <flow descriptor list ::= <FF flow descriptor list | <SE flow descriptor <FF flow descriptor list ::= <FLOWSPEC <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] | <FF flow descriptor list <FF flow descriptor <FF flow descriptor ::= [ <FLOWSPEC ] <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] <SE flow descriptor ::= <FLOWSPEC <SE filter spec list <SE filter spec list ::= <SE filter spec | <SE filter spec list <SE filter spec <SE filter spec ::= <FILTER_SPEC <LABEL [ <RECORD_ROUTE ] Note that FILTER_SPEC and LABEL are not required for a call; however these are mandatory objects. As such, processing of these objects for a call follows the following rules: Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 20 GMPLS RSVP-TE for ASON June 2002 - These objects are ignored on receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message. I.2.3 Modification to PathTear <PathTear Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <RSVP_HOP <CALL_OPS <CALL_ID [ <sender descriptor ] <sender descriptor ::= (see earlier definition) I.2.4 Modification to PathErr <PathErr Message ::= <Common Header [ <INTEGRITY ] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <SESSION <CALL_OPS <CALL_ID <ERROR_SPEC [ <POLICY_DATA ... ] <sender descriptor I.2.5 Modification to Notify <Notify message ::= <Common Header [<INTEGRITY] [ [<MESSAGE_ID_ACK | <MESSAGE_ID_NACK] ... ] [ <MESSAGE_ID ] <ERROR_SPEC <notify session list Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 21 GMPLS RSVP-TE for ASON June 2002 <notify session list ::= [ <notify session list ] <upstream notify session | <downstream notify session <upstream notify session ::= <SESSION <CALL_ID [ <ADMIN_STATUS ] [<POLICY_DATA...] <sender descriptor <downstream notify session ::= <SESSION <CALL_ID [<POLICY_DATA...] <flow descriptor list descriptor Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 22 GMPLS RSVP-TE for ASON June 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). 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. Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 23
Datatracker
draft-lin-ccamp-gmpls-ason-rsvpte-00
Internet-Draft
