The MPLS WG Archive

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

Osama Farrag wrote:
> 
> Assume the following Network topology
> 
>                                  +--------+
>                                  |        |
>                                  |        |
>                          --------|    I1  |
>                         /        |        |
>                        /         +--------+
>                       /
> +------+          +-------+       +-------+
> |      |          |       |       |       |
> | E1   |----------|  C1   |-------|  I2   |
> |      |          |       |       |       |
> +------+          +-------+       +-------+
>                       \
>                        \          +-------+
>                         \         |       |
>                          ---------|  I3   |
>                                   |       |
>                                   +-------+
> 
> If LER I2 initiates an LSP to E1 using RSVP-TE path message,  with
> SE bit set. Then at later point in time LER I1, initiates RSVP LSP
> tunnel to E1 with SE bit set and same TUNNEL-ID value used by I2 in
> session object.

These two LSPs may or may not be in the same session.

If they have different extended tunnel IDs (which is the normal case,
where the extended tunnel ID is set to match the sender address), then
the two LSPs belong to different sessions, and there should be no
interaction between them whatsoever.

If the two LSPs are sent with identical extended tunnel IDs (which
should be zero, if two senders use identical extended tunnel IDs), then
they may share resources if the egress router requests SE style.

> A- When the second Path message arrive at E1; assume E1 supports SE
> style, Does E1 required to assign a new MPLS label in RSVP response
> message? or send the same label used in the previous message?

E1 can theoretically assign the same label for both LSPs, if C1 supports
label merging.  (POS interfaces are assumed to support label merge.  ATM
interfaces may or may not support it - the LABEL_REQUEST object will
indicate whether it does or not.)

In actual practice, however, it is more likely that E1 will assign
separate labels for the two LSPs, since it is difficult to accurately
determine whether a label merge operation is safe to perform.

> B- What should happen at C1;
> 
> First: when the second Path message is received from I1, should it
> pass thru to E1? if not then point A is not an issue, But then C1
> must respond with RESV message and assign a LABEL to I1. I think 
> RESV must be initaited from the EGRESS LER.

Yes.  All Path messages must be passed to the egress.  This is a
requirement of both FF and SE style.  Please note that SE-style Resv
messages must explicitly identify the senders.  The egress node can't do
this if it doesn't know who those senders are.

The only time it is OK to not forward a Path message is if there is a
WF-style reservation in place.  But WF style is not used with MPLS.

Keep in mind that even if labels are merged, there are still two LSPs in
place on the network.  RSVP is not LDP.  They do not work anything like
each other.

> Second: If C1 passes the Second path message thru to E1, then when
> it receives RESV message from E1 and SE bit set, I assume it will
> merge the LSPs from I1 and I2.

Define "merge" in this context.

If E1 decides to make an SE-style reservation, then both LSPs will get
the same FLOWSPEC (meaning the same service level).  This is a
requirement of SE style.

E1 does now, however, have to assign the same label to both LSPs.  If it
is capable of sharing resources between two connections, then it may
choose to create two separate connections, and have them share
resources.  Label merging is not a mandatory feature.

> If a new Label is assigned by E1 which Label C1 should use for
> traffic bound for E1, can it continue to use them both and refresh
> them. I think that C2 must maintain both labels and merge action at
> C1 only implies that resevered resources are shared but these two
> LSPs that are associated by TUNNEL-ID?

The Path and Resv messages must always be refreshed, even if both LSPs
are using the same label values.

An LSP does not cease to exist simply because it is sharing resources
with another LSP.

-- David