Internet Draft
Internet-Draft Nancy Feldman
Expiration Date: May 1998 IBM Corp.
Paul Doolan
Ennovate Networks
Andre Fredette
Bay Networks Inc
Loa Andersson
Ericsson
November 1997
LDP Specification
<draft-feldman-ldp-spec-00.txt>
Status of This Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
An overview of Multi Protocol Label Switching (MPLS) is provided in
[FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental
Feldman, et al. Expiration: May 1998 [Page 1]
Internet-Draft Label Distribution Protocol November 1997
concept in MPLS is that two Label Switching Routers (LSRs) must agree
on the meaning of the labels used to forward traffic between and
through them. This common understanding is achieved by using the
Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and
[ARCH]. This document defines the LDP protocol.
Feldman, et al. Expiration: May 1998 [Page 2]
Internet-Draft Label Distribution Protocol November 1997
Table of Contents
1. Protocol Overview ........................ 4
2. Local and Egress Control ................. 5
3. Selecting Streams ........................ 6
4. LDP Messaging ............................ 8
4.1. Hello Message ............................ 8
4.2. Protocol Message Overview ................ 8
4.2.1. Adjacency Class Messages ................. 8
4.2.2. Advertisement Class Messages ............. 8
4.3. Advertisement Message .................... 9
4.3.1. Local Control ............................ 9
4.3.2. Egress Control ........................... 10
4.3.3. Label Use ................................ 10
4.4. Request Message .......................... 10
4.5. Withdraw Message ......................... 11
4.6. Release Message .......................... 11
4.7. Acknowledge Message ...................... 12
4.8. Query Message ............................ 12
5. Loop Detection ........................... 12
6. Loop Prevention via Diffusion ............ 12
7. Merging .................................. 14
8. Specification ............................ 14
8.1. LDP Hello mechanism ...................... 14
8.2. Common Header ............................ 15
8.3. Object Header ............................ 16
8.4. Adjacency Class Messages ................. 17
8.5. Advertisement Class ...................... 17
8.6. LDP Object definitions ................... 18
8.6.1. MsgType Object ........................... 18
8.6.2. LSR Object ............................... 19
8.6.3. LabelRange Object ........................ 20
8.6.4. Stream Member Descriptor (SMD) Object .... 21
8.6.5. Label Object ............................. 26
8.6.6. Class-of-Service Object .................. 26
8.6.7. LSR Path Vector Object ................... 27
8.6.8. Hop Count Object ......................... 28
8.6.9. MTU Object ............................... 28
8.6.10. Stack Object ............................. 29
8.6.11. Error Object ............................. 30
9. Intellectual Property Considerations ..... 31
10. Acknowledgments .......................... 31
11. References ............................... 31
12. Author Information ....................... 32
Feldman, et al. Expiration: May 1998 [Page 3]
Internet-Draft Label Distribution Protocol November 1997
1. Protocol Overview
LDP is the set of procedures and messages by which one LSR informs
another of the mappings between labels and Streams that it has made.
Two LSRs which use an LDP to exchange label/Stream mapping
information are known as "LDP Peers" with respect to that information
and we speak of there being an "LDP Adjacency" between them. A single
LDP adjacency allows each peer to learn the other's label mappings ie
the protocol is bidirectional.
LDP provides a mechanism whereby LSRs continually indicate their
presence in a network using advertisements which are sent as UDP
packets to the LDP port at the 'all routers' group multicast address.
When, perhaps in response to hearing an advertisement, one LSR
decides to establish an adjacency with another it uses the
initialization procedure of LDP. On succesful completion of this
initialization procedure the two LSRs are LDP peers and may exchange
label mappings.
Note that this document is written with respect to unicast routing
only. Multicast will be addressed in a future revision.
LDP messages are broken into two classes: those required to establish
and maintain neighbor adjacencies, and those which deal with the
advertisement of label mappings.
Correct operation of the label forwarding paradigm requires that
forwarding peers agree on the 'meaning' of labels. This imposes
certain requirements on the LDP including reliable and in order
delivery of mappings (although there are circumstances when this
second requirement could be relaxed). To satisfy these requirements
LDP uses the TCP transport.
The convention used in this document is the same as that used in the
documentation of the internet protocols [rfc1700] ie to express
numbers in decimal and to picture data in "big-endian" order. Fields
are described left to right, with the most significant octet on the
left and the least significant octet on the right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
Feldman, et al. Expiration: May 1998 [Page 4]
Internet-Draft Label Distribution Protocol November 1997
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in the
diagram is the high order or most significant bit. That is, the bit
labeled 0 is the most significant bit.
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit. When
a multi-octet quantity is transmitted the most significant octet is
transmitted first.
2. Local and Egress Control
Each LSR must be configured for local or egress control, to determine
the behavior for the initial setup of LSPs.
When LSP control is done locally, each node may at any time pass
label mappings to its neighbors for each stream recognized by that
node. When the neighboring nodes recognize the same streams, they
map incoming labels to received outgoing labels.
When LSP control is done via egress control, then only the egress
node may initiate the transmission of label mappings. Non-egress
nodes wait until they get a label from downstream for a recognized
stream before mapping the stream and passing a corresponding label
for the stream to upstream peers.
An LSR behaves as an egress (that is, initiating mappings) on a per
stream basis. Thus, an LSR may be considered an egress for a
particular set of streams, and a non-egress for others. An LSR is an
egress LSR, with respect to a particular stream, under any of the
following conditions:
1. The stream refers to the LSR itself (including one of its
Feldman, et al. Expiration: May 1998 [Page 5]
Internet-Draft Label Distribution Protocol November 1997
directly
attached interfaces).
2. The stream is reachable via a next hop router that is out-
side the LSR switching infrastructure.
3. The stream is reachable by crossing a routing domain boun-
dary, such as another area for OSPF summary net-works, or
another autonomous system for OSPF AS externals and BGP
routes [rfc1583] [rfc1771].
3. Selecting Streams
A stream is an aggregate of one or more flows, treated as one for the
purpose of forwarding; that is, all aggregate flows use a single
label.
Following are the currently defined streams. New streams types may be
added as needed:
a) IPv4 address
This stream is a single a IP prefix. This identifier is
used for host or CIDR prefixes [rfc1519]. This type
results in each IP destination prefix sustaining its own
LSP tree. It is recommended in environments where no
aggregation information is provided by the routing proto-
cols (such as RIP), or in networks where the number of des-
tination prefixes is limited.
b) BGP Next Hop
This stream is the value in the BGP NEXT_HOP attribute. It
may be the IP address of a BGP border router (enabling one
LSP tree for all destinations reachable through the same
egress point), or the address of an external BGP peer (ena-
bling one LSP tree for all routes destinated to the same
external peer). This identifier provides the maximum
obtainable aggregation.
c) OSPF Router ID
This stream is the OSPF Router ID of the router that ini-
tiated the link state advertisement. This type allows
aggregation of traffic on behalf of multiple datagram
Feldman, et al. Expiration: May 1998 [Page 6]
Internet-Draft Label Distribution Protocol November 1997
protocols routed by OSPF.
d) OSPF Area Border Router
This stream is the OSPF Router ID of the border router.
This identifier is used in OSPF external link advertisement
with a non-zero forwarding address.
e) Explicit Path
This stream is an explicitly defined source-routed path.
This information may be provided via configuration, or may
be computed via a Dijkstra calculation for a certain metric
(e.g. QoS, Tos), and may be used for point-to-point,
point-to-multipoint, or multipoint-to-point LSPs. This
type of stream may be initiated by an ingress or egress
LSR.
f) Aggregate group
This stream is a list of prefixes that are to share a com-
mon egress point. This type is configured, and may be used
when additional aggregation not provided by the routing
protocols is required.
g) Flow
This stream contains information pertaining to a constant
set of datagram information, such as port, dest-addr, src-
addr, etc. This feature provides the user with the ability
to use MPLS with no aggregation. This type of stream may
be initiated by an ingress or egress LSR.
h) Multicast (S,G)
This stream is a unique (Source, Group) multicast pair. It
creates one LSP tree per (S,G) pair. It is used by DVMRP
and PIM-DM.
i) Multicast (G)
This stream is a unique multicast group on a multicast
tree. It creates one switched path tree per group. It is
used by PIM-SM.
Feldman, et al. Expiration: May 1998 [Page 7]
Internet-Draft Label Distribution Protocol November 1997
4. LDP Messaging
4.1. Hello Message
The hello message is periodically transmitted to autodiscover LSR
peers. The are transmitted as UDP packets to the LDP port at the
'all routers' group multicast address.
4.2. Protocol Message Overview
The protocol messages are constructed from a common header followed
by one or more message 'objects'. The message object structure is of
the form Type, Length, Value.
4.2.1. Adjacency Class Messages
Initialization
Transmitted after neighbor discovery, to exchange LSR characteris-
tics, and establish a neighbor adjacency.
KeepAlive
Periodically transmitted to maintain a neighbor adjacency. It need
be sent only when no other MPLS messages are transmitted within
the KeepAlive timer interval.
Shutdown
Transmitted to ACTIVE neighbors, to terminate a neighbor adja-
cency.
4.2.2. Advertisement Class Messages
Mapping
Transmitted to establish an LSP by transmitting a mapping between
a stream and a label, with associated characteristics.
Request
Transmitted to request a label mapping for a stream.
Withdraw
Transmitted to withdraw a previously allocated label.
Feldman, et al. Expiration: May 1998 [Page 8]
Internet-Draft Label Distribution Protocol November 1997
Release
Transmitted to indicate a previously received label is no longer
in use.
Query
Transmitted when diffusion is in use, to verify that a new routed
path to the stream is loop free.
Acknowledge
An error transmitted on the receipt of an Advertisement Class mes-
sage, or as a response to a query message
4.3. Advertisement Message
The Advertisement message is used by a downstream LSR distribute a
label mapping for a stream to its LDP peers. If an LSR must distri-
bute a mapping for a stream to multiple MPLS peers, it is a local
matter whether it maps a single label to the stream, and distributes
that mapping to all its peers, or whether it uses a different mapping
for each of its peers.
It is the responsibility of the downstream LSR to keep track of the
mappings which it has distributed, and to ensure that the upstream
peer always has these mappings.
4.3.1. Local Control
If an LSR is configured for local control, an advertisement is
transmitted by an LSR to upstream peers upon any of the following
conditions:
1. The LSR recognizes a new stream via the forwarding table.
2. The LSR receives a Request Advertisement from an upstream peer
for a stream present in the LSR's forwarding table.
3. The next hop for a stream changes.
4. The next hop for a stream changes to another LDP peer.
5. The receipt of a mapping from the downstream next hop.
Feldman, et al. Expiration: May 1998 [Page 9]
Internet-Draft Label Distribution Protocol November 1997
4.3.2. Egress Control
If an LSR is configured for egress control, an advertisement is
transmitted by downstream LSRs upon any of the following conditions:
1. The LSR recognizes a new stream via the forwarding table, and
is the egress for the stream.
2. The LSR receives a Request Advertisement from an upstream peer
for a stream present in the LSR's forwarding table, and the
LSR is the egress for that stream OR has a downstream mapping
for that stream.
3. The next hop for a stream changes to another LDP peer.
4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop.
4.3.3. Label Use
An upstream LSR uses a mapping received from the downstream peer if
that peer is the next hop for the stream, and a routed path loop is
not detected via the LSR-path-vector object (see section 8.6.7). If
diffusion is configured, a diffusion algorith may need to be per-
formed before the label is used (see section 6). If, at the time the
mapping is received, the downstream peer is NOT the LSR's Next Hop
for the stream, or an object is determined to be in a loop, the LSR
will not use of the mapping at that time.
4.4. Request Message
The Request message is used by the upstream LSR to explicitly request
that the downstream LSR map and advertise a label for a stream.
An LSR transmits a Request message under any of the following condi-
tions:
1. The LSR recognizes a new stream via the forwarding table, and
the next hop is an ACTIVE MPLS peer.
2. The next hop to the stream changes, and one doesn't already
have a mapping from that next hop for the given stream.
Feldman, et al. Expiration: May 1998 [Page 10]
Internet-Draft Label Distribution Protocol November 1997
If a request cannot be satisfied by the downstream LSR, the request-
ing LSR may optionally choose to request again at a later time, or
may wait for the mapping, assuming that the the downstream LSR will
provide the mapping automatically when it is available.
4.5. Withdraw Message
A downstream LSR distributes a Withdraw message to upstream peers
when it decides to break the mapping between a stream and a label.
Note that if a downstream LSR peer becomes non-ACTIVE, all labels
received from that peer are to be considered withdrawn.
An LSR transmits a Withdraw message under the following condition:
1. The LSR no longer recognizes a previously known stream.
2. Optionally, the LSR has unspliced an upstream label from the
downstream label.
Note that a withdrawn label MAY NOT be reused until the upstream peer
has acknowledged the withdraw via a Release message.
4.6. Release Message
An LSR transmits a Release message to a downstream peer when it is
not using a label previously received from that peer.
An LSR transmits a Release message under any of the following condi-
tions:
1. The downstream LSR which sent the label mapping is not the
next hop for the mapped stream.
2. The downstream LSR which sent the label has ceased to be the
next hop for a stream.
3. The LSR has received a Withdraw message for a previously
received label.
Note that if an LSR is configured for "liberal mode", a release mes-
sage will never be transmitted. In this case, the upstream LSR keeps
each unused label, so that it can immediately be used later if the
downstream peer becomes the next hop for the stream.
Feldman, et al. Expiration: May 1998 [Page 11]
Internet-Draft Label Distribution Protocol November 1997
4.7. Acknowledge Message
An LSR transmits an acknowledge message if it cannot process a
received Advertisement message, or in response to the receipt of a
diffusion query message.
4.8. Query Message
The Query message is used with the diffusion algorithm to verify that
new paths are loop-free before creating an LSP on the new path. See
diffusion section ???
5. Loop Detection
All LSRs perform loop detection via the LSR-path-vector object con-
tained within each label advertisement. Upon receiving such a mes-
sage, the LSR performs loop detection by verifying that its unique
router-id is not already present in the list. If a loop is detected,
the LSR must transmit a NAK message to the sending node, and not
install the mapping or propagate the message any further. In addi-
tion, if there is an upstream label spliced to the downstream label
for the stream, the LSR must unsplice the labels. On those messages
in which no loop is detected, the LSR must concatenate itself to the
LSR-path-vector before propagating.
6. Loop Prevention via Diffusion
LSR diffusion support is a configurable option, which permits an LSR
to verify that a new routed path is loop free before installing an
LSP on that path. An LSR which supports diffusion does not splice an
upstream label a new downstream label until it ensures that concate-
nation of the upstream path with the new downstream path will be loop
free.
A LSR which detects a new nexthop for a stream transmits a query mes-
sage containing its unique router id to each of its upstream peers.
A node that receives such a query processes the query as follows:
o If the sending LSR not the correct next hop for the given
stream, the receiving LSR responds with a positive acknowledge
message, indicating that the sending LSR may change to the new
Feldman, et al. Expiration: May 1998 [Page 12]
Internet-Draft Label Distribution Protocol November 1997
path.
o If the sending LSR is the correct next hop for the given
stream, the receiving LSR performs loop detection via the
LSR-path-vector.
o If a loop is detected, the receiving LSR responds with a nega-
tive "prune" acknowledgment, and unsplices all connections to
the sending node, thereby pruning itself off of the tree.
o If a loop is not detected, the receiving node concatenates its
unique router-id to the LSR-path-vector, and propagates the
query message to its upstream neighbors.
o Each LSR which receives a query acknowledgement from its
upstream neighbor in turn forwards the acknowledgement to the
downstream LSR which sent the query advertisement.
o If an LSR doesn't receive an acknowledgment within a "reason-
able" period of time, it "unsplices" its unsplice the upstream
neighbor that has not responded, and responds with a negative
"prune" acknowledgement.
o An LSR which receives a new query advertisement for a stream
before it has received responses from all of its upstream
neighbors for a previous query advertisement must concaten-
tated the old and the new LSR-path-vector within the new query
advertisement before propagating.
o The diffusion computation continues until each upstream path
responds with an acknowledgment. An LSR that does not have
any upstream MPLS neighbors must acknowledge the query adver-
tisement.
The LSR which began the diffusion may splice its upstream label to
the new downstream label only after receiving an acknowledge message
from the upstream peer.
As LSR diffusion support is a configurable option, an LSRs which do
not support diffusion will never originate a query advertisement.
However, these LSRs must still recognize and process the query mes-
sage, as described above.
Feldman, et al. Expiration: May 1998 [Page 13]
Internet-Draft Label Distribution Protocol November 1997
7. Merging
VC/VP merging, non-merging, and interoperability will be addressed in
a future revision.
8. Specification
The hello mechanism is described first. Following that we define the
structure of the common header and of the objects. We then provide
definitions of the adjacency and advertisement messages and follow
that with definitions for the objects that constitute those messages.
8.1. LDP Hello mechanism
Hello message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This one octet unsigned integer contains the version number of
the protocol. This version of the specification specifies
protocol Version = 0x01.
Reserved
This field is reserved. It must be set to zero on transmission and
must be ignored on receipt.
Length:
This two octet integer specifies the total length of this
PDU in bytes.
Network Address
This 4 octet integer contains the address of the
LSR which originated the discovery message.
Feldman, et al. Expiration: May 1998 [Page 14]
Internet-Draft Label Distribution Protocol November 1997
8.2. Common Header
All LDP PDUs, with the exception of the hello message, must begin
with the following common header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
One octet unsigned integer containing the version number of
the protocol. This version of the specification specifies
protocol Version = 0x01.
Length:
Two octet integer specifying the total length of this
PDU in bytes, including the common header.
MsgClass
One octet integer defining the class of the MPLS message.
This version of the specification defines:
Adjacency Class = 1
Advertisement Class = 2
MPLS Identifier:
Six octet unsigned integer containing a unique identifier for the
LSR that generated the PDU. The value of this Identifier is deter-
mined on startup. The first four octets encode an IP address
assigned to the LSR. The last two octets represent the 'instance'
of MPLS on the LSR. A LSR with only one active MPLS session would
supply the value zero in this field.
Res:
This field is reserved. It must be set to zero on transmission and
must be ignored on receipt.
Feldman, et al. Expiration: May 1998 [Page 15]
Internet-Draft Label Distribution Protocol November 1997
8.3. Object Header
All objects in an MPLS message must begin with the following object
header. Objects must be placed back-to-back within the message, and
must be padded to a word boundary.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Obj Type | Sub Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Type
This one octet field specifies the type of the object following.
This version of the specification defines the following
objects for adjacency class messages:
MSGTYPE_OBJECT = 1
LSR_OBJECT = 2
LABELRANGE_OBJECT = 3
This version of the specification defines the following
objects for advertisement class messages:
MSGTYPE_OBJECT = 1
SMD_OBJECT = 2
LABEL_OBJECT = 3
COS_OBJECT = 4
LSR_PATH_VECTOR_OBJECT = 5
HOPCOUNT_OBJECT = 6
MTU_OBJECT = 7
STACK_OBJECT = 8
ERROR_OBJECT = 9
Sub Type
This one octet field specifies the subtype of this object.
See each of the object definitions for a definition of the subtypes.
Length
This two octet unsigned integer specifies the length of the object,
including this object header.
Feldman, et al. Expiration: May 1998 [Page 16]
Internet-Draft Label Distribution Protocol November 1997
8.4. Adjacency Class Messages
The following notations show the objects that are valid with each
Advertisement Class Message. Only one message may be contained
within a single Adjacency Class PDU.
Initialization Message:
KeepAlive Message:
Shutdown Message:
8.5. Advertisement Class
All Advertisement Class PDUs begin with a common header:
The following notations show the objects that are valid with each
Advertisement Class Message. Multiple messages may be contained
within a single Advertisement Class PDU.
Mapping Message:
[ ] ...
:=