You are on page 1of 28

Technical White Paper for the Unified Control Plane of the SingleBackbone Solution

Technical White Paper for the Unified Control Plane of the SingleBackbone Solution
1 Overview .......................................................................................................................1 2 Model of Unified Control Plane  ......................................................................................2 2.1 Peer Model ....................................................................................................................2 2.2 Overlay Model ...............................................................................................................2 2.3 Border Peer Model .........................................................................................................3 3 Key Technologies for a Unified Control Plane  .................................................................5 3.1 GMPLS ..........................................................................................................................5
3.1.1 Overview .................................................................................................................................................5 3.1.2 Basic GMPLS Protocols ............................................................................................................................6 3.1.3 Multi-Layer Control .................................................................................................................................6 3.1.4 Related Standards ...................................................................................................................................7

3.2 UNI

...............................................................................................................................7

3.2.1 Overview .................................................................................................................................................7 3.2.2 Basic Functions of UNI .............................................................................................................................9 3.2.3 Relevant Standards ................................................................................................................................12

3.3 PCE

.............................................................................................................................13

3.3.1 Overview ...............................................................................................................................................13 3.3.2 PCE Deployment Mode ..........................................................................................................................13 3.3.3 PCE Computation Models ......................................................................................................................16 3.3.4 PCE Discovery and Load Balancing .........................................................................................................19 3.3.5 Communication Between PCCs and PCEs, PCEs and PCEs ......................................................................19 3.3.6 Relevant Standards ................................................................................................................................19

4 Typical Solutions and Application Scenarios  .................................................................20 4.1 UNI + Centralized Transport PCE ..................................................................................20 4.2 UNI + Centralized Transport PCE ..................................................................................20 4.3 UNI + Centralized Multi-Layer PCE ...............................................................................21 5 Summary  .....................................................................................................................22 6 Acronyms and Abbreviations ........................................................................................23 7 References  ...................................................................................................................24

because it brings the following changes: •• Enables a user to freely apply for bandwidth or release bandwidth. •• Enables quick and easy service provisioning. GMPLS. •• Enables equipment to provide services at different service level agreements (SLAs). by providing various protection recovery approaches. semi-automatic synergy. A unified control plane refers to a control plane with integration of various switching technologies. which can be used flexibly. timeslot switching. PCE. control plane 1 Overview The idea of SingleBackbone Solution is IP&OTN Synergy. such as packet switching. UNI.Abstract This white paper presents details on the technologies relevant to the control plane involved in the SingleBackbone solution. •• Facilitates network management. •• Improves service reliability. Key Words MPLS. and port/fiber switching. Intelligent synergy. and there are 3 phases for IP&OTN Synergy: manual synergy. ASON. •• Increases network resource utilization. wavelength switching. 1 . During the last two phases. the control plane will play an important role .

In addition. The client layer and server layer do not exchange routing information in any way. and scalability. the IP/MPLS network functions as the client layer (clients) and the optical/GMPLS network functions as the server layer (network).2 Model of Unified Control Plane Currently in the industry. Then. and even fibers. The following sections use a network with the IP/MPLS layer and optical layer as an example to illustrate the three models in aspects of features. that is. Then. all nodes run generalized multi-protocol label switching (GMPLS) to control Layer 3 packets. each layer only knows the routing information of that one.2 Overlay Model In this model. and border peer model. GMPLS floods the network topology information to all routers and optical nodes. interaction between MPLS and GMPLS is essential. To overcome the 2 . That is to say. To achieve an IP & Optical control plane. MPLS is mature currently and has been deployed by router suppliers. a unified control plane is presented in three models. Therefore. This situation cannot be changed in a short term. 2. 2. which has not been allegedly supported by any supplier.1 Peer Model NNI NNI NNI All GMPLS. respectively. making it less likely to change MPLS to GMPLS. a label switched path (LSP) can be created to provide an end-to-end path. security. each node needs to interpret the topology information and compute paths involving networks with different switching capabilities based on the topology information. wavelengths. This model is a notional model. overlay model. MPLS and GMPLS control IP and optical networks. The major challenges for this model are network management. and their strengths and weaknesses. peer model. Layer 2 packets. time division multiplexing (TDM) services. one domain In this model.

