Network Working Group K. Kompella
Request for Comments: 3480 Y. Rekhter
Category: Standards Track Juniper Networks
Signalling Unnumbered Links in CR-LDP
(Constraint-Routing Label Distribution Protocol)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) does not provide support for unnumbered links.
This document defines procedures and extensions to Constraint-Routing
Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling
protocols that are needed in order to support unnumbered links.
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 BCP 14, RFC 2119
Supporting MPLS TE over unnumbered links (i.e., links that do not
have IP addresses) involves two components: (a) the ability to carry
(TE) information about unnumbered links in IGP TE extensions (ISIS or
OSPF), and (b) the ability to specify unnumbered links in MPLS TE
signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The
focus of this document is on the latter.
Kompella, et al. Standards Track [Page 1]RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003
Current signalling used by MPLS TE does not provide support for
unnumbered links because the current signalling does not 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.
2. Link 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. If one is using OSPF or ISIS as
the IGP in support of traffic engineering, then the IS-IS and/or OSPF
and CR-LDP modules on an LSR must agree on the 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 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
identifier for that link. So does 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.
In the context of this document, the term "Router ID" means a stable
IP address of an LSR that is always reachable if there is any
connectivity to the LSR. This is typically implemented as a
"loopback address"; the key attribute is that the address does not
become unusable if an interface on the LSR is down. In some cases,
this value will need to be configured. If one is using OSPF or ISIS
as the IGP in support of traffic engineering, then it is RECOMMENDED
for the Router ID to be set to the "Router Address" as defined in
[OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-