Network Working Group X. Fu Internet-Draft M. Betts Intended status: Standards Track ZTE Corporation Expires: October 28, 2010 R. Jing X. Huo China Telecom April 26, 2010 Framework for Multi Stages Multiplexing Configuration in G.709 Optical Transport Network draft-fuxh-ccamp-multi-stage-multiplex-config-fwk-00 Abstract Interworking between regions with 1.25G TS and 2.5G TS has been considered in G.709. Multi stages multiplexing/demultiplexing would be desirable to facilitate the introduction of new ODU0 and ODUflex signals to an existing network without having to upgrade every node in the network. So ODU0/ODUflex can be mapped into ODU1/ODU2/ODU3 and transit across the 2.5G TS region. Multi stages multiplexing/ demultiplexing are also used to support the multi-domain OTN applications based on the tunnel design. This document describes the framework for multi stages multiplexing configuration in G.709 Optical Transport Network. 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 28, 2010. Fu, et al. Expires October 28, 2010 [Page 1] Internet-Draft Multi Stages Multiplexing Configuration April 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. GMPLS and PCE Extension to Support Multi Stages Multiplexing Configuration . . . . . . . . . . . . . . . . . . 3 2.1. Routing Extension to Support Multi Stages Multiplexing Configuration . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Signaling Extension to Support Multi Stages Multiplexing Configuration . . . . . . . . . . . . . . . . 4 2.3. PCE Extension to Support Multi Stages Multiplexing Configuration . . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Fu, et al. Expires October 28, 2010 [Page 2] Internet-Draft Multi Stages Multiplexing Configuration April 2010 1. Introduction Multi stages multiplexing configuration requirement is defined in [MULTI-STAGES-MULTIPLEXING-CONFIG-REQ] document. It describes two typical use case of multi stages multiplexing configuration. The introduction of ODU0 and ODUflex to the OTN hierarchy creates a situation where the newly added ODUk signals have a bit rate that is lower than any of the existing signals, which presents some different challenges because the new signals can be clients of the existing signals. As a result, there are clear applications where multi stages of multiplexing would be desirable to facilitate the introduction of these new ODU0 and ODUflex signals to an existing network without having to upgrade every node in the network. Using multi stages of multiplexing at the domain boundary allows the operator to confine the new rates to only those nodes that need to support them. A second potential application for multi stages outside of an upgrade scenario would be a network design based on tunnels. Multi stages multiplexing are used to support the multi-domain OTN applications based on the tunnel design. If there are a large number of circuits that share the same endpoints (or even part of an overall path), it may be convenient from a management perspective to first multiplex those ODU0, ODU1 and ODUflex into ODU2 or ODU3 to minimize the number of connections that need to be made in intermediate nodes. The ODU2/ ODU3 effectively creates a tunnel through the ODU4 network that the ODU0, ODU1 and ODUflex can use. This document describes the framework for multi stages multiplex configuration in G.709 Optical Transport Network. 2. GMPLS and PCE Extension to Support Multi Stages Multiplexing Configuration From the perspective of Management Plane, it must get multi stages multiplexing/demultiplexing capability of each gateway nodes for the service provision. Management Plane must also configure the multi stages multiplexing/demultiplexing in Gateway nodes for the end-to- end service. The gateway nodes provide the multi stages multiplexing/ demultiplexing capability for introducing new ODU0 and ODUflex signals to an existing network and tunnel design. Gateway also supports the signal transfer function between regions with 1.25G TS and 2.5G TS. It needs to extend GMPLS to provide the multi stages multiplexing configuration. Fu, et al. Expires October 28, 2010 [Page 3] Internet-Draft Multi Stages Multiplexing Configuration April 2010 From the perspective of Control Plane, it must get multi stages multiplexing/demultiplexing capability of each gateway nodes for path computation. It can get Multi stages multiplexing/demultiplexing information by Management Plane configuration. Path computation entity can use the IGP protocol or configurations from Management Plane to get this information. Path computation entity must select a proper kind of multi stages multiplexing/demultiplexing of gateway nodes along a specific end-to-end connection. Signaling message must carry the multi stages multiplexing/demultiplexing that has been determined by path computation entity. Multi stages multiplexing/ demultiplexing for a specific service must be configured after gateway receives the signaling of service creation. The purpose of this section is to provide a framework for extensions of the current GMPLS and PCE protocols for multi stages multiplexing configuration in OTN network. 2.1. Routing Extension to Support Multi Stages Multiplexing Configuration It needs to extend the routing protocol to get the multi stages multiplexing/demultiplexing capability information of gateway nodes. Multi stages multiplexing/demultiplexing capability information must be flooded into the path computation entity and the routing domain by gateway nodes with the IGP protocol. LSAs which are advertised by gateway nodes must carry multi stages multiplexing/demultiplexing capability information of gateway nodes. Multi stages multiplexing/ demultiplexing capability should be configured by Management Plane (e.g., Network Planning Tool) or discovered by the gateway node based on the switching and adaptation capability of switching fabrics and cards. In order to make path computation entity get the multi stages multiplexing capability information of gateway node, the routing protocol should be extended to convey the multi stages multiplexing capability information. [MULTI-STAGES-MULTIPLEXING-CONFIG-OSFPTE- EXT] describes OSPF-TE extension for multi stages multiplexing configuration. It enhances the sub-TLVs for the Link TLV to support Multi Stages Multiplexing Configuration. It defines extensions to the OSPF routing protocol which is defined in [RFC3630], [RFC4202], and [RFC4203] in order for multi stages multiplexing configuration. 2.2. Signaling Extension to Support Multi Stages Multiplexing Configuration The multi stages multiplexing capability information should be discovered/enabled by the OSS and as described in the previous point distributed via routing. Based on the [MULTI-STAGES-MULTIPLEXING- Fu, et al. Expires October 28, 2010 [Page 4] Internet-Draft Multi Stages Multiplexing Configuration April 2010 CONFIG-OSPFTE-EXT], path computation entity can get multi stages multiplexing/demultiplexing capability of each gateway nodes for path computation. So the path computation entity must select some proper kinds of multi stages multiplexing/demultiplexing for different gateway nodes along a specific end-to-end connection. All kinds of multi stages multiplexing which has been determined for all gateway nodes along one end-to-end connection by path computation entity must be carried with signaling message. After one gateway node receives the signaling message who carries one kind of multi stages multiplexing for it, it must config this kind of multi stages multiplexing hierarchy to its data plane. It needs to extend the signaling protocol to configure the multi stages multiplexing/ demultiplexing method within the gateway nodes along one specific end-to-end connection. The Explicit Route Object [RFC3209] allows the ingress node to partially or fully specify the route of an LSP. The route is encoded as a sequence of hops that identifies a node or interface that must be crossed. Further attributes assigned to each hop can be added to the route such as per-hop label control [RFC3473] and list of prohibited resources between two nodes [RFC4874]. ERO can carry the multi stages multiplexing information. ,so it is desirable to extend the ERO object. [HOP_ATTRIBUTES] introduce a new ERO sub-object that encodes attributes relevant to a particular node or interface within the gateway node. The HOP_ATTRIBUTES subobject can be inserted into ERO, SERO, RRO and SRRO. [MULTI-STAGES-MULTIPLEXING-CONFIG-RSVPTE-EXT] describes the RSVP-TE extension for multi stages multiplexing configuration in G.709 Optical Transport Network. It extends the HOP_ATTRIBUTES defined in document [HOP_ATTRIBUTES]. It defineds a new Attributes TLV where the kinde of multi stages multiplexing hierarchy relevant to a specific interface of internal node is encoded. Ingress node initiates the setup of end-to-end connection. A specific kind of multi stages multiplexing relevant to a particular gateway node or interface within this gateway node along the path is included in a HOP_ATTRIBUTES subobject, which is inserted into the ERO. On reception of a Path message containing HOP_ATTRIBUTES whose type of Attributes TLV is Multi States Multiplexing Hierarchy Sub- TLV, the receiver of message along the path must check the local data plane capability to see if this kind of multi stages multiplexing/ demultiplexing is acceptable on specific interface or gateway node. If there is an acceptable kind of multi stages multiplexing/ demultiplexing, then this kind of multi stages multiplexing/ demultiplexing must be configed into the data plane Fu, et al. Expires October 28, 2010 [Page 5] Internet-Draft Multi Stages Multiplexing Configuration April 2010 2.3. PCE Extension to Support Multi Stages Multiplexing Configuration Based on the [MULTI-STAGES-MULTIPLEXING-CONFIG-OSPFTE-EXT], path computation entity can get multi stages multiplexing/demultiplexing capability of each gateway nodes for path computation. Path computation entity in Management Plane and/or Control Plane must support the path computation by using the multi stages multiplexing capability constraint information. It must determine some proper kinds of multi stages multiplexing hierarchy for different gateway node along the path. A request from a PCC to a PCE MUST support the inclusion of an optional indication of which kinds of multi stages multiplexing hierarchy can be used for sepecific gateway node or not. So the path computation entity must consider these multi stage multiplexing hierarchy constraints. In the absence of such an indication, the default is that there is no any multi stage multiplexing hierarchy constraint for path computation. PCReq has a desire to be extended to carry some kindes of multi stages multiplexing hierarchy constraints of some specific gateway nodes for path computation from PCC. PCRep also has a desire to be extended to carry all kindes of multi stages multiplexing hierarchy for each gateway nodes along the path. 3. Security Considerations The use of control plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. The data plane technology for an OTN does not introduce any specific vulnerabilities, and so the control plane may be secured using the mechanisms defined for the protocols discussed. For further details of the specific security measures refer to the documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. 4. IANA Considerations TBD 5. References Fu, et al. Expires October 28, 2010 [Page 6] Internet-Draft Multi Stages Multiplexing Configuration April 2010 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-ccamp-gmpls-g709-framework] Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts, M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", draft-ietf-ccamp-gmpls-g709-framework-00 (work in progress), April 2010. 5.2. Informative References Authors' Addresses Xihua Fu ZTE Corporation Email: fu.xihua@zte.com.cn Malcolm Betts ZTE Corporation Email: malcolm.betts@zte.com.cn Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Xiaoli Huo China Telecom Email: huoxl@ctbri.com.cn Fu, et al. Expires October 28, 2010 [Page 7]