One document matched: draft-minei-mpls-ldp-external-02.txt
Differences from draft-minei-mpls-ldp-external-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 17:25:32 |