Such a model fits the layered network model recommended in ITU-T G. The client layer and server layer can exchange information only through UNI interfaces. In this model. the switched connections (SCs) set up by the client layer. the client layer obtains or releases resources on optical connections. In process of information exchange. Then. may not be optimal. overheads are required to plan. For example. and manage transport resource IDs at UNI reference points. There are. A border router has two roles: one as a router involved in control over MPLS domains and the other as an optical node involved in control over GMPLS domains. •• As the route and topology information at one layer is separate from that at another layer. If a border router runs MPLS and GMPLS. the client side is UNI-C and the network side is UNI-N. A network in overlay model has definite layers. and is secure.3 Border Peer Model Compared with the peer model and overlay model. three kinds of reference points are defined: user network interface (UNI) reference points between the client layer and server layer. deleting. routers with direct connections to optical nodes are referred to as border routers. external network-to-network interface (E-NNI) reference points between different domains at the server layer. the client layer first sends requests for creating. which sends requests to the server layer according to the current UNI reference points.UNI-N UNI-C UNI R1 INNI UNI-N UNI-C R2 Optical/GMPLS IP/MPLS limitations of this model. the border peer model is a compromised model. however. 2. At a UNI reference point. is easy to scale and manage. The working and protection paths may have overlapped routes. it maintains traffic engineering (TE) topology information 3 . or modifying connections by running UNI signaling to the server layer.805. allocate. the following challenges for overlay model. and internal network-to-network interface (I-NNI) reference points between different nodes in each domain at the server layer. •• This model requires extra overheads for management.

deployment of the border peer model requires that routers and optical network devices be supplied by the same supplier. making interoperation of ASON products difficult. the I-NNI protocols running on ASON products of different suppliers are different. except the capability of adaptation to optical interfaces. even though they all run the RSVP-TE protocol. That is. GE interfaces. This model combines advantages of the peer model and overlay model. This model has strengths against the overlay model. This decreases flexibility in network construction and conflicts with ASON interworking.R1 INNI INNI BR1 Optical/GMPLS IP/MPLS BR2 R2 regarding both the IP network and optical network. optical switching capabilities are not required at routers. the suppliers may adopt the PNNI protocol. has to determine which border router is better. CR-LDP protocol. however. Currently. when two border routers set up connections in between. routers are connected to optical network devices through POS interfaces. the ASON products cannot interwork. these suppliers make private extensions of the RSVP-TE protocol to provide more functions and ensure better reliability. based on the optical network topology. however. a border router can compute better server paths across the optical network. because relevant standardization fails to go as fast as product development. a non-border router. For example. Directly using optical network devices is far away from sufficient to deploy GMPLS. As a result. Therefore. Though most suppliers adopt the RSVP-TE protocol. Many issues have to be resolved to deploy GMPLS on routers. 4 . or GE colored optical interfaces. which is in focus of operators. To implement this model is not so simple as to run GMPLS intended for the optical network on border routers. It. Other routers maintain only topology information regarding the IP network and all optical nodes maintain only topology information regarding the optical network. Currently. and RSVP-TE protocol. When setting up an end-to-end connection. including separate working and protection paths. has shortcomings in implementation and deployment. These shortcomings eclipse advantages of this model. Hence.

