Network Working Group A. Kern Internet-Draft A. Takacs Intended status: Informational Ericsson Expires: September 2, 2010 March 1, 2010 Use cases and alternatives for configuring intermediate nodes using RSVP-TE draft-kern-ccamp-intermediate-node-config-00 Abstract Lately, a few use-cases have been identified where, besides path setup, specific configuration of intermediate nodes is required for the establishment of an LSP with its associated functions. Today, RSVP-TE is not supporting the selective configuration of intermediate nodes; hence extensions are required to equip RSVP-TE with such a capability. In this document we summarize the use-cases and their requirements and sketch alternative solutions to configure intermediate nodes. Since one of the main issues with intermediate node configuration is the introduction of potential scaling problems, we included scalability in our analysis. This document does not specify any extensions; its sole purpose is to foster discussion on the subject. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 2, 2010. Kern & Takacs Expires September 2, 2010 [Page 1] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Amount of configuration data . . . . . . . . . . . . . . . . . 4 2.1. WSON Regeneration . . . . . . . . . . . . . . . . . . . . 4 2.2. OAM Configuration of Non-Intrusive Monitoring Entities . . 4 2.3. OAM Configuration of Tandem Connection Monitoring Entities . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RSVP-TE signaling alternatives . . . . . . . . . . . . . . . . 6 3.1. Using the LSP_ATTRIBUTES Object . . . . . . . . . . . . . 6 3.2. Using the HOP_ATTRIBUTES Sub-Object in ERO . . . . . . . . 6 3.3. Combination of LSP_ATTRIBUTES and ERO . . . . . . . . . . 6 3.4. Using multiple messages . . . . . . . . . . . . . . . . . 7 3.4.1. Multiple messages with semantic fragmentation . . . . 7 3.4.2. Using other signaling messages/procedures . . . . . . 7 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Kern & Takacs Expires September 2, 2010 [Page 2] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 1. Introduction Lately, a few use-cases have been identified where, besides path setup, specific configuration of intermediate nodes is required for the establishment of an LSP with its associated functions. GMPLS is being extended to support Wavelength Switched Optical Networks (WSON) [WSON-FWK]. In the context of WSON, in [WSON-SIGNAL], it has been identified that in addition to setup the path and configure endpoints of an LSP to input and output a signal with specific attributes, it may be need to signal particular intermediate NEs to perform specific processing, such as 3R regeneration, on the signal. Three types of processing are named which may need configuration at particular intermediate nodes of an LSP: 1) regeneration, 2) fault and performance monitoring and 3) signal attribute conversion. [GMPLS-OAM-FWK] describes GMPLS RSVP-TE signaling extension to configure Operations and Management (OAM) functions associated to a connection. Two OAM entities are differentiated: Maintenance Endpoints (MEPs) that are deployed at connection endpoints and Maintenance Intermediate Points (MIPs) that can be deployed at intermediate nodes. The procedures described in [GMPLS-OAM-FWK] support the detailed configuration of MEPs while for MIPs only the instantiation at every or none of the intermediate nodes is supported. However, transport technologies, such as SDH and OTN provide a rich set of monitoring functions which would require besides detailed MEP configuration, the selective configuration of MIPs as well. For instance, a part of an end-to-end connection can be monitored with the help of tandem connection monitoring (TCM) running between two intermediate nodes, or the end-to-end data flow can be monitored in a non-intrusive fashion at particular intermediate NEs. Kern & Takacs Expires September 2, 2010 [Page 3] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 2. Amount of configuration data 2.1. WSON Regeneration In [WSON-SIGNAL] only the first type of processing, the regeneration, is discussed further. The information that needs to be passed to intermediate nodes consists of the type of regeneration, i.e., no regeneration at this node or 1R, 2R or 3R Regeneration. In addition the particular node may be a fixed or an optional regeneration point. All in all, for regeneration at most an octet of information is needed per intermediate node of an LSP. Assuming that this info is carried in a TLV with reserved bits for extensibility we may calculate with 8 octets. Due to the nature of regeneration, the worst case is when all intermediate nodes are configured with regeneration information. 2.2. OAM Configuration of Non-Intrusive Monitoring Entities A Non-Intrusive Monitoring Entity (NIME) snoops the end-to-end monitoring flow and may trigger consequent actions and invoke alarms. To deploy a NIME, the end-to-end OAM configuration information must be available and some NIME specific attributes may be set as well, such as monitored signals and trigger thresholds. Assuming that the end-to-end OAM configuration information is available using the procedures described in [GMPLS-OAM-FWK], for a specific NIME it is enough to encode the entity identifiers and threshold parameters using TLVs based on [GMPLS-OAM-FWK] and the appropriate technology specific drafts. For instance, in case of SDH and OTN connection we may calculate with roughly 20 octets per NIME. In worst case all intermediate nodes of an LSP can be configured as NIMEs. 2.3. OAM Configuration of Tandem Connection Monitoring Entities The Tandem Connection Monitoring Entity (TCME) is basically a pair of MEPs running on a tandem connection, which is associated to the end- to-end connection. Depending on the technology overlapping or nesting TCMEs are allowed. TCM is independent of the end-to-end monitoring flow, it multiplexes its own monitoring flow on the connection. Hence the configuration of TCM is basically similar to the configuration of end-to-end monitoring, hence requiring the full configuration described in [GMPLS-OAM-FWK], including MEP identifiers, message rates etc. Therefore, specifying a TCME requires the same amount of configuration data as the end-to-end OAM flow, plus the location information of the two endpoints. Hence, we may calculate with Kern & Takacs Expires September 2, 2010 [Page 4] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 roughly 100 octets per entity. Kern & Takacs Expires September 2, 2010 [Page 5] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 3. RSVP-TE signaling alternatives Two aspects need to be considered for each of the alternatives. First, how a particular intermediate node is identified. Second, how the configuration information is carried and used. 3.1. Using the LSP_ATTRIBUTES Object The LSP_ATTRIBUTES Object [RFC5420] can accommodate TLVs to carry configuration information for intermediate nodes as well. In order to identify the nodes to which a specific configuration should be applied the node identifiers must be explicitly listed. A crucial problem here is that the list of nodes in the LSP_ATTRIBUTES Object, the ERO and as a result of any distributed computation must be synchronized. To this end, procedures that modify the path of the LSP and/or the ERO must also revise TLVs in the LSP_ATTRIBUTES Object. 3.2. Using the HOP_ATTRIBUTES Sub-Object in ERO The ERO originally was designed to specify the route for a connection, however over time this has been relaxed and the ERO now carries resource configuration as well. For instance, one can specify the downstream and upstream labels and declare a set of unwanted/non-preferred resource parameters. These parameters are listed as additional ERO Sub-Objects after the Sub-Object defining the hop. To encode general configuration information a new ERO Sub- Object can be defined (e.g., HOP_ATTRIBUTES [HOP-ATTR]), which would allow inclusion of TLVs that contain specific attributes of the intermediate hops of an LSP. Since the ERO may contain loose hops and abstract nodes procedures for intermediate node configuration must be prepared for the appropriate resolution. With this approach the binding of intermediate node configuration information to the actual identification of the hop is naturally solved. 3.3. Combination of LSP_ATTRIBUTES and ERO The ERO could be used to identify that a specific hop has additional configuration information, which is carried in the LSP_ATTRIBUTES Object and point to that information element. In this case the ERO would essentially contain an index to the contents of the LSP_ATTRIBUTES Object. In this case the ERO is not overloaded with configuration data, and in scenarios where the same configuration is used at multiple intermediate hops the data that is carried in the Kern & Takacs Expires September 2, 2010 [Page 6] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 path message is reduced. 3.4. Using multiple messages Multiple message exchanges may be needed to remove scaling issues and support general intermediate node configuration. However it must be noted that not all use-cases will allow for the use of multiple messages. In some cases it is mandatory that particular intermediate nodes are configured together with path setup, hence configuration information must be carried in the first Path message. This is likely the case with WSON regeneration configuration. On the other hand, there will be cases which may benefit from joint signaling with the first Path message but where it may be also acceptable to use multiple messages. This is likely the case with the setup of tandem connection monitoring entities. 3.4.1. Multiple messages with semantic fragmentation The problem of too much data in a single RSVP-TE message has been faced with P2MP LSPs. In [RFC4875] the sub-state concept has been introduced, where a PATH message may refer to a part of the signaling state only, while the whole state is signaled with multiple PATH messages. For intermediate node configuration the fragmentation of information could be considered. For instance, contents of the LSP_ATTRIBUTES Object may be disseminated using several PATH messages. This would allow stepwise configuration of functions, and so be a scalable way to convey intermediate node configuration. 3.4.2. Using other signaling messages/procedures The LSP is setup with RSVP-TE PATH and RESV messages, while intermediate node configuration could be done with other RSVP messages. This has been already applied to implement extra features like collecting RSVP state information [RFC2745] or sending direct notification to an intermediate node [RFC3473]. However, these extensions do not carry configuration information that is included into the RSVP state. How these states are refreshed need further considerations. Kern & Takacs Expires September 2, 2010 [Page 7] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 4. Discussion For intermediate node configuration it is likely that two methods will be needed. One mechanism would support cases where path setup and intermediate node configuration need to happen at the same time. In this case only a very limited configuration of intermediate nodes would be supported, i.e., through a set of flags or indexes. The simplest method is to use the ERO and provide a placeholder for the information. The other mechanism would support complex configurations and to scale may have to rely on multiple message exchanges. A solution based on the semantic fragmentation described for P2MP LSPs may be a viable solution. Kern & Takacs Expires September 2, 2010 [Page 8] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 5. References [GMPLS-OAM-FWK] Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration Framework and Requirements for GMPLS RSVP-TE", draft-ietf-ccamp-oam-configuration-fwk-03 (work in progress), January 2010. [HOP-ATTR] Kern, A. and A. Takacs, "Encoding of Attributes of LSP intermediate hops using RSVP-TE", draft-kern-ccamp-rsvpte-hop-attributes-00 (work in progress), October 2009. [RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [WSON-FWK] Bernstein, G., Lee, Y., and W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework-05 (work in progress), February 2010. [WSON-SIGNAL] Bernstein, G., "Signaling Extensions for Wavelength Switched Optical Networks", draft-bernstein-ccamp-wson-signaling-06 (work in progress), February 2010. Kern & Takacs Expires September 2, 2010 [Page 9] Internet-Draft Configuring middle nodes with RSVP-TE March 2010 Authors' Addresses Andras Kern Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: andras.kern@ericsson.com Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: attila.takacs@ericsson.com Kern & Takacs Expires September 2, 2010 [Page 10]