--- 1/draft-ietf-mpls-crldp-unnum-02.txt 2006-02-05 00:37:44.000000000 +0100 +++ 2/draft-ietf-mpls-crldp-unnum-03.txt 2006-02-05 00:37:44.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Kireeti Kompella Internet Draft Juniper Networks -Expiration Date: March 2002 Yakov Rekhter +Expiration Date: June 2002 Yakov Rekhter Juniper Networks Alan Kullberg NetPlane Systems Signalling Unnumbered Links in CR-LDP - draft-ietf-mpls-crldp-unnum-02.txt + draft-ietf-mpls-crldp-unnum-03.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. @@ -46,191 +46,184 @@ OSPF), and (b) the ability to specify unnumbered links in MPLS TE signalling. The former is covered in [ISIS-TE, OSPF-TE]. The focus of this document is on the latter. Current signalling used by MPLS TE doesn't provide support for unnumbered links because the current signalling doesn't provide a way to indicate an unnumbered link in its Explicit Route Objects. This document proposes simple procedures and extensions that allow CR-LDP signalling [CR-LDP] to be used with unnumbered links. -4. Interface Identifiers +4. Link Identifiers - Since unnumbered links are not identified by an IP address, then for - the purpose of MPLS TE they need some other identifier. We assume - that each unnumbered link on a Label Switched Router (LSR) is given a - unique 32-bit identifier. The scope of this identifier is the LSR to - which the link belongs; moreover, the IS-IS and/or OSPF and CR-LDP - modules on an LSR must agree on interface identifiers. + An unnumbered link has to be a point-to-point link. An LSR at each + end of an unnumbered link assigns an identifier to that link. This + identifier is a non-zero 32-bit number that is unique within the + scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP + modules on an LSR must agree on the identifiers. - Note that links are directed, i.e., a link l is from some LSR A to - some other LSR B. LSR A chooses the interface identifier for link l. - To be completely clear, we call this the "outgoing interface - identifier from LSR A's point of view". If there is a reverse link - from LSR B to LSR A (for example, a point-to-point SONET interface - connecting LSRs A and B would be represented as two links, one from A - to B, and another from B to A), B chooses the outgoing interface - identifier for the reverse link; we call this the link's "incoming - interface identifier from A's point of view". There is no a priori - relationship between the two interface identifiers. + There is no a priori relationship between the identifiers assigned to + a link by the LSRs at each end of that link. + + LSRs at the two end points of an unnumbered link exchange with each + other the identifiers they assign to the link. Exchanging the + identifiers may be accomplished by configuration, by means of a + protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in + the case where a link is a Forwarding Adjacency, see below), or by + means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). + + Consider an (unnumbered) link between LSRs A and B. LSR A chooses an + idenfitier for that link. So is LSR B. From A's perspective we refer + to the identifier that A assigned to the link as the "link local + identifier" (or just "local identifier"), and to the identifier that + B assigned to the link as the "link remote identifier" (or just + "remote identifier"). Likewise, from B's perspective the identifier + that B assigned to the link is the local identifier, and the + identifier that A assigned to the link is the remote identifier. + + This section is equally applicable to the case of unnumbered + component links (see [LINK-BUNDLE]). 5. Unnumbered Forwarding Adjacencies If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR uses the Forwarding Adjacency formed by this LSP as an unnumbered - component link of a bundled link (see [BUNDLE]), the LSR MUST - allocate an interface identifier to that Forwarding Adjacency (just - like for any other unnumbered link). Moreover, the Request message - used for establishing the LSP that forms the Forwarding Adjacency - MUST contain an LSP_TUNNEL_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 interface identifier that the LSR allocated - to the Forwarding Adjacency. + component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST + allocate an identifier to that Forwarding Adjacency (just like for + any other unnumbered link). Moreover, the REQUEST message used for + establishing the LSP that forms the Forwarding Adjacency MUST contain + an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's + Router ID set to the head end's Router ID, and the Interface ID set + to the identifier that the LSR allocated to the Forwarding Adjacency. - 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 identifier to - the reverse Forwarding Adjacency. Furthermore, the MAPPING message - for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the - LSR's Router ID set to the tail end's router ID, and the Interface ID - set to the interface identifier allocated by the tail-end LSR. + If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then + the tail-end LSR MUST allocate an identifier to that Forwarding + Adjacency (just like for any other unnumbered link). Furthermore, + the MAPPING message for the LSP MUST contain an + LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the + tail-end's Router ID, and the Interface ID set to the identifier + allocated by the tail-end LSR. -5.1. LSP_TUNNEL_INTERFACE_ID Object + For the purpose of processing the ERO and the Interface ID TLV, an + unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link + or an unnumbered component link as follows. The LSR that originates + the Adjacency sets the link local identifier for that link to the + value that the LSR allocates to that Forwarding Adjacency, and the + link remote identifier to the value carried in the Interface ID field + of the Reverse Interface ID TLV (for the definition of Reverse + Interface ID TLV see below). The LSR that is a tail-end of that + Forwarding Adjacency sets the link local identifier for that link to + the value that the LSR allocates to that Forwarding Adjacency, and + the link remote identifier to the value carried in the Interface ID + field of the Forward Interface ID TLV (for the definition of Forward + Interface ID see below). - The LSP_TUNNEL_INTERFACE ID object has Type to be determined by IETF +5.1. LSP_TUNNEL_INTERFACE_ID TLV + + The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF consensus and length 8. The format is given below. - Figure 1: Interface ID TLV + This TLV can optionally appear in either a REQUEST message or a + MAPPING message. In the former case, we call it the "Forward + Interface ID" for that LSP; in the latter case, we call it the + "Reverse Interface ID" for the LSP. + + Figure 1: LSP_TUNNEL_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR's Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - This object can optionally appear in either a REQUEST message or a - MAPPING message. In the former case, we call it the "Forward - Interface ID" for that LSP; in the latter case, we call it the - "Reverse Interface ID" for the LSP. - 6. Signalling Unnumbered Links in EROs 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 8. - - The Interface ID is the outgoing interface identifier with respect to - the LSR specified by the router ID. - -6.1. Processing the Unnumbered Interface ID Subobject + The Type is 0x0805 (Unnumbered Interface ID) and the Length is 8. - First of all, the receiving LSR 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 (for - other types of ERO subobjects, the rules in [CR-LDP] apply). + The Interface ID is the identifier assigned to the link by the LSR + specified by the router ID. - The IF_ID TLV ([GMPLS-SIG], [GMPLS-CRLDP]), if present in the - message, MUST contain the same Router ID (IP Address) as the Router - ID carried in the Unnumbered Interface ID subobject. If not, the - receiving LSR MUST return a "Bad Initial ER-Hop" error. If IF_ID TLV - is present, and it carries the IF_INDEX TLV, the receiving LSR SHOULD - check that the value carried in this TLV is the same as carried in - the Interface ID field of the Unnumbered Interface ID subobject. If - the value is different, the receiving LSR MUST return a "Bad Initial - ER-Hop" error. +6.1. Processing the IF_ID TLV - If the above checks are passes, the LSR checks whether the tuple - from the Unnumbered Interface subobject - matches the tuple of any of the - LSPs for which the LSR is a tail-end. If a match is found, the match - identifies the Forwarding Adjacency for which the LSR has to perform - label allocation. + When an LSR receives a REQUEST message containing the IF_ID TLV with + the IF_INDEX TLV, the LSR processes this TLV as follows. The LSR + must have information about the identifiers assigned by its neighbors + to the unnumbered links between the neighbors and the LSR. The LSR + uses this information to find a link with tuple matching the tuple carried in + the IF_INDEX TLV. If the matching tuple is found, the match + identifies the link for which the LSR has to perform label + allocation. - Otherwise, the LSR MUST check whether the tuple from the Unnumbered Interface subobject matches the tuple of any of the bidirectional LSPs for which - the LSR is the head-end. If a match is found, the match identifies - the Forwarding Adjacency for which the LSR has to perform label - allocation, namely, the reverse Forwarding Adjacency for the LSP - identified by the match. + Otherwise, the LSR SHOULD return an error. - Otherwise, the LSR must have information about the identifiers - assigned by its neighbors to the unnumbered links (i.e., incoming - interface identifiers from LSR's point of view). The LSR uses this - information to find a link with tuple matching the tuple from the - Unnumbered Interface subobject. If the matching tuple is found, and - the link is not a bundled link, the match identifies the link for - which the LSR has to perform label allocation. If the matching tuple - is found, and the link is a bundled link, the LSR follows the - procedures for label allocation as described in [LINK-BUNDLE]. +6.2. Processing the ERO object -6.2. Selecting the Next Hop + The Unnumbered Interface ID subobject is defined to be a part of a + particular abstract node if that node has the Router ID that is equal + to the Router ID field in the subobject, and if the node has an + (unnumbered) link or an (unnumbered) Forwarding Adjacency whose local + identifier (from that node's point of view) is equal to the value + carried in the Interface ID field of the subobject. - Once an LSR determines the link for which the LSR has to perform - label allocation, the LSR removes the initial subobject in the ERO, - and computes the next hop. 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 LSR at the other end of the link that the Interface ID refers to. - If this is the LSR itself, the subobject is removed, and the process - repeated. If the next node is some other LSR, this is the next hop - to which a Request message must be sent. + With this in mind, the ERO processing in the presence of the + Unnumbered Interface ID subobject follows the rules specified in + section 4.8.1 of [CR-LDP]. - When sending a Request message to the next hop, if the message - carries the IF_ID object, then this object MUST contain the IF_INDEX - TLV, with IP Address in that TLV set to the LSR's Router ID, and - Interface ID set to the Interface ID carried in the first subobject - of the ERO. + As part of the ERO processing, or to be more precise, as part of the + next hop selection, if the outgoing link is unnumbered, the REQUEST + message that the node sends to the next hop MUST include the IF_ID + TLV, with the IP address field of that TLV set to the Router ID of + the node, and the Interface ID field of that TLV set to the + identifier assigned to the link by the node. 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 too to Bora Akyol and Vach Kompella. 9. References - [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in - MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in - progress) + [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link + Bundling in MPLS Traffic Engineering", draft-kompella-mpls- + bundle-05.txt (work in progress) [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress) [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling Functional Description", draft-ietf-generalized-mpls- signalling-05.txt - [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt [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 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to