[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
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
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard