Subject: Determining the Ingress IP address in an RSVP session

From: Marc Lewis <[email-masked]>
Date: Fri, 27 Apr 2001 08:18:42 -0700

Several recent messages have concerned the issue of how to discern the
Ingress LSR's IP address.  Though it is true that some routers seem to put
it in the Extended Tunnel ID field of the SESSION object,
draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it.

Furthermore, RFC2205 is not terribly clear about what the phrase "a sender"
means, which is used repeatedly in describing the workings of RSVP message
objects.  Assuming it means the Ingress LSR (the original sender) leads to
one interpretation, and assuming it means the LSR that sent the message
being examined (simply an RSVP peer, not necessarily the Ingress LSR) leads
to another interpretation.  I suspect, but am not certain, the latter
assumption is the correct one.

It does seem reasonably unambiguous, however, that the Ingress and Egress IP
addresses are reliably to be found as the source and destination addresses,
respectively, of the IP header of PATH messages.  Quoting from 3.1.3 in
RFC2205: "Each message contains a sender descriptor defining one sender, and
carries the original sender's IP address as its IP source address".

---

From: Eric Gray <[email-masked]>
Date: Mon, 30 Apr 2001 11:46:39 -0400

Marc,

    In at least one case, the IPv4 address is required in the
extended tunnel ID.  That case is described in section 4.6.4
as shown below:

=========================================================================
4.6.4. Reroute and Bandwidth Increase Procedure

   This section describes how to setup a tunnel that is capable of
   maintaining resource reservations (without double counting) while
   it is being rerouted or while it is attempting to increase its
   bandwidth.  In the initial Path message, the ingress node forms a
   SESSION object, assigns a Tunnel_ID, and places its IPv4 address in
   the Extended_Tunnel_ID It also forms a SENDER_TEMPLATE and assigns a
   LSP_ID. Tunnel setup then proceeds according to the normal procedure.
=========================================================================

In addition, though I cannot find where it is explicitly stated right at
the moment, I believe the IPv4 (or IPv6) address in the SENDER_TEMPLATE
object is supposed to be for the ingress LSR on the LSP.  This is implied
by the statement (on page 9, last paragraph in section 2.1):

"The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
 object uniquely identifies an LSP tunnel".

This statement would not be true if two separate ingress LSRs could
each choose to use the same 'sender' when creating the SENDER_TEMPLATE
object.

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Mon, 30 Apr 2001 11:19:23 -0400

Marc Lewis wrote:
> 
> Several recent messages have concerned the issue of how to discern
> the Ingress LSR's IP address.  Though it is true that some routers
> seem to put it in the Extended Tunnel ID field of the SESSION
> object, draft-ietf-mpls-rsvp-lsp-tunnel-08 does not require it.

If extended tunnel ID is non-zero, then it must be a value that can
unambiguously identify the sender (LSP ingress).  The only standard
mechanism for generating these values is to use one of the sender's IP
addresses.

> Furthermore, RFC2205 is not terribly clear about what the phrase "a
> sender" means, which is used repeatedly in describing the workings
> of RSVP message objects.  Assuming it means the Ingress LSR (the
> original sender) leads to one interpretation, and assuming it means
> the LSR that sent the message being examined (simply an RSVP peer,
> not necessarily the Ingress LSR) leads to another interpretation.
> I suspect, but am not certain, the latter assumption is the correct
> one.

This is really a question for the RSVP working group, not the MPLS
group.

"Sender", unless explicitly stated otherwise, always refers to the
sender on the data plane - meaning the ingress node when used in the
context of MPLS.

Any other definition makes the multicast features of RSVP impossible to
implement.  (Never forget that RFC-2205 is not an MPLS document.  RSVP
was designed to signal QoS over a multicast IP network, not over a
unicast MPLS network.)

If two hosts are sending data to a single destination, and their routes
converge at some point, the egress router must be able to keep the two
separate if FF or SE style reservations are to be used.  Remember that
there is no extended tunnel ID in RFC-2205.

If sender is defined as previous-hop, then the recipient of the Path
message will not know that there are two senders.  Both will end up
being replaced with a single PHOP address.

Those who interpret "sender" as previous/next hop have a broken
implementation.

> It does seem reasonably unambiguous, however, that the Ingress and
> Egress IP addresses are reliably to be found as the source and
> destination addresses, respectively, of the IP header of PATH
> messages.  Quoting from 3.1.3 in RFC2205: "Each message contains a
> sender descriptor defining one sender, and carries the original
> sender's IP address as its IP source address".

This is true.

RFC-2205 was designed to work in a network where not everybody supports
RSVP.  (Unlike all MPLS applications of RSVP).  In order to make this
work, packets are addresses to the ultimate recipient of the data, and
not the next-hop router.  This way, the packets won't be dropped by a
non-RSVP router that happens to be in the middle of the path.

-- David

---

From: Guangzhi Li <[email-masked]>
Date: Mon, 30 Apr 2001 13:09:35 -0400

Hi,

In RSVP-TE, section 2.5, it says"
The LSP_TUNNEL_SESSION object is used to narrow the scope of the RSVP session to
the particular TE tunnel in question. To uniquely identify a TE tunnel, we use the
combination of the destination IP address (an address of the node which is the
egres of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which
is placed in the Extended Tunnel ID field."

To apply RSVP-TE to MPLS, destination is the egress node IP address, source is the
ingress node IP address, both are placed in LSP_TUNNEL_SESSION object. Without
Extended Tunnel ID, you can not uniquely identify a TE tunnel.

It seems that both source and sender are ingress node when RSVP-TE talks about the
LSPs.

RSVP was originally designed for multicast applications, where sender and receiver
are clear. In MPLS, LSPs are not exactly applications anymore, I think.

-- Guangzhi