Internet Engineering Task Force Q. Zhao Internet-Draft H. Chen Intended status: Standards Track Huawei Technology Expires: January 7, 2011 N. So Verison Business L. Fang C. Zhou Cisco Systems L. Li China Mobile R. Torvi Juniper Networks July 6, 2010 RSVP-TE Extension for Multi Topology Support draft-zhao-mpls-rsvp-te-multi-topology-00.txt Abstract This document describes options to extend the existing MPLS signalling protocol RSVP for creating and maintaining Label Switching Paths (LSPs) in a Multi-Topology environments. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). 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 January 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Zhao, et al. Expires January 7, 2011 [Page 1] Internet-Draft RSVP-TE Multi Topology Extension July 2010 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5 3.2. Automation of inter-layer interworking . . . . . . . . . . 5 3.3. Migration without service disruption . . . . . . . . . . . 6 3.4. Service Separation . . . . . . . . . . . . . . . . . . . . 6 4. Associating a RSVP message with MT-ID . . . . . . . . . . . . 6 4.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 7 4.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 8 4.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 9 4.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 10 5. Processing of Message with MT ID . . . . . . . . . . . . . . . 10 6. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 10 6.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 10 6.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 11 7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 12 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Zhao, et al. Expires January 7, 2011 [Page 2] Internet-Draft RSVP-TE Multi Topology Extension July 2010 1. Terminology Terminology used in this document MT-ID: A 12 bit value to represent Multi-Topology ID. Default Topology: A topology that is built using the MT-ID value 0. MT topology: A topology that is built using the corresponding MT-ID. 2. Introduction In Multi-protocol Label Switching (MPLS) networks, a label may be assigned to represent a set of Forwarding Equivalent Classes (FEC) of packets and a mapping of the label and the FEC may be signaled along the path traversed by the packets. Therefore, the label switched paths are established to forward packets. Resource reservation protocol (RSVP) is a network control protocol that may be used to enable applications to obtain different quality of service (QoS) for their data flows. However, RSVP is not a routing protocol. Rather, RSVP operates in conjunction with routing protocols. Resource reservation protocol traffic engineering (RSVP-TE) is an extension to RSVP that supports resource reservations across an Internet Protocol (IP) network. Generally, RSVP-TE may be used to establish MPLS label switched paths (LSPs) with or without resource reservations, with consideration given to available bandwidth and a number of explicit hops. The LSPs may be setup using explicit routes. A variety of messages and procedures may be used by network elements to inform other network elements of the labels used for MPLS forwarding. The LSPs may be treated as a tunnel, which is tunneling below normal IP routing and filtering mechanisms. A mechanism for Open Shortest Path First (OSPF) protocol to support multi-topologies (MT) in IP networks, wherein Type of Service (TOS) based metric fields are redefined and used to advertise different topologies is disclosed in P. Psenak, et.al., "Multi-Topology (MT) Routing in OSPF," RFC 4915, June 2007, which is incorporated herein by reference. Separate metrics may be associated for each TOS and may be advertised via protocol information exchange between network elements. The existing OSPF protocol is extended to support network topology changes with Multi-Topology Identifier (MT-ID). Zhao, et al. Expires January 7, 2011 [Page 3] Internet-Draft RSVP-TE Multi Topology Extension July 2010 A mechanism within Intermediate System to Intermediate System (IS-IS) to run a set of independent IP topologies for each network topology is disclosed in T. Przygienda, et.al., "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008, which is incorporated herein by reference. The existing IS-IS protocol is extended so that advertisements of adjacencies and reachable intermediate system within each topology are performed. Therefore, there is a need to have systems and methods for supporting multi-topology in MPLS network and extending the RSVP-TE protocol as a signaling protocol in the MPLS network to establish and maintain traffic engineered LSP tunnel within each network topology or across network topologies. The LSP tunnel may need to follow a specific path or to reserve a certain amount of bandwidth to satisfy QoS requirements for the traffic flowing through the LSP tunnel within a specific network topology or across multiple network topologies. MT based MPLS in general can be used for a variety of purposes such as service separation by assigning each service or a group of services to a topology, where the management, QoS and security of the service or the group of the services can be simplified and guaranteed, in-band management network "on top" of the original MPLS topology, maintain separate routing and MPLS forwarding domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different MPLS topology for the purpose of security, QoS or simplified management and/or operations. One of the use of the MT based MPLS is where one class of data requires low latency links, for example Voice over Internet Protocol (VoIP) data. As a result such data may be sent preferably via physical landline rather than, for example, high latency links such as satellite links. As a result an additional topology is defined as all low latency links on the network and VoIP data packets are assigned to the additional topology. Another example is security- critical traffic which may be assigned to an additional topology for non-radiative links. Further possible examples are file transfer protocol (FTP) or SMTP (simple mail transfer protocol) traffic which can be assigned to additional topology comprising high latency links, Internet Protocol version 4 (IPv4) versus Internet Protocol version 6 (IPv6) traffic which may be assigned to different topology or data to be distinguished by the quality of service (QoS) assigned to it. 3. Application Scenarios Zhao, et al. Expires January 7, 2011 [Page 4] Internet-Draft RSVP-TE Multi Topology Extension July 2010 3.1. Simplified Data-plane IGP-MT requires additional data-plane resources maintain multiple forwarding for each configured MT. On the other hand, MPLS-MT does not change the data-plane system architecture, if an IGP-MT is mapped to an MPLS-MT. In case MPLS-MT, incoming label value itself can determine an MT, and hence it requires a single NHLFE space. MPLS-MT requires only MT-RIBs in the control-plane, no need to have MT-FIBs. Forwarding IP packets over a particular MT requires either configuration or some external means at every node, to maps an attribute of incoming IP packet header to IGP-MT, which is additional overhead for network management. Whereas, MPLS-MT mapping is required only at the ingress-PE of an MPLS-MT LSP, because of each node identifies MPLS-MT LSP switching based on incoming label, hence no additional configuration is required at every node. 3.2. Automation of inter-layer interworking With (G)MPLS-RSVP-MT extensions, an ingress-PE can signal particular path (ERO) that can traverses different network layer to reach a egress-PE. For instance, an ERO is associated with MT-ID RSVP subobject to indicate a "P" router to use a particular Layer-1 TE- link-state topology, instead of default Layer-3 link-state topology as illustrated in the following diagram. With this mechanism an (G)MPLS-TE LSP can be offloaded to lower layers without service disruption and without complexity of configuration. +-------+ +-------+ +---------+ R3 .__________ | R4 +------. | +-------+ +-------+ | +-------+ +--+---+ +-'---+ | I-PE |_.| P | |E-PE | | | +--+---+ +-.---+ +-------+ | | | +---------+ +-------+ | |_______| S1 |_____| S2 |____________| +---------+ +-------+ Figure 1: Layer-3 Link State Topology Layer-3 ERO : P[MT-0]->R3->R4->E-PE[MT-0]. Inter-layer ERO : P[MT-0]->loose-hop[MT-1]->E-PE[MT-0] Procedures to discover MT mapping with an IGP topology at ingress-PE Zhao, et al. Expires January 7, 2011 [Page 5] Internet-Draft RSVP-TE Multi Topology Extension July 2010 nodes requires some auto-discovery mechanism. Figure 1: Layer-3 Link State Topology 3.3. Migration without service disruption As state above, MPLS-MT abstracts link state topology and identifies it by a unique MT-ID, which need not be same as IGP-MT ID. This characteristic is quite useful for service providers looking to migrate to different flavor of IGP, e.g., OSPFv2 to ISIS6, OSPFv2 to OSPFv3. Service providers would like to incrementally upgrade the topologies, which requires an LSP to traverse multiple IGP domains (OSPFv2 to OSPFv3) or (OSPF to ISIS). In order migrate TE-LSPs to use newly deployed link state topology requires a non-trivial effort. This migration may involve service disruption, especially when a path include loose-hops in the ERO. For example: When an incoming PATH message requires an LSR to resolve loose-hop over newly deployed IGP domain, which is not possible in the absence of MPLS-MT signaling. MPLS-MT allows an ingress-PE to specify multi-topology to be used at every hop. 3.4. Service Separation MPLS-MT procedures allow establishing two distinct LSPs for the same FEC, by advertising separate label mapping for each configured topology. Service providers can implement CoS using MPLS-MT procedures without requiring to create separate FEC address for each class. MPLS-MT can also be used separate multicast and unicast traffic. 4. Associating a RSVP message with MT-ID RSVP-TE objects may be utilized to indicate MT information by adding the multi-topology information in an RSVP-TE object carried in a RSVP-TE message. A preferred RSVP-TE object may be a session object. The capability for supporting multi-topology in RSVP can be advertised during RSVP session initialization stage by including the extended RSVP session object in the first RSVP path message. After RSVP session is established, the following Path, Resv, PathErr, ResvErr and ResvConf messages will include the session object in each message and the MT ID contained in the session object will let the receiver of the message to know which topology this message is for. Zhao, et al. Expires January 7, 2011 [Page 6] Internet-Draft RSVP-TE Multi Topology Extension July 2010 This section describes an approach to associate a RSVP message with MT-ID specified in the session object. 4.1. Session Object 4.1.1. P2P LSP TUNNEL IPv4 Session Object Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv(0)| MT-ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of P2P LSP_TUNNEL_IPv4 Session Object Body with MT-ID IPv4 tunnel end point address IPv4 address of the egress node for the tunnel. MT-ID A 12 bit value to represent Multi-Topology Identifier. Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. Zhao, et al. Expires January 7, 2011 [Page 7] Internet-Draft RSVP-TE Multi Topology Extension July 2010 4.1.2. P2P LSP TUNNEL IPv6 Session Object This is the same as the P2MP IPv4 LSP SESSION object with the difference that the extended tunnel ID may be set to a 16-byte identifier [RFC3209]. Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel end point address | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv(0)| MT-ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Extended Tunnel ID | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of P2P LSP_TUNNEL_IPv6 Session Object Body with MT-ID IPv6 tunnel end point address IPv6 address of the egress node for the tunnel. MT-ID A 12 bit value to represent a Multi-Topology Identifier. Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. Zhao, et al. Expires January 7, 2011 [Page 8] Internet-Draft RSVP-TE Multi Topology Extension July 2010 Extended Tunnel ID A 16-byte identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv6 address here as a globally unique identifier. 4.1.3. P2MP LSP TUNNEL IPv4 Session Object This is the same as the P2MP IPv4 LSP SESSION object with the difference that the extended tunnel ID may be set to a 16-byte identifier [RFC3209]. Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv(0)| MT-ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the ingress LSR. MT-ID A 12 bit value to represent a Multi-Topology Identifier. Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Ingress LSRs that wish to have a globally unique identifier for the P2MP tunnel SHOULD place their tunnel sender address here. A combination of this address, P2MP ID, and Tunnel ID provides a globally unique identifier for the P2MP tunnel. Zhao, et al. Expires January 7, 2011 [Page 9] Internet-Draft RSVP-TE Multi Topology Extension July 2010 Figure 4: Format of P2MP LSP_TUNNEL_IPv4 Session Object Body with MT-ID 4.1.4. P2MP LSP TUNNEL IPv6 Session Object Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv(0)| MT-ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (16 bytes) | | | | ....... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of P2MP LSP_TUNNEL_IPv6 Session Object Body with MT-ID 5. Processing of Message with MT ID Procedure changes for processing P2P and P2MP protocol messages with MT ID: [TBD] 6. MPLS Forwarding in MT In MT based MPLS network, forwarding will not only be based on label, but also based on the MT-ID associated with the label. There are multiple options to do this. Below, we list three options. 6.1. Use Label for (FEC, MT-ID) Tuple The first option we propose is that MPLS forwarding for different topologies is implied by labels. This approach does not need any changes to the exiting MPLS hardware forwarding mechanism. It also resolves the forwarding issue that exists in IGP multi-topology forwarding when multiple topologies share an interface with overlaying addresses. On a MT aware LSR, each label is associated with tuple: (FEC, MT-ID). Therefore, same FEC with different MT-ID would be assigned to Zhao, et al. Expires January 7, 2011 [Page 10] Internet-Draft RSVP-TE Multi Topology Extension July 2010 different labels. Using this option, for tuple (FEC-F, MT-ID-N1) and (FEC-F, MT-ID-N2), each LSR along the path that is shared by topology MT-ID-N1 and MT- ID-N2 will allocate different labels to them. Thus two distinguished Label Switching Paths will be created. One (FEC-F, MT-ID-N1) and the other for (FEC-F, MT-ID-N1). The traffic for them will follow different Label Switching Paths (LSPs). Note, in this option, label space is not allowed to be overlapping among different MTs. In the above example, each label belongs to a specific topology or the default topology. MPLS forwarding will be performed exactly same as non-MT MPLS forwarding: using label to find output information. This option will not require any change of hardware forwarding to commodate MPLS MT. Note, We have different RIBs corresponding to different MT IDs. But we will only need one LFIB. Below is an example for option one: RIB(x) for MT-IDx: FEC NEXT HOP FECi(Destination A) R1 RIB(y) for MT-IDy: FEC NEXT HOP FECi(Destination A) R1 LFIB: Ingress Label Egress Label NEXT HOP Lm Lp R1 Ln Lq R2 (could be same as R1) Figure 6: FIB Entry Example for One Label Space 6.2. Overlapping Label Spaces for MT In the option 2, label spaces are overlapping with each other, which means same label value could be used for different MT. In this option, MPLS forwarding will use label value and the MT associated with label. Each label forwarding entry will have an extra label stacked with the original label. This extra label is used as the MT identifier. For example, the forwarding entry in the LIB looks like this: Zhao, et al. Expires January 7, 2011 [Page 11] Internet-Draft RSVP-TE Multi Topology Extension July 2010 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | MT identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: FIB Entry of Overlapping Label Spaces for MT Option 1 is good for backward compatibility and it doesn't require hardware change. The disadvantage is that the 20 bits of label space is shared by all the MTs and label space for each MT is limited. The advantage for option 2 is that each MT can have full label space. The disadvantage is that they need hardware support to perform MPLS MT forwarding. In addition, option 2 require one more label lookup. 7. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: [TBD] 8. Security Consideration MPLS security applies to the work presented. No specific security issues with the proposed solutions are known. The authentication procedure for RSVP signalling is the same regardless of MT information inside the RSVP messages. 9. IANA Considerations TBD 10. Acknowledgement The authors would like to thank Dan Tappan, Nabil Bitar and Huang Xin for their valuable comments on this draft. 11. References Zhao, et al. Expires January 7, 2011 [Page 12] Internet-Draft RSVP-TE Multi Topology Extension July 2010 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. 11.2. Informative References Authors' Addresses Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Zhao, et al. Expires January 7, 2011 [Page 13] Internet-Draft RSVP-TE Multi Topology Extension July 2010 Huaimo Chen Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: huaimochen@huawei.com Ning So Verison Business 2400 North Glenville Drive Richardson, TX 75082 USA Email: Ning.So@verizonbusiness.com Luyuang Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US Email: lufang@cisco.com Chao Zhou Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US Email: czhou@cisco.com Lianyuan Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: lilianyuan@chinamobile.com Zhao, et al. Expires January 7, 2011 [Page 14] Internet-Draft RSVP-TE Multi Topology Extension July 2010 Raveendra Torvi Juniper Networks 10, Technoogy Park Drive Westford, MA 01886-3140 US Email: pratiravi@juniper.com Zhao, et al. Expires January 7, 2011 [Page 15]