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 Requirement for Multi Stages Multiplexing Configuration in G.709 Optical Transport Network draft-fuxh-ccamp-multi-stage-multiplex-config-req-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. 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 requirement for multi stages multiplexing configuration for gateway network elements that are located at a domain boundary 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 Fu, et al. Expires October 28, 2010 [Page 1] Internet-Draft Multi Stages Multiplexing Configuration April 2010 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. 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. Fu, et al. Expires October 28, 2010 [Page 2] Internet-Draft Multi Stages Multiplexing Configuration April 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Typical Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Multi Stages Multiplexing Configuration Requirement for Interworking Between Regions with 1.25G TS and 2.5G TS . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Multi Stages Multiplexing Configuration Requirement for Multi-Domain OTN Applications Based on Tunnel Design . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Requirement for Multi Stages Multiplexing Configuration . . . 11 3.1. Requirement in the level of the Data Plane . . . . . . . . 11 3.2. Requirement in the level of Control Plane and Management Plane . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Fu, et al. Expires October 28, 2010 [Page 3] Internet-Draft Multi Stages Multiplexing Configuration April 2010 1. Introduction G.709 has supported a single stage of ODU multiplexing. The practical consequence of this in OTN v1 is an ODU1 can be mapped directly to a tributary slot of an ODU3, without having to be first mapped into an ODU2. The motivation for this architecture is reducing complexity. In the normal progression of things, new additions to the OTN were expected to be at faster bit rates, and thus the single stage concept could be easily maintained going forward. 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 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. This document describes the requirement for multi stages multiplex configuration in G.709 Optical Transport Network. 2. Typical Use Case 2.1. Multi Stages Multiplexing Configuration Requirement for Interworking Between Regions with 1.25G TS and 2.5G TS In Figure 1, node 4, 5, 6 and 7 have ODU1 and ODU2 switching capability. All nodes only support 2.5G TS granularity. They can't support ODU0/ODUflex directly. They could not have any visibility to the ODU0/ODUflex. Fu, et al. Expires October 28, 2010 [Page 4] Internet-Draft Multi Stages Multiplexing Configuration April 2010 - /|5|\ / - \ / \ - / ODU3 \ - |4| Network 2 |7| - \ / - \ / \ - / \|6|/ - Figure 1 In Figure 2, operator deploys three new 10G OTN networks, such as ODU2 Network 1, ODU 2 Network 3 and ODU2 Network 4. All ODU2 networks are interconnected with ODU3 network by OTU3 link. All nodes of three ODU2 networks support the 1.25G TS granularity and are based on G.709 v3. All nodes in ODU2 Network 1 and ODU2 Network 4 can support ODU0, ODU1 and ODUflex switching capability. ODU2 Network 3 is only desirable to support GigE and ODUflex services, so all nodes in ODU2 Network 3 only support ODU0 and ODUflex for more economical cost. It doesn't support ODU1 (e.g., STM-16) application. -- /|12|\ / -- \ / \ -- / ODU2 \-- |11| Network 4 |13| -- \ / -- \ / \ - / \| |/ - Gateway4 | | - - - /|2|\ /|5|\ /|8|\ / - \ / - \ / - \ / \ / \ / \ - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| - \ / - - \ / - - \ / -- \ /Gateway1 \ / Gateway3\ / \ - / \ - / \ - / \|3|/ \|6|/ \|9|/ Fu, et al. Expires October 28, 2010 [Page 5] Internet-Draft Multi Stages Multiplexing Configuration April 2010 - - - Figure 2 There are clear applications where 2 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. In order for the interworking between 1.25G TS and 2.5G TS networks, there must be some gateway nodes which are added at a domain boundary in order to support ODU0/ODUflex. Within the gateway nodes, multi stages multiplexing/demultiplexing allow ODU0/ODUflex to be supported across the legacy network. ODU0 is mapped first to ODU1 or ODU2, and that ODU1/2 is then mapped into ODU3. Nodes in the legacy network switch the ODU1/ODU2 without having any visibility to the ODU0/ODUflex. Whether ODU1 or ODU2 should be created for end-to-end ODU0 service depends on multi stages multiplexing capability of gateway. Different gateways may support different multi stages multiplexing capabilities based on the network planning and the capability of network element. Gateway 1 is supposed to support the following multi stages multiplexing/demultiplexing capability. o ODU0-ODU1-ODU3 o ODU0-ODU2-ODU3 o ODU1-ODU2-ODU3 o ODUflex-ODU2-ODU3 Gateway 3 is supposed to support the following multi stages multiplexing/demultiplexing capability. o ODU0-ODU2-ODU3 o ODUflex-ODU2-ODU3 Gateway 4 is supposed to support the following multi stages multiplexing/demultiplexing capability. The operator limits the ODUflex application to the local network. There is no any multi- domain ODUflex application which goes into ODU2 Network 4 and vice versa. So it doesn't need to support the ODUflex-ODU2-ODU3 multiplexing. Fu, et al. Expires October 28, 2010 [Page 6] Internet-Draft Multi Stages Multiplexing Configuration April 2010 o ODU0-ODU1-ODU3 o ODU0-ODU2-ODU3 There are several end-to-end services. o E2E ODUflex 1 (e.g., 6*1.25G TS): It transit 1, 3, Gateway 1, 4, 6, 7, Gateway 3 and 8. o E2E GigE 1: It transit 1, 3,Gateway 1, 4, 6, 7, Gateway 3, 9 and 10. o E2E GigE 2: It transit 2, Gateway 1, 5, Gateway 4, 11 and 12. o E2E STM-16 1: It transit 1, 2,Gateway 1, 5, Gateway 4 and 13. The E2E ODUflex 1 (e.g., 6*1.25G TS) and GigE 1 services share the same ODU2 tunnel between Gateway 1 and Gateway 3. Multi stages multiplexing/demultiplexing capability must be configured with ODU0- ODU2-ODU3 in Gateway 1 and Gateway 3 for GigE 1 service. Multi stages multiplexing/demultiplexing capability must be configured with ODUflex-ODU2-ODU3 in Gateway 1 and Gateway 3 for ODUflex 1 service. There is an ODU 1 tunnel between Gateway 4 and Gateway 1 for the E2E GigE 2 service. Multi stages multiplexing/demultiplexing capability must be configured with ODU0-ODU1-ODU3 in Gateway 1 and Gateway 4 for GigE 2 service. There is no any need to configure multi stages multiplexing/demultiplexing for STM-16 1 service. 2.2. Multi Stages Multiplexing Configuration Requirement for Multi- Domain OTN Applications Based on Tunnel Design In Figure 3, operator deploys three new OTN networks again, such as ODU2 Network 5, ODU3 Network 7 and ODU4 Network 6. ODU2 network 5 and ODU3 network 7 are interconnected with ODU4 network by OTU4 link. All nodes of three new OTN networks support the 1.25G TS granularity and are based on the G.709 v3. All nodes in ODU2 Network 5 support ODU0, ODU1 and ODUflex switching capability. All nodes in ODU3 Network 7 support ODU0, ODU1, ODUflex and ODU2 switching capability. All nodes in ODU4 Network 6 only support ODU2 and ODU3 switching capability. In an ODU4 network, there are 80 tributary slots per ODU4. Suppose there are a large number of multi-domain ODU0 and ODUflex demands. 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 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 Fu, et al. Expires October 28, 2010 [Page 7] Internet-Draft Multi Stages Multiplexing Configuration April 2010 tunnel through the ODU4 network that the ODU0, ODU1 and ODUflex can use. In order for the tunnel network design, there must be some gateway nodes which are located at a domain boundary. ODU0, ODU1 and ODUflex can be mapped into ODU2/ODU3 first and that ODU2/ODU3 is then mapped into ODU4. ODU2 Network 3 is only desirable to support GigE and 10GigE services, so all nodes in ODU2 Network 3 only support ODU0 and ODUflex for more economical cost. It doesn't support ODU1 (e.g., STM-16) application. Fu, et al. Expires October 28, 2010 [Page 8] Internet-Draft Multi Stages Multiplexing Configuration April 2010 -- /|12|\ / -- \ / \ -- / ODU2 \-- |11| Network 4 |13| -- \ / -- \ / \ - / \| |/ - Gateway4 | | - - - /|2|\ /|5|\ /|8|\ / - \ / - \ / - \ / \ / \ / \ - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| - \ / - - \ / - - \ / -- \ /Gateway1 \ / Gateway3\ / \ - / \ - / \ - / \|3|/ \|6|/ \|9|/ - - - | -- | |Gateway2 -- | -- -- -- /|15|\ /|18|\ /|21|\ / -- \ / -- \ / -- \ / \ / \ / \ -- / ODU2 \ -- -- / ODU4 \-- -- / ODU3 \ -- |14| Network 5 | |----|17| Network 6 |20|----| | Network 7 |23| -- \ / -- -- \ /-- -- \ / -- \ /Gateway5 \ / Gateway7\ / \ -- / \ -- / \ -- / \|16|/ \|19|/ \|22|/ -- -- -- Figure 3 Gateway 5 is supposed to support the following multi stages multiplexing/demultiplexing capability. Fu, et al. Expires October 28, 2010 [Page 9] Internet-Draft Multi Stages Multiplexing Configuration April 2010 o ODU0-ODU2-ODU4 o ODU0-ODU3-ODU4 o ODU1-ODU2-ODU4 o ODU1-ODU3-ODU4 o ODUflex-ODU2-ODU4 o ODUflex-ODU3-ODU4 Gateway 7 is supposed to support the following multi stages multiplexing/demultiplexing capability. The operator limits the ODU1 application to the local network. There is no any multi-domain ODU1 application which goes into ODU3 Network 7 and vice versa. It doesn't need to support the ODU1-ODU2-ODU4 and ODU1-ODU3-ODU4 multiplexing. o ODU0-ODU2-ODU4 o ODU0-ODU3-ODU4 o ODUflex-ODU2-ODU4 o ODUflex-ODU3-ODU4 Gateway 2 provides demultiplexing to recover the ODU2 from ODU4 and an additional multiplexing of the ODU2 to ODU3 and vice versa. There are several E2E services. o E2E ODUflex 2 (e.g., 10*1.25G TS): It transit 16, Gateway 5, 17, 19, 20, Gateway 7, 22 and 23. o E2E GigE 3: It transit 14, 15, Gateway 5, 17, 19, 20, Gateway 7 and 21. o E2E GigE 4: It transit 15, Gateway 5, 17, 18, Gateway 2, 6, 7, Gateway 3, 9 and 10. o E2E STM-16 2: It transit 15, Gateway 5, 17, 18, Gateway 2, 6,. In Figure 3, the E2E ODUflex 2 (e.g., 10*1.25G TS) and GigE 3 services share the same ODU3 tunnel between Gateway 5 and Gateway 7. Multi stages multiplexing/demultiplexing capability must be configured with ODU0-ODU3-ODU4 in Gateway 5 and Gateway 7 for GigE 3 service. Multi stages multiplexing/demultiplexing capability must be Fu, et al. Expires October 28, 2010 [Page 10] Internet-Draft Multi Stages Multiplexing Configuration April 2010 configured with ODUflex-ODU3-ODU4 in Gateway 5 and Gateway 7 for ODUflex 2 service. There is an ODU 2 tunnel between Gateway 5 and Gateway 3 for the E2E GigE 4 service. Multi stages multiplexing/demultiplexing capability must be configured with ODU0-ODU2-ODU4 in Gateway 5 for GigE 4 service. Multi stages multiplexing/demultiplexing capability must be configured with ODU0-ODU2-ODU3 in Gateway 3 for GigE 4 service. There is an ODU 2 tunnel between Gateway 5 and Gateway 1 for the E2E STM-16 2 service. Multi stages multiplexing/demultiplexing capability must be configured with ODU1-ODU2-ODU4 in Gateway 5 for STM-16 2 service. Multi stages multiplexing/demultiplexing capability must be configured with ODU1-ODU2-ODU3 in Gateway 1 for STM-16 2 service. 3. Requirement for Multi Stages Multiplexing Configuration 3.1. Requirement in the level of the Data Plane This section describes the basic requirements in the Data Plane to support the multi stages multiplexing configuration functions of this document. o Gateway network elements are only located at a domain boundary. Gateway equipment must support the multi stages multiplexing capability in order to introduce new ODU0 and ODUflex signals to an existing network and support multi-domain OTN application based on network tunnel design. o Data Plane of gateway equipment must support different multi stages multiplexing hierarchy (e.g., two or three stages, and so on) and multiple multi stages multiplexing capability. o Data Plane of gateway equipment must support the multi stages multiplexing configuration from Management Plane and/or Control Plane. Gateway equipment must support to check the local data plane capability to see if this kind of multi stages multiplexing/ demultiplexing from MP and/or CP is acceptable on specific interface or gateway node. 3.2. Requirement in the level of Control Plane and Management Plane This section describes the basic requirements for procedures and processes that are used to perform the multi stages multiplexing configuration functions of this document. Fu, et al. Expires October 28, 2010 [Page 11] Internet-Draft Multi Stages Multiplexing Configuration April 2010 o Management Plane must support configuration of multi stages multiplexing hierarchy. * 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 support to config the multi stages multiplexing hierarchy which is determined by path computation entity into the Data Plane for the E2E service. o Control Plane must support configuration of multi stages multiplexing hierarchy which is determined by path computation entity into the Data Plane. * 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 these information. * Path computation element must select a proper kind of multi stages multiplexing/demultiplexing hierarchy of gateway nodes along a specific E2E connection. * Signaling message must carry the multi stages multiplexing/ demultiplexing hierarchy that has been determined by path computation entity. Multi stages multiplexing/demultiplexing hierarchy for a specific service must be configured to data plane after gateway receives the signaling of service creation. 4. 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. Fu, et al. Expires October 28, 2010 [Page 12] Internet-Draft Multi Stages Multiplexing Configuration April 2010 5. IANA Considerations TBD 6. References 6.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. 6.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 13]