> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Friday, November 02, 2001 1:49 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ... Switching Type
>
>
> 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".
[EWART]: In the anology I mentioned above, OXC1 possesses a technology conversion function that, in this instance, strips off the layer 1 & 2 headers off each GigE packet, and maps the resulting IP packet, POS encoded onto SONET, changing the LSP encoding type and G-PID accordingly. This function could alternatively be performed by an intermediate (non-GMPLS) device. GMPLS does not currently factor in the presence of such devices, and it is unreasonable to assume that the LSP encoding type and G-PID should remain the same for the length of an LSP.
>
> > 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 ?
[EWART]: The technology conversion device would perform this function - it would strip the LLC/SNAP header, and POS encode the IP packets. The PPP session would be between the technology conversion device and client B in this instance.
>
> Yakov.
>