2.6. Label Distribution and ManagementThe MPLS architecture [RFC3031] allows an LSR to distribute a FEC label binding in response to an explicit request from another LSR. This is known as Downstream On Demand label distribution. It also allows an LSR to distribute label bindings to LSRs that have not explicitly requested them. [RFC3031] calls this method of label distribution Unsolicited Downstream; this document uses the term Downstream Unsolicited. Both of these label distribution techniques may be used in the same network at the same time. However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. See Section "Downstream on Demand Label Advertisement".
2.6.1. Label Distribution Control ModeThe 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.
188.8.131.52. Independent Label Distribution ControlWhen using independent LSP control, each LSR 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 for label mappings immediately, without waiting for a label mapping from the next hop. When operating in independent Downstream Unsolicited mode, an LSR may advertise a label mapping for a FEC to its neighbors whenever it is prepared to label-switch that FEC. A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.
184.108.40.206. Ordered Label Distribution ControlWhen using LSP Ordered Control, an LSR may initiate the transmission of a label mapping only for a FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. For each FEC for which the LSR is not the egress and no mapping exists, the LSR MUST wait until a label from a downstream LSR is received before mapping the FEC and passing corresponding labels to upstream LSRs. An LSR may be an egress for some FECs and a non-egress for others. An LSR may act as an egress LSR, with respect to a particular FEC, under any of the following conditions:
1. The FEC refers to the LSR itself (including one of its directly attached interfaces). 2. The next hop router for the FEC is outside of the Label Switching Network. 3. FEC elements are reachable by crossing a routing domain boundary, such as another area for OSPF summary networks, or another autonomous system for OSPF AS externals and BGP routes [RFC2328] [RFC4271]. Note that whether an LSR is an egress for a given FEC may change over time, depending on the state of the network and LSR configuration settings.
2.6.2. Label Retention ModeThe MPLS architecture [RFC3031] introduces the notion of label retention mode which specifies whether an LSR maintains a label binding for a FEC learned from a neighbor that is not its next hop for the FEC.
220.127.116.11. Conservative Label Retention ModeIn Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all peer LSRs. When using Conservative Label retention, advertised label mappings are retained only 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, an LSR will request label mappings only from the 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 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 disadvantage 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.
18.104.22.168. Liberal Label Retention ModeIn Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using Liberal Label retention, every label mappings received
from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping. When operating in Downstream on Demand mode with Liberal Label retention, an LSR might choose to request label mappings for all known prefixes from all peer LSRs. Note, however, that Downstream on Demand mode is typically used by devices such as ATM switch-based LSRs for which the conservative approach is recommended. The main advantage of the Liberal Label retention mode is that reaction to routing changes can be quick because labels already exist. The main disadvantage of the liberal mode is that unneeded label mappings are distributed and maintained.
2.6.3. Label Advertisement ModeEach interface on an LSR is configured to operate in either Downstream Unsolicited or Downstream on Demand advertisement mode. LSRs exchange advertisement modes during initialization. The major difference between Downstream Unsolicited and Downstream on Demand modes is in which LSR takes responsibility for initiating mapping requests and mapping advertisements.
2.7. LDP Identifiers and Next Hop AddressesAn LSR maintains learned labels in a Label Information Base (LIB). When operating in Downstream Unsolicited mode, 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 forwarding. 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 Identifier to the peer's addresses to check whether any are a next hop for the prefix. To enable LSRs to map between a peer LDP Identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw 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 advertised addresses from a peer.
2.8. Loop DetectionLoop Detection is a configurable option that provides a mechanism for finding looping LSPs and for preventing Label Request messages from looping in the presence of non-merge capable LSRs. The mechanism makes use of Path Vector and Hop Count TLVs carried by Label Request and Label Mapping messages. It builds on the following basic properties of these TLVs: - A Path Vector TLV contains a list of the LSRs that its containing message has traversed. An LSR is identified in a Path Vector list by its unique LSR Identifier (Id), which is the first four octets of its LDP Identifier. When an LSR propagates a message containing a Path Vector TLV, it adds its LSR Id to the Path Vector list. An LSR that receives a message with a Path Vector that contains its LSR Id detects that the message has traversed a loop. LDP supports the notion of a maximum allowable Path Vector length; an LSR that detects a Path Vector has reached the maximum length behaves as if the containing message has traversed a loop. - A Hop Count TLV contains a count of the LSRS that the containing message has traversed. When an LSR propagates a message containing a Hop Count TLV, it increments the count. An LSR that detects a Hop Count has reached a configured maximum value behaves as if the containing message has traversed a loop. By convention, a count of 0 is interpreted to mean the hop count is unknown. Incrementing an unknown hop count value results in an unknown hop count value (0). The following paragraphs describe LDP Loop Detection procedures. For these paragraphs, and only these paragraphs, "MUST" is redefined to mean "MUST if configured for Loop Detection". The paragraphs specify messages that MUST carry Path Vector and Hop Count TLVs. Note that the Hop Count TLV and its procedures are used without the Path Vector TLV in situations when Loop Detection is not configured (see [RFC3035] and [RFC3034]).
2.8.1. Label Request MessageThe use of the Path Vector TLV and Hop Count TLV prevent Label Request messages from looping in environments that include non-merge capable LSRs.
The rules that govern use of the Hop Count TLV in Label Request messages by LSR R when Loop Detection is enabled are the following: - The Label Request message MUST include a Hop Count TLV. - If R is sending the Label Request because it is a FEC ingress, it MUST include a Hop Count TLV with hop count value 1. - If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, and if the received Label Request contains a Hop Count TLV, R MUST increment the received hop count value by 1 and MUST pass the resulting value in a Hop Count TLV to its next hop along with the Label Request message. The rules that govern use of the Path Vector TLV in Label Request messages by LSR R when Loop Detection is enabled are the following: - If R is sending the Label Request because it is a FEC ingress, then if R is non-merge capable, it MUST include a Path Vector TLV of length 1 containing its own LSR Id. - If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, then if the received Label Request contains a Path Vector TLV or if R is non-merge capable: R MUST add its own LSR Id to the Path Vector, and MUST pass the resulting Path Vector to its next hop along with the Label Request message. If the Label Request contains no Path Vector TLV, R MUST include a Path Vector TLV of length 1 containing its own LSR Id. Note that if R receives a Label Request message for a particular FEC, and R has previously sent a Label Request message for that FEC to its next hop and has not yet received a reply, and if R intends to merge the newly received Label Request with the existing outstanding Label Request, then R does not propagate the Label Request to the next hop. If R receives a Label Request message from its next hop with a Hop Count TLV that exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or which exceeds the maximum allowable length, then R detects that the Label Request message has traveled in a loop. When R detects a loop, it MUST send a Loop Detected Notification message to the source of the Label Request message and drop the Label Request message.
2.8.2. Label Mapping MessageThe use of the Path Vector TLV and Hop Count TLV in the Label Mapping message provide a mechanism to find and terminate looping LSPs. When an LSR receives a Label Mapping message from a next hop, the message is propagated upstream as specified below until an ingress LSR is reached or a loop is found. The rules that govern the use of the Hop Count TLV in Label Mapping messages sent by an LSR R when Loop Detection is enabled are the following: - R MUST include a Hop Count TLV. - If R is the egress, the hop count value MUST be 1. - If the Label Mapping message is being sent to propagate a Label Mapping message received from the next hop to an upstream peer, the hop count value MUST be determined as follows: o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame Relay LSR domain) and the upstream peer is within that domain, R MUST reset the hop count to 1 before propagating the message. o Otherwise, R MUST increment the hop count received from the next hop before propagating the message. - If the Label Mapping message is not being sent to propagate a Label Mapping message, the hop count value MUST be the result of incrementing R's current knowledge of the hop count learned from previous Label Mapping messages. Note that this hop count value will be unknown if R has not received a Label Mapping message from the next hop. Any Label Mapping message MAY contain a Path Vector TLV. The rules that govern the mandatory use of the Path Vector TLV in Label Mapping messages sent by LSR R when Loop Detection is enabled are the following: - If R is the egress, the Label Mapping message need not include a Path Vector TLV. - If R is sending the Label Mapping message to propagate a Label Mapping message received from the next hop to an upstream peer, then:
o If R is merge capable and if R has not previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV. o If the received message contains an unknown hop count, then R MUST include a Path Vector TLV. o If R has previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV if the received message reports an LSP hop count increase, a change in hop count from unknown to known, or a change from known to unknown. If the above rules require R include a Path Vector TLV in the Label Mapping message, R computes it as follows: o If the received Label Mapping message included a Path Vector, the Path Vector sent upstream MUST be the result of adding R's LSR Id to the received Path Vector. o If the received message had no Path Vector, the Path Vector sent upstream MUST be a Path Vector of length 1 containing R's LSR Id. - If the Label Mapping message is not being sent to propagate a received message upstream, the Label Mapping message MUST include a Path Vector of length 1 containing R's LSR Id. If R receives a Label Mapping message from its next hop with a Hop Count TLV that exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or that exceeds the maximum allowable length, then R detects that the corresponding LSP contains a loop. When R detects a loop, it MUST stop using the label for forwarding, drop the Label Mapping message, and signal Loop Detected status to the source of the Label Mapping message.
2.8.3. DiscussionIf Loop Detection is desired in an MPLS domain, then it should be turned on in ALL LSRs within that MPLS domain, else Loop Detection will not operate properly and may result in undetected loops or in falsely detected loops. LSRs that are configured for Loop Detection are NOT expected to store the Path Vectors as part of the LSP state.
Note that in a network where only non-merge capable LSRs are present, Path Vectors are passed downstream from ingress to egress, and are not passed upstream. Even when merge is supported, Path Vectors need not be passed upstream along an LSP that is known to reach the egress. When an LSR experiences a change of next hop, it need pass Path Vectors upstream only when it cannot tell from the hop count that the change of next hop does not result in a loop. In the case of ordered label distribution, Label Mapping messages are propagated from egress toward ingress, naturally creating the Path Vector along the way. In the case of independent label distribution, an LSR may originate a Label Mapping message for a FEC before receiving a Label Mapping message from its downstream peer for that FEC. In this case, the subsequent Label Mapping message for the FEC received from the downstream peer is treated as an update to LSP attributes, and the Label Mapping message must be propagated upstream. Thus, it is recommended that Loop Detection be configured in conjunction with ordered label distribution, to minimize the number of Label Mapping update messages.
2.9. Authenticity and Integrity of LDP MessagesThis section specifies a mechanism to protect against the introduction of spoofed TCP segments into LDP session connection streams. The use of this mechanism MUST be supported as a configurable option. The mechanism is based on use of the TCP MD5 Signature Option specified in [RFC2385] for use by BGP [RFC4271]. See [RFC1321] for a specification of the MD5 hash function. From a standards maturity point of view, the current document relates to [RFC2385] the same way as [RFC4271] relates to [RFC2385]. This is explained in [RFC4278].
2.9.1. TCP MD5 Signature OptionThe following quotes from [RFC2385] outline the security properties achieved by using the TCP MD5 Signature Option and summarize its operation: "IESG Note This document describes current existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks."
"Abstract This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP." "Introduction The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets. To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords). Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option." "MD5 as a Hashing Algorithm Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application. This memo still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original document did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space.
This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field. This would need to be addressed in another document, however." End of quotes from [RFC2385].
2.9.2. LDP Use of TCP MD5 Signature OptionLDP uses the TCP MD5 Signature Option as follows: - Use of the MD5 Signature Option for LDP TCP connections is a configurable LSR option. - An LSR that uses the MD5 Signature Option is configured with a password (shared secret) for each potential LDP peer. - The LSR applies the MD5 algorithm as specified in [RFC2385] to compute the MD5 digest for a TCP segment to be sent to a peer. This computation makes use of the peer password as well as the TCP segment. - When the LSR receives a TCP segment with an MD5 digest, it validates the segment by calculating the MD5 digest (using its own record of the password) and compares the computed digest with the received digest. If the comparison fails, the segment is dropped without any response to the sender. - The LSR ignores LDP Hellos from any LSR for which a password has not been configured. This ensures that the LSR establishes LDP TCP connections only with LSRs for which a password has been configured.
2.10. Label Distribution for Explicitly Routed LSPsTraffic Engineering [RFC2702] is expected to be an important MPLS application. MPLS support for Traffic Engineering uses explicitly routed LSPs, which need not follow normally-routed (hop-by-hop) paths as determined by destination-based routing protocols. CR-LDP [CRLDP] defines extensions to LDP to use LDP to set up explicitly routed LSPs.
3. Protocol SpecificationPrevious sections that describe LDP operation have discussed scenarios that involve the exchange of messages among LDP peers. This section specifies the message encodings and procedures for processing the messages. LDP message exchanges are accomplished by sending LDP protocol data units (PDUs) over LDP session TCP connections. Each LDP PDU can carry one or more LDP messages. Note that the messages in an LDP PDU need not be related to one another. For example, a single PDU could carry a message advertising FEC-label bindings for several FECs, another message requesting label bindings for several other FECs, and a third Notification message signaling some event.
3.1. LDP PDUsEach LDP PDU is an LDP header followed by one or more LDP messages. The LDP header is: 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 | PDU Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LDP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1. PDU Length Two octet integer specifying the total length of this PDU in octets, excluding the Version and PDU Length fields. The maximum allowable PDU Length is negotiable when an LDP session is initialized. Prior to completion of the negotiation, the maximum allowable length is 4096 bytes.
LDP Identifier Six octet field that uniquely identifies the label space of the sending LSR for which this PDU applies. The first four octets identify the LSR and MUST be a globally unique value. It SHOULD be a 32-bit router Id assigned to the LSR and also used to identify it in Loop Detection Path Vectors. The last two octets identify a label space within the LSR. For a platform-wide label space, these SHOULD both be zero. Note that there is no alignment requirement for the first octet of an LDP PDU.
3.2. LDP ProceduresLDP defines messages, TLVs, and procedures in the following areas: - Peer discovery - Session management - Label distribution - Notification of errors and advisory information The sections that follow describe the message and TLV encodings for these areas and the procedures that apply to them. The label distribution procedures are complex and are difficult to describe fully, coherently, and unambiguously as a collection of separate message and TLV specifications. Appendix A, "LDP Label Distribution Procedures", describes the label distribution procedures in terms of label distribution events that may occur at an LSR and how the LSR must respond. Appendix A is the specification of LDP label distribution procedures. If a procedure described elsewhere in this document conflicts with Appendix A, Appendix A specifies LDP behavior.
3.3. Type-Length-Value EncodingLDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages. An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length field, followed by a variable length Value field.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification MUST be returned to the message originator and the entire message MUST be ignored; if U is set (=1), the unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. The sections following that define TLVs specify a value for the U-bit. F-bit Forward unknown TLV bit. This bit applies only when the U-bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message. The sections following that define TLVs specify a value for the F-bit. By setting both the U- and F-bits, a TLV can be propagated as opaque data through nodes that do not recognize the TLV. Type Encodes how the Value field is to be interpreted. Length Specifies the length of the Value field in octets. Value Octet string of Length octets that encodes information to be interpreted as specified by the Type field. Note that there is no alignment requirement for the first octet of a TLV. Note that the Value field itself may contain TLV encodings. That is, TLVs may be nested.
The TLV encoding scheme is very general. In principle, everything appearing in an LDP PDU could be encoded as a TLV. This specification does not use the TLV scheme to its full generality. It is not used where its generality is unnecessary and its use would waste space unnecessarily. These are usually places where the type of a value to be encoded is known, for example by its position in a message or an enclosing TLV, and the length of the value is fixed or readily derivable from the value encoding itself. Some of the TLVs defined for LDP are similar to one another. For example, there is a Generic Label TLV, an ATM Label TLV, and a Frame Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and "Frame Relay TLV". While it is possible to think about TLVs related in this way in terms of a TLV type that specifies a TLV class and a TLV subtype that specifies a particular kind of TLV within that class, this specification does not formalize the notion of a TLV subtype. The specification assigns type values for related TLVs, such as the label TLVs, from a contiguous block in the 16-bit TLV type number space. Section "TLV Summary" lists the TLVs defined in this version of the protocol and the section in this document that describes each.
3.4. TLV Encodings for Commonly Used ParametersThere are several parameters used by more than one LDP message. The TLV encodings for these commonly used parameters are specified in this section.
3.4.1. FEC TLVLabels are bound to Forwarding Equivalence Classes (FECs). A FEC is a list of one or more FEC elements. The FEC TLV encodes FEC items.
Its encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| FEC (0x0100) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FEC Element 1 to FEC Element n There are several types of FEC elements; see Section "FECs". The FEC element encoding depends on the type of FEC element. A FEC Element value is encoded as a 1 octet field that specifies the element type, and a variable length field that is the type- dependent element value. Note that while the representation of the FEC element value is type-dependent, the FEC element encoding itself is one where standard LDP TLV encoding is not used. The FEC Element value encoding is: FEC Element Type Value type name Wildcard 0x01 No value; i.e., 0 value octets; see below. Prefix 0x02 See below. Note that this version of LDP supports the use of multiple FEC Elements per FEC for the Label Mapping message only. The use of multiple FEC Elements in other messages is not permitted in this version, and is a subject for future study. Wildcard FEC Element To be used only in the Label Withdraw and Label Release messages. Indicates the withdraw/release is to be applied to all FECs associated with the label within the following label TLV. Must be the only FEC Element in the FEC TLV.
Prefix FEC Element value encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (2) | Address Family | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] that encodes the address family for the address prefix in the Prefix field. PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a prefix that matches all addresses (the default destination); in this case, the Prefix itself is zero octets). Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary.
22.214.171.124. FEC ProceduresIf in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
3.4.2. Label TLVsLabel TLVs encode labels. Label TLVs are carried by the messages used to advertise, request, release, and withdraw label mappings. There are several different kinds of Label TLVs that can appear in situations that require a Label TLV.
126.96.36.199. Generic Label TLVAn LSR uses Generic Label TLVs to encode labels for use on links for which label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label This is a 20-bit label value represented as a 20-bit number in a 4 octet field as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For further information, see [RFC3032].
188.8.131.52. ATM Label TLVAn LSR uses ATM Label TLVs to encode labels for use on ATM links. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| ATM Label (0x0201) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 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 Virtual Channel 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.
184.108.40.206. Frame Relay Label TLVAn LSR uses Frame Relay Label TLVs to encode labels for use on Frame Relay links. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Frame Relay Label (0x0202)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Len| DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Len This field specifies the number of bits of the DLCI. The following values are supported: 0 = 10 bits of DLCI 2 = 23 bits of DLCI Len values 1 and 3 are reserved. DLCI The Data Link Connection Identifier
For a 10-bit DLCI, the encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Frame Relay Label (0x0202)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Len| 0 | 10-bit DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a 23-bit DLCI, the encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Frame Relay Label (0x0202)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Len| 23-bit DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For further information, see [RFC3034].
3.4.3. Address List TLVThe Address List TLV appears in Address and Address Withdraw messages. Its encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Address List (0x0101) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Addresses | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] that encodes the addresses contained in the Addresses field.
Addresses A list of addresses from the specified Address Family. The encoding of the individual addresses depends on the Address Family. The following address encodings are defined by this version of the protocol: Address Family Address Encoding IPv4 4 octet full IPv4 address IPv6 16 octet full IPv6 address
3.4.4. Hop Count TLVThe Hop Count TLV appears as an optional field in messages that set up LSPs. It calculates the number of LSR hops along an LSP as the LSP is being set up. Note that setup procedures for LSPs that traverse ATM and Frame Relay links require use of the Hop Count TLV (see [RFC3035] and [RFC3034]). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Hop Count (0x0103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC Value | +-+-+-+-+-+-+-+-+ HC Value 1 octet unsigned integer hop count value.
220.127.116.11. Hop Count ProceduresDuring setup of an LSP, an LSR R may receive a Label Mapping or Label Request message for the LSP that contains the Hop Count TLV. If it does, it SHOULD record the hop count value. If LSR R then propagates the Label Mapping message for the LSP to an upstream peer or the Label Request message to a downstream peer to continue the LSP setup, it must determine a hop count to include in the propagated message as follows: - If the message is a Label Request message, R MUST increment the received hop count;
- If the message is a Label Mapping message, R determines the hop count as follows: o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' and the upstream peer is within that domain, R MUST reset the hop count to 1 before propagating the message. o Otherwise, R MUST increment the received hop count. The first LSR in the LSP (ingress for a Label Request message, egress for a Label Mapping message) SHOULD set the hop count value to 1. By convention, a value of 0 indicates an unknown hop count. The result of incrementing an unknown hop count is itself an unknown hop count (0). Use of the unknown hop count value greatly reduces the signaling overhead when independent control is used. When a new LSP is established, each LSR starts with an unknown hop count. Addition of a new LSR whose hop count is also unknown does not cause a hop count update to be propagated upstream since the hop count remains unknown. When the egress is finally added to the LSP, then the LSRs propagate hop count updates upstream via Label Mapping messages. Without use of the unknown hop count, each time a new LSR is added to the LSP a hop count update would need to be propagated upstream if the new LSR is closer to the egress than any of the other LSRs. These updates are useless overhead since they don't reflect the hop count to the egress. From the perspective of the ingress node, the fact that the hop count is unknown implies nothing about whether a packet sent on the LSP will actually make it to the egress. All it implies is that the hop count update from the egress has not yet reached the ingress. If an LSR receives a message containing a Hop Count TLV, it MUST check the hop count value to determine whether the hop count has exceeded its configured maximum allowable value. If so, it MUST behave as if the containing message has traversed a loop by sending a Notification message signaling Loop Detected in reply to the sender of the message. If Loop Detection is configured, the LSR MUST follow the procedures specified in Section "Loop Detection".
3.4.5. Path Vector TLVThe Path Vector TLV is used with the Hop Count TLV in Label Request and Label Mapping messages to implement the optional LDP Loop Detection mechanism. See Section "Loop Detection". Its use in the Label Request message records the path of LSRs the request has traversed. Its use in the Label Mapping message records the path of LSRs a label advertisement has traversed to set up an LSP. Its encoding is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Path Vector (0x0104) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR Id 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR Id n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One or more LSR Ids A list of router-ids indicating the path of LSRs the message has traversed. Each LSR Id is the first four octets (router-id) of the LDP Identifier for the corresponding LSR. This ensures it is unique within the LSR network.
18.104.22.168. Path Vector ProceduresThe Path Vector TLV is carried in Label Mapping and Label Request messages when Loop Detection is configured.
22.214.171.124.1. Label Request Path VectorSection "Loop Detection" specifies situations when an LSR must include a Path Vector TLV in a Label Request message. An LSR that receives a Path Vector in a Label Request message MUST perform the procedures described in Section "Loop Detection". If the LSR detects a loop, it MUST reject the Label Request message.
The LSR MUST: 1. Transmit a Notification message to the sending LSR signaling "Loop Detected". 2. Not propagate the Label Request message further. Note that a Label Request message with a Path Vector TLV is forwarded until: 1. A loop is found, 2. The LSP egress is reached, or 3. The maximum Path Vector limit or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
126.96.36.199.2. Label Mapping Path VectorSection "Loop Detection" specifies the situations when an LSR must include a Path Vector TLV in a Label Mapping message. An LSR that receives a Path Vector in a Label Mapping message MUST perform the procedures described in Section "Loop Detection". If the LSR detects a loop, it MUST reject the Label Mapping message in order to prevent a forwarding loop. The LSR MUST: 1. Transmit a Label Release message carrying a Status TLV to the sending LSR to signal "Loop Detected". 2. Not propagate the message further. 3. Check whether the Label Mapping message is for an existing LSP. If so, the LSR must unsplice any upstream labels that are spliced to the downstream label for the FEC. Note that a Label Mapping message with a Path Vector TLV is forwarded until: 1. A loop is found, 2. An LSP ingress is reached, or 3. The maximum Path Vector or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
3.4.6. Status TLVNotification messages carry Status TLVs to specify events being signaled. The encoding for the Status TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Status (0x0300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U-bit SHOULD be 0 when the Status TLV is sent in a Notification message. SHOULD be 1 when the Status TLV is sent in some other message. F-bit SHOULD be the same as the setting of the F-bit in the Status Code field. Status Code 32-bit unsigned integer encoding the event being signaled. The structure of a Status Code is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|F| Status Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-bit Fatal error bit. If set (=1), this is a fatal Error Notification. If clear (=0), this is an Advisory Notification. F-bit Forward bit. If set (=1), the notification SHOULD be forwarded to the LSR for the next-hop or previous-hop for the LSP, if any, associated with the event being signaled. If clear (=0), the notification SHOULD NOT be forwarded.
Status Data 30-bit unsigned integer that specifies the status information. This specification defines Status Codes (32-bit unsigned integers with the above encoding). A Status Code of 0 signals success. Message ID If non-zero, 32-bit value that identifies the peer message to which the Status TLV refers. If zero, no specific peer message is being identified. Message Type If non-zero, the type of the peer message to which the Status TLV refers. If zero, the Status TLV does not refer to any specific message type. Note that use of the Status TLV is not limited to Notification messages. A message other than a Notification message may carry a Status TLV as an Optional Parameter. When a message other than a Notification carries a Status TLV, the U-bit of the Status TLV SHOULD be set to 1 to indicate that the receiver SHOULD silently discard the TLV if unprepared to handle it.