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

From: Charles Chen <[email-masked]>
Date: Thu, 13 Feb 2003 15:45:55 -0800

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:[email-masked]]
> Sent: Thursday, February 13, 2003 3:01 PM
> To: [email-masked]; [email-masked]
> 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
>

---

From: Sameer K <[email-masked]>
Date: Thu, 20 Feb 2003 00:07:47 -0800 (PST)

Thanks for the clarification Charles.  I understand
that this is not an issue for overlay network model
where the peering NEs at each individual layer (in
our example, the routers) have an understanding of
the "layer resources" and interfaces at the same
layer.

But does this argument stay valid for peering model as
well?

- Sameer

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

---

From: Sameer K <[email-masked]>
Date: Thu, 20 Feb 2003 00:15:50 -0800 (PST)

Hello All,

From the RFC 3471 - GMPLS Signaling Functional
Description, Section 9.1.1, it appears that there is
no way for upstream node, to specify component links
that are numbered, in the IF-ID HOP object.

The TLV format for IF-ID Types 4 and 5 assumes that
the component link is always un-numbered.

Is this the way it was planned to be?.  If yes, then
what should IF-ID look like for numbered component
link (which is a valid scenario per the Link Bundling
draft).

Or did I get it all wrong?
TIA
- Sameer