Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
RFC 3477

Document Type RFC - Proposed Standard (February 2003; No errata)
Updated by RFC 6107
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3477 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Scott Bradner
Send notices to (None)
Network Working Group                                        K. Kompella
Request for Comments: 3477                                    Y. Rekhter
Category: Standards Track                               Juniper Networks
                                                            January 2003

     Signalling Unnumbered Links in Resource ReSerVation Protocol -
                     Traffic Engineering (RSVP-TE)

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 Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   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 Resource
   ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels
   (RSVP-TE), 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
   [RFC2119].

1. Overview

   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 & Rekhter          Standards Track                     [Page 1]
RFC 3477         Signalling Unnumbered Links in RSVP-TE     January 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 and Record
   Route Objects.  This document proposes simple procedures and
   extensions that allow RSVP-TE signalling [RFC3473] 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 RSVP 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 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
   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 the 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-TE].

   This section is equally applicable to the case of unnumbered
   component links (see [LINK-BUNDLE]).

Kompella & Rekhter          Standards Track                     [Page 2]
RFC 3477         Signalling Unnumbered Links in RSVP-TE     January 2003

3. Unnumbered Forwarding Adjacencies

   If an LSR that originates an LSP advertises this LSP as an unnumbered
Show full document text