[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
Hi Dimitri,
This means that switching type is not valid when LSP encoding
type is SDH/SONET. Is this true ?
Thank You for ur help.
Regards,
manoj.
>From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
>To: manoj juneja <manojkumarjuneja@hotmail.com>
>CC: zwlin@lucent.com, jdrake@calient.net, Ben.Mack-Crane@tellabs.com,
>kireeti@juniper.net, ccamp@ops.ietf.org
>Subject: Re: Moving right along ... Switching Type
>Date: Thu, 01 Nov 2001 01:30:49 +0100
>
>Hi Manoj,
>
>When Traffic_Parameters are used to create VC-4-Xc LSP for
>instance, Switching Type would take a default value without
>significance on the node switching capability preference since
>inferred by the Traffic_Parameters. So when creating SDH/Sonet
>LSP the Switching Type value will be ignored.
>
>PS: better to rephrase the below sentence as follows:
> > >The usage of this field is thus optional and can (when applicable)
> > >only be considered when traffic parameters are not defined.
>
>Hope this clarifies,
>
>- dimitri.
>
>manoj juneja wrote:
> >
> > Hi Dimitri,
> > Are SDH/SONET traffic params in SNDER_TSPEC optional ? As
> > per my understanding these are mandatory as it gives information
> > regarding SDH/SONET label allocation (i.e. signal type, NCC, NVC, RCC
> > etc). If SDH/SONET traffic parameters are not present then how can I
> > determine these fields i.e. NCC, NVC, RCC, signals etc. from switching
> > type ?
> >
> > Please correct me if I am wrong.
> >
> > Regards,
> > manoj.
> >
> > >From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
> > >To: Zhi-Wei Lin <zwlin@lucent.com>
> > >CC: John Drake <jdrake@calient.net>, "'Ben Mack-Crane'"
> > ><Ben.Mack-Crane@tellabs.com>, Kireeti Kompella <kireeti@juniper.net>,
> > >ccamp@ops.ietf.org
> > >Subject: Re: Moving right along ... Switching Type
> > >Date: Wed, 31 Oct 2001 23:52:16 +0100
> > >
> > >Hi,
> > >
> > >We have two approaches either "traffic-parameters" are used
> > >(in SENDER_TSPEC) then i think the Switching Type capability
> > >is useless or they aren't then such field could be optionaly
> > >used when applicable (some examples are given in the routing
> > >document).
> > >
> > >Wouldn't be the right way to proceed by defining an "unknown"
> > >or "unspecified" value used when "traffic-parameters" are
> > >included within the Path Message and optional use the ones
> > >proposed in the current version of the specification when they
> > >aren't. This field is thus optional and MUST only be used when
> > >traffic parameters are not defined. I think this solves both
> > >approaches.
> > >
> > >I think that also some additional text is needed in order to
> > >clarify the semantic; the following one can be proposed (after
> > >having discussed with some individuals):
> > >"The Switching Type field is provided to allow nodes having
> > >multiple switching layer capabilities to indicate their
> > >preference. This field should only be used to indicate the
> > >link switching preference but not end-to-end switching
> > >preference".
> > >
> > >Notice that some proposal concerning the applicability scope
> > >have been proposed but never really committed within the I-D.
> > >
> > >Cheers,
> > >- dimitri.
> > >
> > >Zhi-Wei Lin wrote:
> > > >
> > > > Hi John,
> > > >
> > > > > <z>The section you mentioned, from what I can tell, is an example
>list
> > > > > of some possible combinations of different equipment functions. I
>see
> > > > > them as examples. But as I said, from routing perspective, it may
>make
> > > > > sense but not signaling. What you've pointed out is the routing
> > >document...
> > > > > From signaling perspective, if I removed the switching capability
> > > > > field, there is nothing lost...do you agree?
> > > > >
> > > > >
> > > > > JD: No. I will try again. What you have to demonstrate is that
>for
> > >all
> > > > > possible combinations of switching capabilities supported on a
>link,
> > >an
> > > > > intermediate node can deduce, from other fields in the Path
>message,
> > >what
> > > > > switching capability is desired.
> > > > >
> > > >
> > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > different switching capabilities on each side and the possible
> > > > connections and then demonstrate that what switching capability is
> > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > encoding type says and the sender_tspec says is what the switching
>type
> > > > used (I'm lazy, it takes too long to run through all the
> > >combinations)</z>
> > > >
> > > > >
> > > > > And if I removed the switching capability field, then it opens the
> > >door
> > > > > for the possibility where somewhere within my network I might
>change
> > >the
> > > > > switching type in order to satisfy a request (because the
>switching
> > >type
> > > > > requested is non-existent or exhausted).</z>
> > > > >
> > > > >
> > > > > JD: Please give an example of where substituting one value of
> > >switching
> > > > > capability for another in the middle of an LSP makes sense.
> > > > >
> > > >
> > > > <z>Well, for example, you have a SONET network that can provide
>STS-48c,
> > > > and it goes through an all-optical network that can provide OCh1
>(2.5G
> > > > service). In the SONET network it switches the STS-48c layer, while
>in
> > > > OTN network it switches the OCh layer. This is very similar to
>E1/VC-12
> > > > connection, where one part of network may work PDH-based and
>switching
> > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > connection or service is essentially the same. They're not really
> > > > client-server layers but similar layers from different
> > >technologies...</z>
> > > >
> > > > > <z>I think it does make sense. I think you have to assume that
>within
> > > > > the switched transport network there will be many kinds of
>interfaces
> > > > > connecting to the transport network. If you can't offer this
> > >capability,
> > > > > then essentially what you've done is segment the transport network
> > >into
> > > > > sub-networks based on what interfaces they have and only the
>like-type
> > > > > interfaces can connect to each other. If you look at the IP world,
>you
> > > > > might have a switch with 100 Mbps and another with 10 Mbps
>connected
> > > > > together and talking to each other without a problem. This is
> > >capability
> > > > > that is also needed, where one end could be 1 Gbps Ethernet and
> > >another
> > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET
>(no
> > > > > reason to restrict this). What really matters is that the service
>is
> > > > > delivered. Granted there will be some inefficiencies in this, but
> > >that's
> > > > > really a policy decision whether users are willing to accept this
>type
> > > > > of connection.</z>
> > > > >
> > > > >
> > > > > JD: What you're describing here is PSC LSPs and they work just
>fine.
> > >What
> > > > > you were describing in your previous example was an LSP, one end
>of
> > >which
> > > > > was
> > > > > PSC and the other end of which was TDM. And that doesn't make
>sense.
> > > > >
> > > >
> > > > <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?
> > > >
> > > > Again, the point here is that if this doesn't make sense, then
> > > > essentially what you have is multiple switched networks, each
>serving
> > > > one particular type of customer interface, i.e., a switched network
>for
> > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > >
> > > > Is this one of those "violent agreements" where we're concentrating
>on
> > > > two different levels but saying the same thing?</z>
> > ><< dimitri.papadimitriou.vcf >>
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
>http://explorer.msn.com/intl.asp
><< dimitri.papadimitriou.vcf >>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp