| < draft-ietf-mpls-rfc3036bis-03.txt | draft-ietf-mpls-rfc3036bis-04.txt > | |||
|---|---|---|---|---|
| Network Working Group Loa Andersson | Network Working Group Loa Andersson | |||
| Internet Draft Ina Minei | Internet Draft Ina Minei | |||
| Expiration Date: April 2006 Bob Thomas | Expiration Date: March 2007 Bob Thomas | |||
| Editors | Editors | |||
| October 2005 | September 2006 | |||
| LDP Specification | LDP Specification | |||
| draft-ietf-mpls-rfc3036bis-03.txt | draft-ietf-mpls-rfc3036bis-04.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
| skipping to change at page 3, line 47 ¶ | skipping to change at page 3, line 47 ¶ | |||
| 2.6.2 Label Retention Mode .................................. 23 | 2.6.2 Label Retention Mode .................................. 23 | |||
| 2.6.2.1 Conservative Label Retention Mode ..................... 23 | 2.6.2.1 Conservative Label Retention Mode ..................... 23 | |||
| 2.6.2.2 Liberal Label Retention Mode .......................... 24 | 2.6.2.2 Liberal Label Retention Mode .......................... 24 | |||
| 2.6.3 Label Advertisement Mode .............................. 24 | 2.6.3 Label Advertisement Mode .............................. 24 | |||
| 2.7 LDP Identifiers and Next Hop Addresses ................ 24 | 2.7 LDP Identifiers and Next Hop Addresses ................ 24 | |||
| 2.8 Loop Detection ........................................ 25 | 2.8 Loop Detection ........................................ 25 | |||
| 2.8.1 Label Request Message ................................. 26 | 2.8.1 Label Request Message ................................. 26 | |||
| 2.8.2 Label Mapping Message ................................. 27 | 2.8.2 Label Mapping Message ................................. 27 | |||
| 2.8.3 Discussion ............................................ 29 | 2.8.3 Discussion ............................................ 29 | |||
| 2.9 Authenticity and Integrity of LDP Messages ............ 29 | 2.9 Authenticity and Integrity of LDP Messages ............ 29 | |||
| 2.9.1 TCP MD5 Signature Option .............................. 29 | 2.9.1 TCP MD5 Signature Option .............................. 30 | |||
| 2.9.2 LDP Use of TCP MD5 Signature Option ................... 31 | 2.9.2 LDP Use of TCP MD5 Signature Option ................... 31 | |||
| 2.10 Label Distribution for Explicitly Routed LSPs ......... 32 | 2.10 Label Distribution for Explicitly Routed LSPs ......... 32 | |||
| 3 Protocol Specification ................................ 32 | 3 Protocol Specification ................................ 32 | |||
| 3.1 LDP PDUs .............................................. 32 | 3.1 LDP PDUs .............................................. 32 | |||
| 3.2 LDP Procedures ........................................ 33 | 3.2 LDP Procedures ........................................ 33 | |||
| 3.3 Type-Length-Value Encoding ............................ 34 | 3.3 Type-Length-Value Encoding ............................ 34 | |||
| 3.4 TLV Encodings for Commonly Used Parameters ............ 35 | 3.4 TLV Encodings for Commonly Used Parameters ............ 35 | |||
| 3.4.1 FEC TLV ............................................... 36 | 3.4.1 FEC TLV ............................................... 36 | |||
| 3.4.1.1 FEC Procedures ........................................ 37 | 3.4.1.1 FEC Procedures ........................................ 37 | |||
| 3.4.2 Label TLVs ............................................ 38 | 3.4.2 Label TLVs ............................................ 38 | |||
| 3.4.2.1 Generic Label TLV ..................................... 38 | 3.4.2.1 Generic Label TLV ..................................... 38 | |||
| 3.4.2.2 ATM Label TLV ......................................... 38 | 3.4.2.2 ATM Label TLV ......................................... 38 | |||
| 3.4.2.3 Frame Relay Label TLV ................................. 39 | 3.4.2.3 Frame Relay Label TLV ................................. 39 | |||
| 3.4.3 Address List TLV ...................................... 40 | 3.4.3 Address List TLV ...................................... 40 | |||
| 3.4.4 Hop Count TLV ......................................... 40 | 3.4.4 Hop Count TLV ......................................... 41 | |||
| 3.4.4.1 Hop Count Procedures .................................. 41 | 3.4.4.1 Hop Count Procedures .................................. 41 | |||
| 3.4.5 Path Vector TLV ....................................... 42 | 3.4.5 Path Vector TLV ....................................... 43 | |||
| 3.4.5.1 Path Vector Procedures ................................ 43 | 3.4.5.1 Path Vector Procedures ................................ 43 | |||
| 3.4.5.1.1 Label Request Path Vector ............................. 43 | 3.4.5.1.1 Label Request Path Vector ............................. 43 | |||
| 3.4.5.1.2 Label Mapping Path Vector ............................. 43 | 3.4.5.1.2 Label Mapping Path Vector ............................. 44 | |||
| 3.4.6 Status TLV ............................................ 44 | 3.4.6 Status TLV ............................................ 45 | |||
| 3.5 LDP Messages .......................................... 46 | 3.5 LDP Messages .......................................... 46 | |||
| 3.5.1 Notification Message .................................. 48 | 3.5.1 Notification Message .................................. 49 | |||
| 3.5.1.1 Notification Message Procedures ....................... 49 | 3.5.1.1 Notification Message Procedures ....................... 50 | |||
| 3.5.1.2 Events Signaled by Notification Messages .............. 49 | 3.5.1.2 Events Signaled by Notification Messages .............. 50 | |||
| 3.5.1.2.1 Malformed PDU or Message .............................. 50 | 3.5.1.2.1 Malformed PDU or Message .............................. 51 | |||
| 3.5.1.2.2 Unknown or Malformed TLV .............................. 51 | 3.5.1.2.2 Unknown or Malformed TLV .............................. 52 | |||
| 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 51 | 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 52 | |||
| 3.5.1.2.4 Unilateral Session Shutdown ........................... 51 | 3.5.1.2.4 Unilateral Session Shutdown ........................... 52 | |||
| 3.5.1.2.5 Initialization Message Events ......................... 51 | 3.5.1.2.5 Initialization Message Events ......................... 52 | |||
| 3.5.1.2.6 Events Resulting From Other Messages .................. 52 | 3.5.1.2.6 Events Resulting From Other Messages .................. 53 | |||
| 3.5.1.2.7 Internal Errors ....................................... 52 | 3.5.1.2.7 Internal Errors ....................................... 53 | |||
| 3.5.1.2.8 Miscellaneous Events .................................. 52 | 3.5.1.2.8 Miscellaneous Events .................................. 53 | |||
| 3.5.2 Hello Message ......................................... 52 | 3.5.2 Hello Message ......................................... 53 | |||
| 3.5.2.1 Hello Message Procedures .............................. 54 | 3.5.2.1 Hello Message Procedures .............................. 55 | |||
| 3.5.3 Initialization Message ................................ 56 | 3.5.3 Initialization Message ................................ 57 | |||
| 3.5.3.1 Initialization Message Procedures ..................... 64 | 3.5.3.1 Initialization Message Procedures ..................... 65 | |||
| 3.5.4 KeepAlive Message ..................................... 64 | 3.5.4 KeepAlive Message ..................................... 65 | |||
| 3.5.4.1 KeepAlive Message Procedures .......................... 64 | 3.5.4.1 KeepAlive Message Procedures .......................... 65 | |||
| 3.5.5 Address Message ....................................... 65 | 3.5.5 Address Message ....................................... 66 | |||
| 3.5.5.1 Address Message Procedures ............................ 65 | 3.5.5.1 Address Message Procedures ............................ 66 | |||
| 3.5.6 Address Withdraw Message .............................. 66 | 3.5.6 Address Withdraw Message .............................. 67 | |||
| 3.5.6.1 Address Withdraw Message Procedures ................... 67 | 3.5.6.1 Address Withdraw Message Procedures ................... 68 | |||
| 3.5.7 Label Mapping Message ................................. 67 | 3.5.7 Label Mapping Message ................................. 68 | |||
| 3.5.7.1 Label Mapping Message Procedures ...................... 68 | 3.5.7.1 Label Mapping Message Procedures ...................... 69 | |||
| 3.5.7.1.1 Independent Control Mapping ........................... 69 | 3.5.7.1.1 Independent Control Mapping ........................... 70 | |||
| 3.5.7.1.2 Ordered Control Mapping ............................... 69 | 3.5.7.1.2 Ordered Control Mapping ............................... 70 | |||
| 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 70 | 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 71 | |||
| 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 70 | 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 71 | |||
| 3.5.8 Label Request Message ................................. 71 | 3.5.8 Label Request Message ................................. 72 | |||
| 3.5.8.1 Label Request Message Procedures ...................... 72 | 3.5.8.1 Label Request Message Procedures ...................... 73 | |||
| 3.5.9 Label Abort Request Message ........................... 73 | 3.5.9 Label Abort Request Message ........................... 74 | |||
| 3.5.9.1 Label Abort Request Message Procedures ................ 74 | 3.5.9.1 Label Abort Request Message Procedures ................ 75 | |||
| 3.5.10 Label Withdraw Message ................................ 76 | 3.5.10 Label Withdraw Message ................................ 77 | |||
| 3.5.10.1 Label Withdraw Message Procedures ..................... 77 | 3.5.10.1 Label Withdraw Message Procedures ..................... 78 | |||
| 3.5.11 Label Release Message ................................. 77 | 3.5.11 Label Release Message ................................. 78 | |||
| 3.5.11.1 Label Release Message Procedures ...................... 78 | 3.5.11.1 Label Release Message Procedures ...................... 79 | |||
| 3.6 Messages and TLVs for Extensibility ................... 79 | 3.6 Messages and TLVs for Extensibility ................... 80 | |||
| 3.6.1 LDP Vendor-private Extensions ......................... 79 | 3.6.1 LDP Vendor-private Extensions ......................... 80 | |||
| 3.6.1.1 LDP Vendor-private TLVs ............................... 79 | 3.6.1.1 LDP Vendor-private TLVs ............................... 80 | |||
| 3.6.1.2 LDP Vendor-private Messages ........................... 81 | 3.6.1.2 LDP Vendor-private Messages ........................... 82 | |||
| 3.6.2 LDP Experimental Extensions ........................... 82 | 3.6.2 LDP Experimental Extensions ........................... 83 | |||
| 3.7 Message Summary ....................................... 82 | 3.7 Message Summary ....................................... 84 | |||
| 3.8 TLV Summary ........................................... 83 | 3.8 TLV Summary ........................................... 84 | |||
| 3.9 Status Code Summary ................................... 84 | 3.9 Status Code Summary ................................... 85 | |||
| 3.10 Well-known Numbers .................................... 85 | 3.10 Well-known Numbers .................................... 86 | |||
| 3.10.1 UDP and TCP Ports ..................................... 85 | 3.10.1 UDP and TCP Ports ..................................... 86 | |||
| 3.10.2 Implicit NULL Label ................................... 85 | 3.10.2 Implicit NULL Label ................................... 86 | |||
| 4 IANA Considerations ................................... 85 | 4 IANA Considerations ................................... 87 | |||
| 4.1 Message Type Name Space ............................... 85 | 4.1 Message Type Name Space ............................... 87 | |||
| 4.2 TLV Type Name Space ................................... 86 | 4.2 TLV Type Name Space ................................... 87 | |||
| 4.3 FEC Type Name Space ................................... 86 | 4.3 FEC Type Name Space ................................... 88 | |||
| 4.4 Status Code Name Space ................................ 87 | 4.4 Status Code Name Space ................................ 88 | |||
| 4.5 Experiment ID Name Space .............................. 87 | 4.5 Experiment ID Name Space .............................. 88 | |||
| 5 Security Considerations ............................... 87 | 5 Security Considerations ............................... 89 | |||
| 5.1 Spoofing .............................................. 87 | 5.1 Spoofing .............................................. 89 | |||
| 5.2 Privacy ............................................... 88 | 5.2 Privacy ............................................... 90 | |||
| 5.3 Denial of Service ..................................... 89 | 5.3 Denial of Service ..................................... 90 | |||
| 6 Areas for Future Study ................................ 90 | 6 Areas for Future Study ................................ 92 | |||
| 7 Changes from RFC3036 .................................. 91 | 7 Changes from RFC3036 .................................. 93 | |||
| 8 Acknowledgments ....................................... 93 | 8 Acknowledgments ....................................... 95 | |||
| 9 References ............................................ 93 | 9 References ............................................ 96 | |||
| 9.1 Normative references .................................. 93 | 9.1 Normative references .................................. 96 | |||
| 9.2 Non-normative references .............................. 94 | 9.2 Non-normative references .............................. 96 | |||
| 10 Intellectual Property Statement ....................... 95 | 10 Intellectual Property Statement ....................... 97 | |||
| 11 Editors' Addresses .................................... 95 | 11 Editors' Addresses .................................... 98 | |||
| Appendix A LDP Label Distribution Procedures ..................... 96 | Appendix A LDP Label Distribution Procedures ..................... 99 | |||
| A.1 Handling Label Distribution Events .................... 98 | A.1 Handling Label Distribution Events .................... 101 | |||
| A.1.1 Receive Label Request ................................. 99 | A.1.1 Receive Label Request ................................. 102 | |||
| A.1.2 Receive Label Mapping ................................. 102 | A.1.2 Receive Label Mapping ................................. 105 | |||
| A.1.3 Receive Label Abort Request ........................... 108 | A.1.3 Receive Label Abort Request ........................... 111 | |||
| A.1.4 Receive Label Release ................................. 110 | A.1.4 Receive Label Release ................................. 113 | |||
| A.1.5 Receive Label Withdraw ................................ 112 | A.1.5 Receive Label Withdraw ................................ 115 | |||
| A.1.6 Recognize New FEC ..................................... 113 | A.1.6 Recognize New FEC ..................................... 117 | |||
| A.1.7 Detect Change in FEC Next Hop ......................... 116 | A.1.7 Detect Change in FEC Next Hop ......................... 119 | |||
| A.1.8 Receive Notification / Label Request Aborted .......... 119 | A.1.8 Receive Notification / Label Request Aborted .......... 122 | |||
| A.1.9 Receive Notification / No Label Resources ............. 119 | A.1.9 Receive Notification / No Label Resources ............. 123 | |||
| A.1.10 Receive Notification / No Route ....................... 120 | A.1.10 Receive Notification / No Route ....................... 123 | |||
| A.1.11 Receive Notification / Loop Detected .................. 121 | A.1.11 Receive Notification / Loop Detected .................. 124 | |||
| A.1.12 Receive Notification / Label Resources Available ...... 121 | A.1.12 Receive Notification / Label Resources Available ...... 125 | |||
| A.1.13 Detect local label resources have become available .... 122 | A.1.13 Detect local label resources have become available .... 126 | |||
| A.1.14 LSR decides to no longer label switch a FEC ........... 123 | A.1.14 LSR decides to no longer label switch a FEC ........... 127 | |||
| A.1.15 Timeout of deferred label request ..................... 124 | A.1.15 Timeout of deferred label request ..................... 127 | |||
| A.2 Common Label Distribution Procedures .................. 124 | A.2 Common Label Distribution Procedures .................. 128 | |||
| A.2.1 Send_Label ............................................ 125 | A.2.1 Send_Label ............................................ 128 | |||
| A.2.2 Send_Label_Request .................................... 126 | A.2.2 Send_Label_Request .................................... 130 | |||
| A.2.3 Send_Label_Withdraw ................................... 127 | A.2.3 Send_Label_Withdraw ................................... 131 | |||
| A.2.4 Send_Notification ..................................... 128 | A.2.4 Send_Notification ..................................... 131 | |||
| A.2.5 Send_Message .......................................... 128 | A.2.5 Send_Message .......................................... 132 | |||
| A.2.6 Check_Received_Attributes ............................. 129 | A.2.6 Check_Received_Attributes ............................. 132 | |||
| A.2.7 Prepare_Label_Request_Attributes ...................... 130 | A.2.7 Prepare_Label_Request_Attributes ...................... 133 | |||
| A.2.8 Prepare_Label_Mapping_Attributes ...................... 132 | A.2.8 Prepare_Label_Mapping_Attributes ...................... 135 | |||
| Full Copyright Statement .............................. 135 | Full Copyright Statement .............................. 138 | |||
| 1. LDP Overview | 1. LDP Overview | |||
| The MPLS architecture [RFC3031] defines a label distribution protocol | The MPLS architecture [RFC3031] defines a label distribution protocol | |||
| as a set of procedures by which one Label Switched Router (LSR) | as a set of procedures by which one Label Switched Router (LSR) | |||
| informs another of the meaning of labels used to forward traffic | informs another of the meaning of labels used to forward traffic | |||
| between and through them. | between and through them. | |||
| The MPLS architecture does not assume a single label distribution | The MPLS architecture does not assume a single label distribution | |||
| protocol. In fact, a number of different label distribution proto- | protocol. In fact, a number of different label distribution proto- | |||
| skipping to change at page 7, line 45 ¶ | skipping to change at page 7, line 45 ¶ | |||
| LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with | LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with | |||
| each LSP it creates. The FEC associated with an LSP specifies which | each LSP it creates. The FEC associated with an LSP specifies which | |||
| packets are "mapped" to that LSP. LSPs are extended through a net- | packets are "mapped" to that LSP. LSPs are extended through a net- | |||
| work as each LSR "splices" incoming labels for a FEC to the outgoing | work as each LSR "splices" incoming labels for a FEC to the outgoing | |||
| label assigned to the next hop for the given FEC. | label assigned to the next hop for the given FEC. | |||
| More information about the applicability of LDP can be found in | More information about the applicability of LDP can be found in | |||
| [RFC3037]. | [RFC3037]. | |||
| This document assumes familiarity with the MPLS architecture | This document assumes (but does not require) familiarity with the | |||
| [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminol- | MPLS architecture [RFC3031]. Note that [RFC3031] includes a glossary | |||
| ogy, such as ingress, label switched path, etc. | of MPLS terminology, such as ingress, label switched path, etc. | |||
| 1.1. LDP Peers | 1.1. LDP Peers | |||
| Two LSRs which use LDP to exchange label/FEC mapping information are | Two LSRs which use LDP to exchange label/FEC mapping information are | |||
| known as "LDP Peers" with respect to that information and we speak of | known as "LDP Peers" with respect to that information and we speak of | |||
| there being an "LDP Session" between them. A single LDP session | there being an "LDP Session" between them. A single LDP session | |||
| allows each peer to learn the other's label mappings; i.e., the pro- | allows each peer to learn the other's label mappings; i.e., the pro- | |||
| tocol is bi-directional. | tocol is bi-directional. | |||
| 1.2. LDP Message Exchange | 1.2. LDP Message Exchange | |||
| skipping to change at page 11, line 30 ¶ | skipping to change at page 11, line 30 ¶ | |||
| 2.2.1. Label Spaces | 2.2.1. Label Spaces | |||
| The notion of "label space" is useful for discussing the assignment | The notion of "label space" is useful for discussing the assignment | |||
| and distribution of labels. There are two types of label spaces: | and distribution of labels. There are two types of label spaces: | |||
| - Per interface label space. Interface-specific incoming labels | - Per interface label space. Interface-specific incoming labels | |||
| are used for interfaces that use interface resources for labels. | are used for interfaces that use interface resources for labels. | |||
| An example of such an interface is a label-controlled ATM inter- | An example of such an interface is a label-controlled ATM inter- | |||
| face that uses VCIs as labels, or a Frame Relay interface that | face that uses VCIs as labels, or a Frame Relay interface that | |||
| uses DLCIs as labels. | uses DLCIs (Data Link Connection Identifiers) as labels. | |||
| Note that the use of a per interface label space only makes sense | Note that the use of a per interface label space only makes sense | |||
| when the LDP peers are "directly connected" over an interface, | when the LDP peers are "directly connected" over an interface, | |||
| and the label is only going to be used for traffic sent over that | and the label is only going to be used for traffic sent over that | |||
| interface. | interface. | |||
| - Per platform label space. Platform-wide incoming labels are used | - Per platform label space. Platform-wide incoming labels are used | |||
| for interfaces that can share the same labels. | for interfaces that can share the same labels. | |||
| 2.2.2. LDP Identifiers | 2.2.2. LDP Identifiers | |||
| skipping to change at page 16, line 29 ¶ | skipping to change at page 16, line 29 ¶ | |||
| An LSR MUST advertise the same transport address in all Hellos that | An LSR MUST advertise the same transport address in all Hellos that | |||
| advertise the same label space. This requirement ensures that two | advertise the same label space. This requirement ensures that two | |||
| LSRs linked by multiple Hello adjacencies using the same label spaces | LSRs linked by multiple Hello adjacencies using the same label spaces | |||
| play the same connection establishment role for each adjacency. | play the same connection establishment role for each adjacency. | |||
| 2.5.3. Session Initialization | 2.5.3. Session Initialization | |||
| After LSR1 and LSR2 establish a transport connection they negotiate | After LSR1 and LSR2 establish a transport connection they negotiate | |||
| session parameters by exchanging LDP Initialization messages. The | session parameters by exchanging LDP Initialization messages. The | |||
| parameters negotiated include LDP protocol version, label distribu- | parameters negotiated include LDP protocol version, label distribu- | |||
| tion method, timer values, VPI/VCI ranges for label controlled ATM, | tion method, timer values, VPI/VCI (Virtual Path Identifier/ Virtual | |||
| DLCI ranges for label controlled Frame Relay, etc. | Channel Identifier) ranges for label controlled ATM, DLCI (Data Link | |||
| Connection Identifier) ranges for label controlled Frame Relay, etc. | ||||
| Successful negotiation completes establishment of an LDP session | Successful negotiation completes establishment of an LDP session | |||
| between LSR1 and LSR2 for the advertisement of label spaces LSR1:a | between LSR1 and LSR2 for the advertisement of label spaces LSR1:a | |||
| and LSR2:b. | and LSR2:b. | |||
| The following describes the session initialization from LSR1's point | The following describes the session initialization from LSR1's point | |||
| of view. | of view. | |||
| After the connection is established, if LSR1 is playing the active | After the connection is established, if LSR1 is playing the active | |||
| role, it initiates negotiation of session parameters by sending an | role, it initiates negotiation of session parameters by sending an | |||
| skipping to change at page 18, line 17 ¶ | skipping to change at page 18, line 17 ¶ | |||
| d. When LSR1 has received both an acceptable Initialization | d. When LSR1 has received both an acceptable Initialization | |||
| message and a KeepAlive message the session is operational | message and a KeepAlive message the session is operational | |||
| from LSR1's point of view. | from LSR1's point of view. | |||
| Until the LDP session is established, no other messages | Until the LDP session is established, no other messages | |||
| except those listed in the procedures above may be | except those listed in the procedures above may be | |||
| exchanged, and the rules for processing the U-bit in LDP | exchanged, and the rules for processing the U-bit in LDP | |||
| messages are overridden. If a message other than those | messages are overridden. If a message other than those | |||
| listed in the procedures above is received, a Shutdown msg | listed in the procedures above is received, a Shutdown msg | |||
| MUST be tranmitted and the transport connection MUST be | MUST be transmitted and the transport connection MUST be | |||
| closed. | closed. | |||
| It is possible for a pair of incompatibly configured LSRs that | It is possible for a pair of incompatibly configured LSRs that | |||
| disagree on session parameters to engage in an endless sequence | disagree on session parameters to engage in an endless sequence | |||
| of messages as each NAKs the other's Initialization messages with | of messages as each NAKs the other's Initialization messages with | |||
| Error Notification messages. | Error Notification messages. | |||
| An LSR MUST throttle its session setup retry attempts with an | An LSR MUST throttle its session setup retry attempts with an | |||
| exponential backoff in situations where Initialization messages | exponential backoff in situations where Initialization messages | |||
| are being NAK'd. It is also recommended that an LSR detecting | are being NAK'd. It is also recommended that an LSR detecting | |||
| such a situation take action to notify an operator. | such a situation take action to notify an operator. | |||
| The session establishment setup attempt following a NAK'd Ini- | The session establishment setup attempt following a NAK'd Ini- | |||
| tialization message must be delayed no less than 15 seconds, and | tialization message MUST be delayed no less than 15 seconds, and | |||
| subsequent delays must grow to a maximum delay of no less than 2 | subsequent delays MUST grow to a maximum delay of no less than 2 | |||
| minutes. The specific session establishment action that must be | minutes. The specific session establishment action that must be | |||
| delayed is the attempt to open the session transport connection | delayed is the attempt to open the session transport connection | |||
| by the LSR playing the active role. | by the LSR playing the active role. | |||
| The throttled sequence of Initialization NAKs is unlikely to | The throttled sequence of Initialization NAKs is unlikely to | |||
| cease until operator intervention reconfigures one of the LSRs. | cease until operator intervention reconfigures one of the LSRs. | |||
| After such a configuration action there is no further need to | After such a configuration action there is no further need to | |||
| throttle subsequent session establishment attempts (until their | throttle subsequent session establishment attempts (until their | |||
| initialization messages are NAK'd). | initialization messages are NAK'd). | |||
| skipping to change at page 22, line 7 ¶ | skipping to change at page 22, line 7 ¶ | |||
| LSR may send any protocol message to meet this requirement. In cir- | LSR may send any protocol message to meet this requirement. In cir- | |||
| cumstances where an LSR has no other information to communicate to | cumstances where an LSR has no other information to communicate to | |||
| its peer, it sends a KeepAlive message. | its peer, it sends a KeepAlive message. | |||
| An LSR may choose to terminate an LDP session with a peer at any | An LSR may choose to terminate an LDP session with a peer at any | |||
| time. Should it choose to do so, it informs the peer with a Shutdown | time. Should it choose to do so, it informs the peer with a Shutdown | |||
| message. | message. | |||
| 2.6. Label Distribution and Management | 2.6. Label Distribution and Management | |||
| The MPLS architecture [RF3031] allows an LSR to distribute a FEC | The MPLS architecture [RFC3031] allows an LSR to distribute a FEC | |||
| label binding in response to an explicit request from another LSR. | label binding in response to an explicit request from another LSR. | |||
| This is known as Downstream On Demand label distribution. It also | This is known as Downstream On Demand label distribution. It also | |||
| allows an LSR to distribute label bindings to LSRs that have not | allows an LSR to distribute label bindings to LSRs that have not | |||
| explicitly requested them. [RFC3031] calls this method of label dis- | explicitly requested them. [RFC3031] calls this method of label dis- | |||
| tribution Unsolicited Downstream; this document uses the term Down- | tribution Unsolicited Downstream; this document uses the term Down- | |||
| stream Unsolicited. | stream Unsolicited. | |||
| Both of these label distribution techniques may be used in the same | Both of these label distribution techniques may be used in the same | |||
| network at the same time. However, for any given LDP session, each | 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 | LSR must be aware of the label distribution method used by its peer | |||
| skipping to change at page 23, line 17 ¶ | skipping to change at page 23, line 17 ¶ | |||
| 1. The FEC refers to the LSR itself (including one of its directly | 1. The FEC refers to the LSR itself (including one of its directly | |||
| attached interfaces). | attached interfaces). | |||
| 2. The next hop router for the FEC is outside of the Label Switch- | 2. The next hop router for the FEC is outside of the Label Switch- | |||
| ing Network. | ing Network. | |||
| 3. FEC elements are reachable by crossing a routing domain bound- | 3. FEC elements are reachable by crossing a routing domain bound- | |||
| ary, such as another area for OSPF summary networks, or another | ary, such as another area for OSPF summary networks, or another | |||
| autonomous system for OSPF AS externals and BGP routes | autonomous system for OSPF AS externals and BGP routes | |||
| [RFC2328] [RFC1771]. | [RFC2328] [RFC4271]. | |||
| Note that whether an LSR is an egress for a given FEC may change over | 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 | time, depending on the state of the network and LSR configuration | |||
| settings. | settings. | |||
| 2.6.2. Label Retention Mode | 2.6.2. Label Retention Mode | |||
| The MPLS architecture [RFC3031] introduces the notion of label reten- | The MPLS architecture [RFC3031] introduces the notion of label reten- | |||
| tion mode which specifies whether an LSR maintains a label binding | tion 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 | for a FEC learned from a neighbor that is not its next hop for the | |||
| skipping to change at page 25, line 47 ¶ | skipping to change at page 25, line 47 ¶ | |||
| ing a Hop Count TLV it increments the count. An LSR that detects | ing a Hop Count TLV it increments the count. An LSR that detects | |||
| a Hop Count has reached a configured maximum value behaves as if | a Hop Count has reached a configured maximum value behaves as if | |||
| the containing message has traversed a loop. By convention a | the containing message has traversed a loop. By convention a | |||
| count of 0 is interpreted to mean the hop count is unknown. | count of 0 is interpreted to mean the hop count is unknown. | |||
| Incrementing an unknown hop count value results in an unknown hop | Incrementing an unknown hop count value results in an unknown hop | |||
| count value (0). | count value (0). | |||
| The following paragraphs describes LDP loop detection procedures. | The following paragraphs describes LDP loop detection procedures. | |||
| For these paragraphs, and only these paragraphs, "MUST" is redefined | For these paragraphs, and only these paragraphs, "MUST" is redefined | |||
| to mean "MUST if configured for loop detection". The paragraphs | to mean "MUST if configured for loop detection". The paragraphs | |||
| specify messages that must carry Path Vector and Hop Count TLVs. | specify messages that MUST carry Path Vector and Hop Count TLVs. | |||
| Note that the Hop Count TLV and its procedures are used without the | Note that the Hop Count TLV and its procedures are used without the | |||
| Path Vector TLV in situations when loop detection is not configured | Path Vector TLV in situations when loop detection is not configured | |||
| (see [RFC3035] and [RFC3034]). | (see [RFC3035] and [RFC3034]). | |||
| 2.8.1. Label Request Message | 2.8.1. Label Request Message | |||
| The use of the Path Vector TLV and Hop Count TLV prevent Label | The use of the Path Vector TLV and Hop Count TLV prevent Label | |||
| Request messages from looping in environments that include non-merge | Request messages from looping in environments that include non-merge | |||
| capable LSRs. | capable LSRs. | |||
| skipping to change at page 29, line 42 ¶ | skipping to change at page 29, line 42 ¶ | |||
| in conjunction with ordered label distribution, to minimize the num- | in conjunction with ordered label distribution, to minimize the num- | |||
| ber of Label Mapping update messages. | ber of Label Mapping update messages. | |||
| 2.9. Authenticity and Integrity of LDP Messages | 2.9. Authenticity and Integrity of LDP Messages | |||
| This section specifies a mechanism to protect against the introduc- | This section specifies a mechanism to protect against the introduc- | |||
| tion of spoofed TCP segments into LDP session connection streams. | tion of spoofed TCP segments into LDP session connection streams. | |||
| The use of this mechanism MUST be supported as a configurable option. | The use of this mechanism MUST be supported as a configurable option. | |||
| The mechanism is based on use of the TCP MD5 Signature Option speci- | The mechanism is based on use of the TCP MD5 Signature Option speci- | |||
| fied in [RFC2385] for use by BGP. See [RFC1321] for a specification | fied in [RFC2385] for use by BGP [RFC4271]. See [RFC1321] for a | |||
| of the MD5 hash function. | 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 Option | 2.9.1. TCP MD5 Signature Option | |||
| The following quotes from [RFC2385] outline the security properties | The following quotes from [RFC2385] outline the security properties | |||
| achieved by using the TCP MD5 Signature Option and summarizes its | achieved by using the TCP MD5 Signature Option and summarizes its | |||
| operation: | operation: | |||
| "IESG Note | "IESG Note | |||
| This document describes current existing practice for securing | This document describes current existing practice for securing | |||
| skipping to change at page 30, line 46 ¶ | skipping to change at page 30, line 52 ¶ | |||
| TCP implementations with changing passwords). | TCP implementations with changing passwords). | |||
| Finally, there is no negotiation for the use of this option in | Finally, there is no negotiation for the use of this option in | |||
| a connection, rather it is purely a matter of site policy | a connection, rather it is purely a matter of site policy | |||
| whether or not its connections use the option." | whether or not its connections use the option." | |||
| "MD5 as a Hashing Algorithm | "MD5 as a Hashing Algorithm | |||
| Since this memo was first issued (under a different title), the | Since this memo was first issued (under a different title), the | |||
| MD5 algorithm has been found to be vulnerable to collision | MD5 algorithm has been found to be vulnerable to collision | |||
| search attacks [Dobb], and is considered by some to be insuffi- | search attacks [Dobb], and is considered by some to be | |||
| ciently strong for this type of application. | insufficiently strong for this type of application. | |||
| This memo still specifies the MD5 algorithm, however, since the | This memo still specifies the MD5 algorithm, however, since the | |||
| option has already been deployed operationally, and there was | option has already been deployed operationally, and there was | |||
| no "algorithm type" field defined to allow an upgrade using the | no "algorithm type" field defined to allow an upgrade using the | |||
| same option number. The original document did not specify a | same option number. The original document did not specify a | |||
| type field since this would require at least one more byte, and | 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 | it was felt at the time that taking 19 bytes for the complete | |||
| option (which would probably be padded to 20 bytes in TCP | option (which would probably be padded to 20 bytes in TCP | |||
| implementations) would be too much of a waste of the already | implementations) would be too much of a waste of the already | |||
| limited option space. | limited option space. | |||
| skipping to change at page 33, line 16 ¶ | skipping to change at page 33, line 16 ¶ | |||
| Two octet integer specifying the total length of this PDU in octets, | Two octet integer specifying the total length of this PDU in octets, | |||
| excluding the Version and PDU Length fields. | excluding the Version and PDU Length fields. | |||
| The maximum allowable PDU Length is negotiable when an LDP session is | The maximum allowable PDU Length is negotiable when an LDP session is | |||
| initialized. Prior to completion of the negotiation the maximum | initialized. Prior to completion of the negotiation the maximum | |||
| allowable length is 4096 bytes. | allowable length is 4096 bytes. | |||
| LDP Identifier | LDP Identifier | |||
| Six octet field that uniquely identifies the label space of the send- | Six octet field that uniquely identifies the label space of the send- | |||
| ing LSR for which this PDU applies. The first four octets identify | ing 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 | 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 | 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 | detection Path Vectors. The last two octets identify a label space | |||
| within the LSR. For a platform-wide label space, these should both be | within the LSR. For a platform-wide label space, these SHOULD both be | |||
| zero. | zero. | |||
| Note that there is no alignment requirement for the first octet of an | Note that there is no alignment requirement for the first octet of an | |||
| LDP PDU. | LDP PDU. | |||
| 3.2. LDP Procedures | 3.2. LDP Procedures | |||
| LDP defines messages, TLVs and procedures in the following areas: | LDP defines messages, TLVs and procedures in the following areas: | |||
| - Peer discovery; | - Peer discovery; | |||
| skipping to change at page 37, line 20 ¶ | skipping to change at page 37, line 20 ¶ | |||
| 0 1 2 3 | 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 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 (2) | Address Family | PreLen | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Prefix | | | Prefix | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Address Family | Address Family | |||
| Two octet quantity containing a value from ADDRESS FAMILY NUM- | Two octet quantity containing a value from ADDRESS FAMILY NUM- | |||
| BERS in [RFC1700] that encodes the address family for the | BERS in [ASSIGNED_AF] that encodes the address family for the | |||
| address prefix in the Prefix field. | address prefix in the Prefix field. | |||
| PreLen | PreLen | |||
| One octet unsigned integer containing the length in bits of the | One octet unsigned integer containing the length in bits of the | |||
| address prefix that follows. A length of zero indicates a pre- | address prefix that follows. A length of zero indicates a pre- | |||
| fix that matches all addresses (the default destination); in | fix that matches all addresses (the default destination); in | |||
| this case the Prefix itself is zero octets). | this case the Prefix itself is zero octets). | |||
| Prefix | Prefix | |||
| An address prefix encoded according to the Address Family | An address prefix encoded according to the Address Family | |||
| skipping to change at page 38, line 28 ¶ | skipping to change at page 38, line 28 ¶ | |||
| 0 1 2 3 | 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 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 | | |0|0| Generic Label (0x0200) | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Label | | | Label | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label | Label | |||
| This is a 20-bit label value as specified in [RFC3032] represented | This is a 20-bit label value represented as a 20-bit number in a 4 | |||
| as a 20-bit number in a 4 octet field. | 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]. | ||||
| 3.4.2.2. ATM Label TLV | 3.4.2.2. ATM Label TLV | |||
| An LSR uses ATM Label TLVs to encode labels for use on ATM links. | An LSR uses ATM Label TLVs to encode labels for use on ATM links. | |||
| 0 1 2 3 | 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 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 | | |0|0| ATM Label (0x0201) | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 39, line 44 ¶ | skipping to change at page 40, line 6 ¶ | |||
| Len | Len | |||
| This field specifies the number of bits of the DLCI. The follow- | This field specifies the number of bits of the DLCI. The follow- | |||
| ing values are supported: | ing values are supported: | |||
| 0 = 10 bits DLCI | 0 = 10 bits DLCI | |||
| 2 = 23 bits DLCI | 2 = 23 bits DLCI | |||
| Len values 1 and 3 are reserved. | Len values 1 and 3 are reserved. | |||
| DLCI | DLCI | |||
| The Data Link Connection Identifier. Refer to [RFC3034] for the | The Data Link Connection Identifier | |||
| label values and formats. | ||||
| For a 10bit 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 23bit 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 TLV | 3.4.3. Address List TLV | |||
| The Address List TLV appears in Address and Address Withdraw mes- | The Address List TLV appears in Address and Address Withdraw mes- | |||
| sages. | sages. | |||
| Its encoding is: | Its encoding is: | |||
| 0 1 2 3 | 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 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 | |||
| skipping to change at page 40, line 26 ¶ | skipping to change at page 41, line 4 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Address Family | | | | Address Family | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | | |||
| | Addresses | | | Addresses | | |||
| ~ ~ | ~ ~ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Address Family | Address Family | |||
| Two octet quantity containing a value from ADDRESS FAMILY NUMBERS | Two octet quantity containing a value from ADDRESS FAMILY NUMBERS | |||
| in [RFC1700] that encodes the addresses contained in the Addresses | in [ASSIGNED_AF] that encodes the addresses contained in the | |||
| field. | Addresses field. | |||
| Addresses | Addresses | |||
| A list of addresses from the specified Address Family. The | A list of addresses from the specified Address Family. The | |||
| encoding of the individual addresses depends on the Address Family. | encoding of the individual addresses depends on the Address | |||
| Family. | ||||
| The following address encodings are defined by this version of the | The following address encodings are defined by this version of the | |||
| protocol: | protocol: | |||
| Address Family Address Encoding | Address Family Address Encoding | |||
| IPv4 4 octet full IPv4 address | IPv4 4 octet full IPv4 address | |||
| IPv6 16 octet full IPv6 address | IPv6 16 octet full IPv6 address | |||
| 3.4.4. Hop Count TLV | 3.4.4. Hop Count TLV | |||
| skipping to change at page 42, line 18 ¶ | skipping to change at page 42, line 46 ¶ | |||
| the LSP a hop count update would need to be propagated upstream if | 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. | 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 | These updates are useless overhead since they don't reflect the hop | |||
| count to the egress. | count to the egress. | |||
| >From the perspective of the ingress node, the fact that the hop | >From the perspective of the ingress node, the fact that the hop | |||
| count is unknown implies nothing about whether a packet sent on the | 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 | 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. | 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 | 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 | check the hop count value to determine whether the hop count has | |||
| exceeded its configured maximum allowable value. If so, it MUST | exceeded its configured maximum allowable value. If so, it MUST | |||
| behave as if the containing message has traversed a loop by sending a | behave as if the containing message has traversed a loop by sending a | |||
| Notification message signaling Loop Detected in reply to the sender | Notification message signaling Loop Detected in reply to the sender | |||
| of the message. | of the message. | |||
| If Loop Detection is configured, the LSR MUST follow the procedures | If Loop Detection is configured, the LSR MUST follow the procedures | |||
| specified in Section "Loop Detection". | specified in Section "Loop Detection". | |||
| 3.4.5. Path Vector TLV | 3.4.5. Path Vector TLV | |||
| skipping to change at page 47, line 18 ¶ | skipping to change at page 48, line 14 ¶ | |||
| specifications in the sections that follow. | specifications in the sections that follow. | |||
| Optional Parameters | Optional Parameters | |||
| Variable length set of optional message parameters. Many messages | Variable length set of optional message parameters. Many messages | |||
| have no optional parameters. | have no optional parameters. | |||
| For messages that have optional parameters, the optional parame- | For messages that have optional parameters, the optional parame- | |||
| ters may appear in any order. | ters may appear in any order. | |||
| Note that there is no alignment requirement for the first octet of an | Note that there is no alignment requirement for the first octet of an | |||
| LDP message. | LDP message and that there is no padding at the end of a message; | |||
| that is, parameters can end at odd-byte boundaries. | ||||
| The following message types are defined in this version of LDP: | The following message types are defined in this version of LDP: | |||
| Message Name Section Title | Message Name Section Title | |||
| Notification "Notification Message" | Notification "Notification Message" | |||
| Hello "Hello Message" | Hello "Hello Message" | |||
| Initialization "Initialization Message" | Initialization "Initialization Message" | |||
| KeepAlive "KeepAlive Message" | KeepAlive "KeepAlive Message" | |||
| Address "Address Message" | Address "Address Message" | |||
| skipping to change at page 50, line 50 ¶ | skipping to change at page 51, line 50 ¶ | |||
| - The Message Length is too large, that is, indicates that the | - The Message Length is too large, that is, indicates that the | |||
| message extends beyond the end of the containing LDP PDU. This | message extends beyond the end of the containing LDP PDU. This | |||
| is a fatal error signaled by the Bad Message Length Status | is a fatal error signaled by the Bad Message Length Status | |||
| Code. | Code. | |||
| - The Message Length is too small, that is, smaller than the | - The Message Length is too small, that is, smaller than the | |||
| smallest possible value component. This is a fatal error sig- | smallest possible value component. This is a fatal error sig- | |||
| naled by the Bad Message Length Status Code. | naled by the Bad Message Length Status Code. | |||
| - The message is missing one or more Mandatory Parameters. This | - The message is missing one or more Mandatory Parameters. This | |||
| is a non-fatal error signalled by the Missing Message Parame- | is a non-fatal error signaled by the Missing Message Parameters | |||
| ters Status Code. | Status Code. | |||
| 3.5.1.2.2. Unknown or Malformed TLV | 3.5.1.2.2. Unknown or Malformed TLV | |||
| Malformed TLVs contained in LDP messages that are part of the LDP | Malformed TLVs contained in LDP messages that are part of the LDP | |||
| Discovery mechanism are handled by silently discarding the containing | Discovery mechanism are handled by silently discarding the containing | |||
| message. | message. | |||
| A TLV contained in an LDP message received on a TCP connection of an | A TLV contained in an LDP message received on a TCP connection of an | |||
| LDP is malformed if: | LDP is malformed if: | |||
| skipping to change at page 59, line 44 ¶ | skipping to change at page 60, line 44 ¶ | |||
| - Non-merge and VC-merge LSRs may freely interoperate. | - Non-merge and VC-merge LSRs may freely interoperate. | |||
| - The interoperability of VP-merge-capable switches with non- | - The interoperability of VP-merge-capable switches with non- | |||
| VP-merge-capable switches is a subject for future study. | VP-merge-capable switches is a subject for future study. | |||
| When the LSRs differ on the use of VP-merge, the session is | When the LSRs differ on the use of VP-merge, the session is | |||
| established, but VP merge is not used. | established, but VP merge is not used. | |||
| Note that if VP merge is used, it is the responsibility of the | Note that if VP merge is used, it is the responsibility of the | |||
| ingress node to ensure that the chosen VCI is unique within the | ingress node to ensure that the chosen VCI is unique within the | |||
| LSR domain (see [ATM-VP]). | LSR domain. | |||
| N, Number of label range components | N, Number of label range components | |||
| Specifies the number of ATM Label Range Components included in | Specifies the number of ATM Label Range Components included in | |||
| the TLV. | the TLV. | |||
| D, VC Directionality | D, VC Directionality | |||
| A value of 0 specifies bidirectional VC capability, meaning the | A value of 0 specifies bidirectional VC capability, meaning the | |||
| LSR can (within a given VPI) support the use of a given VCI as | LSR can (within a given VPI) support the use of a given VCI as | |||
| a label for both link directions independently. A value of 1 | a label for both link directions independently. A value of 1 | |||
| specifies unidirectional VC capability, meaning (within a given | specifies unidirectional VC capability, meaning (within a given | |||
| skipping to change at page 61, line 32 ¶ | skipping to change at page 62, line 32 ¶ | |||
| Virtual Connection Identifiers that is supported on the | Virtual Connection Identifiers that is supported on the | |||
| originating switch. If the VCI is less than 16-bits it | originating switch. If the VCI is less than 16-bits it | |||
| SHOULD be right justified in this field and preceding bits | SHOULD be right justified in this field and preceding bits | |||
| SHOULD be set to 0. | SHOULD be set to 0. | |||
| When peer LSRs are connected indirectly by means of an ATM VP, the | When peer LSRs are connected indirectly by means of an ATM VP, the | |||
| sending LSR SHOULD set the Minimum and Maximum VPI fields to 0, | sending LSR SHOULD set the Minimum and Maximum VPI fields to 0, | |||
| and the receiving LSR MUST ignore the Minimum and Maximum VPI | and the receiving LSR MUST ignore the Minimum and Maximum VPI | |||
| fields. | fields. | |||
| See [ATM-VP] for specification of the fields for ATM Label Range | ||||
| Components to be used with VP merge LSRs. | ||||
| Frame Relay Session Parameters | Frame Relay Session Parameters | |||
| Used when an LDP session manages label exchange for a Frame | Used when an LDP session manages label exchange for a Frame | |||
| Relay link to specify Frame Relay-specific session parameters. | Relay link to specify Frame Relay-specific session parameters. | |||
| 0 1 2 3 | 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 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| FR Sess Parms (0x0502) | Length | | |0|0| FR Sess Parms (0x0502) | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | M | N |D| Reserved | | | M | N |D| Reserved | | |||
| skipping to change at page 62, line 41 ¶ | skipping to change at page 63, line 41 ¶ | |||
| Non-merge and merge Frame Relay LSRs may freely interoperate. | Non-merge and merge Frame Relay LSRs may freely interoperate. | |||
| N, Number of label range components Specifies the number of Frame | N, Number of label range components Specifies the number of Frame | |||
| Relay Label Range Components included in the TLV. | Relay Label Range Components included in the TLV. | |||
| D, VC Directionality | D, VC Directionality | |||
| A value of 0 specifies bidirectional VC capability, meaning the | A value of 0 specifies bidirectional VC capability, meaning the | |||
| LSR can support the use of a given DLCI as a label for both | LSR can support the use of a given DLCI as a label for both | |||
| link directions independently. A value of 1 specifies unidi- | link directions independently. A value of 1 specifies unidi- | |||
| rectional VC capability, meaning a given DLCI may appear in a | rectional VC capability, meaning a given DLCI may appear in a | |||
| label mapping for one direction on the link only. Wheneither | label mapping for one direction on the link only. When either | |||
| or both of the peers specifies unidirectional VC capability, | or both of the peers specifies unidirectional VC capability, | |||
| both LSRs use unidirectional VC label assignment for the link | both LSRs use unidirectional VC label assignment for the link | |||
| as follows. The LSRs compare their LDP Identifiers as unsigned | as follows. The LSRs compare their LDP Identifiers as unsigned | |||
| integers. The LSR with the larger LDP Identifier may assign | integers. The LSR with the larger LDP Identifier may assign | |||
| only odd-numbered DLCIs in the range as labels. The system | only odd-numbered DLCIs in the range as labels. The system | |||
| with the smaller LDP Identifier may assign only even-numbered | with the smaller LDP Identifier may assign only even-numbered | |||
| DLCIs in the range as labels. | DLCIs in the range as labels. | |||
| Reserved | Reserved | |||
| This field is reserved. It MUST be set to zero on transmission | This field is reserved. It MUST be set to zero on transmission | |||
| skipping to change at page 64, line 46 ¶ | skipping to change at page 65, line 46 ¶ | |||
| No optional parameters are defined for the KeepAlive message. | No optional parameters are defined for the KeepAlive message. | |||
| 3.5.4.1. KeepAlive Message Procedures | 3.5.4.1. KeepAlive Message Procedures | |||
| The KeepAlive Timer mechanism described in Section "Maintaining LDP | The KeepAlive Timer mechanism described in Section "Maintaining LDP | |||
| Sessions" resets a session KeepAlive timer every time an LDP PDU is | Sessions" resets a session KeepAlive timer every time an LDP PDU is | |||
| received on the session TCP connection. The KeepAlive Message is | received on the session TCP connection. The KeepAlive Message is | |||
| provided to allow reset of the KeepAlive Timer in circumstances where | provided to allow reset of the KeepAlive Timer in circumstances where | |||
| an LSR has no other information to communicate to an LDP peer. | an LSR has no other information to communicate to an LDP peer. | |||
| An LSR must arrange that its peer receive an LDP Message from it at | An LSR MUST arrange that its peer receive an LDP Message from it at | |||
| least every KeepAlive Time period. Any LDP protocol message will do | least every KeepAlive Time period. Any LDP protocol message will do | |||
| but, in circumstances where no other LDP protocol messages have been | but, in circumstances where no other LDP protocol messages have been | |||
| sent within the period, a KeepAlive message MUST be sent. | sent within the period, a KeepAlive message MUST be sent. | |||
| 3.5.5. Address Message | 3.5.5. Address Message | |||
| An LSR sends the Address Message to an LDP peer to advertise its | An LSR sends the Address Message to an LDP peer to advertise its | |||
| interface addresses. | interface addresses. | |||
| The encoding for the Address Message is: | The encoding for the Address Message is: | |||
| skipping to change at page 65, line 32 ¶ | skipping to change at page 66, line 32 ¶ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Optional Parameters | | | Optional Parameters | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message ID | Message ID | |||
| 32-bit value used to identify this message. | 32-bit value used to identify this message. | |||
| Address List TLV | Address List TLV | |||
| The list of interface addresses being advertised by the sending | The list of interface addresses being advertised by the sending | |||
| LSR. The encoding for the Address List TLV is specified in Section | LSR. The encoding for the Address List TLV is specified in | |||
| "Address List TLV". | Section "Address List TLV". | |||
| Optional Parameters | Optional Parameters | |||
| No optional parameters are defined for the Address message. | No optional parameters are defined for the Address message. | |||
| 3.5.5.1. Address Message Procedures | 3.5.5.1. Address Message Procedures | |||
| An LSR that receives an Address Message message uses the addresses it | An LSR that receives an Address Message message uses the addresses it | |||
| learns to maintain a database for mapping between peer LDP Identi- | learns to maintain a database for mapping between peer LDP Identi- | |||
| fiers and next hop addresses; see Section "LDP Identifiers and Next | fiers and next hop addresses; see Section "LDP Identifiers and Next | |||
| Hop Addresses". | Hop Addresses". | |||
| skipping to change at page 67, line 21 ¶ | skipping to change at page 68, line 21 ¶ | |||
| See Section "Address Message Procedures" | See Section "Address Message Procedures" | |||
| 3.5.7. Label Mapping Message | 3.5.7. Label Mapping Message | |||
| An LSR sends a Label Mapping message to an LDP peer to advertise FEC- | An LSR sends a Label Mapping message to an LDP peer to advertise FEC- | |||
| label bindings to the peer. | label bindings to the peer. | |||
| The encoding for the Label Mapping Message is: | The encoding for the Label Mapping Message is: | |||
| 0 1 2 3 | 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 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| Label Mapping (0x0400) | Message Length | | |0| Label Mapping (0x0400) | Message Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Message ID | | | Message ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | FEC TLV | | | FEC TLV | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Label TLV | | | Label TLV | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Optional Parameters | | | Optional Parameters | | |||
| skipping to change at page 79, line 36 ¶ | skipping to change at page 80, line 36 ¶ | |||
| optional Label TLV in the Label Release message, then the sending LSR | optional Label TLV in the Label Release message, then the sending LSR | |||
| is releasing all label mappings previously learned from the receiving | is releasing all label mappings previously learned from the receiving | |||
| LSR. | LSR. | |||
| See Appendix A "LDP Label Distribution Procedures" for more details. | See Appendix A "LDP Label Distribution Procedures" for more details. | |||
| 3.6. Messages and TLVs for Extensibility | 3.6. Messages and TLVs for Extensibility | |||
| Support for LDP extensibility includes the rules for the U and F bits | Support for LDP extensibility includes the rules for the U and F bits | |||
| that specify how an LSR should handle unknown TLVs and messages. | that specify how an LSR handles unknown TLVs and messages. | |||
| This section specifies TLVs and messages for vendor-private and | This section specifies TLVs and messages for vendor-private and | |||
| experimental use. | experimental use. | |||
| 3.6.1. LDP Vendor-private Extensions | 3.6.1. LDP Vendor-private Extensions | |||
| Vendor-private TLVs and messages are used to convey vendor-private | Vendor-private TLVs and messages are used to convey vendor-private | |||
| information between LSRs. | information between LSRs. | |||
| 3.6.1.1. LDP Vendor-private TLVs | 3.6.1.1. LDP Vendor-private TLVs | |||
| skipping to change at page 80, line 32 ¶ | skipping to change at page 81, line 32 ¶ | |||
| U bit | U bit | |||
| Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear | Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear | |||
| (=0), a notification MUST be returned to the message originator | (=0), a notification MUST be returned to the message originator | |||
| and the entire message MUST be ignored; if U is set (=1), the | and the entire message MUST be ignored; if U is set (=1), the | |||
| unknown TLV is silently ignored and the rest of the message is | unknown TLV is silently ignored and the rest of the message is | |||
| processed as if the unknown TLV did not exist. | processed as if the unknown TLV did not exist. | |||
| The determination as to whether a vendor-private message is under- | The determination as to whether a vendor-private message is under- | |||
| stood is based on the Type and the mandatory Vendor ID field. | stood is based on the Type and the mandatory Vendor ID field. | |||
| Implementations that support vendor-private TLVs MUST support a | ||||
| user-accessible configuration interface that causes the U-bit to | ||||
| be set on all transmitted vendor-private TLVs; this requirement | ||||
| MAY be satisfied by a user-accessible configuration interface that | ||||
| prevents transmission of all vendor-private TLVs for which the U- | ||||
| bit is clear. | ||||
| F bit | F bit | |||
| Forward unknown TLV bit. This bit only applies when the U bit is | Forward unknown TLV bit. This bit only applies when the U bit is | |||
| set and the LDP message containing the unknown TLV is is to be | set and the LDP message containing the unknown TLV is is to be | |||
| forwarded. If F is clear (=0), the unknown TLV is not forwarded | 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 | with the containing message; if F is set (=1), the unknown TLV is | |||
| forwarded with the containing message. | forwarded with the containing message. | |||
| Type | Type | |||
| Type value in the range 0x3E00 through 0x3EFF. Together, the Type | Type value in the range 0x3E00 through 0x3EFF. Together, the Type | |||
| and Vendor Id field specify how the Data field is to be inter- | and Vendor Id field specify how the Data field is to be inter- | |||
| skipping to change at page 81, line 40 ¶ | skipping to change at page 82, line 47 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| U bit | U bit | |||
| Unknown message bit. Upon receipt of an unknown message, if U is | Unknown message bit. Upon receipt of an unknown message, if U is | |||
| clear (=0), a notification is returned to the message originator; | clear (=0), a notification is returned to the message originator; | |||
| if U is set (=1), the unknown message is silently ignored. | if U is set (=1), the unknown message is silently ignored. | |||
| The determination as to whether a vendor-private message is under- | The determination as to whether a vendor-private message is under- | |||
| stood is based on the Msg Type and the Vendor ID parameter. | stood is based on the Msg Type and the Vendor ID parameter. | |||
| Implementations that support vendor-private messages MUST support | ||||
| a user-accessible configuration interface that causes the U-bit to | ||||
| be set on all transmitted vendor-private messages; this require- | ||||
| ment MAY be satisfied by a user-accessible configuration interface | ||||
| that prevents transmission of all vendor-private messages for | ||||
| which the U-bit is clear. | ||||
| Msg Type | Msg Type | |||
| Message type value in the range 0x3E00 through 0x3EFF. Together, | Message type value in the range 0x3E00 through 0x3EFF. Together, | |||
| the Msg Type and the Vendor ID specify how the message is to be | the Msg Type and the Vendor ID specify how the message is to be | |||
| interpreted. | interpreted. | |||
| Message Length | Message Length | |||
| Specifies the cumulative length in octets of the Message ID, Ven- | Specifies the cumulative length in octets of the Message ID, Ven- | |||
| dor ID, Remaining Mandatory Parameters and Optional Parameters. | dor ID, Remaining Mandatory Parameters and Optional Parameters. | |||
| Message ID | Message ID | |||
| skipping to change at page 85, line 15 ¶ | skipping to change at page 86, line 30 ¶ | |||
| 3.10. Well-known Numbers | 3.10. Well-known Numbers | |||
| 3.10.1. UDP and TCP Ports | 3.10.1. UDP and TCP Ports | |||
| The UDP port for LDP Hello messages is 646. | The UDP port for LDP Hello messages is 646. | |||
| The TCP port for establishing LDP session connections is 646. | The TCP port for establishing LDP session connections is 646. | |||
| 3.10.2. Implicit NULL Label | 3.10.2. Implicit NULL Label | |||
| The Implicit NULL label (see [RFC3031]) is represented as a Generic | The Implicit NULL label is defined in [RFC3031] as follows: | |||
| Label TLV with a Label field value as specified by [RFC3032]. | ||||
| "The Implicit NULL label is a label with special semantics which an | ||||
| LSR can bind to an address prefix. If LSR Ru, by consulting its ILM | ||||
| (Incoming Label Map) sees that labeled packet P must be forwarded | ||||
| next to Rd, but that Rd has distributed a binding of Implicit NULL to | ||||
| the corresponding address prefix, then instead of replacing the value | ||||
| of the label on top of the label stack, Ru pops the label stack, and | ||||
| then forwards the resulting packet to Rd." | ||||
| The implicit NULL label is represented in LDP as a Generic Label TLV | ||||
| with a Label field value of 3, as defined in [RFC3032]. | ||||
| 4. IANA Considerations | 4. IANA Considerations | |||
| LDP defines the following name spaces which require management: | LDP defines the following name spaces which require management: | |||
| - Message Type Name Space. | - Message Type Name Space. | |||
| - TLV Type Name Space. | - TLV Type Name Space. | |||
| - FEC Type Name Space. | - FEC Type Name Space. | |||
| - Status Code Name Space. | - Status Code Name Space. | |||
| - Experiment ID Name Space. | - Experiment ID Name Space. | |||
| skipping to change at page 87, line 36 ¶ | skipping to change at page 89, line 17 ¶ | |||
| This section identifies threats to which LDP may be vulnerable and | This section identifies threats to which LDP may be vulnerable and | |||
| discusses means by which those threats might be mitigated. | discusses means by which those threats might be mitigated. | |||
| 5.1. Spoofing | 5.1. Spoofing | |||
| There are two types of LDP communication that could be the target of | There are two types of LDP communication that could be the target of | |||
| a spoofing attack. | a spoofing attack. | |||
| 1. Discovery exchanges carried by UDP. | 1. Discovery exchanges carried by UDP. | |||
| LSRs indicate their willingness to establish and maintain LDP ses- | ||||
| sions by periodically sending Hello messages. Receipt of a Hello | ||||
| serves to create a new "Hello adjacency", if one does not already | ||||
| exist, or to refresh an existing one. Spoofing a Hello packet for | ||||
| an existing adjacency can cause the adjacency to time out and that | ||||
| can result in termination of the associated session. This can | ||||
| occur when the spoofed Hello specifies a small Hold Time, causing | ||||
| the receiver to expect Hellos within this interval, while the true | ||||
| neighbor continues sending Hellos at the lower, previously agreed | ||||
| to, frequency. | ||||
| LSRs directly connected at the link level exchange Basic Hello | LSRs directly connected at the link level exchange Basic Hello | |||
| messages over the link. The threat of spoofed Basic Hellos can be | messages over the link. The threat of spoofed Basic Hellos can be | |||
| reduced by: | reduced by: | |||
| o Accepting Basic Hellos only on interfaces to which LSRs that | o Accepting Basic Hellos only on interfaces to which LSRs that | |||
| can be trusted are directly connected. | can be trusted are directly connected. | |||
| o Ignoring Basic Hellos not addressed to the All Routers on | o Ignoring Basic Hellos not addressed to the All Routers on | |||
| this Subnet multicast group. | this Subnet multicast group. | |||
| skipping to change at page 89, line 47 ¶ | skipping to change at page 91, line 30 ¶ | |||
| 2. Well known TCP port for LDP Session Establishment | 2. Well known TCP port for LDP Session Establishment | |||
| Like other control plane protocols that use TCP, LDP may be the | Like other control plane protocols that use TCP, LDP may be the | |||
| target of DoS attacks, such a SYN attacks. LDP is no more or less | target of DoS attacks, such a SYN attacks. LDP is no more or less | |||
| vulnerable to such attacks than other control plane protocols that | vulnerable to such attacks than other control plane protocols that | |||
| use TCP. | use TCP. | |||
| The threat of such attacks can be mitigated somewhat by the fol- | The threat of such attacks can be mitigated somewhat by the fol- | |||
| lowing: | lowing: | |||
| o An LSR should avoid promiscuous TCP listens for LDP session | o An LSR SHOULD avoid promiscuous TCP listens for LDP session | |||
| establishment. It should use only listens that are specific | establishment. It SHOULD use only listens that are specific | |||
| to discovered peers. This enables it to drop attack packets | to discovered peers. This enables it to drop attack packets | |||
| early in their processing since they are less likely to | early in their processing since they are less likely to | |||
| match existing or in-progress connections. | match existing or in-progress connections. | |||
| o The use of the MD5 option helps somewhat since it prevents a | o The use of the MD5 option helps somewhat since it prevents a | |||
| SYN from being accepted unless the MD5 segment checksum is | SYN from being accepted unless the MD5 segment checksum is | |||
| valid. However, the receiver must compute the checksum | valid. However, the receiver must compute the checksum | |||
| before it can decide to discard an otherwise acceptable SYN | before it can decide to discard an otherwise acceptable SYN | |||
| segment. | segment. | |||
| skipping to change at page 90, line 30 ¶ | skipping to change at page 92, line 19 ¶ | |||
| - Section 2.16 of the MPLS architecture [RFC3031] requires that | - Section 2.16 of the MPLS architecture [RFC3031] requires that | |||
| the initial label distribution protocol negotiation between | the initial label distribution protocol negotiation between | |||
| peer LSRs enable each LSR to determine whether its peer is | peer LSRs enable each LSR to determine whether its peer is | |||
| capable of popping the label stack. This version of LDP | capable of popping the label stack. This version of LDP | |||
| assumes that LSRs support label popping for all link types | assumes that LSRs support label popping for all link types | |||
| except ATM and Frame Relay. A future version may specify means | except ATM and Frame Relay. A future version may specify means | |||
| to make this determination part of the session initiation nego- | to make this determination part of the session initiation nego- | |||
| tiation. | tiation. | |||
| - LDP support for CoS is not specified in this version. CoS sup- | - LDP support for CoS (class of service) is not specified in this | |||
| port may be addressed in a future version. | version. CoS support may be addressed in a future version. | |||
| - LDP support for multicast is not specified in this version. | - LDP support for multicast is not specified in this version. | |||
| Multicast support may be addressed in a future version. | Multicast support may be addressed in a future version. | |||
| - LDP support for multipath label switching is not specified in | - LDP support for multipath label switching is not specified in | |||
| this version. Multipath support may be addressed in a future | this version. Multipath support may be addressed in a future | |||
| version. | version. | |||
| - LDP support for signalling the maximum transmission unit is not | - LDP support for signalling the maximum transmission unit is not | |||
| specified in this version. It is discussed in the experimental | specified in this version. It is discussed in the experimental | |||
| skipping to change at page 91, line 41 ¶ | skipping to change at page 93, line 28 ¶ | |||
| for a separate document. | for a separate document. | |||
| 7. Changes from RFC3036 | 7. Changes from RFC3036 | |||
| Here is a list of changes from RFC3036 | Here is a list of changes from RFC3036 | |||
| 1. Removed the Host Address FEC and references to it, since it is | 1. Removed the Host Address FEC and references to it, since it is | |||
| not used by any implementation. | not used by any implementation. | |||
| 2. Split the reference list into normative and non-normative ref- | 2. Split the reference list into normative and non-normative ref- | |||
| erences | erences | |||
| 3. Removed "MPLS using ATM VP Switching" from the list of norma- | 3. Removed "MPLS using ATM VP Switching" from the list of norma- | |||
| tive references. | tive references, and references to it. | |||
| 4. Clarified the use of the F bit. | 4. Removed reference to RFC 1700 and replaced it with a link to | |||
| 5. Added option to allow split horizon when doing ordered control. | http://www.iana.org/assignments/address-family-numbers. | |||
| 6. Clarified the processing of messages with the U-bit set during | 5. Removed reference to RFC 1771 and replaced it with a reference | |||
| to RFC 4271. | ||||
| 6. Clarified the use of the F bit. | ||||
| 7. Added option to allow split horizon when doing ordered control. | ||||
| 8. Clarified the processing of messages with the U-bit set during | ||||
| the session initialization procedures | the session initialization procedures | |||
| 7. Clarified the processing of the E-bit during session initial- | 9. Clarified the processing of the E-bit during session initial- | |||
| ization procedures. | ization procedures. | |||
| 8. Added text explaining that the shutdown message in the state | 10. Added text explaining that the shutdown message in the state | |||
| transition diagram is implemented as as a notification message | transition diagram is implemented as as a notification message | |||
| with a status TLV indicating a fatal error. | with a status TLV indicating a fatal error. | |||
| 11. Added case for TLV length too short in the specification for | ||||
| 9. Added case for TLV length too short in the specification for | ||||
| handling malformed TLVs. | handling malformed TLVs. | |||
| 10. In the section describing handling of unknown TLV, removed ref- | 12. Explained the security threat posed by hello spoofing. | |||
| erence to inexistent section (errata in original document) | 13. Added reference to 4271 and 4278 and text for standards matu- | |||
| 11. In the "receive label request" procedures, if a loop is | rity variance with regards to the MD5 option. | |||
| 14. Added text from 3031 explaining the handling of implicit NULL | ||||
| label. | ||||
| 15. Included the encoding of DLCIs to remove normative reference to | ||||
| 3034. | ||||
| 16. Moved references to 3031, 3032 and 3034 to informative. | ||||
| 17. In the section describing handling of unknown TLV, removed ref- | ||||
| erence to inexistent section (errata in original document). | ||||
| 18. Added text clarifying how to achieve interoperability when | ||||
| sending vendor-private TLVs and messages. | ||||
| 19. In the "receive label request" procedures, if a loop is | ||||
| detected, changed the procedure to send a notification before | detected, changed the procedure to send a notification before | |||
| aborting the rest of the processing. | aborting the rest of the processing. | |||
| 12. In "receive label release" procedures, clarified the behavior | 20. In "receive label release" procedures, clarified the behavior | |||
| for merge-capable LSRs. | for merge-capable LSRs. | |||
| 13. In "receive label release" procedures, clarified the behavior | 21. In "receive label release" procedures, clarified the behavior | |||
| for receipt of an unknown FEC. | for receipt of an unknown FEC. | |||
| 14. In note 4 of "Detect Change in FEC Next Hop", modified the text | 22. In note 4 of "Detect Change in FEC Next Hop", modified the text | |||
| to reference the correct set of conditions for sending a label | to reference the correct set of conditions for sending a label | |||
| request procedure (typo in the original document). | request procedure (typo in the original document). | |||
| 15. In the procedures for "LSR decides to no longer label switch a | 23. In the procedures for "LSR decides to no longer label switch a | |||
| FEC", clarified the fact that the label must not be reused | FEC", clarified the fact that the label must not be reused | |||
| until a label release is received. | until a label release is received. | |||
| 16. In the routine "Prepare_Label_Mapping_Attributes" added a note | 24. In the routine "Prepare_Label_Mapping_Attributes" added a note | |||
| regarding the treatment of unknown TLVs according to their U | regarding the treatment of unknown TLVs according to their U | |||
| and F bits. | and F bits. | |||
| 17. In the address message processing procedures, clarified the | 25. In the address message processing procedures, clarified the | |||
| behavior for the case where an LSR receives re-advertisement of | behavior for the case where an LSR receives re-advertisement of | |||
| an address previously advertised it, or withdrawal of an | an address previously advertised it, or withdrawal of an | |||
| address from an LSR that has not previously advertised that | address from an LSR that has not previously advertised that | |||
| address. | address. | |||
| 18. In the routine "Receive Label Mapping" clarified the meaning of | 26. In the routine "Receive Label Mapping" clarified the meaning of | |||
| PrevAdvLabel when no label advertisement message has been sent | PrevAdvLabel when no label advertisement message has been sent | |||
| previously. | previously. | |||
| 19. In the "receive label mapping" procedures, if a loop is | 27. In the "Receive Label Mapping" procedures, if a loop is | |||
| detected, modified the procedure to send a notification before | detected, modified the procedure to send a notification before | |||
| aborting the rest of the processing. | aborting the rest of the processing. | |||
| 20. In the "receive label mapping" procedures, corrected step | 28. In the "Receive Label Mapping" procedures, corrected step | |||
| LMp.10 to handle label mapping messages for additional (non- | LMp.10 to handle label mapping messages for additional (non- | |||
| merged) LSPs for the FEC. | merged) LSPs for the FEC. | |||
| 21. In the routine "Receive Label Abort Request" clarified the | 29. In the "Receive Label Mapping" procedures, clarified behavior | |||
| when receiving a duplicate label for the same FEC. | ||||
| 30. In the routine "Receive Label Abort Request" clarified the | ||||
| behavior for non-merging LSRs. | behavior for non-merging LSRs. | |||
| 22. Added the following items to the section discussing areas for | 31. Added the following items to the section discussing areas for | |||
| future study: | future study: | |||
| o extensions for communicating the maximum transmission unit | o extensions for communicating the maximum transmission unit | |||
| o basic peer discovery on NBMA media | o basic peer discovery on NBMA media | |||
| o option of shutting down an adjacency | o option of shutting down an adjacency | |||
| o mechanisms for securing Hello messages | o mechanisms for securing Hello messages | |||
| o detection of a stateless fast control plane restart | o detection of a stateless fast control plane restart | |||
| o support of "end of LIB" message | o support of "end of LIB" message | |||
| o mechanisms for dealing with the case where different LSRs advertise | o mechanisms for dealing with the case where different LSRs | |||
| the same address. | advertise the same address. | |||
| 8. Acknowledgments | 8. Acknowledgments | |||
| This document was originally published as RFC 3036 in January 2001. | This document was originally published as RFC 3036 in January 2001. | |||
| It was produced by the MPLS working of the IETF and was jointly | It was produced by the MPLS working of the IETF and was jointly | |||
| authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette | authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette | |||
| and Bob Thomas. | and Bob Thomas. | |||
| The ideas and text in RFC3036 were collected from a number of | The ideas and text in RFC3036 were collected from a number of | |||
| sources. We would like to thank Rick Boivie, Ross Callon, Alex | sources. We would like to thank Rick Boivie, Ross Callon, Alex | |||
| Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov | Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov | |||
| Rekhter, and Arun Viswanathan for their input for RFC3036. | Rekhter, and Arun Viswanathan for their input for RFC3036. | |||
| The editors would like to thank Eric Gray for his insight and input | The editors would like to thank Eric Gray, David Black and Sam Hart- | |||
| to the current document. | man for their input to and review of the current document. | |||
| In addition, the editors would like to thank the members of the mpls | In addition, the editors would like to thank the members of the mpls | |||
| working group for their ideas and the support they have given to this | working group for their ideas and the support they have given to this | |||
| document, and in particular to Eric Rosen, Luca Martini, Markus Jork, | document, and in particular to Eric Rosen, Luca Martini, Markus Jork, | |||
| Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan, | Mark Duffy, Vach Kompella, Kishore Tiruveedhula. Rama Ramakrishnan, | |||
| Nick Weeds and Adrian Farrel. | Nick Weeds, Adrian Farrel and Andy Malis. | |||
| 9. References | 9. References | |||
| 9.1. Normative references | 9.1. Normative references | |||
| [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 2434, | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |||
| October 1998. | October 1998. | |||
| [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, | |||
| April 1992. | April 1992. | |||
| [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap- | [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adap- | |||
| tation Layer 5", RFC 1483, July 1993. | tation Layer 5", RFC 1483, July 1993. | |||
| [RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, | [ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers | |||
| RFC 1700, October 1994. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol | [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP | |||
| Label Switching Architecture", RFC 3031, January 2001. | MD5 Signature Option", RFC 2385, August 1998. | |||
| [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., | ||||
| Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack | ||||
| Encoding", RFC 3032, January 2001. | ||||
| [RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switch- | ||||
| ing on Frame Relay Networks Specification", RFC 3034, | ||||
| January 2001. | ||||
| [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., | [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., | |||
| Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and | Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and | |||
| ATM VC Switching", RFC 3035, January 2001. | ATM VC Switching", RFC 3035, January 2001. | |||
| [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, | [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, | |||
| January 2001. | January 2001. | |||
| 9.2. Non-normative references | 9.2. Non-normative references | |||
| [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. | ||||
| Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional | ||||
| Specification", RFC 2205, September 1997. | ||||
| [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP | ||||
| MD5 Signature Option", RFC 2385, August 1998. | ||||
| [CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. | [CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. | |||
| Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. | Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. | |||
| G. Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R. | E. Kilty, A. G. Malis, M. Girish, K. Sundell, P. Vaana- | |||
| Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002 | nen, T. Worster, L. Wu, R. Dantu, "Constraint-Based LSP | |||
| Setup using LDP", RFC 3212, January 2002 | ||||
| [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. | [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. | |||
| and W. Weiss, "An Architecture for Differentiated Services", RFC | and W. Weiss, "An Architecture for Differentiated Ser- | |||
| 2475, December 1998. | vices", RFC 2475, December 1998. | |||
| [LDP-MTU] Black, B. and Kompella, K. "Maximum Transmission Unit Sig- | [LDP-MTU] Black, B. and Kompella, K. "Maximum Transmission Unit | |||
| nalling Extensions for the Label Distribution Protocol", draft-ietf- | Signalling Extensions for the Label Distribution Proto- | |||
| mpls-ldp-mtu-extensions-03.txt, April 2004. | col", draft-ietf-mpls-ldp-mtu-extensions-03.txt, April | |||
| 2004. | ||||
| [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 | [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. | |||
| (BGP-4)", RFC 1771, March 1995. | ||||
| Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | ||||
| Functional Specification", RFC 2205, September 1997. | ||||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | ||||
| [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. | [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. | |||
| McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, | McManus, "Requirements for Traffic Engineering over | |||
| September 1999. | MPLS", RFC 2702, September 1999. | |||
| [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol | ||||
| Label Switching Architecture", RFC 3031, January 2001. | ||||
| [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., | ||||
| Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack | ||||
| Encoding", RFC 3032, January 2001. | ||||
| [RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switch- | ||||
| ing on Frame Relay Networks Specification", RFC 3034, | ||||
| January 2001. | ||||
| [RFC4271] Rekhter, Y., Li, T. and Hares, S. "A Border Gateway Pro- | ||||
| tocol 4 (BGP-4)", RFC 4271, January 2006. | ||||
| [RFC4278] Bellovin, S., Zinin, A., "Standards Maturity Variance | ||||
| Regarding the TCP MD5 Signature Option (RFC 2385) and the | ||||
| BGP-4 Specification", RFC 4278, January 2006. | ||||
| 10. Intellectual Property Statement | 10. Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| skipping to change at page 104, line 22 ¶ | skipping to change at page 107, line 22 ¶ | |||
| LMp.9 Does LSR have a previously received label mapping for FEC | LMp.9 Does LSR have a previously received label mapping for FEC | |||
| from MsgSource for the LSP in question? (See Note 6.) | from MsgSource for the LSP in question? (See Note 6.) | |||
| If not, goto LMp.11. | If not, goto LMp.11. | |||
| LMp.10 Does the label previously received from MsgSource match | LMp.10 Does the label previously received from MsgSource match | |||
| Label (i.e., the label received in the message)? | Label (i.e., the label received in the message)? | |||
| (See Note 3.) | (See Note 3.) | |||
| OR | OR | |||
| Is the received label mapping in response to a previously | Is the received label mapping in response to a previously | |||
| outstanding label request sent to MsgSource? (See Note 12). | outstanding label request sent to MsgSource? | |||
| (See Note 12.) | ||||
| If so, goto LMp.11. | If so, goto LMp.11. | |||
| LMp.10a Is LSR operating in Downstream Unsolicited mode with Liberal | LMp.10a Is LSR operating in Downstream Unsolicited mode? | |||
| Label retention? | If so, delete the label mapping for the label previously | |||
| If not, goto LMp.32. (See Note 4.) | received from MsgSource and remove it from | |||
| forwarding/switching use. | ||||
| Execute procedure Send_Message (MsgSource, Label Release, | ||||
| FEC, label previously received from MsgSource). | ||||
| LMp.11 Determine the Next Hop for FEC. | LMp.11 Determine the Next Hop for FEC. | |||
| LMp.12 Is MsgSource the Next Hop for FEC? | LMp.12 Is MsgSource the Next Hop for FEC? | |||
| If so, goto LMp.14. | If so, goto LMp.14. | |||
| LMp.13 Perform LSR Label Release procedure: | LMp.13 Perform LSR Label Release procedure: | |||
| For Conservative Label retention: | For Conservative Label retention: | |||
| skipping to change at page 105, line 20 ¶ | skipping to change at page 108, line 25 ¶ | |||
| LMp.19 Is the Downstream Unsolicited Ordered Control Label | LMp.19 Is the Downstream Unsolicited Ordered Control Label | |||
| Distribution procedure being used by LSR? | Distribution procedure being used by LSR? | |||
| If not, goto LMp.28. | If not, goto LMp.28. | |||
| LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, | LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, | |||
| FEC, RAttributes, SAttributes, IsPropagating, | FEC, RAttributes, SAttributes, IsPropagating, | |||
| StoredHopCount). | StoredHopCount). | |||
| LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, | LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, | |||
| PrevAdvLabel, SAttributes). (See note 13.) | PrevAdvLabel, SAttributes). (See Note 13.) | |||
| Goto LMp.28 | Goto LMp.28 | |||
| LMp.22 Iterate through LMp.27 for each label mapping for FEC | LMp.22 Iterate through LMp.27 for each label mapping for FEC | |||
| previously sent to Peer. | previously sent to Peer. | |||
| LMp.23 Are RAttributes in the received label mapping consistent | LMp.23 Are RAttributes in the received label mapping consistent | |||
| with those previously sent to Peer? | with those previously sent to Peer? | |||
| If so, continue iteration from LMp.22 for next label | If so, continue iteration from LMp.22 for next label | |||
| mapping. (See Note 9.) | mapping. (See Note 9.) | |||
| skipping to change at page 109, line 43 ¶ | skipping to change at page 112, line 47 ¶ | |||
| LAbR.5 Does LSR have a label mapping for FEC? | LAbR.5 Does LSR have a label mapping for FEC? | |||
| If not, goto LAbR.11 | If not, goto LAbR.11 | |||
| LAbR.6 Generate Event: Received Label Release Message for FEC | LAbR.6 Generate Event: Received Label Release Message for FEC | |||
| from MsgSource. (See Note 2.) | from MsgSource. (See Note 2.) | |||
| Goto LAbR.11. | Goto LAbR.11. | |||
| LAbR.7 Is LSR merging the LSP for FEC? | LAbR.7 Is LSR merging the LSP for FEC? | |||
| If not, goto LAbR.9. | If not, goto LAbR.9. | |||
| LAbR.8 Are there outstanding label requrests for this FEC? | LAbR.8 Are there outstanding label requests for this FEC? | |||
| If so, goto LAbR.11. | If so, goto LAbR.11. | |||
| LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort | LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort | |||
| Request, FEC, TLV), where TLV is a Label Request Message | Request, FEC, TLV), where TLV is a Label Request Message | |||
| ID TLV containing the Message ID used by the LSR in the | ID TLV containing the Message ID used by the LSR in the | |||
| outstanding Label Request message. | outstanding Label Request message. | |||
| LAbR.10 Record that a label abort request for FEC is pending. | LAbR.10 Record that a label abort request for FEC is pending. | |||
| LAbR.11 Delete record of label request for FEC from MsgSource. | LAbR.11 Delete record of label request for FEC from MsgSource. | |||
| skipping to change at page 111, line 8 ¶ | skipping to change at page 114, line 12 ¶ | |||
| LRl.3 Does message match an outstanding label withdraw for FEC | LRl.3 Does message match an outstanding label withdraw for FEC | |||
| previously sent to MsgSource? | previously sent to MsgSource? | |||
| If not, goto LRl.5 | If not, goto LRl.5 | |||
| LRl.4 Delete record of outstanding label withdraw for FEC | LRl.4 Delete record of outstanding label withdraw for FEC | |||
| previously sent to MsgSource. | previously sent to MsgSource. | |||
| LRl.5 Is LSR merging labels for this FEC? | LRl.5 Is LSR merging labels for this FEC? | |||
| If not, goto LRl.7. (See Note 2.) | If not, goto LRl.7. (See Note 2.) | |||
| LRl.6 Does LSR have outstanding label advertisements for this FEC? | LRl.6 Does LSR have outstanding label advertisements for this | |||
| If so, goto LRl.11. | FEC? If so, goto LRl.11. | |||
| LRl.7 Is LSR egress for the FEC? | LRl.7 Is LSR egress for the FEC? | |||
| If so, goto LRl.11 | If so, goto LRl.11 | |||
| LRl.8 Is there a Next Hop for FEC? AND | LRl.8 Is there a Next Hop for FEC? AND | |||
| Does LSR have a previously received label mapping for FEC | Does LSR have a previously received label mapping for FEC | |||
| from Next Hop? | from Next Hop? | |||
| If not, goto LRl.11. | If not, goto LRl.11. | |||
| LRl.9 Is LSR configured to propagate releases? | LRl.9 Is LSR configured to propagate releases? | |||
| skipping to change at page 123, line 32 ¶ | skipping to change at page 127, line 10 ¶ | |||
| 1. Iteration ResA.5 through ResA.8 handles the situation where the | 1. Iteration ResA.5 through ResA.8 handles the situation where the | |||
| LSR is using Downstream Unsolicited label distribution and was | LSR is using Downstream Unsolicited label distribution and was | |||
| previously unable to allocate a label for a FEC. | previously unable to allocate a label for a FEC. | |||
| A.1.14. LSR decides to no longer label switch a FEC | A.1.14. LSR decides to no longer label switch a FEC | |||
| Summary: | Summary: | |||
| An LSR may unilaterally decide to no longer label switch a FEC for | An LSR may unilaterally decide to no longer label switch a FEC for | |||
| an LDP peer. An LSR that does so MUST send a label withdraw message | an LDP peer. An LSR that does so MUST send a label withdraw | |||
| for the FEC to the peer. | message for the FEC to the peer. | |||
| Context: | Context: | |||
| - Peer. The peer. | - Peer. The peer. | |||
| - FEC. The FEC. | - FEC. The FEC. | |||
| - PrevAdvLabel. The label for FEC previously advertised to Peer. | - PrevAdvLabel. The label for FEC previously advertised to Peer. | |||
| Algorithm: | Algorithm: | |||
| skipping to change at page 124, line 10 ¶ | skipping to change at page 127, line 33 ¶ | |||
| NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, | NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, | |||
| PrevAdvLabel). (See Note 1.) | PrevAdvLabel). (See Note 1.) | |||
| NoLS.2 DONE. | NoLS.2 DONE. | |||
| Notes: | Notes: | |||
| 1. The LSR may remove the label from forwarding/switching use as | 1. The LSR may remove the label from forwarding/switching use as | |||
| part of this event or as part of processing the label release | part of this event or as part of processing the label release | |||
| from the peer in response to the label withdraw. If the LSR | from the peer in response to the label withdraw. If the LSR | |||
| doesn't wait for the label reelase message from the peer it | doesn't wait for the label release message from the peer it | |||
| SHOULD NOT reuse the label until it receives the label release. | SHOULD NOT reuse the label until it receives the label release. | |||
| A.1.15. Timeout of deferred label request | A.1.15. Timeout of deferred label request | |||
| Summary: | Summary: | |||
| Label requests are deferred in response to No Route and Loop | Label requests are deferred in response to No Route and Loop | |||
| Detected notifications. When a deferred FEC label request for a | Detected notifications. When a deferred FEC label request for a | |||
| peer times out, the LSR sends the label request. | peer times out, the LSR sends the label request. | |||
| Context: | Context: | |||
| - LSR. The LSR handling the event. | - LSR. The LSR handling the event. | |||
| - FEC. The FEC associated with the timeout event. | - FEC. The FEC associated with the timeout event. | |||
| - Peer. The LDP peer associated with the timeout event. | - Peer. The LDP peer associated with the timeout event. | |||
| - Attributes. Attributes stored with deferred Label Request mes- | - Attributes. Attributes stored with deferred Label Request | |||
| sage. | message. | |||
| Algorithm: | Algorithm: | |||
| TO.1 Retrieve the record of the deferred label request. | TO.1 Retrieve the record of the deferred label request. | |||
| TO.2 Is Peer the next hop for FEC? | TO.2 Is Peer the next hop for FEC? | |||
| If not, goto TO.4. | If not, goto TO.4. | |||
| TO.3 Execute procedure Send_Label_Request (Peer, FEC). | TO.3 Execute procedure Send_Label_Request (Peer, FEC). | |||
| skipping to change at page 127, line 27 ¶ | skipping to change at page 130, line 52 ¶ | |||
| SLRq.6 Postpone the label request by recording label mapping for | SLRq.6 Postpone the label request by recording label mapping for | |||
| FEC and Attributes from Peer is needed but that no label | FEC and Attributes from Peer is needed but that no label | |||
| resources are available. | resources are available. | |||
| SLRq.7 Return failure. | SLRq.7 Return failure. | |||
| Notes: | Notes: | |||
| 1. If the LSR is a non-merging LSR it must distinguish between | 1. If the LSR is a non-merging LSR it must distinguish between | |||
| attempts to send label requests for a FEC triggered by differ- | attempts to send label requests for a FEC triggered by | |||
| ent upstream LDP peers from duplicate requests. This procedure | different upstream LDP peers from duplicate requests. This | |||
| will not send a duplicate label request. | procedure will not send a duplicate label request. | |||
| A.2.3. Send_Label_Withdraw | A.2.3. Send_Label_Withdraw | |||
| Summary: | Summary: | |||
| An LSR uses the Send_Label_Withdraw procedure to withdraw a label | An LSR uses the Send_Label_Withdraw procedure to withdraw a label | |||
| for a FEC from an LDP peer. To do this the LSR sends a Label | for a FEC from an LDP peer. To do this the LSR sends a Label | |||
| Withdraw message to the peer. | Withdraw message to the peer. | |||
| Parameters: | Parameters: | |||
| skipping to change at page 132, line 45 ¶ | skipping to change at page 136, line 11 ¶ | |||
| - PrevHopCount. The Hop Count, if any, this LSR associates with | - PrevHopCount. The Hop Count, if any, this LSR associates with | |||
| the LSP for the FEC. | the LSP for the FEC. | |||
| Additional Context: | Additional Context: | |||
| - LSR Id. The unique LSR Id of this LSR. | - LSR Id. The unique LSR Id of this LSR. | |||
| Algorithm: | Algorithm: | |||
| PMpA.1 Do the RAttributes include any unknown TLVs? If not, goto PMpA.4. | PMpA.1 Do the RAttributes include any unknown TLVs? | |||
| If not, goto PMpA.4. | ||||
| PMpA.2 Do the settings of the U and F bits require forwarding of | PMpA.2 Do the settings of the U and F bits require forwarding of | |||
| these TLVs? If not, goto PMpA.4. | these TLVs? If not, goto PMpA.4. | |||
| PMpA.3 Copy the unknown TLVs in SAttributes. | PMpA.3 Copy the unknown TLVs in SAttributes. | |||
| PMpA.4 Is Hop Count required for this Peer (see Note 1.) ? OR | PMpA.4 Is Hop Count required for this Peer (see Note 1.) ? OR | |||
| Do RAttributes include a Hop Count? OR | Do RAttributes include a Hop Count? OR | |||
| Is Loop Detection configured on LSR? | Is Loop Detection configured on LSR? | |||
| If not, goto PMpA.24. | If not, goto PMpA.24. | |||
| PMpA.5 Is LSR egress for FEC? | PMpA.5 Is LSR egress for FEC? | |||
| If not, goto PMpA.7. | If not, goto PMpA.7. | |||
| skipping to change at page 135, line 7 ¶ | skipping to change at page 138, line 7 ¶ | |||
| form TTL-decrement and it is propagating the Label Mapping mes- | form TTL-decrement and it is propagating the Label Mapping mes- | |||
| sage upstream into the cloud, it sets the Hop Count to 1 so | sage upstream into the cloud, it sets the Hop Count to 1 so | |||
| that Hop Count across the cloud is calculated properly. This | that Hop Count across the cloud is calculated properly. This | |||
| ensures proper TTL management for packets forwarded across the | ensures proper TTL management for packets forwarded across the | |||
| part of the LSP that passes through the cloud. | part of the LSP that passes through the cloud. | |||
| 3. For hop count arithmetic, unknown + 1 = unknown. | 3. For hop count arithmetic, unknown + 1 = unknown. | |||
| Full Copyright Statement | Full Copyright Statement | |||
| Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| Additional copyright notices are not permitted in IETF Documents | Additional copyright notices are not permitted in IETF Documents | |||
| except in the case where such document is the product of a joint | except in the case where such document is the product of a joint | |||
| development effort between the IETF and another standards development | development effort between the IETF and another standards development | |||
| organization or the document is a republication of the work of | organization or the document is a republication of the work of | |||
| another standards organization. Such exceptions must be approved on | another standards organization. Such exceptions must be approved on | |||
| an individual basis by the IAB. | an individual basis by the IAB. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- | |||
| MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES | MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES | |||
| OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Acknowledgement | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| End of changes. 82 change blocks. | ||||
| 225 lines changed or deleted | 319 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||