You are here: irt.org | RFCs | RFC6456 [ previous next ]
Internet Engineering Task Force (IETF) H. Li Request for Comments: 6456 R. Zheng Category: Informational Huawei Technologies ISSN: 2070-1721 A. Farrel Old Dog Consulting November 2011 Multi-Segment Pseudowires in Passive Optical Networks Abstract This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN). PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager. This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration. This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. Li, et al. Informational [Page 1]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6456. Copyright Notice Copyright (c) 2011 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 ....................................................2 2. Terminology for G-PON/XG-PON ....................................5 3. Multi-Segment Pseudowire over PON Network Reference Model .......6 4. Label Provisioning for Pseudowires over PON .....................9 5. Security Considerations .........................................9 6. References .....................................................10 6.1. Normative References ......................................10 6.2. Informative References ....................................11 1. Introduction The use of PWs in Packet Switched Networks (PSNs) is defined in [RFC3985]. This architecture is extended in [RFC5659] for multi- segment pseudowires (MS-PWs) satisfying the requirements in [RFC5254]. More detail on MS-PWs is provided in [RFC6073]. Li, et al. Informational [Page 2]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 An MS-PW is a useful technology for certain applications where there is an aggregation of paths toward a common point in the network, e.g., mobile backhaul; the segments can be aggregated within tunnels between PW switching points thus improving scalability and reducing the number of control plane adjacencies where a control plane is used. Segments of an MS-PW in a PSN can be set up using manual provisioning (static PWs) or using a dynamic control plane such as the Label Distribution Protocol (LDP) [RFC5036] [RFC4447]. In many scenarios, in access and metro networks, a Passive Optical Network (PON) provides longer distance, higher bandwidth, and better economy than other technologies such as point-to-point Ethernet or Digital Subscriber Line (DSL). Mobile backhaul with PON is already being deployed. Figure A depicts the physical infrastructure of an Optical Distribution Network (ODN). | | |<--Optical Distribution Network-->| | | | branch main | +-----+ fibers fiber Base ------| | | | Stations ------| ONU |\ | | ------| | \ V | +-----+ \ | \ +----------+ | +-----+ \| | | +-----+ Base ------| | | Optical | V | | Stations ------| ONU |---------| Splitter |-------------| OLT | ------| | /| | | | +-----+ / +----------+ +-----+ / +-----+ / Base ------| |/ Stations ------| ONU | ------| | +-----+ Figure A: Typical PON System Architecture In a PON, the Optical Network Unit (ONU) and Optical Line Termination (OLT) are adjacent nodes connected by an Optical Distribution Network (ODN), which consists of optical fibers and optical splitters in a tree topology. The link between each ONU and OLT is simulated as a Li, et al. Informational [Page 3]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 point-to-point link, and there is no path redundancy between them. The OLT resides in the central office, while ONUs reside in customer premises. ONUs are deployed in huge numbers and so they are cost sensitive. More information about ODNs can be found in [G.984.1]. In a mobile backhaul network, many 2G and 3G base stations still use legacy interfaces such as Time-Division Multiplexing (TDM) and ATM. Therefore, these native services must be carried across the PON before they can be carried over the PSN using PWs. This document describes how MS-PWs can be constructed with end segments that operate over the PON and are switched to further segments operated over the PSN. In this case, the base stations are connected by access circuits (ACs) to the ONUs, which act as Terminating Provider Edge (T-PE) nodes. The OLT is a Switching Provider Edge (S-PE). This model is shown in Figure B. Routing protocols and dynamic label distribution protocols such as LDP would significantly increase the ONUs' cost and complexity as they place requirements on both hardware and software. Besides the coding and maintenance of these new protocols, a much more powerful CPU and more memory are also necessary for them to run smoothly. As there is no redundant path between each ONU and the OLT, routing and path selection are not necessary in the PON. Therefore, static provisioning of PW labels between ONUs and the OLT is simple and preferred because it can greatly reduce the cost of an ONU that acts as a T-PE. However, use of a Network Management System (NMS) to provision PWs in a PON would require the network manager to configure each ONU and to configure the OLT once for each PW. Since there may be very many ONUs (and hence very many PWs) in a PON, this requires a large amount of operational effort. Additionally, there is an issue that the configuration of each PW at the OLT and ONU might be inconsistent since these nodes are configured separately. [G.988] defines the G-PON/XG-PON management protocol called the "ONT Management and Control Interface (OMCI)". OMCI is an implementation requirement for all G-PON/XG-PON systems. If OMCI is used to configure PWs on an ONU, no upgrade to an ONU's hardware is required and the extension to the OMCI implementation is negligible. This provides a way of reducing the cost and complexity of provisioning PWs in a G-PON/XG-PON. This document shows how the two technologies (PON and PSN) can be combined to provide an end-to-end multi-segment MPLS PW. The MPLS PWs are also carried over the PON in MPLS Label Switched Path (LSP) tunnels. There is an MPLS LSP tunnel in each direction between each ONU and the OLT in a one-to-one relationship with the underlying G- PON/XG-PON channel. The OLT and ONU perform penultimate hop popping Li, et al. Informational [Page 4]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 (PHP) [RFC3031] on this single-hop LSP so no labels are used on the wire for the MPLS LSP tunnel. There is no change to the operation of MPLS PWs, and MPLS packets are carried by the G-PON link layer according to ITU-T [G.984.3amd1] or XG-PON link layer according to ITU-T [G.987.3]. 2. Terminology for G-PON/XG-PON We defined the following terms derived from [G.987]: o Gigabit-capable Passive Optical Network (G-PON). A variant of the Passive Optical Network (PON) access technology supporting transmission rates in excess of 1 Gbit/s and based on the ITU-T G.984.x series of Recommendations [G.984.1], [G.984.4amd2] and [G.984.3amd1]. o G-PON Encapsulation Method (GEM). A data frame transport scheme used in G-PON systems that is connection oriented and that supports fragmentation of the user data frames into variable sized transmission fragments. o GEM port. An abstraction of the G-PON adaptation layer representing a logical connection associated with a specific client packet flow between the OLT and the ONU. o 10-gigabit-capable Passive Optical Network (XG-PON): A PON system supporting nominal transmission rates on the order of 10 Gbit/s in at least one direction, and implementing the suite of protocols specified in the ITU-T G.987.x series Recommendations. o XG-PON encapsulation method (XGEM): A data frame transport scheme used in XG PON systems that is connection oriented and that supports fragmentation of user data frames into variable-sized transmission fragments. o XGEM port: An abstraction in the XG-PON transmission convergence (XGTC) service adaptation sublayer representing a logical connection associated with a specific client packet flow. o Optical Distribution Network (ODN). In the PON context, a tree of optical fibers in the access network, supplemented with power or wavelength splitters, filters, or other passive optical devices. o Optical Line Termination (OLT). A device that terminates the common (root) endpoint of an ODN; implements a PON protocol, such as that defined by ITU-T G.984 series; and adapts PON PDUs for uplink communications over the provider service interface. The OLT provides management and maintenance functions for the Li, et al. Informational [Page 5]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 subtended ODN and ONUs. In this document, the OLT is a network element with multiple PON ports and uplinks that provide switching capability to the PSN. o Optical Network Termination (ONT). A single subscriber device that terminates any one of the distributed (leaf) endpoints of an ODN, implements a PON protocol, and adapts PON PDUs to subscriber service interfaces. An ONT is a special case of an ONU. o Optical Network Unit (ONU). A generic term denoting a device that terminates any one of the distributed (leaf) endpoints of an ODN, implements a PON protocol, and adapts PON PDUs to subscriber service interfaces. In some contexts, an ONU implies a multiple subscriber device. In this document, an ONU is a Provider Edge (PE) node with one or more ACs that map to the service interfaces. The ONU acts as a T-PE. o ONT Management and Control Interface (OMCI). The management and control channel between OLT and ONT in PON. The OMCI protocol runs between the OLT Controller and the ONT Controller across a GEM connection that is established at ONT initialization. The OMCI protocol is asymmetric: the Controller in the OLT is the master and the one in the ONT is the slave. A single OLT Controller using multiple instances of the protocol over separate control channels may control multiple ONTs. The OMCI protocol is used to manage the ONT in areas of configuration, fault management, performance, and security. o Passive Optical Network (PON). An OLT connected, using an ODN, to one or more ONUs or ONTs. 3. Multi-Segment Pseudowire over PON Network Reference Model [RFC5659] provides several pseudowire emulation edge-to-edge (PWE3) reference architectures for the multi-segment case. These are general models extended from [RFC3985] to enable point-to-point pseudowires through multiple PSN tunnels. A G-PON/XG-PON consists of an OLT, an ODN, and multiple ONUs. The ODN is actually a fiber tree that provides physical connections between the OLT and the ONUs. G-PON/XG-PON has its own physical layer and link layer. A GEM/XGEM port is a logical point-to-point connection between the OLT and each ONU over GPON Transmission Convergence (GTC) layer/XG-PON transmission convergence (XGTC) layer. There can be more than one GEM/XGEM port between the OLT and an individual ONU. Each GEM/XGEM port can be assigned different Quality of Service (QoS) and bandwidth. Li, et al. Informational [Page 6]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 Figure B shows how the MS-PW architecture is applied to a network comprising a PON and a PSN. The Terminating PE1 (TPE1) is an ONU and the Switching PE1 (SPE1) is an OLT. One or more PWs run between the ONU and the remote end system (TPE2) to provide service emulation between Customer Edges (CEs) (CE1 and CE2). In each of the PON and PSN, the PW segments are carried in PSN tunnels. In the PSN, the tunnel is established and operated as normal for PWs (see [RFC3985]). In the PON, the tunnel used is a single-hop MPLS LSP tunnel so that the OLT and ONU are label edge routers. The OLT and ONU make use of PHP on the MPLS LSP tunnel. Since this is a single-hop LSP (there are no MPLS-capable nodes between the OLT and ONU), this means that there is no MPLS encapsulation for the MPLS LSP tunnel on the wire (that is, no label or shim header is used). This results in the on-wire encapsulations shown in Figure C. Native |<------Multi-Segment Pseudowire------>| Native Service | GEM/XGEM | Service (AC) | |<--Port-->| | (AC) | | | | | | | | | PSN | PSN | | | | |<-Tunnel->| |<-Tunnel->| | | | V V V V V V | | +----+ +-----+ +----+ | +----+ | |TPE1|===========|S-PE1|==========|TPE2| | +----+ | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| | | CE1| | | | | | | | | |CE2 | | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| | +----+ | | |===========| |==========| | | +----+ Base ^ +----+ +-----+ +----+ ^ Station | Provider Edge 1 ^ Provider Edge 2 | | ONU | | | PW switching point | | OLT | | | |<------------------ Emulated Service --------------->| Figure B: MS-PW over PON Network Reference Model Li, et al. Informational [Page 7]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 Base ----AC-- TPE1--PW over PON--SPE1--PW over PSN--TPE2--AC------ Station ---------- ---------- -------- |Packetized| |Packetized| -------- |Native | |Native | |Native | |Native | |Service | |Service | |Service | |Service | -------- |----------| |----------| -------- |Control | |Control | |Word | |Word | |----------| |----------| |PW Label | |PW Label | |----------| |----------| |GEM/XGEM | |MPLS | |----------| |Tunnel | |GPON/XGPON| |Label | |-Phy | | | ---------- |----------| |Link Layer| |----------| |Phy | ---------- Figure C: On-Wire Data Encapsulations for MS-PWs It should be noted that all PW segments are of the same technology, which is packet encapsulated. The use of the PW label enables multiple PWs to be multiplexed over a single GEM/XGEM port within the MPLS LSP tunnel. This enables the traffic for multiple base stations to be kept separate and allows different services and separate ACs for a single base station to be supported. Furthermore, the multiple ACs at an ONU can belong to different native services. At the same time, each ONU can support more than one GEM/XGEM port (each supporting a single MPLS LSP tunnel) connecting it to the OLT. This allows greater bandwidth and so more PWs. It may also be used to provide a simple way to aggregate PWs intended to be routed across different PSN tunnels in the core network, or even across different core networks. At present, Ethernet over GEM/XGEM is the dominant encapsulation in G-PON/XG-PON. For fast deployment of MPLS over G-PON/XG-PON, putting MPLS PWs over Ethernet over GEM/XGEM is an alternative way of transporting MPLS PWs over G-PON/XG-PON with existing hardware. Li, et al. Informational [Page 8]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 4. Label Provisioning for Pseudowires over PON For an MS-PW with a segment running over a PON, where the OLT acts as an S-PE and the ONU as a T-PE, PW provisioning can be performed through static configuration, e.g., from an NMS. However, in this model, each ONU has to be configured as each PW is set up. The huge number of ONUs (and PWs) makes this method quite forbidding. The labor of provisioning static labels at the ONUs for PWs can be significantly reduced by using a management protocol over PON. This approach keeps the ONU simple by not requiring the implementation of a new dynamic control protocol. The usual management protocol in a G-PON/XG-PON system used to manage and control ONUs is OMCI. It is used to perform all configuration of the G-PON/XG-PON physical layer and data GTC/XGTC layer on ONUs. Per [G.984.4amd2] and [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels from ONUs to OLT. When using OMCI to provision PWs in a G-PON/XG-PON, the network manager sends configuration information to the OLT only. The OLT will select suitable PW labels and send all PW and MPLS LSP tunnel parameters to the ONUs through OMCI. The AC can be identified in the OMCI signaling so that the network manager does not need to configure the PWs at each ONU. OMCI supports the configuration of a number of PW types including TDM, ATM, and Ethernet. The protocol can also be used to allow the ONU to notify the OLT of the status of the AC. 5. Security Considerations This document describes a variation of a multi-segment pseudowire running over an MPLS PSN, in which one (or both) of the MPLS PSNs that provides connectivity between a T-PE and its associated S-PE is replaced by a G-PON/XG-PON PSN. The security considerations that apply to the PW itself [RFC3985] [RFC4385] are unchanged by this change in PSN type. For further considerations of PW security, see the security considerations section of the specific PW type being deployed. G-PON/XG-PON [G.987.3] [G.984.3amd1] includes security mechanisms that are as good as those provided in a well-secured MPLS PSN. The use of a G-PON/XG-PON PSN in place of an MPLS PSN therefore does not increase the security risk of a multi-segment pseudowire. Protecting against an attack at the physical or data link layer of the PON is out of the scope of this document. Li, et al. Informational [Page 9]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 The MPLS control plane and management plane mechanisms are unchanged by this document. This document introduces OMCI as a provisioning mechanism that runs between the OLT Controller and the ONT Controller across a GEM connection that is established at ONT initialization. In other words, the protocol runs on an in-fiber control channel. That means that injection and modification of OMCI messages would be very hard (harder, for example, than injection or modification in an MPLS Associated Channel Header (ACH) that has been accepted to provide adequate security by isolation ([RFC4385] and [RFC5586]). 6. References 6.1. Normative References [G.984.1] ITU-T, "Gigabit-capable passive optical networks (GPON): General characteristics", March 2008, <http://www.itu.int/rec/T-REC-G.984.1-200803-I>. [G.984.3amd1] ITU-T, "Gigabit-capable Passive Optical Networks (G-PON): Transmission convergence layer specification", February 2009, <http://www.itu.int/rec/T-REC- G.984.3-200902-I!Amd1>. [G.987] ITU-T, "10-Gigabit-capable passive optical network (XG- PON) systems: Definitions, abbreviations, and acronyms", October 2010, <http://www.itu.int/rec/T-REC- G.987-201010-I>. [G.987.3] ITU-T, "10-Gigabit-capable passive optical networks (XG- PON): Transmission convergence (TC) layer specification", October 2010, <http://www.itu.int/rec/T-REC- G.987.3-201010-I/en>. [G.988] ITU-T, "ONU management and control interface (OMCI) specification", October 2010, <http://www.itu.int/rec/T- REC-G.988-201010-I>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. Li, et al. Informational [Page 10]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008. [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. 6.2. Informative References [G.984.4amd2] ITU-T, "Gigabit-capable passive optical networks (G-PON): ONT management and control interface specification", November 2009, <http://www.itu.int/rec/T-REC- G.984.4-200911-I!Amd2>. [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. Li, et al. Informational [Page 11]
RFC 6456 Multi-Segment Pseudowires in PON November 2011 Authors' Addresses Hongyu Li Huawei Technologies Huawei Industrial Base Shenzhen China EMail: hongyu.lihongyu@huawei.com Ruobin Zheng Huawei Technologies Huawei Industrial Base Shenzhen China EMail: robin@huawei.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Li, et al. Informational [Page 12]