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 LDP Extesnion for Muti Topology Support draft-zhao-ldp-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 LDP Muti Topology Extension Oct 2009 Abstract Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. Each route computed by OSPF or IS-IS is associated with a specific topology. Label Distribution Protocol (LDP) is used to distribute labels for FECs advertised by routing protocols. It is a natural requirement to extend LDP in order to make LDP be aware of MT and thus take advantage of MT based routing. This document describes options to extend the existing MPLS signalling protocol (LDP) for creating and maintaining Label Switching Paths (LSPs) in a Multi-Topology enviroment. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Associating a FEC or group of FECs with MT-ID . . . . . . . . 4 3.1. MT-ID TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. FEC TLV with MT-ID Extenstion . . . . . . . . . . . . . . 5 4. LDP MT Capability Advertisement . . . . . . . . . . . . . . . 6 4.1. Session Initialization . . . . . . . . . . . . . . . . . . 7 4.2. After Session Setup . . . . . . . . . . . . . . . . . . . 8 5. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 9 7. LDP Messages with FEC TLV and MT-ID TLV . . . . . . . . . . . 9 7.1. Label Mapping Message . . . . . . . . . . . . . . . . . . 10 7.2. Label Request Message . . . . . . . . . . . . . . . . . . 11 7.3. Label Abort Request Message . . . . . . . . . . . . . . . 11 7.4. Label Withdraw Message . . . . . . . . . . . . . . . . . . 12 7.5. Label Release Message . . . . . . . . . . . . . . . . . . 13 8. Session Initialization Message with MT Capability . . . . . . 13 9. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14 9.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 14 9.2. Overlapping Label Space for MT . . . . . . . . . . . . . . 15 9.3. Comparing Option 1 and Option 2 . . . . . . . . . . . . . 16 10. Security Consideration . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Zhao, et al. Expires April 4, 2010 [Page 2] Internet-Draft LDP 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 There are increasing requirements to support multi-topology in MPLS network. For example, service providers may want to assign different level of service(s) to different topologies so that the service separation can be achieved. It is also possible to have an in-band management network on top of the original MPLS topology, or maintain separate routing and MPLS 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. OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify different topologies. For each topology identified by a MT-ID, IGP computes a separate SPF tree independently to find the best paths to the IP prefixes associated with this topology. For FECs that are associated with a specific topology, we propose to use the same MT-ID of this topology in LDP. Thus the Label Switching Path (LSP) for a certian FEC may be created and maintained along the IGP path in this topology. Maintaining multiple MTs for MPLS network in a backwards-compatible manner requires several extensions to the label signaling encoding and processing procedures. When label is associated with a FEC, the FEC includes both ip address and topology it belongs to. There are two possible solutions to support MT awared MPLS network from MPLS forwarding point of view. The first one is to map label to both ip address and the corresponding topology. The alternative one is to use label stacks. The upper label maps to the topology, the lower label maps to the ip address. The first option does not require change to data plane, and it could use multiple labels for the same address on different topologies. The second option requires two lookups on data forwarding plane, and it can use the same label Zhao, et al. Expires April 4, 2010 [Page 3] Internet-Draft LDP Muti Topology Extension Oct 2009 for the same address on different topologies. There are a few possible ways to apply the MT-ID of a topology in LDP. One way is to have a new TLV for MT-ID and insert the TLV into messages describing a FEC that needs Multi-Topology information. Another approach is to expand the FEC TLV to contain MT-ID if the FEC needs Multi-Topology information. 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 FEC or group of FECs with MT-ID This section describes two approaches to associate a FEC or a group of FECs to a MT-ID in LDP. One way is to have a new TLV for MT-ID and insert the MT-ID TLV into messages describing a FEC that needs Multi-Topology information. Another approach is to extend FEC TLV to contain the MT-ID if the FEC needs Multi-Topology information. 3.1. MT-ID TLV The new TLV for MT-ID is defined as below: Zhao, et al. Expires April 4, 2010 [Page 4] Internet-Draft LDP Muti Topology Extension Oct 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| TLV Code Point(TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: U and F bits: As specified in [RFC3036]. TLV Code Point: The TLV type which identifies a specific capability. MT-ID is a 12-bit field containing the ID of the topology corresponding to the MT-ID used in IGP and LDP. Lack of MT-ID TLV in messages MUST be interpreted as FECs are used in default MT-ID (0) only. A MT-ID TLV can be inserted into the following LDP messages as an optional parameter. Label Mapping "Label Mapping Message" Label Request "Label Request Message" Label Abort Request "Label Abort Request Message" Label Withdraw "Label Withdraw Message" Label Release "Label Release Message" The message with inserted MT-ID TLV associates a FEC in same message to the topology identified by MT-ID. Figure 1: MT-ID TLV Format 3.2. FEC TLV with MT-ID Extenstion The new TLV for MT-ID is defined as below: Zhao, et al. Expires April 4, 2010 [Page 5] Internet-Draft LDP Muti Topology Extension Oct 2009 The extended FEC TLV has the format below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| FEC (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This new FEC TLV may contain a number of FEC elements and a MT-ID. It associates these FEC elements with the topology identified by the MT-ID. Each FEC TLV can contain only one MT-ID. Figure 2: Extended FEC with MT-ID 4. LDP MT Capability Advertisement The LDP MT capability can be advertised either during the LDP session initailizatin or after the LDP session is setup. The capability for supporting multi-topology in LDP can be advertised during LDP session initialization stage by including the LDP MT capability TLV in LDP Initialization message. After LDP session is established, the MT capability can also be advertised or changed using Capability message. If an LSR has not advertised MT capability, its peer must not send messages that include MT identifier to this LSR. If an LSR receives a Label Mapping message with MT parameter from downstream LSR-D and its upstream LSR-U has not advertised MT capability, an LSP for the MT will not be established. If an LSR is changed from non MT capable to MT capable, it sets the S bit in MT capability TLV and advertises via the Capability message. The existing LSP is treated as LSP for default MT (ID 0). Zhao, et al. Expires April 4, 2010 [Page 6] Internet-Draft LDP Muti Topology Extension Oct 2009 If an LSR is changed from MT capable to non-MT capable, it may initiate withdraw of all label mapping for existing LSPs of all non- default MTs. Alternatively, it may wait until the routing update to withdraw FEC and release the label mapping for existing LSPs of specific MT. There will be case where IGP is MT capable but MPLS is not and the handling procedure for this case is TBD. 4.1. Session Initialization In an LDP session initialization, the MT capability may be advertised through an extended session initailization message. This extended message has the same format as the original session initialization message but contains the LDP MT capability TLV as an optional parameter. The format of the TLV for LDP MT is specified in the [LDPCAP] as below: Zhao, et al. Expires April 4, 2010 [Page 7] Internet-Draft LDP Muti Topology Extension Oct 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| TLV Code Point(TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ Capability Data | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: U and F bits: As specified in [RFC3036]. TLV Code Point: The TLV type which identifies a specific capability. The "IANA Considerations" section of [RFC3036] specifies the assignment of code points for LDP TLVs. S-bit: The State Bit indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV Code Point. The State bit is used as follows: 1 - The TLV is advertising the capability specified by the TLV Code Point. 0 - The TLV is withdrawing the capability specified by the TLV Code Point. Capability Data: Information, if any, about the capability in addition to the TLV Code Point required to fully specify the capability. Figure 3: LDP MT CAP TLV 4.2. After Session Setup During the normal operating stage of LDP sessions, the capability message defined in the [LDPCAP] will be used with an LDP MT capability TLV. The format of the Capability message is as follows: Zhao, et al. Expires April 4, 2010 [Page 8] Internet-Draft LDP Muti Topology Extension Oct 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Capability (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_1 (LDP-MT Capability TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: LDP CAP Format where TLV_1 (LDP-MT Capability TLV) specifies that the LDP MT capability is enabled or disbabled by setting the S bit of the TLV to 1 or 0. 5. LDP Sessions Depending on the number of label spaces supported, if a single gloabl label space is supported, there will be one session supported for each pair of peers, even there are multiple topologoies supported between these two peers. If there are different label spaces supported for different topologies, which means that label spaces overlap with each other for different MTs, then it is suggested to establish multiple sessions for multipple topologies between these two peers. In this case, multiple LSR-IDs need to be allocated beforehand so that each multiple topology can have its own label space ID. This section is still TBD. 6. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: [TBD] 7. LDP Messages with FEC TLV and MT-ID TLV Zhao, et al. Expires April 4, 2010 [Page 9] Internet-Draft LDP Muti Topology Extension Oct 2009 7.1. Label Mapping Message An LSR sends a Label Mapping message to an LDP peer to advertise FEC- label bindings. In the Optional Parameters' field, the MT-ID TLV will be inserted. The encoding for the Label Mapping message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are: Optional Parameter Length Value Label Request 4 See below Message ID TLV Hop Count TLV 1 See below Path Vector TLV variable See below MT TLV variable See below MT TLV see the defination section for this new TLV. Figure 5: Label Mapping Message Zhao, et al. Expires April 4, 2010 [Page 10] Internet-Draft LDP Muti Topology Extension Oct 2009 7.2. Label Request Message An LSR sends the Label Request message to an LDP peer to request a binding (mapping) for a FEC. The MT TLV will be inserted into the Optional parameters' field. The encoding for the Label Request message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Label Request Message In the DU mode, when a label mapping is received by a LSR which has a downstream with MT capability advertised and an upstream without the MT capability advertised, it will not send label mapping to its upstream. in the DoD mode, the label request is sent down to the downstream LSR until it finds the downstrream LSR which doesn't support the MT, then the current LSPR will send a notification to its upstream LSR. In this case, no LSP is setup. We propose to add a new notification event to signal the upstream that the downstream is not capable. 7.3. Label Abort Request Message The Label Abort Request message may be used to abort an outstanding Label Request message. The MT TLV will be inserted into the optional parameters' field. The encoding for the Label Abort Request message is: Zhao, et al. Expires April 4, 2010 [Page 11] Internet-Draft LDP Muti Topology Extension Oct 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Abort Req (0x0404) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Request Message ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Label Abort Request Message 7.4. Label Withdraw Message An LSR sends a Label Withdraw Message to an LDP peer to signal the peer that the peer may not continue to use specific FEC-label mappings the LSR had previously advertised. This breaks the mapping between the FECs and the labels. The MT TLV will be added into the optional paramters' field. The encoding for the Label Withdraw Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Withdraw (0x0402) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Label Withdraw Message Zhao, et al. Expires April 4, 2010 [Page 12] Internet-Draft LDP Muti Topology Extension Oct 2009 7.5. Label Release Message An LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC-label mappings previously requested of and/or advertised by the peer. The MT TLV will be added into the optional paramers' field. The encoding for the Label Release Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Release (0x0403) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Label Release Message 8. Session Initialization Message with MT Capability The session initializtion message is extended to contain the LDP MT capability as an optional parameter. The extended session initialization message has the format below. Zhao, et al. Expires April 4, 2010 [Page 13] Internet-Draft LDP Muti Topology Extension Oct 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Initialization (0x0200) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Session Parameters TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LDP MT Capability TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Session Initialization Message with MT Capability 9. MPLS Forwarding in MT Although forwading is out of the scope of this draft. For the completness of discussion, we include some forwarding consideration for informational purpose here. In MT based MPLS network, forwarding will be based not only on label, but also on MT-ID associsted with the label. There are multiple options to do this. Below, we list two options. 9.1. Use Label for (FEC, MT-ID) Tuple The first option we suggest is that MPLS forwarding for different topologies is implied by labels. This approach does not need any change 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 overlay address space. 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), each LSR along the LSP path that is shared by topology MT-ID-N1 and MT-ID-N2 will allocate different labels to them. Thus two different Label Switching Paths will be created. One for (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). Zhao, et al. Expires April 4, 2010 [Page 14] Internet-Draft LDP Muti Topology Extension Oct 2009 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. We will 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) R2 LFIB: Ingress Label Egress Label NEXT HOP Lm Lp R1 Ln Lq R2 (could be same as R1) Figure 11: Forwarding Option1 9.2. Overlapping Label Space for MT In 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 one label for MT and one label for FEC. Each forwarding entry will have an extra label stacked on the FEC label. This extra label is used for MT identifer. In this option, the default MT's label space and the label used for MT identifier are in the same label space. For example, the forwarding entry in LIB looks like this: Zhao, et al. Expires April 4, 2010 [Page 15] Internet-Draft LDP 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One example for option 2 is below: RIB(x) for MT-IDx: FEC NEXT HOP FECi(Destination A) R1 RIB(y) for MT-IDy: FEC NEXT HOP FECi(Destination A) R2 LFIB (x): Ingress Label Egress Label NEXT HOP Lm Lp R1 LFIB (y): Ingress Label Egress Label NEXT HOP Lm Lq R2 Note, multiple RIBs and LFIBs are needed in this option. Figure 12: Forwarding Option2 9.3. Comparing Option 1 and Option 2 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 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 it needs hardware support to perform MPLS MT forwarding. In addition, option 2 would require one more label lookup. 10. Security Consideration MPLS security applies to the work presented. No specific security Zhao, et al. Expires April 4, 2010 [Page 16] Internet-Draft LDP Muti Topology Extension Oct 2009 issues with the proposed solutions are known. The authentication procedure for RSVP signalling is the same regardless of MT information inside the RSVP messages. 11. IANA Considerations TBD 12. Acknowledgement The authors would like to thank Dan Tappan and Nabil Bitar for their valuable comments on this draft. 13. References 13.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. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [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. 13.2. Informative References Zhao, et al. Expires April 4, 2010 [Page 17] Internet-Draft LDP Muti Topology Extension Oct 2009 Authors' Addresses Quintin Zhao Huawei Technology, Inc. 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com 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 Zhao, et al. Expires April 4, 2010 [Page 18] Internet-Draft LDP Muti Topology Extension Oct 2009 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 19]