[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
Zhi,
You may need the "adaptation function descriptor" as an attribute to the
"virtual port" for the CAC and path selection at the source node. Yet, I am not
sure whether this makes things easier or more complicated.
Yangguang
Zhi-Wei Lin wrote:
>
> Hi John, Eric,
>
> I'm not sure if we need to include adaptation function in GMPLS. My
> understanding of the adaptation function is that this is a transport
> level capability for "adapting" or mapping the signal.
>
> From the GMPLS perspective, there is some local action that takes place
> (the magic you mentioned?) to adapt the signal, but the signaling impact
> is simply changing the encoding type and/or GPID and/or the SONET/SDH
> SENDER_TSPEC to another value based on the local adaptation (or no
> change at all)...depends on what adaptation you perform...
>
> I think this has gone beyond switching type discussion...or am I wrong?
>
> Zhi
>
> Eric Gray wrote:
>
> > John,
> >
> > The simplest such proposal is for 'adaptation functions' that are logically
> > distinct from protocol entities to be disallowed. If the adaptation function
> > is required to participate in signaling (either as a direct participant, or through
> > proxy), then a lot of the complexity disappears.
> >
> > You wrote:
> >
> >
> >>"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.
> >>>
> >
> > --
> > Eric Gray (mailto:eric.gray@sandburst.com)
> > http://www.mindspring.com/~ewgray
> >
> >
> >
> >
> >