Internet Draft
Network Working Group L Andersson
Internet Draft Ericcson
Expiration Date: September 1998
P Doolan
Ennovate Networks
N Feldman
IBM
A Fredette
Bay Networks
R Thomas
cisco Systems
March 1998
Label Distribution Protocol
draft-mpls-ldp-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).
Anderson, et al. [Page 1]
Internet Draft draft-mpls-ldp-00 .txt March 1998
1. Abstract
An overview of Multi Protocol Label Switching (MPLS) is provided in
[FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental
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.
Contents
Status of this Memo ...................................... 1
1 Abstract ................................................. 2
2 LDP Overview ............................................. 3
3 LDP Operation ............................................ 4
3.1 Selecting Streams ........................................ 4
3.2 Label Spaces, LDP Identifiers, LDP Sessions and LDP Transport 5
3.3 LDP Sessions between non-Directly Connected LSRs ......... 6
3.4 LDP Discovery ............................................ 7
3.5 Establishing and Maintaining LDP Session ................. 8
3.6 Label Distribution and Management ........................ 15
3.7 LDP Identifiers and Next Hop Addresses ................... 17
3.8 Loop Detection ........................................... 18
3.9 Loop Prevention via Diffusion ............................ 18
3.10 Explicitly routing LSPs .................................. 19
4 Protocol Specification ................................... 22
4.1 Discovery Class Messages ................................. 22
4.2 Adjacency Class Messages ................................. 26
4.3 Advertisement Class Messages ............................. 29
4.4 LDP Objects .............................................. 43
5 Security ................................................. 63
6 Acknowledgments .......................................... 63
7 References ............................................... 64
8 Author Information ....................................... 64
Anderson, et al. [Page 2]
Internet Draft draft-mpls-ldp-00 .txt March 1998
2. LDP Overview
LDP is the set of procedures and messages by which Label Switched
Routers (LSRs) establish Label Switched Paths (LSPs) through a
network by mapping network-layer routing information directly to
data-link layer switched paths. These LSPs may have an endpoint at a
directly attached neighbor (comparable to IP hop-by-hop forwarding),
or may have an endpoint at a network egress node, enabling switching
via all intermediary nodes.
An LSP is created for a stream, which identifies a path through a
network. Streams may be extracted from information existing in the
routing protocols, or may be configured. LSPs are extended through a
network as each LSR "splices" incoming labels for a stream to the
outgoing label assigned to the next hop for the given stream.
Two LSRs which use 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 i.e.
the protocol is bi-directional.
There are three classes of LDP messages: 1) A discovery class
message, used to announce and maintain the presence of an LSR in a
network, 2) An adjacency class message, used to establish, maintain,
and terminate adjacencies between LSR peers, and 3) An advertisement
class message, used to create, change, and delete label mappings for
streams.
The discovery class message provides the mechanism whereby LSRs
continually indicate their presence in a network via the Hello
message. This is transmitted as a UDP packet to the LDP port at the
`all LSR routers' group multicast address. When an LSR chooses to
establish an adjacency with an LSR learned via the hello message, it
uses the LDP initialization procedure over TCP transport. Upon
successful completion of the initialization procedure, the two LSRs
are LDP peers, and may exchange advertisement messages.
When to request or advertise a label mapping to a peer is largely a
local decision made by the LSR. In general, an LSR requests a label
mapping from a neighboring LSR when it needs one, and advertises a
label mapping to a neighboring LSR when it wishes the neighbor to use
a label. This document is written from the perspective of control-
traffic driven allocation of labels ie it describes mappings which
are initiated for routes in the forwarding table, regardless of the
traffic over those routes. However, LDP does not preclude support of
a data-driven model.
Anderson, et al. [Page 3]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Correct operation of the label forwarding paradigm requires that
forwarding peers agree on the mappings between Streams and 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 for adjacency and
advertisement class messages.
This document is written with respect to unicast routing only.
Multicast will be addressed in a future revision, although in some
cases placeholders for multicast have been indicated.
The convention used in this document is the same as that used in the
documentation of the internet protocols [rfc1700] i.e. 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.
3. LDP Operation
3.1. Selecting Streams
A stream is one path or an aggregate of several paths, treated as one
for the purpose of forwarding; i.e., all paths using the same unique
label.
LDP supports LSP granularity ranging from end-to-end flows to the
aggregation of all traffic through a common egress node; the choice
of granularity is determined by the stream choice.
Following are the currently defined type of streams. New streams
types may be added as needed:
a) Network Address
This stream is a single network address which resides in a
forwarding information base (FIB). This type results in
the specified address sustaining its own LSP tree. It is
recommended in environments where no aggregation informa-
tion is provided by the routing protocols (such as RIP), or
in networks where the number of destination 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
Anderson, et al. [Page 4]
Internet Draft draft-mpls-ldp-00 .txt March 1998
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 initi-
ated the link state advertisement. This type allows aggre-
gation of traffic on behalf of multiple datagram 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) 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.
f) Flow This stream contains information pertaining to a con-
stant 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.
3.2. Label Spaces, LDP Identifiers, LDP Sessions and LDP Transport
The notion of "label space" is useful for discussing the assignment
and distribution of local (incoming) labels. There are two types of
label spaces:
- Per interface label space. Interface-specific incoming labels
are used for interfaces that use interface resources for
labels. An example of such an interface is a label-controlled
ATM interface which uses VCIs as labels.
Note that the use of a per interface label space only makes
sense when the LDP peers are "directly connected" over an
interface, and the label is only going to be used for traffic
sent over that interface.
- Per platform label space. Platform-wide incoming labels are
Anderson, et al. [Page 5]
Internet Draft draft-mpls-ldp-00 .txt March 1998
used for interfaces that can share the same labels.
An LDP identifier is a six octet quantity used to identify an LSR
label space. The first four octets encode an IP address assigned
to the LSR, and the last two octets identify a specific label space
within the LSR. The last two octets of LDP Identifiers for plat-
form-wide label spaces are always both zero. This document uses
the following print representation for LDP Identifiers:
:
for example, 171.32.27.28:0, 192.0.3.5:2.
Note that an LSR that manages and advertises more than one label
space uses a different LDP Identifier for each such label space.
LDP sessions exist between LSRs to support label exchange between
them.
When a LSR must use LDP to advertise more than one label space
to another LSR it uses a separate LDP session for each label
space rather than a single LDP session for all the label spaces
LDP uses TCP as a reliable transport for sessions.
When multiple LDP sessions are required between two platforms
there is one LDP session per TCP connection rather than many LDP
sessions per TCP connection.
3.3. LDP Sessions between non-Directly Connected LSRs
LDP sessions between LSRs that are not directly connected at the link
level may be desirable in some situations.
For example, consider a "traffic engineering" application where LSR
LSR1 sends traffic matching some criteria via an LSP to non-directly
connected LSR LSR2 rather than forwarding the traffic along its nor-
mally routed path.
An LDP session between LSR1 and LSR2 enables LSR2 to label switch
traffic arriving on the LSP from LSR1. In this situation LSR1
applies two labels to traffic it forwards on the LSP. First, it adds
the label learned via the LDP session with LSR2 to the packet label
stack (either by replacing the label on top of the packet label stack
with it if the packet arrives labeled or or by pushing it if the
packet arrives unlabeled). Next, it pushes the label for the LSP
onto the label stack.
Anderson, et al. [Page 6]
Internet Draft draft-mpls-ldp-00 .txt March 1998
3.4. LDP Discovery
LDP discovery is a mechanism that enables an LSR to discover poten-
tial LDP peers. Discovery makes it unnecessary to explicitly config-
ure an LSR's label switching peers.
There are two variants of the discovery mechanism:
- A basic discovery mechanism used to discover LSR neigbhors
that are directly connected at the link level.
- An extended discovery mechanism used to locate LSRs that are
not directly connected at the link level.
3.4.1. Basic Discovery Mechanism
To engage in LDP Basic Discovery on an interface an LSR periodically
sends LDP Link Hellos out the interface. LDP Link Hellos are sent as
UDP packets addressed to the well known LDP discovery port for the
"all routers" group multicast address.
An LDP Link Hello sent by an LSR carries the LDP Identifier for the
label space the LSR intends to use for the interface and possibly
additional information.
Receipt of an LDP Link Hello on an interface identifies an "Hello
adjacency" with a potential LDP peer reachable at the link level on
the interface as well as the label space the peer intends to use for
the interface.
3.4.2. Extended Discovery Mechanism
LDP sessions between non-directly connected LSRs are supported by LDP
Extended Discovery.
To engage in LDP Extended Discovery an LSR periodically sends LDP
Targeted Hellos to a specific network address. LDP Targeted Hellos
are sent as UDP packets addressed to the well known LDP discovery
port at the specific address.
An LDP Targeted Hello sent by a LSR carries the LDP Identifier for
the label space the LSR intends to use and possibly additional
optional information.
Extended Discovery differs from Basic Discovery in the following
ways:
Anderson, et al. [Page 7]
Internet Draft draft-mpls-ldp-00 .txt March 1998
- A Targeted Hello is sent to a specific network address rather
than to the "all routers" group multicast address for the out-
going interface.
- Unlike Basic Discovery, which is symmetric, Extended Discovery
is asymmetric.
One LSR initiates Extended Discovery with another targeted
LSR, and the targeted LSR decides whether to respond to or
ignore the Targeted Hello. A targeted LSR that chooses to
respond does so by periodically sending Targeted Hellos to the
initiating LSR.
Receipt of an LDP Targeted Hello identifies an "Hello adjacency"
with a potential LDP peer reachable at the network level and the
label space the peer intends to use.
3.5. Establishing and Maintaining LDP Session
3.5.1. LDP Session Establishment
The exchange of LDP Discovery Hellos between two LSRs triggers LDP
session establishment. Session establishment is a two step process:
- Transport connection establishment.
- Session parameter negotiation.
The following describes establishment of an LDP session between LSRs
LSR1 and LSR2 from LSR1's point of view. It assumes the exchange of
Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
for LSR2.
3.5.2. Transport Connection Establishment
The exchange of Hellos results in an Hello adjacency at LSR1 which
binds link L and the label spaces LSR1:a and LSR2:b.
1. If LSR1 does not already have an LDP session for the exchange
of label spaces LSR1:a and LSR2:b it attempts to open an LDP
TCP connection for a new session with LSR2.
LSR1 determines the transport addresses to be used at its end
(A1) and LSR2's end (A2) of the LDP TCP connection. Address
A1 is determined as follows:
Anderson, et al. [Page 8]
Internet Draft draft-mpls-ldp-00 .txt March 1998
a) If LSR1 uses the Transport Address optional object, A1 is
the address LSR1 advertises via the optional object;
b) If LSR1 does not use the Transport Address optional
object, A1 is the source IP address used for Hellos to
LSR2.
Similarly, address A2 is determined as follows:
a) If LSR2 uses the Transport Address optional object, A2 is
the address LSR2 advertises via the optional object;
b) If LSR2 does not use the Transport Address optional
object, A2 is the source IP address used for Hellos from
LSR2.
2. LSR1 determines whether it will play the active or passive
role in session establishment by comparing addresses A1 and A2
as unsigned integers. If A1 > A2, LSR1 plays the active role;
otherwise it is passive.
3. If LSR1 is active, it attempts to establish the LDP TCP con-
nection by connecting to the well known LDP port at address
A2. If LSR1 is passive, it waits for LSR2 to establish the
LDP TCP connection to its well known LDP port.
3.5.3. Initialization
After LSR1 and LSR2 establish a transport connection they negotiate
session parameters by exchanging LDP Initialization messages. The
parameters negotiated include LDP protocol version, label distribu-
tion method, timer values, VPI/VCI ranges for label controlled ATM,
etc.
Successful negotiation completes establishment of an LDP session
between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
and LSR2:b.
The following describes the negotiation from LSR1's point of view.
1. After the connection is established, if LSR1 is is playing the
active role, it initiates negotiation of session parameters by
sending an Initialization message to LSR2. If LSR1 is pas-
sive, it waits for LSR2 to initiate the parameter negotiation.
In general when there are multiple links between LSR1 and LSR2
Anderson, et al. [Page 9]
Internet Draft draft-mpls-ldp-00 .txt March 1998
and multiple label spaces to be advertised by each, the pas-
sive LSR cannot know which label space to advertise over a
newly established TCP connection until it receives the first
LDP PDU on the connection.
By waiting for the Initialization message from its peer the
passive LSR can match the label space to be advertised by the
peer (as determined from the LDP Identifier in the common
header for the Initialization message) with an Hello adjacency
previously created when Hellos were exchanged.
2. When LSR1 plays the passive role:
a) If LSR1 receives an Initialization message it attempts to
match the LDP Identifier carried by the message PDU with
an Hello adjacency.
b) If there is a matching Hello adjacency, the adjacency
specifies the local label space for the session.
Next LSR1 checks whether the session parameters proposed
in the message are acceptable. If they are, LSR1 replies
with an Initialization message of its own to propose the
parameters it wishes to use and a KeepAlive message to
signal acceptance of LSR2's parameters. If the parame-
ters are not acceptable, LSR1 responds by sending a Nak
message and closing the TCP connection.
c) If LSR1 cannot find a matching Hello adjacency it sends a
Nak message and closes the TCP connection.
d) If LSR1 receives a KeepAlive in response to its Initial-
ization message, the session is operational from LSR1's
point of view.
e) If LSR1 receives a Nak message, LSR2 has rejected its
proposed session parameters and LSR1 closes the TCP con-
nection.
3. When LSR1 plays the active role:
a) If LSR1 receives a Nak message, LSR2 has rejected its
proposed session parameters and LSR1 closes the TCP con-
nection.
b) If LSR1 receives an Initialization message, it checks
whether the session parameters are acceptable. If so, it
Anderson, et al. [Page 10]
Internet Draft draft-mpls-ldp-00 .txt March 1998
replies with a KeepAlive message. If the session parame-
ters are unacceptable, LSR1 sends a Nak message and
closes the connection.
c) If LSR1 receives a KeepAlive message, LSR2 has accepted
its proposed session parameters.
d) When LSR1 has receive both an acceptable Initialization
message and a KeepAlive message the session is opera-
tional from LSR1's point of view.
3.5.4. Initialization State Machine
It is convenient to describe LDP session negotiation behavior in
terms of a state machine. We define the LDP state machine to have
five possible states and present the behavior as a state transition
table and as a state transition diagram.
Anderson, et al. [Page 11]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Session Initialization State Transition Table
STATE EVENT NEW STATE
NON EXISTENT Session TCP connection established INITIALIZED
established
INITIALIZED Transmit Initialization msg OPENSENT
Receive acceptable OPENREC
Initialization msg
Action: Transmit Initialization
msg and KeepAlive msg
Receive Any other LDP msg NON EXISTENT
Action: Transmit Nak msg and
close transport connection
OPENREC Receive KeepAlive msg OPERATIONAL
Receive Any other LDP msg NON EXISTENT
Action: Transmit Nak msg and
close transport connection
OPENSENT Receive acceptable OPENREC
Initialization msg
Action: Transmit KeepAlive msg
Receive Any other LDP msg NON EXISTENT
Action: Transmit Nak msg and
close transport connection
OPERATIONAL Receive Shutdown msg NON EXISTENT
Action: Transmit Shutdown msg and
close transport connection
Receive other LDP msgs OPERATIONAL
Timeout NON EXISTENT
Action: Transmit Shutdown msg and
close transport connection
Anderson, et al. [Page 12]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Session Initialization State Transition Diagram
+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg |
| +-----------+ |
Rx Any other | | | |
msg / | |INITIALIZED| |
Tx Nak msg | +---| |-+ |
| | +-----------+ | |
| | | |
| | Rx Init msg / | Tx Init msg |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other |
| +-------+ +--------+ msg / |
Rx KeepAlive | ^ | Tx Nak msg |
msg | | | |
| | | Rx Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown msg
All other | ^ or TIMEOUT /
LDP msgs | | Tx Shutdown msg
| |
+---+
Anderson, et al. [Page 13]
Internet Draft draft-mpls-ldp-00 .txt March 1998
3.5.5. Maintaining Hello Sessions
An LDP session with a peer has one or more Hello adjacencies.
An LDP session has multiple Hello adjacencies when a pair of LSRs are
connected by multiple links that share the same label space; for
example, multiple PPP links between a pair of routers. In this situ-
ation the Hellos an LSR sends on each such link carries the same LDP
Identifier.
LDP includes mechanisms to monitor the necessity of an LDP session
and its Hello adjacencies.
LDP uses the regular receipt of LDP Discovery Hellos to indicate a
peer's intent to use the label space identified by the Hello. An LSR
maintains a hold timer with each Hello adjacency which it restarts
when it receives an Hello that matches the adjacency. If the timer
expires without receipt of a matching Hello from the peer, LDP con-
cludes that the peer no longer wishes to label switch using that
label space for the link (or target, in the case of Targeted Hellos)
in question or that the peer has failed, and it deletes the Hello
adjacency. When the last Hello adjacency for a LDP session is
deleted, the LSR terminates the LDP session by closing the transport
connection.
3.5.6. Maintaining LDP Sessions
LDP includes mechanisms to monitor the integrity of the session
transport connection.
LDP uses the regular receipt of LDP PDUs on the session transport
connection to monitor the integrity of the connection. An LSR main-
tains a keepalive timer for each peer session which it resets when-
ever it receives an LDP PDU from the session peer. If the keepalive
timer expires without receipt of an LDP PDU from the peer the LSR
concludes that the transport connection is bad or that the peer has
failed, and it terminates the peer session by closing the transport
connection.
An LSR must arrange that its LDP peer sees an LDP PDU from it at
least every keepalive time period to ensure the peer restarts the
session keepalive timer. The LSR may send any protocol message to
meet this requirement. In circumstances where an LSR has no other
information to communicate to its peer, it sends a KeepAlive message.
An LSR may choose to terminate an LDP session with a peer at any
time. Should it choose to do so, it informs the peer with a Shutdown
Anderson, et al. [Page 14]
Internet Draft draft-mpls-ldp-00 .txt March 1998
message.
3.6. Label Distribution and Management
3.6.1. Label Distribution Control Mode
The behavior of the initial setup of LSPs is determined by whether
the LSR is operating with independent or ordered LSP control. An LSR
may support both types of control as a configurable option.
3.6.1.1. Independent Label Distribution Control
When using independent LSP control, each node may advertise label
mappings to its neighbors at any time it desires. For example, when
operating in independent Downstream-on-Demand mode, an LSR may answer
requests immediately, without waiting for a label mapping from the
next hop. When operating in independent Downstream allocation mode,
an LSR may advertise label mappings to its neighbors whenever it rec-
ognizes a valid stream.
A consequence of using independent mode is that an upstream label can
be advertised before a downstream label is received. This can result
in unlabeled packets being sent to the downstream node.
3.6.1.2. Ordered Label Distribution Control
When LSP is control is ordered control, an LSR may only initiate the
transmission of label mappings for a stream for which it has a label
mapping, or for which the LSR is the egress. For those streams for
which the LSR is not the egress and no mapping exists, the LSR MUST
wait until a label from a downstream LSR for is received before map-
ping the streams and passing corresponding labels to upstream LSRs.
An LSR may be an egress for a particular set of streams, and a non-
egress for others. An LSR is an egress LSR, with respect to a par-
ticular stream, under any of the following conditions:
1. The stream refers to the LSR itself (including one of its
directly attached interfaces).
2. The next hop router for the stream outside of the Label
Switching Network.
Anderson, et al. [Page 15]
Internet Draft draft-mpls-ldp-00 .txt March 1998
3 The stream is reachable by crossing a routing domain boundary,
such as another area for OSPF summary net-works, or another
autonomous system for OSPF AS externals and BGP routes
[rfc1583] [rfc1771].
3.6.2. Label Retention Mode
3.6.2.1. Conservative Label Retention Mode
In Downstream Allocation mode, label mapping advertisements for all
routes may be received from all peer LSRs. When using conservative
label retention, advertised label mappings are only retained if they
will be used to forward packets (i.e., if they are received from a
valid next hop according to routing). If operating in Downstream-on-
Demand mode, label mappings will only be requested of the appropriate
next hop LSR according to routing. Since Downstream-on-Demand mode
is primarily used when label conservation is desired (e.g., an ATM
switch with limited cross connect space), it is typically used with
the conservative label retention mode.
The main advantage of the conservative mode is that the only the
labels that are required for the forwarding of data are allocated and
maintained. This is particularly important in LSRs where the label
space is inherently limited, such as in an ATM switch. A disadvan-
tage of the conservative mode is that if routing changes the next hop
for a given destination, a new label must be obtained from the new
next hop before labeled packets can be forwarded.
3.6.2.2. Liberal Label Retention Mode
In Downstream Allocation mode, label mapping advertisements for all
routes may be received from all peer LSRs. When using liberal label
retention,
advertised label mappings are retained from all next hops regardless
of whether they are valid next hops for the advertised mapping. When
operating in Downstream-on-Demand mode, label mappings are requested
of all peer LSRs. Note, however, that Downstream-on-Demand mode is
typically associated with ATM switch-based LSRs where the conserva-
tive approach is recommended.
The main advantage of the liberal label retention mode is that reac-
tion to routing changes can be quick because labels already exist.
The main disadvantage of the liberal mode is that unneeded label map-
pings are distributed and maintained.
Anderson, et al. [Page 16]
Internet Draft draft-mpls-ldp-00 .txt March 1998
3.6.3. Label Advertisement Mode
Each interface on an LSR is configured to operate in either Down-
stream or Downstream-on-Demand allocation mode. LSRs exchange adver-
tisement modes
during initialization. The major difference between Downstream and
Downstream-on-Demand modes is in who is responsible for initiating
mapping requests and mapping advertisements
3.7. LDP Identifiers and Next Hop Addresses
An address message is used when an LSR is engaged in Downstream label
allocation (as opposed to Downstream-on-Demand).
The LSR maintains learned labels in a Label Information Base (LIB).
The LIB entry for an address prefix associates a collection of (LDP
Identifier, label) pairs with the prefix, one such pair for each peer
advertising a label for the prefix.
When the next hop for a prefix changes the LSR must retrieve the
label advertised by the new next hop from the LIB for use in forward-
ing. To retrieve the label the LSR must be able to map the next hop
address for the prefix to an LDP Identifier.
Similarly, when the LSR learns a label for a prefix from an LDP peer,
it must be able to determine whether that peer is currently a next
hop for the prefix to determine whether it needs to start using the
newly learned label when forwarding packets that match the prefix.
To make that decision the LSR must be able to map an LDP Identfier to
the peer's addresses to check whether any are a next hop for the pre-
fix.
To enable LSRs to map between a peer LDP identifier and the peer's
addresses, LSRs advertise their addresses using LDP Address and With-
draw Address messages.
An LSR sends an Address message to advertise its addresses to a peer.
An LSR sends a Withdraw Address message to withdraw previously adver-
tised addresses from a peer
Anderson, et al. [Page 17]
Internet Draft draft-mpls-ldp-00 .txt March 1998
3.8. Loop Detection
Each LSR MUST support the configurable loop-detection option. LSRs
perform loop detection via the LSR-path-vector object contained
within each Mapping and Query message. 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.
If loop detection is desired in some portion of the network, then it
should be turned on in ALL LSRs within that portion of the network,
to ensure loop detection operates properly.
3.9. 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 to a new downstream label until it ensures that con-
cate- nation of the upstream path with the new downstream path will
be loop free.
A LSR which detects a new next hop for a stream transmits a Query
mes- sage containing its unique router id to each of its upstream
peers. An LSR that receives such a Query message processes the Query
as follows:
o If the downstream LSR not the correct next hop for the given
stream, the upstream LSR responds with an Ack message, indi-
cating that the downstream LSR may change to the new path.
o If the downstream LSR is the correct next hop for the given
stream, the upstream LSR performs loop detection via the LSR-
path-vector.
o If a loop is detected, the upstream LSR responds with a
"prune" Nak message, and unsplices all connections for that
stream to the downstream node, thereby pruning itself off of
the tree.
o If a loop is not detected, the upstream node concatenates its
unique router-id to the LSR-path-vector, and propagates the
Anderson, et al. [Page 18]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Query message to its upstream peers.
o Each LSR which receives a Query Ack message from its upstream
peer in turn forwards the acknowledgement to the downstream
LSR which sent the Query message.
o If an LSR doesn't receive a Query Ack Message within a "rea-
sonable" period of time, it "unsplices" the upstream peer that
has not responded, and responds with a Query Nak to its down-
stream peer, indicating the pruning of the upstream peer.
o An LSR which receives a new Query message for a stream before
it has received responses from all of its upstream peers for a
previous Query message must concatenate 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 LDP peers must acknowledge the Query message.
The LSR which began the diffusion may splice its upstream label to
the new downstream label only after receiving an acknowledge mes-
sage from the upstream peer.
As LSR diffusion support is a configurable option, an LSR which
does not support diffusion will never originate a Query message.
However, these LSRs must still recognize and process the Query mes-
sages, as described above.
3.10. Explicitly routing LSPs
The need for explicit routing (ER) in MPLS has been explored else-
where [ARCH] [FRAME]. At the MPLS WG meeting held during the Wash-
ington IETF there was concensus that LDP should support explicit
routing of LSPs with provision for indication of associated (forward-
ing) priority. This section specifies mechanisms to provide that
support. It goes somewhat further in that we also provide means to
allow the reservation of 'resources' for the explicitly routed LSP.
In this document we propose an end to end setup mechanism that could,
in principal, be invoked from either end of the explicitly routed
LSP (ERLSP). However we specify it here only for the case of initia-
tion by the egress in the belief that such a mechanism maps naturally
to the downstream on demand label allocation paradigm that fits most
naturally with ATM [ARCH]. We believe that the, inevitable, latency
Anderson, et al. [Page 19]
Internet Draft draft-mpls-ldp-00 .txt March 1998
associated with this (end to end) setup mechanism is tolerable since
most of the motivations for ERLSPs, for example 'traffic engineering'
imply that the LSPs setup in this manner will have a long lifetime
(at least when compared to those setup in reponse to dynamic rout-
ing).
We introduce objects and procedures that provide support for:
- Strict and Loose explicit routing
- Specification of priority
- Reservation of bandwidth
To setup an ERLSP an LSR (that will be the 'egress' of the LSP)
generates an explicit request. The explicit request contains an
explicit request object which in turn contains a sequence of
explicit request next hop objects and a pointer to the current
entry in that sequence. The explicit request next hop objects
specify the IPv4 address of the LSRs through which the ERLSP should
pass. There may be reservation objects associated with each of the
next hop objects.
An explicit request MUST specify the stream that will be associated
with the ERLSP by inserting the appropriate SMD value in the
request. The SMD value 'opaque tunnel' exists to support ERLSPs
where the intermediate LSRs on the LSP need know nothing about the
traffic flowing on the LSP. Note that in the case where the value
'opaque tunnel' is specified some mechanism outside the scope of
this protocol must be used to inform the (head) end of the ERLSP
what traffic to pass into it. Configuration is an example of one
such mechanism.
The setup mechanism for ERLSPs employs an end to end protocol.
Individual ERLSPs are uniquely identified by an ERLSPID associated
with them by the LSR that initiates their setup. Requests travel
from the 'egress' of the LSP toward what will be the 'ingress'.
Responses indicating the success or otherwise of the ERLSP request
travel back toward the egress of the ERLSP. ERLSP is used in both
Request and Response messages.
The addresses specified in the next hop objects in the explicit
route request should be those of incoming interfaces on the LSRs
through which the LSP should pass. At each LSR the explicit route
object is processed as follows:
The ERLSPID, label, SMD, incoming interface and LDP identifier of
the LSR that generated the message are all stored in an ERLSP
Anderson, et al. [Page 20]
Internet Draft draft-mpls-ldp-00 .txt March 1998
control block.
The 'active' ERNH object specified by the pointer in the explicit
route object is processed as follows:
When the ERNH objects subtype indicates 'Strict' the appropriate
LDP Identifier for the LDP session with the next hop and the
appropriate output interface are discovered (by using the infor-
mation learnt from the address message see "LDP Identifiers"
section 2.7).
Procedure for the case where the ERNH subtype indicates 'Loose'
are FFS.
Resource reservations (if any) are processed. How this happens
i.e. the precise connection admission procedures is outside the
scope of the LDP specification. If a reservation cannot be acco-
modated a response indicating that fact is returned to the pre-
vious hop.
If the ERLSP can be accomodated an outgoing label is selected
and inserted into the request message. The pointer in the
explicit request object is incremented to point at the next
explicit request next hop object and the request message is sent
to the LDP peer discovered as described above.
If an LSR finds it impossible to satisfy a Explicit request then
an 'Explicit response' message is created indicating the reason.
The ERLSPID from (failed) request is inserted in the message and
it is sent to the LDP peer identified in the associated entry in
the ERLSP control block after which the ERLSP block is freed.
LSRs receiving Explicit responses indicating failure process
them in a similar manner. They create a new Explicit request and
copy the ERLSPID and Status from the Explicit request they
received into it. They use the ERLSPID to obtain the appropri-
ate ERLSP control block and thus identify the LDP peer toward
which the 'new' Explicit response message should be sent. Having
done that they free the ERLSP control block.
When an Explicit request reaches the LSR specified in the last
ERNH object in that request and that LSR acceeds to the request
it generates an Explicit response indicating successful setup of
the ERLSP. The Explicit response is (reverse path) forwarded
through the LSRs that the original Explicit request traversed
using the mechanism described above (inspection of ERLSP control
block). In this case, of course,the ERLSP control block is not
deleted;
Anderson, et al. [Page 21]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4. Protocol Specification
4.1. Discovery Class Messages
4.1.1. Discovery Encoding
An LDP Hello PDU is an LDP common header followed by an object header
and Hello message object:
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 | Msg Class | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Res | Msg Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
One octet unsigned integer containing the version number of the
protocol. This version of the specification specifies protocol
Version = 0x01.
Msg Class
One octet integer defining the class of the MPLS message. This
version of the specification defines:
Discovery Class = 0x01
Adjacency Class = 0x02
Advertisement Class = 0x03
PDU Length
Two octet integer specifying the total length of this PDU in
bytes, excluding the common header.
LDP Identifier
Six octet field that uniquely identifiers the label space for
which this PDU applies. The first four octets encode an IP
address assigned to the LSR. This address should be the router-
Anderson, et al. [Page 22]
Internet Draft draft-mpls-ldp-00 .txt March 1998
id, also used in LSR-path-vector loop detection/prevention
objects. The last two octets identify a label space within the
LSR. For a platform-wide label space, these should both be
zero.
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Type
The MsgType field identifies the type of message. The following
discovery messages are supported:
Hello Message = 0x01
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Length
Two octet integer specifying the total length of all objects
associated with the message type.
4.1.2. Hello Objects
See section 4.4 for the object encodings.
Mandatory Objects
This version of the protocol defines no mandatory objects for the
Hello message.
Optional Objects
Zero or more optional object headers with associated objects.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Targeted Hello | 0x01 |
+-----------------------+----------+
| Send Targeted Hello | 0x02 |
+-----------------------+----------+
| Transport Address | 0x03 |
+-----------------------+----------+
| Hello Hold Time | 0x04 |
+-----------------------+----------+
Targeted Hello
Anderson, et al. [Page 23]
Internet Draft draft-mpls-ldp-00 .txt March 1998
This Hello is a Targeted Hello. Without this optional parameter
the Hello is a Link Hello.
Send Targeted Hello
Requests the receiver to send periodic Targeted Hellos to the
source of this Hello. An LSR initiating Extended Discovery uses
this option.
Transport Address
Specifies the IPv4 address to be used for the sending LSR when
opening the LDP session TCP connection. If this optional object
is not present the IPv4 source address for the UDP packet carry-
ing the Hello should be used.
Hello Hold Time
An LSR maintains a record of Hellos received from potential
peers (see "Discovery Processing" section 3.1.3) When present,
this parameter specifies the time in seconds the sending LSR
will maintain its record of Hellos from the receiving LSR with-
out receipt of another Hello. When not present, the sender will
use a default hold time. There are interface- type specific
defaults for Link Hellos as well a default for Targeted Hellos.
4.1.3. Discovery Processing
An LSR receiving Hellos from another LSR maintains an Hello adjacency
for the Hellos. The LSR maintains a hold timer with the Hello adja-
cency which it restarts whenever it receives an Hello that matches
the Hello adjacency. If the hold timer for an Hello adjacency
expires the LSR discards the Hello adjacency (see "Maintaining LDP
Sessions and Hello Adjacencies" sections 2.5.5 and 2.5.6).
A LSR processes a received LDP Hello as follows:
1. The LSR checks whether the Hello is acceptable. The criteria
for determining whether an Hello is acceptable are implementa-
tion dependent (see below for example criteria).
2. If the Hello is not acceptable, the LSR ignores it.
3. If the Hello is acceptable, the LSR checks whether it has an
Hello adjacency for the Hello source. If so, it restarts the
hold timer for the Hello adjacency. If not it creates an
Hello adjacency for the Hello source and starts its hold
timer.
4. If the Hello carries any optional objects the LSR processes
Anderson, et al. [Page 24]
Internet Draft draft-mpls-ldp-00 .txt March 1998
them (see below).
5. Finally, if the LSR has no LDP session for the label space
specified by the LDP identifier in the common header for the
Hello, it attempts to establish a session for the label space
(see "LDP Session Establishment" section 2.5.1).
The following are examples of acceptability criteria for Link and
Targeted Hellos:
A Link Hello is acceptable if the interface on which it was
received has been configured for label switching.
A Targeted Hello from IP source address a.b.c.d is acceptable if
either:
1. The LSR has been configured to accept Targeted Hellos, or
2. The LSR has been configured to send Targeted Hellos to
a.b.c.d.
The following describes how an LSR processes Hello optional objects:
Targeted Hello
No special processing required.
Send Targeted Hello
If the Send Targeted Hello option is carried by the Hello, the
LSR checks whether it has been configured to send Targeted
Hellos to the Hello source in response to Hellos with this
option. If not, it ignores the option. If so, it initiates
periodic transmission of Targeted Hellos to the Hello source.
Transport Address
The LSR associates the specified transport address with the
Hello adjacency.
Hello Hold Time
A pair of LSRs negotiate the hold times they use for Hellos
from each other. Each LSR proposes a hold time in its Hellos
either explicitly by including the Hold Time optional object
or implicitly by omitting it. The hold time used by the LSRs
is the minimum of the hold times proposed in their Hellos.
We recommend that the interval between Hello transmissions be at most
one third of the Hello hold time.
Anderson, et al. [Page 25]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.2. Adjacency Class Messages
Adjacency class messages manage LSR peers.
4.2.1. Adjacency Encoding
An LDP adjacency PDU consists of an LDP common header followed by a
message type and zero or more objects. Note only one message type may
be contained within a single Adjacency Class PDU.
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 | Msg Class | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Res | Msg Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
One octet unsigned integer containing the version number of the
protocol. This version of the specification specifies protocol
Version = 0x01.
Msg Class
One octet integer defining the class of the MPLS message. This
version of the specification defines:
Discovery Class = 0x01
Adjacency Class = 0x02
Advertisement Class = 0x03
PDU Length
Two octet integer specifying the total length of this PDU in
bytes, excluding the common header.
LDP Identifier
Six octet field that uniquely identifiers the label space for
Anderson, et al. [Page 26]
Internet Draft draft-mpls-ldp-00 .txt March 1998
which this PDU applies. The first four octets encode an IP
address assigned to the LSR. This address should be the router-
id, also used in LSR-path-vector loop detection/prevention
objects. The last two octets identify a label space within the
LSR. For a platform-wide label space, these should both be
zero.
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Type
The MsgType field identifies the type of message. The following
adjacency messages are supported:
Ack/Nak Message 0x01
Initialization Message 0x02
KeepAlive Message 0x03
Shutdown Message 0x04
Address Message 0x05
Withdraw Address Message 0x06
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Length
Two octet integer specifying the total length of all objects
associated with the message type.
4.2.2. Ack/Nak Objects
An LSR transmits an Nak message if it cannot process a received adja-
cency.
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| Error | 0x01 |
+-----------------------+----------+
Optional Objects
This version of the protocol defines no optional objects for the
Anderson, et al. [Page 27]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Ack/Nak message.
Error
The error code associated with received message. A zero error
code is an Ack message. A non-zero error code is a Nak message.
4.2.3. Initialization Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| LSR | 0x02 |
+-----------------------+----------+
Optional Objects
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Label Range | 0x03 |
+-----------------------+----------+
LSR
The LSR characteristics exchanged between LSR peers at startup,
such as KeepAlive timer, loop detection, allocation type, etc.
Label Range
A pair of LSRs exchange their supported label range at initial-
ization. A receiving LSR MUST calculate the intersection
between the received range and its own supported label range.
The intersection is the range in which the LSR may allocate and
accept labels.
4.2.4. KeepAlive Objects
Mandatory Objects
This version of the protocol defines no mandatory objects for the
KeepAlive message.
Anderson, et al. [Page 28]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Optional Objects
This version of the protocol defines no optional objects for the
KeepAlive message.
4.2.5. Address/Withdraw-Address Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| Address List | 0x04 |
+-----------------------+----------+
Optional Objects
This version of the protocol defines no optional objects for the
Address message.
Address List
The LSR address(es), used by a peer to map the LDP identifier to
the given address(es), for the purpose of next hop verification.
4.2.6. Shutdown Objects
Mandatory Objects
This version of the protocol defines no mandatory objects for the
Shutdown message.
Optional Objects
This version of the protocol defines no optional objects for the
Shutdown message.
4.3. Advertisement Class Messages
The advertisement class messages control the formation and the pro-
cessing of LSPs.
Anderson, et al. [Page 29]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.3.1. Advertisment Encoding
An LDP advertisement PDU consists of an LDP common header followed by
one or more message types and associated message objects.
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 | MsgClass | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MsgType | Res | MsgLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Objects |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
One octet unsigned integer containing the version number of the
protocol. This version of the specification specifies protocol
Version = 0x01.
Msg Class
One octet integer defining the class of the MPLS message. This
version of the specification defines:
Discovery Class = 0x01
Adjacency Class = 0x02
Advertisement Class = 0x03
PDU Length
Two octet integer specifying the total length of this PDU in
bytes, excluding the common header.
LDP Identifier
Six octet field that uniquely identifiers the label space for
which this PDU applies. The first four octets encode an IP
address assigned to the LSR. This address should be the router-
id, also used in LSR-path-vector loop detection/prevention
objects. The last two octets identify a label space within the
LSR. For a platform-wide label space, these should both be
zero.
Anderson, et al. [Page 30]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Type
The MsgType field identifies the type of message. The following
advertisement messages are supported:
Ack/Nak Message 0x01
Mapping Message 0x02
Request Message 0x03
Withdraw Message 0x04
Release Message 0x05
Query Message 0x06
Explicit Request 0x07
Explicit Response 0x08
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Msg Length
Two octet integer specifying the total length of all objects
associated with the message type.
4.3.2. Ack/Nak
An LSR transmits an Nak message if it cannot process a received
advertisement. An LSR may transmit an Ack only in response to a dif-
fusion query message.
4.3.2.1. Ack/Nak Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
| Error | 0x01 |
+-----------------------+----------+
Optional Objects
Anderson, et al. [Page 31]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Label | 0x03 |
+-----------------------+----------+
Rules:
1. SMD object(s) MUST always be listed before the associated
Error Object and optional objects.
2. Optional objects are associated with the preceding SMD Object.
SMD
The Stream Member Descriptor specifies the stream which is being
Acknowledged.
Error
The error code associated with the SMD. A zero error code is an
Ack message. A non-zero error code is a Nak message.
Label
The label associated with the SMD which is being Ack'd or Nak'd.
4.3.3. Mapping
The Mapping message is used by an LSR to distribute a label mapping
for a stream to its LDP peers. If an LSR distributes a mapping for a
stream to multiple LDP 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.
An LSR is always responsible for the consistency of the label map-
pings it has distributed, and that its peers have these mappings.
4.3.3.1. Independent Control Mapping
If an LSR is doing independent control, a mapping message is trans-
mitted by an LSR to peers upon any of the following conditions:
1. The LSR recognizes a new stream via the forwarding table, and
the label advertisement mode is Downstream allocation.
Anderson, et al. [Page 32]
Internet Draft draft-mpls-ldp-00 .txt March 1998
2. The LSR receives a Request message from an upstream peer for a
stream present in the LSR's forwarding table.
3. The next hop for a stream changes to another LDP peer, and
loop detection is configured.
4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop, AND
- no upstream mapping has been created OR
- loop detection is configured OR
- the attributes of the mapping have changed.
4.3.3.2. Ordered Control Mapping
If an LSR is doing ordered control, a Mapping message 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 that stream.
2. The LSR receives a Request message 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, and
loop detection is configured.
4. The attributes of a mapping change.
5. The receipt of a mapping from the downstream next hop, AND
- no upstream mapping has been created OR
- loop detection is configured OR
- the attributes of the mapping have changed.
4.3.3.3. Downstream-on-Demand Label Advertisement Mapping
In general, the upstream LSR is responsible for requesting label map-
pings when operating in Downstream-on-Demand mode. Unless some rules
are followed, it is possible for neighboring LSRs with different
advertisement modes to get into a sort of LDP livelock where every-
thing is functioning properly, but no labels are distributed. For
example, consider two LSRs Ru and Rd where Ru is the upstream LSR and
Anderson, et al. [Page 33]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Rd is the downstream LSR for a particular stream. In this example,
Ru is using Downstream allocation mode and Rd is using Downstream-on-
Demand mode. In this case, Rd may assume that Ru will request a
label mapping when it wants one and Ru may assume that Rd will adver-
tise a label if it wants Ru to use one. If Rd and Ru operate as sug-
gested, no labels will be distributed and packets must be routed at
layer 3.
This LDP livelock can be avoided if the following rule is observed.
An LSR operating in Downstream-on-Demand mode should not be expected
to send unsolicited mapping advertisements. Therefore, if the down-
stream LSR is
operating in Downstream-on-Demand mode, the upstream LSR is responsi-
ble for requesting label mappings as needed. If the trigger mode is
control, then the LSR should request label mappings for all routes.
However, if all interfaces on the LSR are configured to operate in
Downstream-on-Demand mode the LSR can wait to issue a request until a
corresponding request has been sent from an upstream LSR.
4.3.3.4. Downstream Allocation Label Advertisement Mapping
In general, the downstream LSR is responsible for advertising label
mappings when it wants an upstream LSR to use labels. An upstream
LSR may issue a mapping request if it so desires.
4.3.3.5. Mapping Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
Anderson, et al. [Page 34]
Internet Draft draft-mpls-ldp-00 .txt March 1998
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
| Label | 0x03 |
+-----------------------+----------+
Optional Objects
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Class of Service | 0x04 |
+-----------------------+----------+
| LSR Path Vector | 0x05 |
+-----------------------+----------+
| Hop Count | 0x06 |
+-----------------------+----------+
| MTU | 0x07 |
+-----------------------+----------+
| Stack | 0x08 |
+-----------------------+----------+
Rules:
1. SMD object(s) MUST always be listed before the associated
Label Object
2. Single SMD object followed by single Label Object: One-to-one
mapping between SMD and label.
3. Multiple SMD objects followed by a Label Object: Multiple SMDs
applied to same label.
4. Single SMD followed by multiple Label Objects is a multipath
SMD.
5. Multiple SMDs followed by multiple labels is prohibited.
6. Optional objects are associated with the preceding Label
Object.
SMD
The Stream Member Descriptor specifies the stream which is to be
mapped to a given label, forming an LSP.
Anderson, et al. [Page 35]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Label
The label which is mapped to the SMD.
Class of Service
The class of service to be assigned to the Label.
LSR Path Vector
A list of the unique router-identifiers of the LSRs traversed in
the creation of the LSP for the given SMD. It is used when loop
detection is configured. An LSR that finds its own unique iden-
tifier in a Path Vector is in a loop. When no loop is present,
the LSR is responsible for appending its unique router-id to the
Path Vector, and including the vector in the Mapping message
forwarded to the next LSR.
Hop Count
The number of hops in the LSP created for the SMD/Label pair.
This value is incremented by one at each LSR forwarding the Map-
ping message.
MTU
The maximum transmission unit along the LSP. Each LSR must com-
pare the received value with its own MTU on the receiving link.
The minimum of these values is the MTU forwarded in the Mapping
message.
Stack
A list of prefixes that are associated with the label in the
Stack object, such that the LSR at the termination point of the
LSP may continue L2 forwarding on the given stacked label,
thereby avoiding L3 forwarding.
4.3.4. Request
The Request message is used by an 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 OPERATIONAL LDP peer, and one doesn't
already have a mapping from the next hop for the given stream.
2. The next hop to the stream changes, and the LSR doesn't
already have a mapping from that next hop for the given
stream.
Anderson, et al. [Page 36]
Internet Draft draft-mpls-ldp-00 .txt March 1998
If a request cannot be satisfied by the downstream LSR, the
requesting LSR may optionally choose to request again at a later
time, or, if the downstream LSR is configured for Downstream Allo-
cation, the requesting LSR may wait for the mapping, assuming that
the downstream LSR will provide the mapping automatically when it
is available.
4.3.4.1. Request Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
| Class of Service | 0x04 |
+-----------------------+----------+
Optional Objects
This version of the protocol defines no optional objects for the
Request message.
SMD
The Stream Member Descriptor specifies the stream for which a
label is requested.
Class of Service
The class of service to be assigned to the Label.
4.3.5. Withdraw
An LSR distributes a Withdraw message to LDP peers when it breaks the
mapping between a stream and a label. Note that if an LDP peer
becomes non- OPERATIONAL, 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.
Anderson, et al. [Page 37]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.3.5.1. Withdraw Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
Optional Objects
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Label | 0x03 |
+-----------------------+----------+
Rules:
1. SMD object(s) MUST always be listed before the associated
Label Object
2. Single SMD object followed by single Label Object: One-to-one
mapping between SMD and label.
3. Multiple SMD objects followed by a Label Object: Multiple SMDs
applied to same label.
4. Single SMD followed by multiple Label Objects: Multipath SMD
SMD
The Stream Member Descriptor specifies the stream for which
labels are to be withdrawn. If no label object follows, all
labels associated with the SMD are withdrawn, else only the
labels specified in the following label object are withdrawn.
Label
The label associated with the SMD which is to be withdrawn.
Anderson, et al. [Page 38]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.3.6. Release
An LSR transmits a Release message to a 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 LSR which sent the label mapping is not the next hop for
the mapped stream, and the LSR is configured for conservative
operation.
2. The LSR which sent the label has ceased to be the next hop for
a stream, and the LSR is configured for conservative opera-
tion.
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.
4.3.6.1. Release Objects
See section 4.4 for the object encodings.
Mandatory Objects
At least one of each mandatory object with associated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
Optional Objects
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Label | 0x03 |
+-----------------------+----------+
Rules:
Anderson, et al. [Page 39]
Internet Draft draft-mpls-ldp-00 .txt March 1998
1. SMD object(s) MUST always be listed before the associated
Label Object
2. Single SMD object followed by single Label Object: One-to-one
mapping between SMD and label.
3. Multiple SMD objects followed by a Label Object: Multiple SMDs
applied to same label.
4. Single SMD followed by multiple Label Objects: Multipath SMD
SMD
The Stream Member Descriptor specifies the stream for which
labels are to be released. If no label object follows, all
labels associated with the SMD are released, else only the
labels specified in the following label object are released.
Label
The label associated with the SMD which is to be released.
4.3.7. Query
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
"Loop Detection Via Diffusion" section 3.9).
4.3.7.1. Query Objects
Mandatory Objects At least one of each mandatory object with associ-
ated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
| Path Vector | 0x05 |
+-----------------------+----------+
Optional Objects
This version of the protocol defines no optional objects for the
Anderson, et al. [Page 40]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Query message.
Rules:
1. SMD object(s) MUST always be listed before the associated Path
Vector Object.
2. One-to-one mapping between SMD and Path Vector.
SMD The Stream Member Descriptor specifies the stream for which the
diffusion algorithm is being computed.
Path Vector
A list of the unique router-identifiers the LSRs traversed in
the creation of the LSP for the given SMD. This list is used in
the diffusion algorithm. An LSR that finds its own unique iden-
tifier in a Path Vector is in a loop. When no loop is present,
the LSR is responsible for appending its unique router-id to the
Path Vector, and including the vector in the Query message for-
warded to the next LSR.
4.3.8. Explicit Request
An explicitly routed LSP setup request is used to specify the
sequence of LSRs that an LSP will traverse and, optionally, to
reserve resources for the LSP at those LSRs.
4.3.8.1. Explicit Request Objects
Mandatory Objects At least one of each mandatory object with associ-
ated object headers.
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| ERLSPID | 0x09 |
+-----------------------+----------+
| SMD | 0x02 |
+-----------------------+----------+
| Label | 0x03 |
+-----------------------+----------+
| Explicit Route | 0x0A |
+-----------------------+----------+
Anderson, et al. [Page 41]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Optional Objects
Zero or more optional objects with associated object headers.
+-----------------------+----------+
| OPTIONAL OBJECT | Type |
+-----------------------+----------+
| Class of Service | 0x04 |
+-----------------------+----------+
ERLSPID
This object specifies a globally unique value chosen by the LSR
that originates the Explicit Request message that acts as an
identifier for the explicit request.
SMD
This object specifies the stream for which the explicitly routed
LSP is being setup; it must be set to one of the SMD values
listed in "Stream Member Description Object" section 4.4.4.2).
If the SMD field indicates 'Opaque tunnel' the means by which
the end point of the Explicit Request understands what traffic
is to arrive over the explicit route LSP is beyond the scope of
this specification. Configuration could be one mechanism.
Explicit Route
Explicit Route (ER) object that specifies the LSRs the explicit
route LSP is to traverse. See "Explicit Route Object" section
4.4.4.10.
Class of Service
The class of service to be assigned to the Label.
4.3.9. Explicit Response
An explicitly routed LSP setup response message is issued in response
to an Explicit Request message. It indicates the outcome of the setup
attempt.
4.3.9.1. Explicit Response Objects
Mandatory Objects
At least one of each mandatory object with associated object headers.
Anderson, et al. [Page 42]
Internet Draft draft-mpls-ldp-00 .txt March 1998
+-----------------------+----------+
| MANDATORY OBJECT | Type |
+-----------------------+----------+
| ERLSPID | 0x09 |
+-----------------------+----------+
| Status | 0x0D |
+-----------------------+----------+
Optional Objects
This version of the protocol defines no optional objects for the
Explicit
Response message.
ERLSPID
This object specifies the globally unique value used for ERLSPID
in the Explicit Request message that elicited this Response mes-
sage.
Status
This object indicates the success or otherwise of the Request
that contained the ERLSPID value contained in the ERLSPID object
in this Response message.
4.4. LDP Objects
4.4.1. Object Header
All objects in an LDP message must begin with the following object
header. Objects must be placed back-to-back within the message, and
must be padded to a 16-bit 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 follow-
ing. This version of the specification defines the following
objects for discovery class messages:
TARGETED_HELLO_OBJECT = 0x01
SEND_TARGETED_HELLO_OBJECT = 0x02
TRANSPORT_ADDRESS_OBJECT = 0x03
HELLO_HOLD_TIME_OBJECT = 0x04
Anderson, et al. [Page 43]
Internet Draft draft-mpls-ldp-00 .txt March 1998
This version of the specification defines the following
objects for adjacency class messages:
ERROR_OBJECT = 0x01
LSR_OBJECT = 0x02
LABELRANGE_OBJECT = 0x03
ADDRESS_LIST_OBJECT = 0x04
This version of the specification defines the following
objects for advertisement class messages:
ERROR_OBJECT = 0x01
SMD_OBJECT = 0x02
LABEL_OBJECT = 0x03
COS_OBJECT = 0x04
PATH_VECTOR_OBJECT = 0x05
HOPCOUNT_OBJECT = 0x06
MTU_OBJECT = 0x07
STACK_OBJECT = 0x08
ERLSPID_OBJECT = 0x09
ER_OBJECT = 0x0A
ERNH OBJECT = 0x0B
RES_OBJECT = 0x0C
STATUS_OBJECT = 0x0D
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, excluding the object header.
4.4.2. Discovery Class Objects
4.4.2.1. Targeted Hello
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Targeted Hello | 0x01 | 0x01 Default | 0 |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Default
Anderson, et al. [Page 44]
Internet Draft draft-mpls-ldp-00 .txt March 1998
No parameters
4.4.2.2. Send Targeted Hello
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Send Targeted Hello | 0x02 | 0x01 Default | 0 |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Default
No parameters
4.4.2.3. Transport Address
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Transport Address | 0x03 | 0x01 Default | variable |
+-------------------------------+--------------------------+----------+
Subtype = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Address Family
This 16 bit quantity contains a value from ADDRESS FAMILY NUM-
BERS in Assigned Numbers [rfc1700] that encodes the address
family that the network layer addresses in the Addresses field
are from.
Address
An address encoded according to the Address Family field,
padded to a 16-bit boundary.
Anderson, et al. [Page 45]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.4.2.4. Hello Hold Time
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Hello Hold Time | 0x04 | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
Subtype = 0x01 Default
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Timer
Two octet unsigned non zero integer that indicates the number of
seconds the sending LSR will maintain its record of Hellos from the
receiving LSR without receipt of another Hello.
4.4.3. Adjacency Class Objects
4.4.3.1. Error Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Error | 0x01 | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
This object contains an error code associated with an SMD.
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MsgType |E| Reserved | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MsgType
One-octet value indicating the Advertisement message type
Anderson, et al. [Page 46]
Internet Draft draft-mpls-ldp-00 .txt March 1998
being acknowledged. This value is determined from the MsgType
field of the received message which is being acknowledged.
E-bit (End-to-End Ack)
One-bit value indicating whether the error is to be forwarded
to the associated SMDs next hop, or next node in the case of
explicit paths. A value of 0 indicates DO NOT FORWARD; A
value of 1 indicates FORWARD.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Error
An error code. A value of 0 indicates no error. Error values
TBA.
4.4.3.2. LSR Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| LSR | 0x02 | 0x01 ATM | 4 |
+-------------------------------+--------------------------+----------+
The LSR object exchanges LSR characteristics with peers at
initialization.
SubType = 0x01 ATM
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeepAlive Timer |L| A | Merge |N| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KeepAlive Timer
Two octet unsigned non zero integer that indicates the number
of seconds that the peer initiating the connection proposes
for the value of the KeepAlive Interval. The receiving LSR
MUST MUST calculate the value of the KeepAlive Timer by using
the smaller of its configured KEEPALIVE_TIME and the
KEEPALIVE_TIME received in the PDU. The value chosen for
KEEPALIVE_TIME indicates the maximum number of seconds that
may elapse between the receipt of successive PDUs from the LSR
Anderson, et al. [Page 47]
Internet Draft draft-mpls-ldp-00 .txt March 1998
peer. The Keepalive Timer is reset each time a PDU arrives.
L-bit (Loop Detection Bit)
One bit value indicating if Loop Detection is enabled. A
value of 1 is enabled, 0 is disabled.
A-bits (Allocation Bits)
Two bit value indicating the type of Label allocation. A
value of 00 is downstream allocation, 01 is downstream-on-
demand.
Merge
Four bit value specifying the switch merge capabilities. The
following values are supported in this version of the specifi-
cation:
Non Merge = 0
VP Merge = 1
VC Merge = 2
VP & VC Merge = 3
NULL Encap Bit
One bit value set to non-zero when the LSR supports the null
encapsulation of [rfc1483] for its data VCs. In this case IP
packets are carried directly inside AAL5 frames.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
4.4.3.3. LabelRange Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Label Range | 0x03 | 0x01 ATM | 8 |
+-------------------------------+--------------------------+----------+
The LabelRange object contains the label range supported by the
transmitting LSR. A receiving LSR MUST calculate the intersection
between the received range and its own supported label range. The
intersection is the range in which the LSR may allocate and accept
labels. LSRs may NOT establish an adjacency with neighbors whose
intersection range is NULL.
SubType = 0x01 ATM
0 1 2 3
Anderson, et al. [Page 48]
Internet Draft draft-mpls-ldp-00 .txt March 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Minimum VPI (12 bits)
This 12 bit field specifies the lower bound of a block of Vir-
tual Path Identifiers that is supported on the originating
switch. If the VPI is less than 12-bits it should be right
justified in this field and preceding bits should be set to 0.
Minimum VCI (16 bits)
This 16 bit field specifies the lower bound of a block of Vir-
tual Connection Identifiers that is supported on the originat-
ing switch. If the VCI is less than 16-bits it should be
right justified in this field and preceding bits should be set
to 0.
Maximum VPI (12 bits)
This 12 bit field specifies the upper bound of a block of Vir-
tual Path Identifiers that is supported on the originating
switch. If the VPI is less than 12-bits it should be right
justified in this field and preceding bits should be set to 0.
Maximum VCI (16 bits)
This 16 bit field specifies the upper bound of a block of Vir-
tual Connection Identifiers that is supported on the originat-
ing switch. If the VCI is less than 16-bits it should be
right justified in this field and preceding bits should be set
to 0.
4.4.3.4. Address List Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Address List | 0x04 | 0x01 Default | variable |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Default
Anderson, et al. [Page 49]
Internet Draft draft-mpls-ldp-00 .txt March 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address List Family | Addresses (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Address Family
This 16 bit quantity contains a value from ADDRESS FAMILY NUM-
BERS in Assigned Numbers [ref] that encodes the address family
that the network layer addresses in the Addresses field are
from.
Addresses
One or more addresses encoded according to the Address Family
Field, padded to a 16-bit boundary.
4.4.4. Advertisement Class Objects
4.4.4.1. Error Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Error | 0x01 | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
This object contains an error code associated with an SMD.
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MsgType |E| Reserved | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MsgType
One-octet value indicating the Advertisement message type
being acknowledged. This value is determined from the MsgType
field of the received message which is being acknowledged.
E-bit (End-to-End Ack)
Anderson, et al. [Page 50]
Internet Draft draft-mpls-ldp-00 .txt March 1998
One-bit value indicating whether the error is to be forwarded
to the associated SMDs next hop, or next node in the case of
explicit paths. A value of 0 indicates DO NOT FORWARD; A
value of 1 indicates FORWARD.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Error
An error code. A value of 0 indicates no error. Error values
TBA.
4.4.4.2. Stream Member Descriptor (SMD) Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| SMD | 0x02 | 0x01 Wildcard | 4 |
+-------------------------------+--------------------------+----------+
| | 0x02 Network Address | variable |
+-------------------------------+--------------------------+----------+
| | 0x03 BGP Next Hop | 4 |
+-------------------------------+--------------------------+----------+
| | 0x04 OSPF Router ID | 4 |
+-------------------------------+--------------------------+----------+
| | 0x05 OSPF ABR | variable |
+-------------------------------+--------------------------+----------+
| | 0x06 Aggregation List | variable |
+-------------------------------+--------------------------+----------+
| | 0x07 Opaque Tunnel | TBA |
+-------------------------------+--------------------------+----------+
| | 0x08 Flow | 16 |
+-------------------------------+--------------------------+----------+
This object specifies the streams for which LSPs are created.
SubType = 0x01 Wild Card
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Place Holder |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anderson, et al. [Page 51]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Place Holder
Four octet integer set to all 0s. This field is used in asso-
ciation with a Label Object, to indicate ALL SMDs associated
with the given label are to be processed.
SubType = 0x02 Network Address
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Len | Address . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . (length variable )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Address Family
This 16 bit quantity contains a value from ADDRESS FAMILY NUM-
BERS in Assigned Numbers [ref] that encodes the address family
that the network layer addresses in the Addresses field are
from.
Address Len
One octet unsigned integer containing the length in bits of
the address that follows.
Address
An address encoded according to the Address Family field,
whose length, in bits, was specified in the Address Len field,
padded to a 16-bit boundary.
SubType = 0x03 BGP Next Hop
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Next Hop IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BGP Next Hop
Four octet IPv4 address of the BGP Next Hop router.
SubType = 0x04 OSPF Router Id
0 1 2 3
Anderson, et al. [Page 52]
Internet Draft draft-mpls-ldp-00 .txt March 1998
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF Router ID
Four octet router identifier of an OSPF node.
SubType = 0x05 OSPF Area Border Router
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Border Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Len | Prefix (length variable )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
OSPF Area Border Router ID
Four octet router identifier of the OSPF ABR node.
Prefix Len
One octet unsigned integer containing the length in bits of
the address prefix that follows.
Prefix
A variable length field containing an address prefix whose
length, in bits, was specified in the previous (Prefix Len)
field. A Prefix must be padded with sufficient trailing zero
bits to cause the end of the field to fall on a 16-bit bound-
ary.
SubType = 0x06 Aggregation list
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregate Router-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Prefix Len | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Aggregate Router-Id
Anderson, et al. [Page 53]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Four octet unique identifier on an LSR which is initiating the
aggregation.
Prefix Count
Two octet number of address prefixes in this object, which
comprise the set of prefixes that are to be aggregated
together.
Prefix Len
One octet unsigned integer containing the length in bits of
the address prefix that follows.
Prefix
A variable length field containing an address prefix whose
length, in bits, was specified in the previous (Prefix Len)
field. The last prefix in the list must be padded with suffi-
cient trailing zero bits to cause the end of the field to fall
on a 16-bit boundary.
SubType = 0x07 Opaque Tunnel
TBA.
SubType = 0x08 Flow
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Dest Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Direction | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Source Address
Four octet source Network address.
Network Destination Address
Four octet destination Network address.
Source Port
Two octet source port.
Destination Port
Anderson, et al. [Page 54]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Two octet destination port.
Protocol
Protocol type.
Direction
One octet indicating the direction of the LSP. Field is set
to 1 on Downstream; field is set to 2 on Upstream.
4.4.4.3. Label Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Label | 0x03 | 0x01 ATM | 4 |
+-------------------------------+--------------------------+----------+
| | 0x02 Shim | TBA |
+-------------------------------+--------------------------+----------+
This object specifies a link-layer label associated with an SMD.
SubType = 0x01 ATM
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
V-bits
Two-bit switching indicator. If V-bits is 00, both the VPI
and VCI are significant. If V-bits is 01, only the VPI field
is significant. If V-bit is 10, only the VCI is significant.
VPI (12 bits)
Virtual Path Identifier. If VPI is less than 12-bits it should
be right justified in this field and preceding bits should be
set to 0.
VCI (16 bits)
Virtual Connection Identifier. If the VCI is less than
16-bits, it should be right justified in the field and the
Anderson, et al. [Page 55]
Internet Draft draft-mpls-ldp-00 .txt March 1998
preceding bits must be set to 0. If Virtual Path switching is
indicated in the V-bits field, then this field must be ignored
by the receiver and set to 0 by the sender.
SubType = 0x02 Shim
TBA.
4.4.4.4. Class-of-Service (COS) Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Class of Service | 0x04 | 0x01 Default | TBA |
+-------------------------------+--------------------------+----------+
This object specifies a class of service that is to be associated
with a label.
SubType = 0x01 Default
TBA.
4.4.4.5. Path Vector Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Label | 0x05 | 0x01 Default | variable |
+-------------------------------+--------------------------+----------+
This object contains the LSR path the advertisement has traversed. Any
LSR that finds its own unique LSR Id in the received LSR Path Vector is
determined to be in a loop.
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anderson, et al. [Page 56]
Internet Draft draft-mpls-ldp-00 .txt March 1998
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Id 1 to n-1
A series of router-identifiers indicating the path that the
mapping message has traversed. Each router-id must be unique
within the LSR network.
Router Id n
Router-id of the router that sent the current message, where
the router-id is the value of the first four-octets of the LDP
Identifier. Each LSR receiving this object MUST append its
own unique LSR Id to the object before forwarding the object.
4.4.4.6. Hop Count Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Hop Count | 0x06 | 0x01 Default | 2 |
+-------------------------------+--------------------------+----------+
This object calculates the number of LSR hops along an LSP.
SubType = 0x01 Default
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Count
The number of LSR hops along the LSP. It is incremented by
one at each LSR forwarding the object.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Anderson, et al. [Page 57]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.4.4.7. MTU Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| MTU | 0x07 | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
This object identifies the MTU along an LSP. An LSR initiating data
along the LSP path may not transmit data larger than the given MTU.
It is scoped within a single routing domain.
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTU
The maximum transmission unit for a given LSP. Any LSR
receiving the MTU object must compare the given value with its
own MTU on the receiving link. The minimum of these values is
the MTU to be associated with the LSP and forwarded in the
object.
Anderson, et al. [Page 58]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.4.4.8. Stack Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| Stack | 0x08 | 0x01 ATM | variable |
+-------------------------------+--------------------------+----------+
This object contains a stacked label and a list of prefixes which are
to use the stacked label. This enables a deaggregating LSR to avoid
L3 forwarding, by removing an incoming L2 header with the label given
in a LABEL_OBJECT, and then continuing switching on the given stack
label.
SubType = 0x01 ATM
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Prefix Len | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................
Res
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
V-bits
Two-bit switching indicator. If V-bits is 00, both the VPI
and VCI are significant. If V-bits is 01, only the VPI field
is significant. If V-bit is 10, only the VCI is significant.
VPI (12 bits)
Virtual Path Identifier. If VPI is less than 12-bits it should
be right justified in this field and preceding bits should be
set to 0.
VCI (16 bits)
Virtual Connection Identifier. If the VCI is less than
16-bits, it should be right justified in the field and the
preceding bits must be set to 0. If Virtual Path switching is
indicated in the V-bits field, then this field must be ignored
by the receiver and set to 0 by the sender.
Anderson, et al. [Page 59]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Prefix Count
Two octet number of address prefixes in this object, which
comprise the set of prefixes that are use the given label.
Prefix Len
One octet unsigned integer containing the length in bits of
the address prefix that follows.
Prefix
A variable length field containing an address prefix whose
length, in bits, was specified in the previous (Prefix Len)
field. The last prefix in the list must be padded with suffi-
cient trailing zero bits to cause the end of the field to fall
on a 16-bit boundary.
4.4.4.9. ERLSPID Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| ERLSPID | 0x09 | 0x01 Default | 8 |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Explicit Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Explicit Identifier
A 6-octet globally unique value that identifies the explicit
route LSP. It is generated by the LSR that creates the
Explicit Request message. The first four octets is the LSR IP
Address. The last two octets contain a `Local identifier'
value. It is incumbent on an LSR that originates an Explicit
Request message to choose an unused value for the Local Iden-
tifier.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
Anderson, et al. [Page 60]
Internet Draft draft-mpls-ldp-00 .txt March 1998
4.4.4.10. Explicit Route (ER) Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| ER | 0x0A | 0x01 Default | Variable |
+-------------------------------+--------------------------+----------+
This object contains a sequence of ER Next Hop (ERNH) objects
and a pointer to the one that should be processed by the LSR
that receives this ER Object.
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next ERNH Obj Pointer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERNH Objects (Variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next ERNH Obj Pointer
This 16 bit unsigned integer points to the offset in octets of
the next ERNH object to be processed. The first octet after
the two reserved octets that follow this pointer is defined to
have an offset value of zero. For example an ERNH Obj Pointer
value of zero would point to the first ERNH Object in the
sequence of ERNH Objects.
Reserved
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
ERNH
See "ERNH Object" section 4.4.4.11
4.4.4.11. ERNH Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| ERNH | 0x0B | 0x01 Strict | Variable |
+-------------------------------+--------------------------+----------+
| | 0x02 Loose | Variable |
+-------------------------------+--------------------------+----------+
This object contains the four octet IP address of an LSR
Anderson, et al. [Page 61]
Internet Draft draft-mpls-ldp-00 .txt March 1998
through which the Explicit Route LSP is to pass and an
(optional) reservation (RES) object to be processed by that
LSR.
The strict subtype indicates that the ER LSP setup must be
routed directly via the LSR indicated in the ERNH object; i.e.
that that LSR must be the next hop in the Explicit Route LSP's
path. The loose subtype indicates that the LSP may be routed
in any way; i.e. via other unspecified LSRs, so long as it
(eventually) reaches the LSR specified in the ERNH object.
This object may be followed by the optional Reservation
Object.
SubType = 0x01 Strict
0x02 Loose
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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ipv4 Address
The IP address of the next LSR in the Explicit Route LSP.
4.4.4.12. Reservation (RES) Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| RES | 0x0C | 0x01 Raw Bandwidth | Variable |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Raw Bandwidth
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BW requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BW Requirement
Unsigned 32 bit integer representing the bandwidth, in units
of 64,000 bps, that must be reserved for the LSP at the LSR
Anderson, et al. [Page 62]
Internet Draft draft-mpls-ldp-00 .txt March 1998
identified in the ERNH Object that contains this Reservation
Object.
4.4.4.13. Status Object
+-----------------------+-------+--------------------------+----------+
| OBJECT | Type | Subtype(s) | Length |
+-----------------------+-------+--------------------------+----------+
| STATUS | 0x0D | 0x01 Default | 4 |
+-------------------------------+--------------------------+----------+
SubType = 0x01 Default
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Success Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Success Code
The success code is a single 32 bit unsigned integer. The
value 0 indicates success, 1 indicates failure; all others are
currently reserved.
5. Security
Security considerations will be addressed in a future revision of
this document.
6. Acknowledgments
The ideas and text in this document have been collected from a number
of sources. We would like to thank Rick Boivie, Ross Callon, Eric
Rosen, Yakov Rekhter, and Arun Viswanathan.
Anderson, et al. [Page 63]
Internet Draft draft-mpls-ldp-00 .txt March 1998
7. References
[FRAMEWORK] Callon et al, "A Framework for Multiprotocol Label
Switching" draft-ietf-mpls-framework-01 .txt, July 1997
[ARCH] Rosen et al, "A Proposed Architecture for MPLS" draft-ietf-
mpls-arch-00.txt, August 1997
[rfc1700] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700 , ISI,
October 1994
[rfc1583] J. Moy, "OSPF Version 2", RFC 1583 , Proteon Inc, March 1994
[rfc1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771 , IBM Corp, Cisco Systems, March 1995
[rfc1483] J. Heinanen, "Multiprotocol Encapsulation over ATM Adapta-
tion Layer 5", RFC 1483 , Telecom Finland, July 1993
8. Author Information
Loa Andersson
Ericsson
Phone: + 46 8 719 52 67
email: loa.andersson@etx.ericsson.se
Paul Doolan
Ennovate Networks
330 Codman Hill Rd
Marlborough MA 01719
Phone: 978-263-2002
email: pdoolan@ennovate.com
Nancy Feldman
IBM Corp.
17 Skyline Drive
Hawthorne NY 10532
Phone: 914-784-3254
email: nkf@us.ibm.com
Andre Fredette
Bay Networks Inc
3 Federal Street
Billerica, MA 01821
Phone: 508-916-8524
email: fredette@baynetworks.com
Anderson, et al. [Page 64]
Internet Draft draft-mpls-ldp-00 .txt March 1998
Bob Thomas
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
email: rhhomas@cisco.com
Anderson, et al. [Page 65]