Using Unnumbered Point-To-Point Interface In Rsvp - Alcatel-Lucent 7450 Manual

Using Unnumbered Point-to-Point Interface in RSVP

Using Unnumbered Point-to-Point Interface in RSVP
This feature introduces the use of unnumbered IP interface as a Traffic Engineering (TE) link for
the signaling of RSVP P2P LSP and P2MP LSP.
An unnumbered IP interface is identified uniquely on a router in the network by the tuple {router-
id, ifIndex}. Each side of the link assigns a system-wide unique interface index to the unnumbered
interface. ISIS, OSPF, RSVP, and OAM modules will use this tuple to advertise the link
information, signal LSP paths over this unnumbered interface, or send and respond to an MPLS
echo request message over an unnumbered interface.
The interface borrowed IP address is used exclusively as the source address for IP packets that are
originated from the interface and needs to be configured to an address different from system
interface for the FRR bypass LSP to come up at the ingress LER.
The borrowed IP address for an unnumbered interface is configured using the following CLI
command with a default value set to the system interface address:
configure> router>interface>unnumbered [ip-int-name | ip-address].
The support of unnumbered TE link in IS-IS consists of adding a new sub-TLV of the extended IS
reachability TLV, which encodes the Link Local and Link Remote Identifiers as defined in RFC
5307.
The support of unnumbered TE link in OSPF consists of adding a new sub-TLV, which encodes
the same Link Local and Link Remote Identifiers in the Link TLV of the TE area opaque LSA and
sends the local Identifier in the Link Local Identifier TLV in the TE link local opaque LSA as per
RFC 4203.
The support of unnumbered TE link in RSVP implements the signaling of unnumbered interfaces
in ERO/RRO as per RFC 3477 and the support of IF_ID RSVP_HOP object with a new Ctype as
per Section 8.1.1 of RFC 3473. The IPv4 Next/Previous Hop Address field is set to the borrowed
IP interface address.
The unnumbered IP is advertised by IS-IS TE and OSPF TE, and CSPF can include them in the
computation of a path for a P2P LSP or for the S2L of a P2MP LSP. This feature does not,
however, support defining an unnumbered interface a hop in the path definition of an LSP.
A router creates an RSVP neighbor over an unnumbered interface using the tuple {router-id,
ifIndex}. The router-id of the router that advertised a given unnumbered interface index is
obtained from the TE database. As as result, if traffic engineering is disabled in IS-IS or OSPF, a
non-CSPF LSP with the next-hop for its path is over an unnumbered interface will not come up at
the ingress LER since the router-id of the neighbor that has the next-hop of the path message
cannot be looked up. In this case, the LSP path will remain in operationally down state with a
reason noRouteToDestination. If a PATH message was received at the LSR in which traffic
engineering was disabled and the next-hop for the LSP path is over an unnumbered interface, a
Page 56 7450 ESS MPLS Guide