Subject: Re: regarding termination of LSP at Egress Edge

From: Arthi Ayyangar <[email-masked]>
Date: Fri, 15 Oct 1999 15:09:41 -0400 (EDT)

Hi,

I think I could have some explaination below based on my interpretation of your 
Question.Hope that helps.

1. RSVP is used as signaling protocol in MPLS domain to establish LSPs.
2. MPLS is operating over ATM switches.

Queries:
1. If RSVP request comes from user and it will pass through MPLS domain 
and will terminate at next domain which is not  MPLS aware and supports
ATM interface. In this scenario, how  Egress-edge router in MPLS domain
assign label(channel). Is there any special mechanism required to solve
this problem?

2. In case RSVP request comes from different domain which is not MPLS
aware, but, supports ATM. In this scenario, how to allocate Channel
through  RSVP to forward user data. Is there any special mechanism to
handle this situation?

ANSWER:

Basically, what you seem to be looking for is  interdomain working of RSVP
across MPLS and non-MPLS domains.
                
                PATH ----->
                <---------RESV
RSVP                                    RSVP
IP                                      IP
MPLS                                    ATM
ATM
                
                 ---------
                | EDGE LSR|
                 ---------

                   or
RSVP                                    RSVP
IP                                      IP
ATM                                     MPLS
                                        ATM

In the first case the edge LSR shown is EGRESS for the LSP and in the
second case it is the INGRESS.

In either case according to sections 4.2.2 and 4.1.2 of
<draft-mpls-rsvp-lsp-tunnel-04.txt> the EDGE LSR will eventually know  
through PATHerr or RESVerr (although these are propagated all the way to
the sender/receiver respectively) ,that the adjacent switch is not MPLS
capable, in which case it should forward PATH/RESV msgs accordingly, w/o
the MPLS specific objects (LABEL_REQUEST/LABEL respectively).

Now as far as sending of PATH and RESV msgs themselves ,is concerned, you
could have a PVC configured for sending RSVP control msgs. in the domain.
(ref: "A Framework for Integrated Services and RSVP over ATM" RFC:2382)

In the MPLS domain, the data path (LSP) will be based on the label
(VPI/VCI)  value carried with the RESV msg propagated upstream, while in
the ATM (non-MPLS) domain, the data VC Management can be done using
any of the models described in section 4.2 of RFC 2382.

Regards,
Arthi

---

From: "N.V.Subbarao" <[email-masked]>
Date: Mon, 18 Oct 1999 12:15:34 +0530

Hi All,

I am  looking for is  interdomain working of RSVP across MPLS and non-MPLS domains.

                 PATH ----->
                <---------RESV

RSVP                                    RSVP
IP                                          IP
ATM                                     MPLS
                                            ATM
                  ---------
                | EDGE LSR|
                 ---------
                and

                PATH ----->
                <---------RESV
RSVP                                    RSVP
IP                                          IP
MPLS                                    ATM
ATM

                 ---------
                | EDGE LSR|
                 ---------

In the first case the edge LSR shown is IGRESS for the LSP and in the
second case it is the EGRESS.

My Query is:
How to provide interoperability if both source and destination lies in Non-MPLS
domain and in between an MPLS domain exists.

Thanks in advance
N.V.Subbarao.

---

From: "N.V.Subbarao" <[email-masked]>
Date: Sat, 30 Oct 1999 16:19:02 +0530

Hi arthi,
You are right that in interdomain working of RSVP
across MPLS and non-MPLS domains, there will be an error message
received,.
 in which case it should forward PATH/RESV msgs accordingly, w/o
the MPLS specific objects (LABEL_REQUEST/LABEL respectively).

But, how does the data VCs are decided between MPLS and non-MPLS domains
in this case. These data VCs should also consider the QoS parameters on
these VCs
for each flow as per RSVP negotiations.

Thanks&regards,
N.V.Subbarao