Internet Draft MPLS Working Group Zhi-Wei Lin, Lucent Internet Draft Technologies Expiration Date: May 2001 Hirokazu Ishimatsu, Japan Telecom Olivier Duroyon, Alcatel Jim Jones, Alcatel Curtis Brownmiller, Worldcom November 2000 Need for Aligning Signaling Parameters of Various Signaling Protocols draft-lin-mpls-sigalign-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. Abstract This draft attempts to map the generic parameters to those currently specified in CR-LDP, RSVP-TE, and the OIF UNI 1.0 specification, outlining the differences among the various proposed protocol parameters. This draft proposes that the list of parameters be aligned among the various protocols. Lin, et al 1 Parameter Alignment of Signaling Protocols November 2000 1. Introduction This draft attempts to map the generic parameters to those currently in CR-LDP, RSVP-TE, and the OIF UNI 1.0 specification, outlining the differences among the various proposed protocol parameters. This draft proposes that this list of parameters be aligned among the various protocols. 2. Parameters for UNI Signaling The following section provides a list of possible parameters that may be used in the UNI signaling protocol. These parameters provide the basis for connection operations. UNI signaling requests may be initiated by (a) A-end user, (b) a third-party signaling agent, or (c) by the Z-end NNI agent. Convention used in the following Tables: Italic text are those that (loosely) map one protocol's parameter to the generic parameter (e.g., source port ID maps into the service name) 2.1.1 UNI Create 2.1.1.1 UNI Create request parameters UNI Create Request Generic CR-LDP RSVP-TE (PATH OIF UNI 1.0 Comments parameters Message) Version ID Backwards compatibility ID Message ID Message ID FEC TLV Service name Generalized Label Request TLV Service name Generalized extension Label Request TLV A-end name Source Sender Source termination Template termination point TLV Object point address Service Label Source port ID name/service Set/Suggested name extension Label Service Source channel name/service ID name extension Lin, et al. Expires May 2001 2 Parameter Alignment of Signaling Protocols November 2000 Service Source name/service subchannel ID name extension Z-end name Destination Session Destination termination Object termination point TLV point address Egress Label Destination port ID Destination channel ID Destination subchannel ID A-end User Source User Session Source user group ID group ID TLV Attribute group ID Object Z-end user Destination Session Destination group ID user group ID Attribute user group ID TLV Object Lightpath ID Contract ID Contract ID TLV Session Contract ID Attribute Object Generalized Framing Label Request Object Generalized Bandwidth Label Request Object Transparency Generalized Transparency TLV Label Request Object Service Upstream Directionality name/service Label Object name extension Schedule- Lightpath duration schedule TLV Contract ID Service Level Session Service level Attribute Object Drop-side protection Protection mode Diversity TLV Session Diversity Attribute Object and Generalized Label Request Object Lin, et al. Expires May 2001 3 Parameter Alignment of Signaling Protocols November 2000 priority Contract ID Propagation Propagation Propagation delay Delay (TBD) delay Optional parameters Avoid name list Include name list Security FEC TLV: Additional information is required in order to establish the requirements for the FEC TLV. Within the ASON network, this parameter may not be appropriate. Destination port, channel, subchannel: To obtain this information, it is necessary that the requesting end have full knowledge of the port connectivity with all its potential connections. If this were not true, then destination specific information may not be specified by the UNI, instead only the particular Z-end name may be known to the A-end user. The service provider, during the course of setting up the user connection, determines the _best_ port, channel, subchannel to use to connect with the Z-end (via the service provider-to-user UNI request or as determined by the local resource management between the Z-end service provider and the Z-end user). Full knowledge of the destination information may be possible if the A-end and Z-end are within the same user domain; however, this is one of many possibilities, and thus it may not be appropriate to specify protocol targeted for this one application. Framing, bandwidth, transparency: These parameters provide information regarding the specific services being requested, and assumes a specific partitioning of the service category. Because the ASON network would provide a deterministic set of services, there is no reason for this particular partitioning. A simplified list of service types (as embedded within the service name or the generalized label request TLV) should be sufficient. For example, in RSVP, a generalized payload ID may be used to provide a list of all available services (e.g., STS-1, STS-3c, SONET line overhead transparent service at OC-48, etc.). Lightpath priority: This parameter provides priority of services and preemptibility information of the connections. Because this is an added feature, service provider input is needed to determine the usefulness of this parameter as well as to consider the implications of the complexities introduced into the network. Propagation delay: Information regarding ASON connection delay is provided to determine the propagation delay of a connection. However, given that the ASON network is circuit-based, and delay information is primarily due to light propagation, the variability Lin, et al. Expires May 2001 4 Parameter Alignment of Signaling Protocols November 2000 of the delay value for (potential) routes are small (e.g., a connection from San Francisco to New York may traverse different alternate routes, but the difference in propagation delay between these routes are likely small _ a 1200 km route introduces a propagation delay of approximately 6 ms; thus one path may exhibit 25 ms delay while an alternate path may exhibit 30 ms delay). This information may also be embedded within a contract ID, where users of the ASON network may specify extremal scenarios (e.g., whether to allow satellite links within their connection instead of specific delay values). Drop-side protection, protection mode, diversity: These information are expected to allow a user to influence the availability of a particular requested connection. However, the user should not have visibility to the service provider network, nor should the user have information regarding the type of protection/restoration being used within the service provider network. Specifying these detailed architecture/topology information in constraining the service provider route determination may not be appropriate. Instead information regarding the availability requirements of a requested connection may be more appropriate. This availability information is primarily provided as a differentiated class of service as embedded within the contract ID (e.g., bronze for best effort, silver for meshed restoration, platinum for 1+1 protection). For example, the service provider connection from A-end user to Z-end user traverses different subnetworks X, Y and Z, where subnetwork X is based on a ring topology, subnetwork Y is based on a mesh topology, and subnetwork Z is point-to-point. In this scenario, what may be specified in terms of the protection mode or diversity may not be appropriate. Additionally, consider two service providers M and N serving the same market with high earthquake rates. Service provider M provides duplicate nodes at each central office and encase its fibers in concrete conduits (possibly!), while service provider N provides only single node at each central office and lays aerial fiber. The reliability of these two networks will be drastically different. Therefore, what is important to a user should not be whether they have diversity or certain protection mode, but whether they can get certain level of reliability for those connections (availability metrics). Avoid name list, include name list: These information are lists of specific user-service provider agreed names that the user may use in constraining the service provider route determination. The lists do not provide topology or resource information. Service TLV, Source ID TLV, Generalized Label Request TLV: The required service characteristics information is spread among these various TLVs. for example, service TLV contains delay, diversity and bandwidth, source ID TLV contains port/channel/subchannel ID, label Lin, et al. Expires May 2001 5 Parameter Alignment of Signaling Protocols November 2000 request TLV contains link protection, encoding, lightpath payload. How do these relate to the characteristics of the service? Suggested Label TLV, Label Set TLV: How are these parameters used in the UNI message? Is this the same information as the lightpath ID? If it is used to bound the value of the lightpath ID, then it implies the user has knowledge of the service provider name space used for lightpath ID, and thus in order to make suggested labels, must also have knowledge of the semantics of the name space. Is this correct? Are service providers willing to share this information with the user? Shouldn't the lightpath ID assignment be delegated to the service provider who is setting up the connection? Is there a good reason for the user to control (determine) the lightpath ID? 2.1.1.2 UNI Create response parameters UNI Create Response Generic CR-LDP RSVP-TE (RESV Comments message) OIF UNI 1.0 parameters Version ID Backwards compatibility ID Message ID Message ID FEC TLV Generalized Label TLV Generalized Label TLV User connection Lightpath ID Session Lightpath ID Object ID Source Session Source termination Object termination point TLV point address Source port ID Source channel ID Source subchannel ID Destination Session Destination termination Object termination point TLV point address Destination port ID Lin, et al. Expires May 2001 6 Parameter Alignment of Signaling Protocols November 2000 channel ID Destination subchannel ID Source User Session Source User group ID TLV Attribute group ID Object Destination user Session Destination group ID TLV Attribute user group Object ID Contract ID TLV Session Attribute Object Status code Result code Error Spec Result code Object Optional parameters Lightpath ID: Lightpath ID includes the Ipv4 address of the optical network element. Why is it not the address (or more generally the name) of the user network element? What is the reason to include the address of the service provider network element? As a response to the create request, information regarding the source and destination port, channel, subchannel and generalized label TLV are not required. To uniquely identify this message as a response to a request, the same message ID is used. Thus the connection ID (lightpath ID) identifies the results of the request. The source/destination addresses and the label TLV are provided to the service provider in order to help determine the specific route and the characteristics of that route. Once determined, these information are no longer relevant. The user group ID is not needed in the response message. This information is used only during the policy verification and route determination within the service provider domain, and is not required as part of the response signaling. The contract ID is not needed in the response message. This information is used only during the policy verification and route determination within the service provider domain, and is not required as part of the response signaling. 2.1.2 UNI Delete 2.1.2.1 UNI Delete request parameters UNI Delete Request CR-LDP Comments Lin, et al. Expires May 2001 7 Parameter Alignment of Signaling Protocols November 2000 parameters (PathTear/ResvTear 1.0 message) Version ID Backwards compatibility ID Message ID Message ID FEC TLV User Session Attribute Lightpath ID connection ID Object Lightpath ID Optional parameters Security 2.1.2.2 UNI Delete response parameters UNI Delete Response Generic CR-LDP RSVP-TE (?) OIF UNI 1.0 Comments parameters Version ID Backwards compatibility ID Message ID Message ID FEC TLV User connection Lightpath ID Session Lightpath ID Attribute ID Object Status code Result code Error Spec Result code Object Optional parameters 2.1.3 UNI Modify 2.1.3.1 UNI Modify request parameters UNI Modify Request Generic CR-LDP RSVP-TE OIF UNI 1.0 1 Comments parameters Version ID Backwards compatibility ID Message ID 1 In OIF2000.125.2, the modify request has been removed from UNI 1.0. Lin, et al. Expires May 2001 8 Parameter Alignment of Signaling Protocols November 2000 Service name Service name extension A-end name Z-end name A-end User group ID Z-end user group ID User connection Lightpath ID ID Contract ID Contract ID Lightpath bandwidth Schedule- duration Protection mode Lightpath priority Service Level Diversity Avoid name list Include name list Security Prior to determining the _best_ set of parameters for modification, OIF needs to first determine the type of information that may be desired to be modified, the default set of information that may be desired as a response. It should be noted that, depending on what modify means, any, all or none of the characteristics of a connection may be subjected to be modified. If none, then a modify may not be needed, and a create-delete combination command may be defined to effect the required actions. 2.1.3.2 UNI Modify response parameters UNI Modify Response Generic CR-LDP RSVP-TE OIF UNI 1.0 Comments parameters Version ID Backwards compatibility ID Message ID Lin, et al. Expires May 2001 9 Parameter Alignment of Signaling Protocols November 2000 User connection Lightpath ID ID Contract ID Lightpath bandwdith Protection mode Lightpath priority Service level Diversity Status code Result code 2.1.4 UNI Query For query, the status code may provide information such as how many UNI links are set up by the requesting user, health of all those links or health of a particular link, usage information of the particular link, etc. 2.1.4.1 UNI Query Request parameters UNI Query Request Generic CR-LDP RSVP-TE (DREQ OIF UNI 1.0 Comments parameters message) Version ID Backwards compatibility ID Message ID Message ID User connection Lightpath ID Session Lightpath ID Object ID UNI-C ID TLV UNI-C ID Optional parameters Security Prior to determining the _best_ set of parameters for query, OIF needs to first determine the type of information that may be desired as a response, the default set of information that may be desired as a response. Lin, et al. Expires May 2001 10 Parameter Alignment of Signaling Protocols November 2000 2.1.4.2 UNI Query response parameters UNI Query Response Generic CR-LDP RSVP-TE OIF UNI 1.0 Comments parameters (DREP message) Version ID Backwards compatibility ID Message ID Message ID User connection Lightpath ID Session Lightpath ID ID TLV Object Source Sender Source termination Template termination point TLV Object point address Sender Template Object Source port ID Source channel ID Source subchannel ID Destination Session Destination termination Object termination point TLV point address Destination port ID Destination channel ID Destination subchannel ID Source User Session Source User group ID TLV Attribute group ID Object Destination Session Destination user group ID Attribute user group ID TLV Object Contract ID TLV Session Contract ID Attribute Object Generalized Framing Label Request Object Generalized Bandwidth Label Request Object Transparency Lin, et al. Expires May 2001 11 Parameter Alignment of Signaling Protocols November 2000 TLV Label Request Object Generalized Directionality Label Request Object Lightpath schedule TLV Service Level Session Attribute Object Service level Drop-side protection Protection mode Diversity TLV Diversity Lightpath priority Propagation Propagation delay delay Retention mode Status code Status TLV Status Optional parameters 2.1.5 UNI Notification parameters UNI Notification Generic CR-LDP RSVP-TE OIF UNI 1.0 Comments parameters (Notify message) Version ID Backwards compatibility ID Message ID Message ID User connection Lightpath ID Session Lightpath ID Object ID Status code Status TLV Error Spec Status Object Optional parameters Lin, et al. Expires May 2001 12 Parameter Alignment of Signaling Protocols November 2000 3. Proposal Given the various parameter sets of the different proposed UNI signaling protocols (RSVP-TE, CR-LDP, OIF UNI 1.0), this contribution proposes that OIF align these parameter lists across all the signaling protocols that may be considered as an option for the UNI 1.0 specification. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Lin, et al. Expires May 2001 13 Author's Addresses Curtis Brownmiller, Worldcom Tel: 972-729-7171 Email: curtis.brownmiller@wcom.com Zhi-Wei Lin, Lucent Tel: 732-949-5141 Email: zwlin@lucent.com Olivier Duroyon, Alcatel Tel: 703-654-8605 Email: oduroyon@adn.alcatel.com Hirokazu Ishimatsu, Japan Telecom Tel: +81 3 5540 8493 Email: hirokazu@japan-telecom.co.jp Lin, et al 14 Parameter Alignment of Signaling Protocols November 2000 Full Copyright Statement "Copyright (C) The Internet Society (2000). 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 Lin, et al. Expires May 2001 15