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

[Sameer K <sameerdw@yahoo.com>]

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
 
--- Charles Chen <cchen@mahinetworks.com> wrote:
> 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
> > 
> 


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