and delete optical connections.709 OTN).1 Overview An ASON is a next-generation optical network. •• Shared risk link group (SRLG): Paths for a service under 1+1 protection can include links in different SRLGs. or deleted by means of signaling control. and ring protection). and frame relay). ATM. The control plane for an ASON is based on GMPLS. •• Link-level protection: GMPLS diffuses and uses the protection capabilities of links (such as 1+1. GMPLS has the following features: •• Separate control channel and data channel: A fault on the control channel does not affect data transmission over the data channel. Originally. With a design to support different network technologies. with switching and transport features. MPLS is designed for the data plane and focuses on transport of data streams. 5 . and packet switching (MPLS and MPLS-TP). wavelength switching (WDM and G. create. Unlike MPLS. restore. timeslot switching (TDM). •• Bidirectional LSP: A bidirectional LSP can be set up in only one signaling process. Layer 2 switching (Ethernet. UNI. This improves service reliability. This chapter presents details on these key technologies. GMPLS has extended to fiber/port switching. An optical network can be considered as a transport plane controled and managed by GMPLS and an MPLS data network as a data plane also controled and managed by GMPLS. and PCE. 1:1. Unlike a traditional optical network.1 GMPLS 3. GMPLS is designed for the control plane and focuses on management of connections. which enables the network to automatically compute paths. Currently. •• Bandwidth allocation by priority: Bandwidth resources are allocated by priority. GMPLS is based on MPLS. GMPLS can control both an optical network and an MPLS data network. an ASON has a control plane. where paths are computed based on user requirements and optical connections are automatically created.3 Key Technologies for a Unified Control Plane The key technologies for a unified control plane are GMPLS. GMPLS is intended to apply MPLS to control wavelength switching. they greatly differ from each other as they extend the basic protocols. Though GMPLS and MPLS are based on the same set of protocols (such as RSVP as the signaling protocol and OSPF as the routing protocol). 3. restored.1.

protection. •• Connection management: GMPLS enables end-to-end connections for services. The client layer invokes service on the server layer through UNIs. and signaling protocols. routing protocols.3 Multi-Layer Control The following figure shows a simplified model of GMPLS controlling a multilayer network. Source Client layer GMPLS UNI GMPLS UNI Dest Virtual client-layer link Service layer Lowest layer GMPLS UNI Virtual service-layer link GMPLS UNI An upper layer is the client layer for the lower layer and a lower layer is the server layer for the upper layer. 3. and provides traffic engineering (TE). provisions routes. On the control plane. query. GMPLS enables the following functions: •• Auto-discovery of resources: Available resources on a network are automatically discovered and resource information is automatically updated. 3. which are based on extensions of protocols related to MPLS-TE.2 Basic GMPLS Protocols The common control and measure plane (CCAMP) workgroup of IETF studies and defines GMPLS-related protocols. such as IP over SDH over WDM. or IP over DWDM network. •• Route control: GMPLS automatically discovers and updates the network topology. calculates service paths. as well as creation. and restoration of the connections. modification. IP over OXC over WDM. 6 .1.1. deletion. These GMPLS-related protocols can be classified into link management protocols.•• Multi-layer network control: A multi-layer network. can be controlled in a unified manner.

see the following table. In this approach. such as CR-LDP. RFC 4204. For more information regarding history of the OIF. •• Another optional approach is PCE. Then. RFC 3473. PNNI. For more information regarding PCE. but resources at the server layer may be wasted. RFC 4258. RFC 4139. LSPs are easy to manage but optimal end-to-end LSPs cannot be computed.1. RFC 3945. optimal paths can be computed.1 Overview In the late 1990s. The OIF UNI protocol is based on the IETF RSVP protocol. were based on different signaling protocols. also support OIF UNI. the OIF UNI standard has been mature and the major optical network equipment suppliers. RFC 5212 3. This approach is simple and fits the layer network model. the OIF has successfully organized many internetworking tests and released relevant standards. which. the TE topology at the server layer is visible to the client layer. The TE topology at the server layer is not visible to the client layer and LSPs at the server layer are expressed by link at the client layer. RFC 4873. certain suppliers and operators established the optical internetworking forum (OIF). with the 7 . RFC 4872. In this approach.2 UNI 3. GMPLS-related standards are mature and they are: IETF. RFC 4203. there are three methods to express and compute the multi-layer paths: •• LSPs at the server layer are advertised as virtual TE links at the client layer. In this approach. In addition. That is. The TE topology at the client layer is a virtual topology. Since 2001. certain telecommunication equipment suppliers showcased their ASON products. however." 3.4 Related Standards Currently. links must be advertised as links with multiple switching capabilities. and RSVP-TE. RFC 4202. the client layer can compute end-to-end paths according to the topologies at the client layer and server layer. RFC 4209. RFC 3209. there is a centralized PCE at each layer and PCEs at these layers coordinate with each other to compute multi-layer paths.2. including Huawei.3 "UNI + Centralized Multi-Layer PCE. After years of development. which focused on standardization and testing related to internetworking. •• The client layer shares the TE topology view of the server layer. see section 4. To ensure internetworking between these ASON products.For multi-layer control. RFC 3471.

internetworking of GMPLS UNI is demonstrated on MPLS 2004/2005/2006.0 R2 and E-NNI 1. One is OIF UNI stipulated by the OIF and the other is GMPLS UNI stipulated by the IETF.0 UNI 2. though making it complex.0 R2 E-NNI signaling 1. the connections between UNI-Cs are not end-to-end LPSs. and certain other suppliers.0 internetworking testing on OFC. Such a design ensures a flexible and independent I-NNI domain. Major router suppliers support GMPLS UNI. In this model. but multiple sessions (source UNI session. or iPOP 2005/2006 held by ISOCORE with focus on data or IP & Optical synergy. most optical network equipment suppliers support OIF UNI.0 and ENNI 1. The OIF organized UNI 1.0 2005 2007 ENNI OSPF 1. Internetworking of OIF UNI and GMPLS UNI is also demonstrated on iPOP. E-NNI session. and sink UNI 8 . Huawei also participated in the testing. there are two UNI protocols. The OIF organized UNI 2. OIF UNI has not been acknowledged by the IETF and the IETF even presents GMPLS UNI.0 signaling UNI 2. I-NNI session.0 and ENNI 1. Therefore. support both. The OIF organized the first UNI 1.0 . OIF UNI considers an I-NNI domain as a black box where different signaling protocols can be running. Huawei also participated in the testing. including Huawei.0 internetworking testing on SuperComm.RSVP 2008 former extending the later.0 internetworking testing on SuperComm. The OIF organized internetworking testing with the topic of "On-Demand Ethernet Services". Now. Domain A CR-LDP OIF UNI NE TNA UNI Session ENNI Session INNI Session ENNI Session FA Session NE OIF E-NNI NE NE Domain B RSVP-TE OIF E-NNI NE NE TNA UNI Session Domain C PNNI OIF UNI Client Client The previous figure shows an OIF UNI model.Year 1998 Event Certain suppliers and operators established the OIF together. Currently. Released Standard 2001 UNI 1. The OIF organized the first UNI internetworking testing on SuperComm.0 2003 2004 UNI 1. Huawei also participated in the testing.

The RSVP-TE protocol is used as UNI signaling. through a UNI interface. In this model. is not that simple. the suppliers extend the protocol to satisfy their own requirements. the relevant functions and features also differ from each other. This requires special configuration management and extension of OSPF to flood the reachability information of TNA addresses. OIF UNI defines a TNA address for a UNI interface.2 Basic Functions of UNI With the help of UNI. I-NNI signaling. OTN connections. making I-NNI internetworking difficult. however. Therefore. Calls refer to association relationships between end nodes or key transport nodes (such as border nodes on a network). standardization (especially in the aspect of protection restoration) lags behind product development. In this manner.2. Though most ASON equipment suppliers choose RSVP-TE. Calls also refer to contractual relationships between end nodes. but only builds the association relationships between one or more connections. One call supports one instance of user service. and thus there is only one RSVP session. Connections between UNI-Cs are end-to-end LSPs. The requested connections can be either unidirectional or bidirectional. a user can freely send a request for creating or deleting a connection to a transmission network. Consequently. conversion between standard objects and non-standard objects is essential at a UNI-N node. or Ethernet connections. This group of connections provide end-to-end data transfer service for 9 .session). and are used to manage a group of connections. A call itself does not ensure connectivity of the link for user service transmission. the address space and addressing approach used at a UNI interface are the same as those for the network domain. and E-NNI signaling. Call Control UNI has the call control function. 3. Client GMPLS UNI NE NE Domain A RSVP-TE GMPLS NE NE Domain B RSVP-TE GMPLS NE Domain C RSVP-TE GMPLS UNI NE Client E2E Session FA Session FA Session FA Session LSP Stitching The previous figure shows a GMPLS UNI model. and can be SDH/SONET connections. simply and easily. Implementation of GMPLS UNI.

I-NNI UNI E-NNI Call (end-to-end) Call segments Connections UNI Signaling UNI signaling refers to the messages exchanged between UNI-C and UNI-N entities. such as bandwidth. A connection is set up between access points as required. and capability negotiation between end nodes. the signaling messages are carried over a communication link between the UNI-C and the UNI-N. For an out-fiber channel. or modifying a connection in a call. •• Modifies calls. •• Modifies connections. such as bandwidth. A connection is deleted between access points as required. The following figure shows a model of calls and connections. separate from the data-bearing links. Service parameters. Parameter settings about calls and connections can be queried. UNI signaling has the following functions: •• Sets up connections. are modified easily by deleting a connection from a call. Transport Channel for UNI Signaling UNI-C and UNI-N need to exchange signaling messages to access various types of services on the transport network. the signaling messages are carried over a communication link embedded in the data-carrying link between the UNI-C and the UNI-N. a physical channel must be available between UNI-C and UNI-N for them to exchange signaling messages. are modified easily. The control channel can be an in-fiber channel or an out-fiber channel. Hence. users enjoy various types of services on the transmission network. Such a channel refers to a control channel. •• Deletes a connection. Parameter settings. By exchanging these messages. Setup of call involves policy verification. A control channel can be available in the following ways: •• Transmitting UNI signaling through DCC overhead bytes of SDH 10 . adding a connection to a call. For an in-fiber channel. network security authentication. •• Queries status of calls and connections. authorization.users.

In this case. In this case. In this case. In this case. DCC overhead bytes of SDH can be used as a control channel to transmit UNI signaling. In this case. the control channel is also an in-fiber channel. multiple control channels are generated. If there are multiple Ethernet links between UNI-C and UNI-N. one control channel can be selected according to the local policy to transmit UNI signaling. 11 . the control channel is also an in-fiber channel. •• Transmitting UNI signaling through GCC0 overhead bytes of OTN Bidirectional OTN links UNI-C UNI-N UNI signaling transferred over GCC0 overhead bytes When there is an SDH link between UNI-C and UNI-N. the control channel is an in-fiber channel. GCC0 overhead bytes of OTN can be used as a control channel to transmit UNI signaling.3ah OAM frame. If there are multiple SDH links between UNI-C and UNI-N. multiple control channels are generated. Ethernet OAM frames can be used as a control channel to transmit UNI signaling. The following table lists the format of an IEEE 802.Bidirectional SDH links UNI-C UNI-N UNI signaling transferred over DCC overhead bytes When there is an OTN link between UNI-C and UNI-N. In this case. If there are multiple OTN links between UNI-C and UNI-N. one control channel can be selected according to the local policy to transmit UNI signaling. one control channel can be selected according to the local policy to transmit UNI signaling. multiple control channels are generated. •• Transmitting UNI signaling through Ethernet OAM frames When there is an Ethernet link between UNI-C and UNI-N.

OIF-UNI-02. OIF-UNI-01. the control channel is an out-fiber channel.0-R2-Common. the UNI-relevant standards are as follows: •• IETF: RFC 4208. RFC 4974 •• OIF: OIF-UNI-01. an Ethernet port must be specified to transmit signaling messages.0-RSVP 12 . In this case. OIF-UNI-02.Field Size in Octets 6 6 2 1 2 1 3 39-1493 4 Fields in MAC Frame Destination Address Source Address Type/Length Subtype Flags Code Data/Pad FCS Value (s) 0x01-80-C2-00-00-02 (Slow_Protocols_ Multicast address) UNI 1.0-R2-RSVP.2. •• Transmitting UNI signaling through an exclusive signaling channel A bidirectional connection can be set up between UNI-C and UNI-N to exclusively transmit UNI signaling. In this case.3 Relevant Standards Currently. •• Transmitting UNI signaling through an external IP transmission network Bidirectional data links UNI-C UNI signaling transmitted through an external IP transmission network IP transmission network UNI-N UNI signaling can also be transmitted through an external IP transmission network. 3.0 0x88-09 (Slow_Protocols_Type field value) 0x03 (OAM) 0xFE (vendor unique) 0x00-0F-10 (OIF OUI) Data – IP packet as described in the protocol-specific IA The data field in an OAM frame can be used to carry UNI signaling messages. When there are multiple logical Ethernet ports at a UNI interface.0Common. the control channel is an out-fiber channel.

a PCE is a function module of a node. paths must be computed based on constraints to achieve traffic engineering.3. If distributed path computation is used. Therefore. On a multi-domain network. On a large network. Each node with the path computation function can be referred to as a PCE node. can compute optical multi-domain paths. when collaborating with each other. the path computation elements in these domains must collaborate with each other to compute optimal multi-domain paths. the PCE sends the computation results to the requester or path computation client (PCC). Path computation requests in each domain can be sent to the PCE in the domain. Multiple PCEs. A domain in this document may be one or multiple IGP areas or ASs. PCE Inside a Node In this mode. Routing protocol TED Adjacent node PCE Path computation request or response Service request Signaling processing Signaling protocol Signaling processing PCE integration node 13 .3. each node must have powerful capabilities of path computation. After finishing path computation.3.3 PCE 3.2 PCE Deployment Mode A PCE can be deployed in various modes. 3.1 Overview On an MPLS or GMPLS network. the topology of each domain is not visible to other domains. A PCE has powerful computation capabilities. path computation based on constraints is complex and requires powerful computation capabilities on relevant elements. to compute optical end-to-end multi-domain paths. leading to high costs at each node. The PCE function can be deployed on either a network node or an external server. PCE is such a path computation technology intended to satisfy the preceding requirements. A PCE is responsible for path computation in one domain.

Multiple PCEs Computing Paths Section by Section In this mode. Stand-alone PCE server Routing protocol TED PCE Path computation request or response Source node Service request Signaling processing Signaling protocol Adjacent node Signaling processing The previous figure illustrates the process of establishing a TE LSP when the PCE function is available on an external node. one PCE does not have the topology information of the entire network and thus cannot compute end-to-end paths. When receiving a request for establishing a TE LSP. such a node sends a path computation request to the PCE server. the node receives the path computation result and triggers the signaling process to send signaling messages with the request for establishing a TE LSP to a downstream node. the node receives the path computation result and triggers the signaling process to send signaling messages with the request for establishing a TE LSP to a downstream node. A node with the PCE function can be a node on the network or a stand-alone path computation server. To obtain required paths. After the PCE finishes path computation. A common node does not have the PCE function. the source node asks the PCE server to compute a path. a PCE is deployed on a stand-alone node and works as a server.The preceding figure shows a typical centralized PCE node. the node asks the PCE to compute a path. Such a path needs further computation. PCE Outside a Node In this mode. This node exchanges TE information with an adjacent node by running a routing protocol and saves the TE information in TED. but a section of a path. providing PCE service to other nodes. When receiving a request for establishing a TE LSP. After the PCE finishes path computation. 14 . The path sent back by the PCE is strict in the first section but loose in the reset sections.

the intermediate node continues the signaling process and sends signaling messages with a request for establishing a TE LSP to a downstream node. Multiple PCEs Computing Complete Paths Together In this mode. the source node asks the first PCE to compute a path. the intermediate node asks the second PCE to compute the rest sections of the path. a PCE does not have the topology information about the entire Stand-alone PCE server Stand-alone PCE server TED TED PCE communication protocol PCE PCE Path computation request or response Service request Signaling protocol Signaling protocol Signaling processing Signaling processing Signaling processing Source node Intermediate node Adjacent node 15 . When finishing path computation.Stand-alone PCE server Stand-alone PCE server TED TED PCE PCE Path computation request or response Service request Signaling protocol Path computation request or response Signaling protocol Signaling processing Signaling processing Signaling processing Source node Intermediate node Adjacent node As shown in the previous figure. when receiving a request for establishing a TE LSP. When receiving the path section. the source node triggers the signaling process and sends signaling messages with a request for establishing a TE LSP to a downstream node. When the signaling messages reach an intermediate node (for path re-computation). This PCE computes only a section of a path and sends the path section to the source node.

LSR H1. When receiving the path computation result. LSR H3. 16 . a PCE interacts with other PCEs to compute an end-to-end path and then sends back the path computation result to the requester. multi-PCEs in collaboration to compute multi-domain paths). the backup PCE takes over the job of path computation. In this model. The PCE cannot compute an end-to-end path and thus requests other PCEs to collaborate to compute such an end-to-end path. one PCE computes multi-layer paths. To avoid this problem. LSR L1. multiple PCEs are responsible for computing paths in one domain. the source node triggers the signaling process and sends signaling messages with a request for establishing a TE LSP to a downstream node. a path can be computed by one PCE (singlePCE path computation) or multiple PCEs (multi-PCE path computation. and LSR H4 form the upper-layer network and LSR H2. or freely selects a PCE for path computation. for example. a PCE in a domain is responsible for computing all paths in the domain.3 PCE Computation Models Centralized Computation In this model. when receiving a request for establishing a TE LSP. A domain refers to one or multiple IGP areas or ASs. The PCE can be either an external server (PCE outside a node) or a designated node (PCE inside a node). all PCCs send path computation requests to a PCE to obtain paths. Each PCC can be associated with a PCE.3.network. or a group of network nodes. Single-PCE Multi-Layer Path Computation In this model. In this model. LSR H2. The preceding figure shows a simple two-layer network. a fault on the PCE results in networkwide path computation failures. the first PCE obtains an end-to-end path and sends the path computation result to the source node. Each PCE saves the topology information about the multi-layer network and runs the algorithm for computing multi-layer paths. LSR L2. the source node asks the first PCE to compute a path. When failing to compute an end-to-end path. In this case. a backup PCE can be specified. When the active PCE is faulty. Distributed Computation In this model. By means of interactive computation. As shown in the previous figure. 3.

a PCE computes the H1-H2-L1-L2-H3-H4 path according to the network topology information. multiple PCEs need to collaborate with each other. After connections are set up along the section. to compute a path from LSR H1 to LSR H4. 17 . PCE Hi LSR H1 LSR H2 PCE Lo LSR L1 LSR L2 LSR H3 LSR H4 The previous figure shows a multi-layer network. the process for computing a path from layer H1 to layer H4 is as follows: •• LSR H1 sends a request for computing an H1-to-H4 path to PCE Hi. Then. A PCE saves topology information about the two layers of networks and thus can compute end-to-end multilayer paths. For example. Assume that PCE Hi is responsible for computing paths at the upper layer and PCE Lo is responsible for computing paths at the lower layer. A PCE at each layer is responsible for computing paths at the layer. The H2-L1-L2-H3 section of the path is at the lower layer. To compute end-to-end multi-layer paths. •• PCE Hi selects H2 or H3 as an ingress or egress node on the network at the lower layer. a TE link can be advertised to the upper layer and then connections at the upper layer can be set up.PCE LSR H1 LSR H2 LSR H3 LSR H4 LSR L1 LSR L2 and LSR H3 form the lower-layer network. Multi-Layer PCE Path Computation In this model. one PCE does not save the topology information about all layers.

In the case of synchronous computation. When signaling reaches the ingress node on the lower-layer network. multiple paths must be computed. a PCE computes a group of paths (paths up to certain constraints. a PCE considers multiple requests from multiple stand-alone request messages or one message as stand-alone requests for path computation and places the path computation results standalone response messages sent to the PCC or places multiple computation results in one response message sent to the PCC. A PCC can specify synchronous computation or asynchronous computation in a path computation request sent to a PCE. multiple paths are computed according to constraints on these paths. •• PCE Hi computes the H1-H2-L1-L2-H3-H4 end-to-end path and sends the path back to LSR H1. the connections are used as links at the upper layer and thus forwarding upper-layer signaling can continue. The PCEs at the upper and lower layers may not interact. For example. When multiple paths need to be computed. on an MPLS-SDH-OTN network. In this case.•• PCE Hi requests PCE Lo to compute an H2-to-H3 path. •• PCE Lo returns the H2-L1-L2-H3 path to PCE Hi. the ingress node requests the PCE at the lower layer to compute paths at the lower layer and to set up connections along the lower-layer path. In the case of asynchronous computation. the PCE at the upper layer computes paths at the upper layer and signaling carries information about upper-layer paths to set up connections. When the network consists of three or more layers. the models of "single PCE for computation of multi-layer paths" and "multi-layer PCEs for path computation" can be used together. After connections at the lower layer are set up. a PCC can send multiple standalone requests to a PCE to compute multiple paths or one request to a PCE to compute a group of paths. an upperlayer PCE is responsible for computing paths on the MPLS network and a lowerlayer PCE is responsible for computing paths on the SDH and OTN networks. stand-alone path computation requests 18 . such as path separation. such as a service under 1+1 protection. In the case of asynchronous path computation. In the case of synchronous path computation. such as mutual separation) and places the path group in one or multiple response messages sent back to the PCC. Synchronous or Asynchronous Path Computation Sometimes to provision a service.

but the former is less efficient than the latter. When path computation is successful. waiting for response from a PCE. a PCE is selected according to the information about the PCEs and the local policy. RFC 5521. RFC 5440. When multiple PCEs are available.are processed without any constraint being considered.6 Relevant Standards Currently.3. only internal interface communication needs to be defined. RFC 4655. RFC 5541.4 PCE Discovery and Load Balancing A PCC does not broadcast a request message to all PCEs on the network. 3. A PCE CP enables a PCC to send a path computation request message to a PCE and a PCE to send a path computation response message to a PCC. RFC 5394 19 .3. the workload of path computation is evenly loaded on the PCEs. When multiple PCEs are available for a PCC. synchronous path computation is better than asynchronous path computation. such as addresses. RFC 5088. When path computation fails. RFC 4927. the latter considers the former as a PCC. RFC 5557. they need to communicate with each other by running a protocol (for path computation requests and responses). In this manner. Therefore. PCEs also need to communicate with each other by running a protocol. 3. Instead. a communication protocol (PCE CP) does not need to be defined between a PCC and a PCE. RFC 4674. RFC 4657. When multiple PCEs compute multi-domain paths together.5 Communication Between PCCs and PCEs. each PCE has its own computation capability or saves topology information about different domains. 3. For example. PCE-relevant standards are mature and they are: IETF. If a PCC and a PCE are at different nodes. PCEs and PCEs When the PCE function is deployed inside a node. a PCE sends back a response message to a PCC. RFC 5089. a PCE sends the path information back to the PCC. RFC 5520. Instead. A PCC can discover PCEs according to static configuration or by running a protocol. a computation task can be executed by multiple PCEs together. a PCC needs to know from which PCE it can obtain path information and relevant information about such a PCE.3. a PCC sends a request message to a designated PCE. indicating the probable cause of the failure whenever possible. When one PCE sends a path computation request to another PCE. Hence.

3. asking NE4 to creating an NE3-R2 connection. In addition. Such a PCE can be a stand-alone external server or a 20 . 4. a centralized PCE is responsible for computing all paths on the network. The following figure shows an example of centralized transport PCEs. PCE PCC R1 PCE PCC R2 NE4 PCE NE3 PCE NE1 Optical/ NE2 GMPLS IP/MPLS 1. In this solution. a PCE can compute better optical paths with much less cost. R1 sends the Path message to NE4. Like a border router in the border peer model. 2. this solution complies with the client-server or user-network architecture and it is a natural extension of UNI. R1 sends the PCReq message to NE1. The IP/MPLS network and optical/GMPLS network interact with each other through UNI interfaces. the PCE CP client function is required at routers and the PCE CP server function is required at the transport NEs. A PCE can be deployed to achieve computation of paths involving the two layers. 4.4 Typical Solutions and Application Scenarios The solution of UNI + PCE is applicable to control of a network with an IP/ MPLS layer and optical/GMPLS layer.2 UNI + Centralized Transport PCE On a transport network. and sends the PCRep message to R1. NE1 computes an optical path from NE4 to NE3. asking NE1 to computate a path from R1 to R2.1 UNI + Centralized Transport PCE A centralized transport PCE refers to a PCE deployed on a transport NE.

3 UNI + Centralized Multi-Layer PCE The following figure shows application of this solution. for example) and another centralized PCE is deployed on the transport network (ASON PCE. the router starts the process of setting up connections. the IP/MPLS PCE sends the path information to the router. When receiving the request. This solution ensures that the paths on the transport network are optimal. asking NE1 to computate a path from R1 to R2. The IP/MPLS PCE computes paths on the IP/ MPLS network and the ASON PCE computes paths on the transport network. IP/MPLS PCC PCC R1 PCC PCC R2 NE4 Optical/ NE3 PCC GMPLS PCC NE1 PCE NE2 1.node on the transport network. IP/MPLS PCE ASON PCE PCC PCC PCC PCC PCC PCC PCC PCC In this solution. for example). and sends the PCRep message to R1. 2. R1 sends the PCReq message to PCE. a centralized PCE is deployed on the IP/MPLS network (IP/MPLS PCE. Finally. 3. The following figure shows an example of a centralized transport PCE. PCE computes an optical path from NE4 to NE3. the router first sends a path computation request to the IP/MPLS PCE. the IP/MPLS PCE interacts with the ASON PCE to obtain an end-to-end path. 4. Then. asking NE4 to creating an R1-NE4-NE3-R2 connection. R1 sends the Path message to NE4. 21 . When a router requires an end-to-end connection across the transport network.

do 22 . More detailed information of SingleBackbone Solution. UNI. the unified control plane of SingleBackbone Solution adopts the overlay model. With the trend of intelligent network. which is an open architecture. the unified control plane will be more and more important to SingleBackbone Solution. you can refer to the Technical White Paper for the SingleBackbone Solution.com/broadband/iptime_backbone_solution. PCE. And the key technologies include GMPLS. http://www.5 Summary In summary.huawei.

6 Acronyms and Abbreviations ABR ARPU AS ASBR ASON CAPEX CR-LDP E-NNI ERO FRR GMPLS IETF I-NNI ITU LMP LSP MPLS NNI OIF OPEX OSPF OTN PCC PCE PCECP RSVP SC SRLG TDM TE TED UNI UNI-C UNI-N WDM Area Border Router Average Revenue Per User Autonomous System Autonomous System Boundary Router Automatically Switched Optical Network CAPital EXpenditure Constraint-based Routed-Label Distribution Protocol External Network-to-Network Interface Explicit Route Object Fast Reroute Generalized Multi-Protocol Label Switching Internet Engineering Task Force Internal Network-to-Network Interface International Telecommunication Union Link Management Protocol Label Switched Path Multi-Protocol Label Switching Network-to-Network Interface Optical Internetworking Forum OPerational EXpenditure Open Shortest Path First Optical Transport Network Path Computation Client Path Computation Element Path Computation Element Communication Protocol Resource ReSerVation Protocol Switched Connection Shared Risk Link Group Time Division Multiplexing Traffic Engineering Traffic Engineering Database User-Network Interface User-Network Interface-Client User-Network Interface-Network Wavelength Division Multiplexing 23 .

OIF-UNI-02. RFC 4872. RFC 4209. RFC 4139. Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls •• OIF. RFC 3471. Routing Extensions in Support of GMPLS •• IETF. User Network Interface (UNI) 1. Generalized Multi-Protocol Label Switching (GMPLS) Architecture •• IETF.0 Signaling Specification •• OIF. RFC 4202. OIF-UNI-01. Release 2 •• OIF. User Network Interface (UNI) 1.7 References •• IETF.0 Signaling Specification: Common Part 24 .0-R2-RSVP. RFC 4203. Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) •• IETF. GMPLS Segment Recovery •• IETF. Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems •• IETF. OIF-UNI-01. RFC 4974. Release 2: Common Part •• OIF.0 Signaling. RFC 3473. RFC 5212. Requirements for GMPLS-Based Multi-Region and MultiLayer Networks (MRN/MLN) •• IETF. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions •• IETF. RFC 3945. Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) •• IETF. RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery •• IETF.0. Generalized Multiprotocol Label Switching (GMPLS) UserNetwork Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model •• IETF. OIF-UNI-01. RFC 3209. RFC 4873. Link Management Protocol (LMP) •• IETF. RFC 4204. RSVP-TE: Extensions to RSVP for LSP Tunnel •• IETF. OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) •• IETF.0 Signaling Specification.0-Common. RFC 4258.0-R2-Common. User Network Interface (UNI) 2. RSVP Extensions for User Network Interfaces (UNI) 1. Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description •• IETF. RFC 4208.

Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization •• IETF. OIF-UNI-02.0 Signaling •• IETF. OSPF Protocol Extensions for Path Computation Element (PCE) Discovery •• IETF. A Path Computation Element (PCE)-Based Architecture •• IETF. RFC 5557. RFC 5440. RFC 5089. Path Computation Element (PCE) Communication Protocol Generic Requirements •• IETF. Requirements for Path Computation Element (PCE) Discovery •• IETF. Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) •• IETF.•• OIF. RFC 4927. RFC 4657. RFC 4674. RFC 4655. Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions •• IETF. Path Computation Element (PCE) Communication Protocol (PCEP) •• IETF. RFC 5520. Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering •• IETF. RFC 5521. IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery •• IETF.0-RSVP. RSVP Extensions for User Network Interface (UNI) 2. Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism •• IETF. RFC 5394. RFC 5541. RFC 5088. Policy-Enabled Path Computation Framework 25 .

Huawei Industrial Base Bantian Longgang Shenzhen 518129. RELIABILITY OR CONTENTS OF THIS MANUAL. EXCEPT AS REQUIRED BY APPLICABLE LAWS. Trademark Notice . TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. service and company names mentioned are the property of their respective owners. P. BUSINESS. NO WARRANTIES OF ANY KIND.huawei.R. product.: M3-013080799-20100928-C-1. GOODWILL OR ANTICIPATED SAVINGS ARISING OUT OF OR IN CONNECTION WITH THE USE OF THIS MANUAL.. OR CONSEQUENTIAL DAMAGES. DATA. EITHER EXPRESS OR IMPLIED. All rights reserved. LTD BE LIABLE FOR ANY SPECIAL. INCIDENTAL.Copyright © Huawei Technologies Co. Ltd. and are trademarks or registered trademarks of Huawei Technologies Co. 2010. China Tel: +86-755-28780808 Version No. Ltd.com . HUAWEI.0 www. OR LOST PROFITS.. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co. LTD. INDIRECT. HUAWEI TECHNOLOGIES CO. IN NO CASE SHALL HUAWEI TECHNOLOGIES CO. THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Ltd... Other trademarks. NO WARRANTY THE CONTENTS OF THIS MANUAL ARE PROVIDED “AS IS”. INCLUDING BUT NOT LIMITED TO. REVENUE.. ARE MADE IN RELATION TO THE ACCURACY.