The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

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