Re: Moving right along ... Switching Type

[Yakov Rekhter <yakov@juniper.net>]

Ewart,

> See embedded comment below.

response in-line...

> 
> 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.

In case you missed it, I'll repeat what I said before:

   Please note that R1 (a router) uses Ethernet encapsulation when
   sending data on the GigE port. Please also note that R2 (also
   a router) expects to have HDLC encapsulation when receiving data
   on its OC-48 port.  As Maarten said in his e-mail, " 1GE port
   on R1 and OC-48 port on R2 "don't speak the same language".

> 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?"

I have even simpler question - how would you carry IP packets over such
an LSP, given that client A is going to encapsulate IP into (FC Network 
Header + LLC/SNAP Header) (see rfc2625), while client B would expect
IP packets to be carried over PPP ? In other words, where in your picture
is the device that converts (FC Network Header + LLC/SNAP) into the
encapsulation used by PPP ?

Yakov.