Network Working Group E. Roch Internet Draft Ciena Intended status: Informational T. Marcot Expires: April 2011 France Telecom L. Ong Ciena October 18, 2010 Extensions to Hierarchical LSPs for ASON identifiers support draft-roch-ccamp-lsp-hier-ason-00.txt 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 April 18, 2011. 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 Simplified BSD License. Roch, Marcot & Ong Expires April 18, 2011 [Page 1] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 Abstract A set of requirements and a proposed solution for the control of hierarchical Label Switched Paths (LSPs) is found in [HIER]. However, support of address separation as allowed by the Automatically Switched Optical Network (ASON) architecture [G.8080] is not covered by [HIER]. This internet draft describes additional requirements to consider for the use of LSP hierarchy in ASON networks and proposes extensions to address those requirements. Table of Contents 1. Introduction and Problem Statement.............................2 1.1. Separate control plane instances at different layers......3 1.2. Address and identifier separation within a layer..........3 2. Requirements...................................................4 2.1. Routing Controller Identification.........................4 2.2. Signaling Controller Identification.......................4 3. Mechanisms and Protocol Extensions.............................4 3.1. LSP_TUNNEL_INTERFACE_ID sub-TLVs..........................4 3.1.1. Routing Controller Protocol Controller (RC PC) Identifier..................................................5 3.1.2. Routing Controller Protocol Controller (RC PC) Reachable Address...........................................5 3.1.3. Signaling Controller Protocol Controller (SC PC) Identifier..................................................5 3.1.4. Signaling Controller Protocol Controller (SC PC) Reachable Address...........................................5 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. References.....................................................6 6.1. Normative References......................................6 6.2. Informative References....................................6 7. Acknowledgments................................................6 1. Introduction and Problem Statement This problem statement applies to the operation of multilayer networks according to the ASON architecture. [HIER] defines a set of extensions for the control of hierarchical Label Switched Paths (LSPs). This internet draft describes additional requirements for the use of LSP Hierarchy in ASON networks. Roch, Marcot & Ong Expires April 18, 2011 [Page 2] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 1.1. Separate control plane instances at different layers In ASON architecture, the control plane instance in a client layer may be a separate instance than the control plane instance for the client layer. This requires that when a server layer link is created, sufficient information must be passed to allow a new control (signaling and optionally routing) association to be created between the client control instances at the ends of the new link. This includes identification and addressing information for both the signaling control instance and routing control instance at each end. The ASON architecture [G.8080] allows for separate control plane instances for each controlled layer. In a real deployment, this can be seen in a few scenarios. For example, in networks mixing legacy equipment and emerging technologies, existing legacy control plane for some layers and new control plane for other layers may be based on different protocols, requiring different instances. Additionally, some equipment may be entirely under management plane control whereas other is under control plane. There might also be business boundaries due to mergers and acquisitions or due to internal company organization. In these cases, the result is multiple instances of control plane. Another scenario is that different instances may be used to solve scalability problems. 1.2. Address and identifier separation within a layer Separate identification of routing controller instances, signaling controller instances and resource identifiers is required in order to support ASON signaling and routing. Separation of routing controller and resource identifier is already addressed as a requirement in [RFC4652], as referenced by the terms ''Li'' and ''Pi'' for the logical control plane entity and physical node identifiers, respectively. This allows 1:n relationships between the control entity and the physical resources being controlled, for example. Separation of routing and signaling controller identifiers and their respective reachable addresses allows the routing and signaling controller identifiers to be independent of the specific network address by which they are reached. This allows the operator to modify the signaling communications network addressing scheme without impacting the control plane protocols. Routing controller addressing is further discussed in [RFC4258]. Roch, Marcot & Ong Expires April 18, 2011 [Page 3] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 2. Requirements 2.1. Routing Controller Identification In ASON architecture, a routing controller possesses two identifiers. The first is the Routing Controller Protocol Controller Identifier (RC PC ID). The second is the IPv4 address at which the routing controller can be reached, the Routing Controller Protocol Controller Signaling Control Network address (RC PC SCN address). New requirement: It must be possible to exchange RC PC IDs and RC PC SCN addresses for the establishment of a routing adjacency in the client layer. 2.2. Signaling Controller Identification In ASON architecture, signaling controller identifiers cannot be automatically derived from routing controller identifiers. In order to establish an RSVP-TE signaling adjacency between two client signaling controllers, a signaling mechanism is required in the server layer to identify the signaling controller. Each signaling controller requires two identifiers. The first is the Signaling Controller Protocol Controller Identifier (SC PC ID). The second is the IPv4 address at which the signaling controller can be reached, the Signaling Controller Protocol Controller Signaling Control Network address (SC PC SCN address). New Requirement: It must be possible to exchange SC PC IDs and SC PC SCN addresses for the establishment of a signaling adjacency in the client layer. 3. Mechanisms and Protocol Extensions This section defines protocol extensions to address the requirements described in the previous section. 3.1. LSP_TUNNEL_INTERFACE_ID sub-TLVs The following sub-TLVs are optional sub-TLVs of the LSP_TUNNEL_INTERFACE_ID, in addition to already defined Target IGP Identifier and Component Link Identifier TLV. These sub-TLVs allow the client layer to use separate routing and signaling controller identifiers and reachable addresses. Roch, Marcot & Ong Expires April 18, 2011 [Page 4] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 3.1.1. Routing Controller Protocol Controller (RC PC) Identifier The following sub-TLV is included to identify the RC PC associated with the client layer. The TLV is formatted as described in Section 3.1.2 of [HIER]. The Type field has the value 4 (TBD), and the Value field has the following content: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Controller Protocol Controller Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.2. Routing Controller Protocol Controller (RC PC) SCN Address The following sub-TLV is included to provide the SCN reachable address for the RC PC associated with the client layer. The TLV is formatted as described in Section 3.1.2 of [HIER]. The Type field has the value 5 (TBD), and the Value field has the following content: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Controller Protocol Controller SCN IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.3. Signaling Controller Protocol Controller (SC PC) Identifier The following sub-TLV is included to identify the SC PC associated with the client layer. The TLV is formatted as described in Section 3.1.2 of [HIER]. The Type field has the value 6 (TBD), and the Value field has the following content: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signaling Controller Protocol Controller Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.4. Signaling Controller Protocol Controller (SC PC) SCN Address The following sub-TLV is included to provide the reachable SCN address for the RC PC associated with the client layer. The TLV is Roch, Marcot & Ong Expires April 18, 2011 [Page 5] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 formatted as described in Section 3.1.2 of [HIER]. The Type field has the value 7 (TBD), and the Value field has the following content: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Controller Protocol Controller SCN IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Security Considerations TBD 5. IANA Considerations TBD 6. References 6.1. Normative References [HIER] Shiomoto, K., and Farrel, A. (Editors), ''Procedures for Dynamically Signaled Hierarchical Label Switched Paths'', draft-ietf-ccamp-lsp-hierarchy-bis-08.txt, February 2010 [RFC4258] Brungard, D, Ed. ''Requirements for Generalized Multi- Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)'', RFC4258, November 2005 [RFC4652] Papadimitriou, D., Ed. ''Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements'', RFC4652, October 2006 6.2. Informative References [G.8080] ITU-T Rec G.8080/Y.1304 ''Architecture for the Automatically Switched Optical Network (ASON)'', June 2006 7. Acknowledgments The authors would like to thank Vishnu Shukla (Verizon) for his contribution and comments to this document. Roch, Marcot & Ong Expires April 18, 2011 [Page 6] Internet-Draft draft-roch-ccamp-lsp-hier-ason October 2010 Authors' Addresses Evelyne Roch Ciena Email: eroch@ciena.com Thierry Marcot France Telecom Email: thierry.marcot@orange-ftgroup.com Lyndon Ong Ciena Email: lyong@ciena.com Roch, Marcot & Ong Expires April 18, 2011 [Page 7]