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".
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. 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.
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.
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.
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.
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. 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]. 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]. 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. 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.
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. 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.
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.
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.
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.
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]. 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 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.
- 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".
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. Section "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. Section "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.
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.