Internet Engineering Task Force Quintin Zhao Internet-Draft Huaimo Chen Intended status: Standards Track Huawei Technology, Inc. Expires: April 4, 2010 Luyuan Fang Chao Zhou Cisco Systems, Inc. Lianyuan Li Xin Huang China Mobile, Inc. October 19, 2009 RSVP Extesnion for Muti Topology Support draft-zhao-rsvp-multi-topology-extension-00.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 4, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhao, et al. Expires April 4, 2010 [Page 1] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 enviroments. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Associating a RSVP message with MT-ID . . . . . . . . . . . . 4 3.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 5 3.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 6 3.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 7 3.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 9 4. Processing of Message with MT ID . . . . . . . . . . . . . . . 9 5. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 9 5.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 9 5.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 10 6. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 11 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhao, et al. Expires April 4, 2010 [Page 2] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 April 4, 2010 [Page 3] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 managment, 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 forwrding 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 landlines rather than, for example, high latency links such as satellite links. As a result an additional tolology is defined as all low latency links on the network and VoIP data packets are assinged 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 prtocol (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 distingushed by the quality of service (QoS) assinged to it. 3. Associating a RSVP message with MT-ID RSVP-TE objects may be utilized to indicate MT information by adding Zhao, et al. Expires April 4, 2010 [Page 4] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 inlcude 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. This section describes an approach to associate a RSVP message with MT-ID specified in the session object. 3.1. Session Object 3.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 1: 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 Zhao, et al. Expires April 4, 2010 [Page 5] Internet-Draft RSVP Muti Topology Extension Oct 2009 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. 3.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 2: Format of P2P LSP_TUNNEL_IPv6 Session Object Body with MT-ID IPv6 tunnel end point address Zhao, et al. Expires April 4, 2010 [Page 6] Internet-Draft RSVP Muti Topology Extension Oct 2009 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. 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. 3.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]. Zhao, et al. Expires April 4, 2010 [Page 7] Internet-Draft RSVP Muti Topology Extension Oct 2009 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. Figure 3: Format of P2MP LSP_TUNNEL_IPv4 Session Object Body with MT-ID Zhao, et al. Expires April 4, 2010 [Page 8] Internet-Draft RSVP Muti Topology Extension Oct 2009 3.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 4: Format of P2MP LSP_TUNNEL_IPv6 Session Object Body with MT-ID 4. Processing of Message with MT ID Procedure changes for processing P2P and P2MP protocol messages with MT ID: [TBD] 5. MPLS Forwarding in MT In MT based MPLS network, forwarding will not only be based on label, but also based on the MT-ID associsted with the label. There are multiple options to do this. Below, we list three options. 5.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 exsiting 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 awared LSR, each label is associated with tuple: (FEC, MT-ID). Therefore, same FEC with different MT-ID would be assigned to different labels. Using this option, for tuple (FEC-F, MT-ID-N1) and (FEC-F, MT-ID-N2), Zhao, et al. Expires April 4, 2010 [Page 9] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 coresspoding 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 5: FIB Entry Example for One Label Space 5.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 assocaited with label. Each label forwarding entry will have an extra label stacked with the orginal label. This extra label is used as the MT identifer. For example, the forwarding entry in the LIB looks like this: Zhao, et al. Expires April 4, 2010 [Page 10] Internet-Draft RSVP Muti Topology Extension Oct 2009 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 6: 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. 6. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: [TBD] 7. 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. 8. IANA Considerations TBD 9. Acknowledgement The authors would like to thank Dan Tappan and Nabil Bitar for their valuable comments on this draft. 10. References Zhao, et al. Expires April 4, 2010 [Page 11] Internet-Draft RSVP Muti Topology Extension Oct 2009 10.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. 10.2. Informative References Authors' Addresses Quintin Zhao Huawei Technology, Inc. 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Zhao, et al. Expires April 4, 2010 [Page 12] Internet-Draft RSVP Muti Topology Extension Oct 2009 Huaimo Chen Huawei Technology, Inc. 125 Nagog Technology Park Acton, MA 01719 US Email: Huaimochen@huawei.com Luyuang Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US Email: lufang@cisco.com Chao Zhou Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 US Email: czhou@cisco.com Lianyuan Li China Mobile, Inc. 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: lilianyuan@chinamobile.com Xin Huang China Mobile, Inc. 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: huangxin@chinamobile.com Zhao, et al. Expires April 4, 2010 [Page 13]