RE: Moving right along ... Switching Type

[John Drake <jdrake@calient.net>]

"As mentioned by Zhi, one of the OXCs in the path would
need to do the adaptation from GigE to Ethetnet over GFP"

There is a considerable amount of magic contained in the
above sentence.  I think it's well understood by everyone
what needs to be done.  The more interesting question is
how, and a proposal for how adaptation functions should be
incorporated into GMPLS would be timely.

-----Original Message-----
From: Jonathan Sadler [mailto:Jonathan.Sadler@tellabs.com]
Sent: Friday, November 02, 2001 3:03 PM
To: Yakov Rekhter
Cc: Ewart Tempest; ccamp@ops.ietf.org
Subject: Re: Moving right along ... Switching Type


Yakov, et al -

The OC-48 port could be terminating Ethernet over GFP, in which case PPP
is not in use.  As mentioned by Zhi, one of the OXCs in the path would
need to do the adaptation from GigE to Ethetnet over GFP.  Further,
since GigE is speed wise slower than OC-48, such a configuration would
not generate any service degradation...

Jonathan Sadler

Yakov Rekhter wrote:
> 
> 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.