--- 1/draft-ietf-mpls-crldp-unnum-00.txt 2006-02-05 00:37:42.000000000 +0100 +++ 2/draft-ietf-mpls-crldp-unnum-01.txt 2006-02-05 00:37:42.000000000 +0100 @@ -1,20 +1,20 @@ Network Working Group Kireeti Kompella Internet Draft Juniper Networks -Expiration Date: May 2001 Yakov Rekhter - Cisco Systems +Expiration Date: August 2001 Yakov Rekhter + Juniper Networks Alan Kullberg NetPlane Systems Signalling Unnumbered Links in CR-LDP - draft-ietf-mpls-crldp-unnum-00.txt + draft-ietf-mpls-crldp-unnum-01.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -72,29 +72,33 @@ interface identifier from A's point of view". There is no a priori relationship between the two interface identifiers. 5. Unnumbered Forwarding Adjacencies If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST allocate an interface ID to that Forwarding Adjacency. Moreover, the REQUEST message for the LSP MUST contain an INTERFACE ID object (described below), with the LSR's Router ID set to the head end's - router ID, and the Interface ID set to the LSP's interface ID. + router ID, and the Interface ID set to the LSP's interface ID. If + the LSP is part of a bundled link (see [BUNDLE]), the Interface ID is + set to the component interface ID of the LSP. If the LSP is bidirectional, and the tail-end LSR (of the forward LSP) advertises the reverse LSP as an unnumbered Forwarding Adjacency, the tail-end LSR MUST allocate an interface ID to the reverse Forwarding Adjacency. Furthermore, the MAPPING message for the LSP MUST contain an INTERFACE ID object, with the LSR's Router ID set to the tail end's router ID, and the Interface ID set to the - reverse LSP's interface ID. + reverse LSP's interface ID. If the LSP is part of a bundled link + (see [BUNDLE]), the Component Interface ID is set to the component + interface ID of the LSP; otherwise, it is set to zero. 5.1. INTERFACE ID Object The INTERFACE ID object has Type to be determined by IETF consensus and length 8. The format is given below. Figure 1: Interface ID TLV 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 @@ -116,115 +120,109 @@ A new subobject of the Explicit Route Object (ERO) is used to specify unnumbered links. This subobject has the following format: Figure 2: Unnumbered Interface ID Subobject 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| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This subobject is strict. The Type is 0x0805 (Unnumbered Interface - ID) and the Length is 4. + ID) and the Length is 8. - An LSR sending a Request message that includes an Unnumbered - Interface ID subobject as the first subobject in the ERO MUST also - include a PHOP TLV, specifying the Router ID of the sending LSR. - This TLV is depicted in Figure 3. +6.1. Interpreting the Unnumbered Interface ID Subobject - Figure 3: PHOP TLV + The Router ID (say X) is the router ID of the LSR P at the upstream + end of the unnumbered link. The Interface ID (say I) is the outgoing + interface identifier with respect to the LSR specified by the router + ID. If not, the receiving node MUST return an error message. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0|0| Type | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LSR's Router ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +6.2. Validating the Unnumbered Interface ID Subobject - The Type (PHOP TLV) is to be determined by IETF consensus and the - Length is 4. + First of all, the receiving node R must validate that it received the + Request message correctly. If the first subobject in the ERO is an + Unnumbered Interface subobject, the check is done as follows. R + looks up in its Traffic Engineering database the node P corresponding + to the router ID X in the ERO subobject. It then checks that there + is a link from P to R that carries the same Interface ID as the one + in the ERO subobject (I). If this is not the case, R has received + the message in error and SHOULD return a "Bad Initial ER-Hop" error. -6.1. Interpreting the Unnumbered Interface ID Subobject + For other types of ERO subobjects, the rules in [CR-LDP] apply. - The Interface ID is the outgoing interface identifier with respect to - the previous node in the path (i.e., the PHOP). If the Request - message contains an Unnumbered Interface ID subobject as the first - subobject in the ERO, then the PHOP object in the message must - contain the router ID of the previous node. +6.3. Determining the Link Identified by the ERO -6.2. Processing the Unnumbered Interface ID Subobject + Determining the link for which label allocation must be done depends + on whether a Component Interface Identifier object [BUNDLE] is + present in the Request message or not. If so, set ID to the + Component Interface ID; otherwise, set ID to I (the Interface ID in + the ERO subobject). X is (as above) the router ID in the Unnumbered + ERO subobject. - A node that receives a Request message with an Unnumbered Interface - ID as the first subobject in the ERO carried by the message MUST - check whether the tuple matches the tuple matches the tuple of any of the LSPs for which the node is a tail-end. If a match is found, the match identifies the Forwarding Adjacency for which the node has to perform label allocation. - Otherwise, the node MUST check whether the tuple - matches the tuple of any of - the bidirectional LSPs for which the node is the head-end. If a - match is found, the match identifies the Forwarding Adjacency for - which the node has to perform label allocation, namely, the reverse - Forwarding Adjacency for the LSP identified by the match. + Otherwise, the node MUST check whether the tuple matches the + tuple of any of the + bidirectional LSPs for which the node is the head-end. If a match is + found, the match identifies the Forwarding Adjacency for which the + node has to perform label allocation, namely, the reverse Forwarding + Adjacency for the LSP identified by the match. - Otherwise, if the node maintains information about Interface IDs - assigned by its neighbors for the unnumbered links between the node - and the neighbors (i.e., incoming interface identifiers from the - node's point of view), the node SHOULD check whether the tuple matches - for any link. If a match is found, the match identifies the link for - which the node has to perform label allocation. + Otherwise, R must have information about Interface IDs and Component + Interface IDs assigned by its neighbors for the unnumbered links + between R and its neighbors (i.e., incoming interface identifiers + from R's point of view). + + If the Request message does not contain a Component Interface + Identifier object, R determines the link by looking up in the + Traffic Engineering database. If the Request message contains a + Component Interface Identifier object, R determines the link as + described in [BUNDLE]. Otherwise, it is assumed that the node has to perform label allocation for the link over which the Request message was received. - In this case the receiving node MAY validate that it received the - Request Message correctly. To do so, the node must maintain a - database of Traffic Engineering information distributed by IS-IS - and/or OSPF. - - To validate that it received the Request message correctly, the node - looks up in its Traffic Engineering database for the node - corresponding to the router ID of the sender of the Request message. - It then checks that there is a link from the previous node to itself - that carries the same Interface ID as the one in the ERO subobject. - If this is not the case, the receiving node has received the message - in error and SHOULD return a "Bad Initial ER-Hop" error. Otherwise, - the receiving node removes the first subobject, and continues - processing the ERO. -6.3. Selecting the Next Hop +6.4. Selecting the Next Hop - If, after processing and removing all initial subobjects in the ERO - that refer to itself, the receiving node finds a subobject of type - Unnumbered Interface ID, it determines the next hop as follows. The - Interface ID MUST refer to an outgoing interface identifier that this - node allocated; if not, the node SHOULD return a "Bad Strict Node" - error. The next hop is the node at the other end of the link that - the Interface ID refers to. + Once the link has been determined, the initial subobject is removed, + and the next hop should be computed. The next hop for an Unnumbered + Interface ID subobject is determined as follows. The Interface ID + MUST refer to an outgoing interface identifier that this node + allocated; if not, the node SHOULD return a "Bad Strict Node" error. + The next hop is the node at the other end of the link that the + Interface ID refers to. If this node is R itself, the subobject is + removed, and the process repeated. If the next node is not R, say N, + this is the next hop to which a Request message must be sent. - Furthermore, when sending a Request message to the next hop, the ERO - to be used is the current ERO (starting with the Unnumbered Interface - ID subobject). + Furthermore, when sending a Request message to N, the ERO to be used + is the remaining ERO (i.e., starting with the subobject that refers + to a node different from the receiving node); the PHOP object is R's + router ID. 7. Security Considerations This document raises no new security concerns for CR-LDP. 8. Acknowledgments - Thanks to Rahul Aggarwal for his comments on the text. + Thanks to Rahul Aggarwal for his comments on the text. Thanks too to + Bora Akyol and Vach Kompella. 9. References [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-02.txt (work in progress) [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS @@ -235,20 +233,20 @@ 10. Author Information Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 e-mail: kireeti@juniper.net Yakov Rekhter -Cisco Systems, Inc. -170 West Tasman Drive -San Jose, CA 95134 -e-mail: yakov@cisco.com +Juniper Networks, Inc. +1194 N. Mathilda Ave. +Sunnyvale, CA 94089 +e-mail: yakov@juniper.net Alan Kullberg NetPlane Systems, Inc. 888 Washington St. Dedham, MA 02026 e-mail: akullber@netplane.com