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