draft-ietf-mpls-crldp-unnum-07.txt   draft-ietf-mpls-crldp-unnum-08.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2003 Yakov Rekhter Expiration Date: April 2003 Yakov Rekhter
Juniper Networks Juniper Networks
Alan Kullberg Alan Kullberg
NetPlane Systems NetPlane Systems
Signalling Unnumbered Links in CR-LDP Signalling Unnumbered Links in CR-LDP
draft-ietf-mpls-crldp-unnum-07.txt draft-ietf-mpls-crldp-unnum-08.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract 2. Abstract
Current signalling used by Multi-Protocol Label Switching Traffic Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) doesn't provide support for unnumbered links. Engineering (MPLS TE) doesn't provide support for unnumbered links.
This document defines procedures and extensions to Constraint-Routing This document defines procedures and extensions to Constraint-Routing
Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling
protocols, that are needed in order to support unnumbered links. protocols, that are needed in order to support unnumbered links.
3. Overview 3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview
Supporting MPLS TE over unnumbered links (i.e., links that do not Supporting MPLS TE over unnumbered links (i.e., links that do not
have IP addresses) involves two components: (a) the ability to carry have IP addresses) involves two components: (a) the ability to carry
(TE) information about unnumbered links in IGP TE extensions (ISIS or (TE) information about unnumbered links in IGP TE extensions (ISIS or
OSPF), and (b) the ability to specify unnumbered links in MPLS TE OSPF), and (b) the ability to specify unnumbered links in MPLS TE
signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The
focus of this document is on the latter. focus of this document is on the latter.
Current signalling used by MPLS TE doesn't provide support for Current signalling used by MPLS TE doesn't provide support for
unnumbered links because the current signalling doesn't provide a way unnumbered links because the current signalling doesn't provide a way
to indicate an unnumbered link in its Explicit Route Objects. This to indicate an unnumbered link in its Explicit Route Objects. This
document proposes simple procedures and extensions that allow CR-LDP document proposes simple procedures and extensions that allow CR-LDP
signalling [CR-LDP] to be used with unnumbered links. signalling [CR-LDP] to be used with unnumbered links.
4. Link Identifiers 5. Link Identifiers
An unnumbered link has to be a point-to-point link. An LSR at each 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 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 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 scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP
modules on an LSR must agree on the identifiers. modules on an LSR must agree on the identifiers.
There is no a priori relationship between the identifiers assigned to There is no a priori relationship between the identifiers assigned to
a link by the LSRs at each end of that link. a link by the LSRs at each end of that link.
skipping to change at page 3, line 5 skipping to change at page 3, line 9
to the identifier that A assigned to the link as the "link local to the identifier that A assigned to the link as the "link local
identifier" (or just "local identifier"), and to the identifier that identifier" (or just "local identifier"), and to the identifier that
B assigned to the link as the "link remote identifier" (or just B assigned to the link as the "link remote identifier" (or just
"remote identifier"). Likewise, from B's perspective the identifier "remote identifier"). Likewise, from B's perspective the identifier
that B assigned to the link is the local identifier, and the that B assigned to the link is the local identifier, and the
identifier that A assigned to the link is the remote identifier. identifier that A assigned to the link is the remote identifier.
This section is equally applicable to the case of unnumbered This section is equally applicable to the case of unnumbered
component links (see [LINK-BUNDLE]). component links (see [LINK-BUNDLE]).
5. Unnumbered Forwarding Adjacencies 6. Unnumbered Forwarding Adjacencies
If an LSR that originates an LSP advertises this LSP as an unnumbered 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 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR
uses the Forwarding Adjacency formed by this LSP as an unnumbered uses the Forwarding Adjacency formed by this LSP as an unnumbered
component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST
allocate an identifier to that Forwarding Adjacency (just like for allocate an identifier to that Forwarding Adjacency (just like for
any other unnumbered link). Moreover, the REQUEST message used for any other unnumbered link). Moreover, the REQUEST message used for
establishing the LSP that forms the Forwarding Adjacency MUST contain establishing the LSP that forms the Forwarding Adjacency MUST contain
an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's 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 Router ID set to the head end's Router ID, and the Interface ID set
skipping to change at page 3, line 40 skipping to change at page 4, line 5
value that the LSR allocates to that Forwarding Adjacency, and the value that the LSR allocates to that Forwarding Adjacency, and the
link remote identifier to the value carried in the Interface ID field link remote identifier to the value carried in the Interface ID field
of the Reverse Interface ID TLV (for the definition of Reverse 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 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 Forwarding Adjacency sets the link local identifier for that link to
the value that the LSR allocates to that Forwarding Adjacency, and the value that the LSR allocates to that Forwarding Adjacency, and
the link remote identifier to the value carried in the Interface ID the link remote identifier to the value carried in the Interface ID
field of the Forward Interface ID TLV (for the definition of Forward field of the Forward Interface ID TLV (for the definition of Forward
Interface ID see below). Interface ID see below).
5.1. LSP_TUNNEL_INTERFACE_ID TLV 6.1. LSP_TUNNEL_INTERFACE_ID TLV
The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF
consensus and length 8. The format is given below. consensus and length 8. The format is given below.
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 Figure 1: LSP_TUNNEL_INTERFACE_ID TLV
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| Type | Length | |0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID | | LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Signalling Unnumbered Links in EROs 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.
7. Signalling Unnumbered Links in EROs
A new Type of ER-Hop TLV of the Explicit Route Object (ERO) is used A new Type of ER-Hop TLV of the Explicit Route Object (ERO) is used
to specify unnumbered links. This Type is called Unnumbered to specify unnumbered links. This Type is called Unnumbered
Interface ID, and has the following format: Interface ID, and has the following format:
Figure 2: Unnumbered Interface ID Figure 2: Unnumbered Interface ID
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 4, line 44 skipping to change at page 5, line 8
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12. The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12.
The L bit is set to indicate a loose hop, and cleared to indicate a The L bit is set to indicate a loose hop, and cleared to indicate a
strict hop. strict hop.
The Interface ID is the identifier assigned to the link by the LSR The Interface ID is the identifier assigned to the link by the LSR
specified by the router ID. specified by the router ID.
6.1. Processing the IF_ID TLV 7.1. Processing the IF_ID TLV
When an LSR receives a REQUEST message containing the IF_ID TLV (see When an LSR receives a REQUEST message containing the IF_ID TLV (see
[GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as
follows. The LSR must have information about the identifiers assigned follows. The LSR must have information about the identifiers assigned
by its neighbors to the unnumbered links between the neighbors and by its neighbors to the unnumbered links between the neighbors and
the LSR. The LSR uses this information to find a link with tuple the LSR. The LSR uses this information to find a link with tuple
<Router ID, local identifier> matching the tuple <IP Address, <Router ID, local identifier> matching the tuple <IP Address,
Interface ID> carried in the IF_INDEX TLV. If the matching tuple is Interface ID> carried in the IF_INDEX TLV. If the matching tuple is
found, the match identifies the link for which the LSR has to perform found, the match identifies the link for which the LSR has to perform
label allocation. label allocation.
Otherwise, the LSR SHOULD return an error. Otherwise, the LSR SHOULD return an error.
6.2. Processing the ERO 7.2. Processing the ERO
The Unnumbered Interface ID ER-Hop is defined to be a part of a The Unnumbered Interface ID ER-Hop is defined to be a part of a
particular abstract node if that node has the Router ID that is equal particular abstract node if that node has the Router ID that is equal
to the Router ID field in the Unnumbered Interface ID ER-Hop, and if to the Router ID field in the Unnumbered Interface ID ER-Hop, and if
the node has an (unnumbered) link or an (unnumbered) Forwarding the node has an (unnumbered) link or an (unnumbered) Forwarding
Adjacency whose local identifier (from that node's point of view) is Adjacency whose local identifier (from that node's point of view) is
equal to the value carried in the Interface ID field of the equal to the value carried in the Interface ID field of the
Unnumbered Interface ID ER-Hop. Unnumbered Interface ID ER-Hop.
With this in mind, the ERO processing in the presence of the With this in mind, the ERO processing in the presence of the
Unnumbered Interface ID ER-Hop follows the rules specified in section Unnumbered Interface ID ER-Hop follows the rules specified in section
4.8.1 of [CR-LDP]. 4.8.1 of [CR-LDP].
As part of the ERO processing, or to be more precise, as part of the 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 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 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 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 the node, and the Interface ID field of that TLV set to the
identifier assigned to the link by the node. identifier assigned to the link by the node.
7. IANA Considerations 8. IANA Considerations
RFC3036 [LDP] defines the LDP TLV name space. RFC3212 [CD-LDP] RFC3036 [LDP] defines the LDP TLV name space. RFC3212 [CD-LDP]
further subdivides the range of RFC 3036 from that TLV space for TLVs further subdivides the range of RFC 3036 from that TLV space for TLVs
associated with the CR-LDP in the range 0x0800 - 0x08FF. associated with the CR-LDP in the range 0x0800 - 0x08FF.
Following the policies outlined in [IANA], TLV types in this range Following the policies outlined in [IANA], TLV types in this range
are allocated through an IETF Consensus action. are allocated through an IETF Consensus action.
This document makes the following assignments: This document makes the following assignments:
TLV Type TLV Type
-------------------------------------- ---------- -------------------------------------- ----------
UNNUMBERED_INTERFACE_ID 0x0805 UNNUMBERED_INTERFACE_ID 0x0805
LSP_TUNNEL_INTERFACE_ID 0x08?? LSP_TUNNEL_INTERFACE_ID 0x08??
8. Security Considerations 9. Security Considerations
This document extends CR-LDP and raises no new security issues. CR- This document extends CR-LDP and raises no new security issues. CR-
LDP inherits the same security mechanism described in Section 4.0 of LDP inherits the same security mechanism described in Section 4.0 of
[LDP] to protect against the introduction of spoofed TCP segments [LDP] to protect against the introduction of spoofed TCP segments
into LDP session connection streams. into LDP session connection streams.
9. Acknowledgments 10. Acknowledgments
Thanks to Rahul Aggarwal for his comments on the text. Thanks too to Thanks to Rahul Aggarwal for his comments on the text. Thanks too to
Bora Akyol, Vach Kompella, and George Swallow. Bora Akyol, Vach Kompella, and George Swallow.
10. References 11. References
10.1. Normative references 11.1. Normative references
[CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using
LDP", RFC3212, December 2001 LDP", RFC3212, December 2001
[GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling
Functional Description", draft-ietf-generalized-mpls- Functional Description", draft-ietf-generalized-mpls-
signalling-08.txt signalling-08.txt
[GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR-
LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt
[LDP] Andersson, Loa, et al., "LDP Specification" RFC3036, January [LDP] Andersson, Loa, et al., "LDP Specification" RFC3036, January
2001 2001
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Non-normative references 11.2. Non-normative references
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", draft-kompella-mpls- Bundling in MPLS Traffic Engineering", draft-kompella-mpls-
bundle-05.txt (work in progress) bundle-05.txt (work in progress)
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS
TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress)
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-03.txt (work in progress) draft-ietf-ccamp-lmp-03.txt (work in progress)
skipping to change at page 7, line 4 skipping to change at page 7, line 22
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS
TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress)
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-03.txt (work in progress) draft-ietf-ccamp-lmp-03.txt (work in progress)
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
extensions-11.txt (work in progress) extensions-11.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-
gmpls-extensions-07.txt (work in progress) gmpls-extensions-07.txt (work in progress)
11. Author Information 12. Author Information
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: kireeti@juniper.net e-mail: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/