RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS-RSVP

[Charles Chen <cchen@mahinetworks.com>]

It is an interesting question to ask, but it may not be an issue in the real
world. In your example, one can assume that a router A would like to ask the
transport network to set up a PPP link dynamically to a remote router B.
Let's put this in the overlay mode perspective, the router A (edge device)
will request a connection to a core device (OXC). In reality, the router A
has some prior knowledge or is driven by the traffic engineering policy that
it wants to connect to the remote router B. At the minimum, the router A has
to provide the information about the router B (destination address in the
transport network), the path constraints and so on.

It is not possible to build a network that provides all possible application
level information.  The above issue makes no difference from that a user A
establishes a UDP connection in order to transmit JPEG video over it to a
user B. The user A finds out later that the receiving user B only supports
the MPEG coding scheme. Yes, it is a blocking model but scalable.

Charles

> -----Original Message-----
> From: Sameer K [mailto:sameerdw@yahoo.com]
> Sent: Thursday, February 13, 2003 3:01 PM
> To: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Regarding Switching capability and GPID in OSPF-TE and
> GMPLS-RSVP
> 
> 
> Hello All,
> 
> I have some questions regarding switching capability
> descriptor, encoding type and GPID parameters, and the
> correlation between the values signaled in signaling
> request and the values advertised in OSPF TE LSAs.
> 
> From the previous discussions, it appears that if a
> data capable device has to establish LSP through a
> network of OXCs, the switching type requested would be
> FSC, the encoding type would be SDH/SONET with GPID
> being PPP (assuming that the data device that is LSP
> ingress wants to send IP data over the LSP).  Now, the
> LSP will be established without any problem as long as
> the destination node is advertising a switching
> capability FSC and the encoding type SONET/SDH for all
> its interfaces.
> 
> However, for the LSP to be of any use to ingress node,
> the destination must be capable of terminating PPP
> (which in turn requires data capability on the
> incoming interface of egress node).  The way to ensure
> this would be to read GPID and then egress can reject
> the LSP if it cannot support the GPID.
> 
> However, what if destination is a multi-service switch
> and bears certain interfaces that are FSC capable and
> can terminate PPP as well (that is, support data over
> FSC -if you will), other than the FSC only interfaces.
>  CSPF running at ingress can never tell the difference
> between these (data over FSC type) interfaces and
> other (FSC only) interfaces and the LSP might end up
> on an interface that cannot support PPP termination. 
> In such a case, even though the node supports PPP at
> certain interfaces, the LSP will have to be rejected.
> 
> 
> Now, if some "higher layer" information (PPP
> termination capability for this example), is
> advertised as a part of OSPF TE LSAs, the CSPF running
> on the ingress node can pick up the correct incoming
> interface on egress node based on the GPID desired,
> thus reducing the probability of LSP failures.
> 
> Would like to hear opinions.
> TIA
> - Sameer.
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
> http://shopping.yahoo.com
>