Network Working Group Luyuan Fang INTERNET DRAFT AT&T Expiration Date: March 2005 Ina Minei Nischal Sheth Juniper Networks LDP signaled LSPs for external prefixes draft-minei-mpls-ldp-external-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society 2004. All Rights Reserved. Abstract In order to create forwarding state for a FEC received from a downstream LSR, LDP requires the presence of a matching entry in the routing table. This document describes a mechanism that allows the creation of LDP signaled LSPs for prefixes which are not present in the routing table. This draft is applicable to address prefix FECs and host FECs associated with either IPv4 or IPv6 prefixes. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. draft-minei-mpls-ldp-external-02.txt [Page 1] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 1. Introduction In order to create forwarding state for a FEC associated with an IPv4 or IPv6 prefix, LDP requires the presence of a matching entry in the routing table [RFC3036]. This requirement is usually fulfilled by having the IGP advertise the prefix. However, it is not always desirable to inject routes for all LDP FECs into the IGP. Let us take as an example a VPN environment where the PEs belong in different ASs [RFC2547bis]. Such a topology may exist either in a multi-provider situation, or within a single provider, if the provider's network is built of multiple ASs. In such a topology, the Service Provider wants to establish LSPs to the remote PEs, but may not want to advertise the PEs addresses into the local IGP just for this purpose. Or, the Service Provider may be wary of redistributing these routes from BGP into the IGP, when the only gain is allowing LDP to set up forwarding state. This document presents a mechanism for establishing LSPs for FECs for which there are no matching entries in the routing table. It is applicable to address prefix FECs and host FECs associated with either IPv4 or IPv6 prefixes. The idea is to match against the LSR's IPv4/IPv6 routing table not the address prefix carried in the FEC TLV of the Label Mapping message, but to augment the Label Mapping message with the address of the LSR that first injected this FEC into LDP, and use this address for matching against the LSR's routing table. In the multi-AS example above, the (remote) PE addresses would be the address prefixes carried in the FECs, and the address that would be used for matching against the routing table would be one of the loopback addresses of the ASBR that injected these FECs into LDP. This approach has several advantages: a) avoids route redistribution. There is no need to inject the PE addresses in the IGP, it is enough to make sure to inject the relevant loopback address of the ASBR in the IGP. b) helps troubleshooting. The source of an LDP FEC can be easily traced. c) improves convergence time. In a setup running the normal LDP procedures, if the ASBR-ASBR BGP session goes down, the ASBR has to generate label withdraw FEC-label mapping of all the PEs received via this BGP session, and also withdraw all the routes to these PEs from its IGP. With the proposed LDP change, it would be sufficient for the ASBR to withdraw from the IGP only the address it uses in the augmented Label Mapping message mentioned above. There are two concepts: 1) decoupling of the FEC from the routing table entry, and 2) specifying a different address on which to draft-minei-mpls-ldp-external-02.txt [Page 2] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 apply the decision making process of whether to use the label for forwarding and whether to propagate the FEC to the neighbors. Neither of these two concepts is new or at odds with the LDP specification, so this concept can be easily expanded to arbitrary FECs. 2. LDP extensions A new TLV is defined, with the following encoding: 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|0| Resolution Nexthop (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Host Addr | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TLV type for the Resolution Nexthop TLV is not yet assigned. Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. Host Addr A host address encoded according to the Address Family field. The Resolution Nexthop TLV is used in label mapping, label withdraw and label release messages. When the Resolution Nexthop TLV is present in a label withdraw message or release messages, the Label TLV MUST be present as well. If a message is received that contains the Resolution Nexthop TLV, but does not contain a FEC TLV, the message is dropped and a "Missing FEC TLV" notification is sent (see definition below). draft-minei-mpls-ldp-external-02.txt [Page 3] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 3. Operation The Resolution Nexthop TLV carries the address which should be used in the decision making process of whether to install MPLS forwarding state for a particular FEC, and whether to advertise a label binding for this FEC to the neighbors. Usually the Resolution Nexthop TLV will carry the router-id of the LSR which originally injected the FEC into LDP. In order to install forwarding state, LDP label mapping procedures require to find a routing table entry that exactly matches the FEC. When the Resolution Nexthop TLV is present, the mapping procedures are changed as detailed in the following sections. 3.1. Label mapping Label mapping procedures are modified as follows: When an LSR receives a label mapping message that carries the optional Resolution Nexthop TLV, the LSR MUST NOT use the label for forwarding unless the following two conditions are met: - 1) the routing table contains an entry that exactly matches the address in the Resolution Nexthop TLV. - 2) the mapping was received from the (downstream) neighbor that is (according to the routing table) the next hop to the address in the Resolution Nexthop TLV. If the LSR chooses to advertise the FEC to its neighbors, it MUST include the Resolution Nexthop TLV unchanged. An LSR should remember for each FEC the Resolution Nexthop with which it was advertised. What uniquely identifies a FEC is the combination of the value in the FEC TLV and the address in the Resolution Nexthop TLV. If an LSR receives two label mappings for the same FEC, with different values of the Resolution Nexthop TLV, it should treat them as two separate FECs and allocate separate outgoing labels for them. An LSR that receives a message containing the Resolution Nexthop TLV, and which does not support this TLV, will drop the message and return a notification to the sender. This behaviour is mandated by the fact that the U-bit is zero in the TLV. Thus, consistent establishment of the LSP is guaranteed. draft-minei-mpls-ldp-external-02.txt [Page 4] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 3.2. Label withdraw Label withdraw procedures are modified as follows: If an LSR decides to break the mapping between a FEC and a label, if the FEC is associated with a Resolution Nexthop, the LSR MUST include the Resolution Nexthop TLV and the Label TLV in the withdrawal message. If an LSR receives a label withdraw message that does not contain the Resolution Nexthop TLV, there are two cases: - a) the FEC is not associated with any Resolution Nexthop, regular withdraw procedures occur, as defined in [RFC3036]. - b) the FEC is associated with some Resolution Nexthop, the message is dropped and a "Missing Resolution Nexthop TLV" notification is sent (see definition below). If an LSR receives a label withdraw message containing the Resolution Nexthop TLV, there are two cases: - a) the LSR has a mapping for this FEC, but the Resolution Nexthop TLV associated with it is different, or not existent, the message is dropped and a "Incompatible Resolution Nexthop TLV" is sent (see definition below) - b) the LSR has a mapping and the Resolution Nexthop TLV is the same, regular withdraw procedures occur, as defined in [RFC3036]. 3.3. Label release Label release procedures are modified as follows: If an LSR decides to send a label release for a FEC which is associated with a Resolution Nexthop TLV, it must include the Resolution Nexthop TLV and the label TLV in the release message. 3.4. New status codes for notifications The following new status codes are defined: Status Code E Status Data Incompatible Resolution Nexthop TLV 1 TBD Missing Resolution Nexthop TLV 1 TBD Missing FEC TLV 1 TBD The "E" column is the required setting of the Status Code E-bit; the "Status Data" column is the value of the 30-bit Status Data field in draft-minei-mpls-ldp-external-02.txt [Page 5] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 the Status Code TLV. The values of the new status codes have not yet been assigned. 4. Security considerations The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant. In addition to these, LSRs implementing this scheme may be subject to the following: an attacker may divert traffic to a particular box in the network by injecting false advertisements with the loopback of this box in the Resolution Nexthop TLV. Such attacks may be countered by the use of an authentication scheme between peers, such as MD5, described in [RFC3036], or by other mechanisms that prevent such incorrect advertisements from being disseminated in a network. 5. Intellectual Property Considerations Juniper Networks may have intellectual property rights claimed in regard to some of the specification contained in this document. 6. Acknowledgments The authors would like to thank Yakov Rekhter, Pedro Marques and Jerry Ash for their suggestions and insight. 7. References [RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700, October 1994 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2547bis] "BGP/MPLS VPNs", Rosen et. al., draft-ietf-l3vpn- rfc2547bis-00.txt [RFC3036] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC 3036, January 2001 draft-minei-mpls-ldp-external-02.txt [Page 6] Internet Draft draft-minei-mpls-ldp-external-02.txt September 2004 8. Authors' Addresses Luyuan Fang AT&T 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748 Phone: 732-420-1921 Email: luyuanfang@att.com Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: ina@juniper.net phone: 408.745.2000 Nischal Sheth Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: nsheth@juniper.net phone: 408.745.2000 draft-minei-mpls-ldp-external-02.txt [Page 7]