Re: Moving right along ... Switching Type

[Yangguang Xu <xuyg@lucent.com>]

> Ewart Tempest wrote:
> 
> Yakov,
> 
Ewart,

One way is to abstract the port, so that in OSPF/ISIS-TE database, port =
conventional port info (with attributes) + adaptation functions the port card
can support. This is indeed straightforward because a NE can be views as ports +
switching fabric; here ports are abstract entities that include adaptation
functions. Then CSPF also need to consider this new parameter to calculate an
e2e path.

Yangguang

> See embedded comment below.
> 
> Ewart
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > Sent: Wednesday, October 31, 2001 8:19 PM
> > To: Zhi-Wei Lin
> > Cc: ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... Switching Type
> >
> >
> > Zhi-Wei,
> >
> > > <z>Maybe this is one where we need to ask individuals with
> > operational
> > > experience and have some experience with service
> > provisioning whether
> > > having one end with Ethernet and another end with OC-48
> > sounds like a
> > > configuration that makes sense?
> >
> > Let me see if I understand your proposal. Consider the following
> > example:
> >
> >    R1---OXC1---OXC2----R2
> >
> > where the TE interface on R1 is a collection of GigE ports, and the TE
> > interface on R2 is a collection of OC-48 ports. Are you saying that
> > establishing an LSP between R1 to R2 makes sense ?
> 
> [EWART]: Correct. OXC1 may be capable of performing signal conversion or, more
> likely, there may be some intermediate non-GMPLS device between R1 & OXC1 that
> performs such a conversion (refer to e-mail entitled "Query on Encoding field
> wrt presence of technology conversion devices - OSPF-TE/ISIS-TE extensions",
> 23rd Oct., on which you were copied and which, for the benefit of those that
> were not, I have repeated below) because the OXC has no GigE interface port.
> 
> "Within the GMPLS related routing documents
> (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions),
> there is an Encoding field contained in the Interface Switching Capability
> Descriptor sub-TLV of the Link/IS Reachability TLV.
> 
> My request for GMPLS to support FiberChannel is driven by a need for clients
> to be able to attach to the ASTN using FiberChannel. However, the ASTN devices
> at the edge (e.g. LSR A in the diagram below) may not be equipped with
> FiberChannel ports. In this situation, the FiberChannel coming from the client
> device (client A in the diagram below) has to pass through a technology
> conversion device that maps the FiberChannel to something which LSR A is
> capable of supporting. For example, there are devices readily available on the
> market today that map FiberChannel to POS. Client A is opaque to this
> conversion being done - when client A wants to establish an LSP on the
> FiberChannel link, it does so using FiberChannel based GMPLS signalling (i.e.
> LSP Enc. Type = FiberChannel, G-PID = FC-3) - the signalling is handled by LSR
> A, and not by the non-GMPLS savvy technology conversion device. Similarly, any
> signalling performed by LSR A to client A wrt this same link will use
> FiberChannel based GMPLS signalling, even though the link which manifests
> itself on a FiberChannel port on client A manifests itself on a SONET port on
> LSR A. However, in terms of the GMPLS signalling that LSR A propagates
> downstream, within a SONET based ASTN, this will be SONET based GMPLS
> signalling.
> 
> 
>                             SONET          SONET (LSP Enc. Type = SONET,
>                               |                 G-PID = one of POS*)
>                               |            |             |            |
>                 technology    v            v             v
> v                         client A ------ conversion ------ LSR A ------- LSR
> B ------ LSR C ------- client B
> 
>            ^      device
>            |                        \-------------------------------/
>            |                                          ASTN
>       FiberChannel
>         (LSP Enc. Type = FiberChannel,
>          G-PID = FC-3)
> 
> My question is that in the above instance, the LSP established between client
> A and client B will have an Encoding Type of FiberChannel from client A's
> perspective, and of type SONET from client B's perspective. How do the
> OSPF-TE/ISIS-TE extensions handle the above case?"
> 
> >
> > Yakov.
> >
> >