Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 29 Dec 2001 18:38:42 -0800 Message-ID: <8D96A66B0F50D3119BEF0008C7F31B5B01AFA8B5@UKMSX6> From: "Morgan, Peter (Engineering)" To: "'ccamp@ops.ietf.org'" Subject: GMPLS testing Date: Sun, 30 Dec 2001 02:34:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello, I am presenting a seminar at the All-Optical Networks & GMPLS conference in London in January. My topic is "Examining the key market drivers for the deployment of GMPLS as a control plane in All-Optical Networks". I have written an outline but information available on the Net is limited re case studies, lab trials etc. Any information anyone could provide on these would be appreciated. Thanks, Peter. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Dec 2001 07:25:31 -0800 Message-ID: <3C29EBFD.6C3585FB@npd.hcltech.com> Date: Wed, 26 Dec 2001 20:55:49 +0530 From: Rajaraman B MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Questions Regarding UNI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have the following doubts in UNI Implementation Aggrement. 1) whether there should be two UNI session for source UNI(UNI-C and UNI-N) and destination UNI(UNI-N and UNI-C) respectively while sending Path message, since we need to specify in SESSION object destination Node ID as adjacent UNI-N's node ID in the case source UNI and as adjacent UNI-C's Node ID in the case of destination UNI(when message is sent across NNI to destination UNI-N to destination UNI-C). 2) if there is two session across source and destination UNI, whether SenderTSpec(flowspec in Reservation message) is to be interpreted at UNI-N through some admission control module as in base RSVP(rfc-2205 - using Link Layer Dependent Adaptation Layer in ISI-RSVP implementation source code). 3) what is the purpose of using SenderTSpec and FlowSpec in UNI-RSVP? Whether it is used to specify label range. if that specifies label range, then whether it should be interpreted at UNI-N to check the incoming label(whether it lies in that label range as in the IP-MPLS network) Please clarify. Thanks, Rajaraman. B Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Dec 2001 03:19:43 -0800 Message-ID: <9549DC8CBBA9D411BEFD00062938847B015A9AC6@lat4576.rd.francetelecom.fr> From: LE ROUX Jean-Louis FTRD/DAC/LAN To: "'ccamp@ops.ietf.org '" Subject: SRLG in generalized ISIS Date: Wed, 26 Dec 2001 12:12:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Folks, I have a question regarding the TLV SRLG (138) in "draft-ietf-isis-gmpls-extensions-05.txt" Why is this information included in a separated TLV ? SRLG is a new TE parameter, it is link related, so shouldn't it be encoded in a new sub-TLV, inside TLV 22 ? Thanks in advance JL Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 12:57:19 -0800 Message-Id: <4.3.2.7.2.20011221154720.0686dda0@mo-ex1> Date: Fri, 21 Dec 2001 15:49:24 -0500 To: "Gopal Kailad" From: Lou Berger Subject: Re: Transport networks and draft-ietf-mpls-generalized-rsvp-te [ was Re: GMPLS signaling documents updated per last calls] Cc: "Berger, Lou" ,, ,,,, ,,, ,, ,, ,, , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:38 AM 12/20/2001, Gopal Kailad wrote: >The Restart Time field in the Restart_Cap object supports a >maximum value of about 49 days. In case of transport networks, >this would mean that in case of a controller failure due to say, >a natural disaster, if the node is not accessible, established >connections will fail after 49 days even if data plane is not >affected, which is unacceptable. You're right. This looks like a blown edit. The 0xffffffff value applies to Restart not recovery time. I'll move the text. I'll also elaborate for a bit more clarity. Thanks, Lou Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 11:57:45 -0800 Message-ID: <3C2393D9.BB2A7233@lucent.com> Date: Fri, 21 Dec 2001 14:56:09 -0500 From: George Newsome Organization: Lucent Technologies, Bell Labs MIME-Version: 1.0 To: Dimitri Papadimitriou CC: "Mannie, Eric" , "'Maarten Vissers'" , "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri Papadimitriou wrote: > > Maarten, > ........ > > The agreement "we have a satisfactory solution but not the one proposed > by Maarten/Stephen/etc." so this discussion for me is closed ... but i > think that some people would like to see THEIR OWN solution into the > document the reason is clear for me introduce their own view on the > protocol architecture for distributed control plane restricting us to > use the complexities they have introduced in their own model... sorry > but this was not the aim of the last IETF meeting discussion. > This is almost funny. The whole debate is about getting rid of unnessary and restrictive complexity in your current solution. ......... > > > > It is not only a matter of the signal type field in the draft, it is also a > > matter of how the network is monitored/operated. A SONET signal is not > > always 100% compatible with an SDH signal. It depends on the profile used in > > SDH and SONET. For sure there are different profiles for SONET and SDH (e.g. > > differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood > > that there is a join effort between T1 and ITU to reduce these differences, > > but you cannot assume that everybody will adapt to/implement the latest > > (draft) version of the transport plane standards. > > I would like also to remember here that our target is to achieve an > efficient and interoperable running code, we don't target state of Given your current solution, I can only wish you well > the art transmission system modelling "theory" since in practice state > of the art models are rarely applicable in the real world. Good models are taken from the real world - the one that some of us have worked with for many years. Its hard to see how such models don't apply. (Remember the new economy - the old models didn't apply) > > ... these remarks translates the problem of people working only from > the "theoretical" viewpoint without any pragmatic view on the reality. > Well Dimitri, if you can't deal with Maarten's arguments, at least you can try and call him names. ........ > > For all, if you take a look at the complexity introduced by this model, > call/discovery then connection i more than 100% sure that we are on the > right track here BY KEEPING THINGS SIMPLE. > Again, the best I can do is wish you well with your "simple" model Have a Merry Xmas Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 11:40:11 -0800 Message-Id: <200112211937.fBLJbN640470@merlot.juniper.net> To: Dimitri Papadimitriou cc: "Mannie, Eric" , "'Maarten Vissers'" , "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88346.1008963443.1@juniper.net> Date: Fri, 21 Dec 2001 11:37:23 -0800 From: Yakov Rekhter Dimitri, > Maarten, > > I will add some hints here to the one already pointed out by Eric. > See in-line... [clipped...] > I would like also to remember here that our target is to achieve an > efficient and interoperable running code, we don't target state of > the art transmission system modelling "theory" since in practice state > of the art models are rarely applicable in the real world. > > ... these remarks translates the problem of people working only from > the "theoretical" viewpoint without any pragmatic view on the reality. I certainly agree with the above. And since this is not the first time we are getting into the theory vs practice arguments, to set up the expectations straight and avoid any misunderstanding/confusion I would suggest to put the following disclaimer into the GMPLS document: It is an explicit non-goal of the solution described in this document to address all possible (as well as impossible) requirements. Therefore, the solution described in this document is clearly not a perfect solution, and as such doesn't quality for being a LTSFGTC (Long Term Solution For Generations To Come). Work on the perfect solution (aka LTSFGTC) is in progress, and is expected to be published in RFC100000. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 11:13:54 -0800 Message-ID: <3C23889E.88D573ED@alcatel.be> Date: Fri, 21 Dec 2001 20:08:14 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Mannie, Eric" , "'Maarten Vissers'" CC: "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Content-Type: multipart/mixed; boundary="------------04787838FBA9204781476572" This is a multi-part message in MIME format. --------------04787838FBA9204781476572 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, I will add some hints here to the one already pointed out by Eric. See in-line... "Mannie, Eric" wrote: > > Hello Maarten, > > > It is not the intention to leave the choice of LSP encoding type and SU > label > structure to the vendor. This would give immediate interworking problems. > > Sorry but this comment doesn't make sense. Of course if one implements an > IP-LSR it could not speak SDH ! The vendor has the choice of the type of box > he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of > course we leave the choice of the supported LSP encoding types to the > vendors ! The main question is not the control but the transmission plane. And i would like to strengthen that if (even today) or in future convergence is achieved the current proposal doesn't preclude it at all. In the meantime your Maarten (or ITU since you maintain another confusion here for me) doesn't provide backward comptability. > The label structure is defined in the draft. > > > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, > VC-4-4c/STS-12c, > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP > encoding type "SDH". > > No, not necessarily. Why do you want to reject all SONET implementations ? Again your restricted interpretation. > > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, > VC-4-64c/STS-192c > and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. > > No, not necessarily. Why do you want to reject all SONET implementations ? Probably this one of the key question here. > > Looking at the label text in section 3 of the sonet-sdh document, I find > it very > confusing to read that SONET doesn't use the "U" field. > > This didn't change since 1 or 2 years. > > By the way, I thought that we reached an agreement ? The agreement "we have a satisfactory solution but not the one proposed by Maarten/Stephen/etc." so this discussion for me is closed ... but i think that some people would like to see THEIR OWN solution into the document the reason is clear for me introduce their own view on the protocol architecture for distributed control plane restricting us to use the complexities they have introduced in their own model... sorry but this was not the aim of the last IETF meeting discussion. > > As we indicated before there is no STS type signal that isn't having an > SDH equivalent; i.e. there are no specific higher order SONET signals left. > It is therefore much better to take out the SONET text for the SU label part > altogether. > > It is not only a matter of the signal type field in the draft, it is also a > matter of how the network is monitored/operated. A SONET signal is not > always 100% compatible with an SDH signal. It depends on the profile used in > SDH and SONET. For sure there are different profiles for SONET and SDH (e.g. > differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood > that there is a join effort between T1 and ITU to reduce these differences, > but you cannot assume that everybody will adapt to/implement the latest > (draft) version of the transport plane standards. I would like also to remember here that our target is to achieve an efficient and interoperable running code, we don't target state of the art transmission system modelling "theory" since in practice state of the art models are rarely applicable in the real world. ... these remarks translates the problem of people working only from the "theoretical" viewpoint without any pragmatic view on the reality. > Indeed, I think that we should have much more than just than two LSP > encoding types (SDH and SONET), but that we should in addition indentify > profiles. Having SDH and SONET is a strict minimum. Making mandatory the use > of one single LSP encoding type for both SONET and SDH is lying to the > people. It will make GMPLS impossible to use in practice. > > Anyway, as you said there are different profiles in SDH, and different > profiles in SONET. The difference between SDH and SONET comes from the fact > that they use different profiles (they can also use the same). In the LSP > encoding type, when we use SONET, we mean a different profile than SDH. We > wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't > want. Eric the above remark is clear from the study made on the difference b/w the OH at the Section/RS, Line/MS and Path. I think that we were probably on the right track when having used the versioning of the SDH/Sonet rec's but we took the decision at that time to introduce this profiling into the routing ("the discovery of the interface capabilities"). > If I understood, your idea is to have a second signaling protocol doing a > second pass to setup the profile. Having a control plane with several > signaling round trips and different signaling protocols to setup one single > circuit is a complete mistake from my point of view and from my control > plane design experience. Of course since you want to impose this second > signaling pass, you need to impose a single unique LSP encoding type for > both SDH and SONET so that we will be obliged to use another pass to make > the distinction. I think that now everybody can understand what you have in > mind but don't want to explain. For all, if you take a look at the complexity introduced by this model, call/discovery then connection i more than 100% sure that we are on the right track here BY KEEPING THINGS SIMPLE. > >Otherwise we will get a lot of confusion in the marketplace. > > I think that you are creating the confusion by claiming that there is no > difference at all between SDH and SONET. Strange to see such a remark coming from your side... see below. > > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the > label > with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and > must > thus use the "SDH" SU format. > > We are back at the beginning of the discussion... for the Xth time ! As > usual. ... and after Maarten you friendly tell us that we introduce confusion... is it not the case when you rediscuss many times the same issue for which a decision has been taken and endorsed one or two weeks before ? > Rgds, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, December 19, 2001 9:05 AM > To: Mannie, Eric > Cc: 'jonathan.sadler@tellabs.com'; 'Stephen Trowbridge'; Kireeti > Kompella; ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com > Subject: Re: GMPLS signaling documents updated per last calls > > Eric, > > It is not the intention to leave the choice of LSP encoding type and SU > label > structure to the vendor. This would give immediate interworking problems. > > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, > VC-4-4c/STS-12c, > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP > encoding type "SDH". > > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, > VC-4-64c/STS-192c > and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. > > Looking at the label text in section 3 of the sonet-sdh document, I find it > very > confusing to read that SONET doesn't use the "U" field. As we indicated > before > there is no STS type signal that isn't having an SDH equivalent; i.e. there > are > no specific higher order SONET signals left. It is therefore much better to > take > out the SONET text for the SU label part altogether. Otherwise we will get a > lot > of confusion in the marketplace. > > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the > label > with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and > must > thus use the "SDH" SU format. > > ------- > > All, > > With the clarification on VT-3 given by Deborah, I would request to consider > a > further simplification of the GMPLS standard: delete the LSP encoding type > "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there > would be no ambiguity left at all. > > Regards, > > Maarten > > "Mannie, Eric" wrote: > > > > Hi Jonathan, > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > interoperability problems in the future... > > > > To leave to the manufacturer and to the user the right to decide if he/she > > wants to signal an LSP as either SDH or SONET. There is no > interoperability > > problem at all since you use EITHER SDH OR SONET. If you decide to request > > an SDH signal with what do you want to have interoperability issue at this > > stage ? The sentence means indeed "one should better use SDH than SONET" ! > > Once you decided, there is no issue. > > > > > I'm curious what sort of backward compatability is necessary, as a > > "standard" doesn't exist currently that this needs to be backward > > compatible with... > > > > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with > > the implementations that could not care of SDH, with implementations that > > still do a distinction between SONET and SDH for some reasons, with the > > implementations that could still use the VT3 (DS1C) (I don't have > > confirmation that nobody is using it today, and this is not the goal of > this > > draft to state what is obsolete or not in SONET), etc. > > > > Anyway, there is no issue, the SONET label format is not used until SONET > is > > explicitly requested as such. This is not a primary feature of the draft, > > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for > > everything, consequently you don't care of the SONET label, you skip it in > > the draft, you ignore it, you don't implement it and you just use a full > SDH > > implementation. > > > > I think that the solution is quite simple: if the SONET signal is indeed > an > > SDH signal, why do you bother with SONET ? Just ask for an SDH signal, > > that's all. > > > > By the way, since according to some folks SONET is just a subset of SDH, > why > > do we care about SONET in these documents ? Why don't we simply remove all > > references to SONET ? > > > > Is there somebody on this mailing list that cares about SONET ? If yes, > why > > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ? > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > > Sent: Tuesday, December 18, 2001 9:57 PM > > To: Mannie, Eric > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > > dbrungard@att.com; lberger@movaz.com > > Subject: Re: GMPLS signaling documents updated per last calls > > > > Eric - > > > > Comments inline... > > > > Jonathan Sadler > > > > "Mannie, Eric" wrote: > > > "A SONET signal which has an identical SDH signal SHOULD be requested > > using > > > the same traffic parameters as for the equivalent SDH signal, and will > > > consequently use the SDH label." > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > interoperability problems in the future... > > > > > We spend with Maarten a lot of time to write that sentence (not easy to > > > write). > > > > > > Maybe that it should be better written: > > > > > > "A SONET signal which has an identical SDH signal SHOULD be requested as > > an > > > SDH signal using the same traffic parameters as for the equivalent SDH > > > signal, and will consequently use the SDH label." > > > > Again, "SHOULD" needs to be replaced with "MUST"... > > > > > This doesn't mean that the SONET signal format disappear (simply not > used > > in > > > that case), for backward compatibility we need to keep it. > > > > I'm curious what sort of backward compatability is necessary, as a > > "standard" doesn't exist currently that this needs to be backward > > compatible with... > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Tuesday, December 18, 2001 7:46 PM > > > To: Kireeti Kompella > > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > > bwijnen@lucent.com; sob@harvard.edu > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > Kireeti, > > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > > > (T1X1.5 chair) on this one and I take the liberty of sharing her > response: > > > > > > Deborah Brungard wrote: > > > > The VT3 (3M) structure was defined - but no services (mappings) were > > ever > > > defined for it. So there are no services/equip > > > > with it. My take was if in the future it was ever defined (doubtful), > we > > > would be adding it to g707 also. So then it > > > > would just be part of g707 too. > > > > > > So basically, there are no mappings or equipment functions for this > rate, > > > and as far as we know no network equipment or networks supporting it. > > > Deborah suggests that if we were ever to define such mappings, that this > > > would be proposed for addition to G.707 and hence be part of SDH. > > > > > > I think our agreement had been to use the SDH label for all signals that > > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > > > thought > > > that this was everything except VT3. Given that VT3 seems not to be a > > "real" > > > signal at this point and will likely be added to SDH if it ever becomes > > > real, does our agreement then become that we use SDH labels for > > everything? > > > > > > Regards, > > > Steve > > > > > > Kireeti Kompella wrote: > > > > > > > > Hi Deborah, > > > > > > > > > I previously made the > > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > > > several issues, among them this one. The upshot was that whenever > > > > possible, the SDH label should be used, with the encoding type > > > > set to SDH (i.e., G.707); however, there are signals that have > > > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > > > me!), so we will keep SONET labels and encoding types around > > > > for that case and for legacy equipment. > > > > > > > > The revised SONET/SDH document will contain the exact wording. > > > > I will also be sending a reply to the ITU communication stating > > > > the agreement we came to. > > > > > > > > Kireeti. --------------04787838FBA9204781476572 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------04787838FBA9204781476572-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 09:24:39 -0800 Message-ID: From: "Mannie, Eric" To: 'Heiles Juergen' , ''John Drake' ' , 'Maarten Vissers ' , 'manoj juneja ' Cc: "'ccamp@ops.ietf.org '" Subject: RE: Lambda LSP establishment Date: Fri, 21 Dec 2001 18:21:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, We already discussed it so many times.... FAs and links are two different objects. No routing adjacency over an FA LSP. FAs are optional. You can route a VC-12 without having any FA. You can have mini dummy VC-4 "circuits" just between two adjacent LSRs (VC-4 POH terminated in two adjacent SDH/SONET nodes). These mini dummy VC-4 circuits will not be seen as customer circuits. They don't need to be seen as FAs. Kind regards, Eric -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Thursday, December 20, 2001 11:04 AM To: Mannie, Eric; Heiles Juergen; ''John Drake' '; 'Maarten Vissers '; 'manoj juneja ' Cc: 'ccamp@ops.ietf.org ' Subject: RE: Lambda LSP establishment Hi Eric, thanks for the explanation below. I have some further questions for clarification and I also think an informational I-D would be helpful. You said that from the routing point of view a link and an FA are two different things. There is a routing adjacency "over" a link but not over a FA. I don't see the difference between a "physical link" and a FA as routing can use both to establish a connection. Furthermore for the SDH case if a VC-12 connection is setup via an existing VC-4 connection the VC-4 connection is an FA according to my understanding. However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA, it is a link. Is this correct? From the VC-12 or VC-4 routing view point I don't see a difference between the FA or link. Furthermore the STM-16 connection itself could be transported via an OCh or ODUk in a WDM system. So it is not the physical interface of the equipment. Is it still a link and no FA as from the physical topology only WDM (OTM-n) interfaces are seen. Now concerning the setup of a VC-12 over a STM-16. In this case you use the full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3 connection has to be established prior to the VC-12 connection. Is this implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists. Is it now seen as a FA? Lets have a look on two examples: (1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC (2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4 switching are directly interconnected via a STM-16. In this case the VC-12 label could be defined in relation to the STM-16 interface with the full SUKLM set. In the second example the two 4/1 cross-connects are interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do we need a VC-4 FA in this case between the two 4/1 cross-connects to setup the VC-12 connection? Regards Juergen > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Thursday, December 13, 2001 6:57 PM > To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj > juneja ' > Cc: 'ccamp@ops.ietf.org ' > Subject: RE: Lambda LSP establishment > > > Hi All, > > A few comments, > > >In MPLS the FA establishes "virtual" layer networks. In > GMPLS the layer > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, > OCh, OMS, OTS). A > FA basically corresponds to a real trail in a circuit > switched network. > > Eric: ...and this trail is setup dynamically using GMPLS. That's the > interest. One can think of SDH/SONET FAs as shortcuts or > express-routes. > > >One special thing about the SDH label is, that it includes a > hierarchy as > it identifies the lower order VC in a higher order VC in a > STM-N signal. > Note that this is somehow in contradiction with a statement > in the GMPLS > signaling document which says > > >"A Generalized Label only carries a single level of label, > i.e., it is > non-hierarchical. When multiple levels of label (LSPs > within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > > No, hierarchy of labels is not hierarchy of layers. And even > one should have > a common definition of what means a "layer". This text says > that we cannot > have multiple embedded labels, e.g. one label containting a > label stack. > This is a signaling stuff that doesn't imply anything on the transport > plane. > > Now, a label identifies ONE LSP at an interface. This LSP can > be HO or LO in > SDH. The label can be fully specified or partially specified, > depending on > the context where the LSP is established. > > E.g. when an LSP is established over a FA, the highest part > of the LSP label > is not relevant. When the FA LSP is established the lowest > part of the FA > LSP label is not relevant. > > If a low order LSP is established without any higher order > FA, the label is > fully specified. As you said the link is indeed the "ultimate > FA" in that > case. Except that from the routing point of view a link and > an FA are two > different things. There is a routing adjacency "over" a link > but not over a > FA. > > The SDH/SONET label just includes what you need to include in > each scenario. > > Moreover, the label MUST be interpreted according to the type > of interface > for which it is used. It is possible to code two labels > having the same > value but a complete different meaning. Labels are context > sensitive of > course. > > For instance, an LSP over an STM-0 interface or over a FA > will have the > highest part set to zero, and could possibly have the same > lowest part. You > cannot understand what means the label without knowning the > detail of the > interface. In that case, the interface is either an STM-0 > interface or a > VC-3 FA. And of course that FA and STM-0 interface are two > different things, > but from the LSP point of view, in both cases what it wants > is a VC-3 in > which it can be multiplexed. > > Hope this helps. > > I start to wonder if we should have an informational draft describing > different scenarios of SDH/SONET LSP establishment. That > could complement > the SDH/SONET signaling drafts and the GMPLS architecture. > That could solve > many terminology and modeling issues. > > Kind regards, > > Eric > > -----Original Message----- > From: Heiles Juergen > To: 'John Drake'; Maarten Vissers; manoj juneja > Cc: ccamp@ops.ietf.org > Sent: 12/13/01 11:15 AM > Subject: RE: Lambda LSP establishment > > Let me express my understanding of FAs in MPLS/GMPLS, please > correct me > if I am wrong. I have also some questions related to the label > generation and interactions between layer networks. > > The label in MPLS is local to the link between two adjacent MPLS > switches, it indicates a LSP in this link. This link is therefore the > ultimate FA. An already established LSP between two MPLS > switches, which > don't have to be adjacent, can be used to transport/tunnel other LSPs > between this two nodes. This already established LSP > generates a virtual > adjacency between the two nodes, the FA. As several LSPs can > use this FA > it is also a kind of virtual multiplexing. > If you compare it with a circuit switched network the FA is a server > layer trail that provides transport (a link connection) for > one or more > client layer signals. > In MPLS the FA establishes "virtual" layer networks. In GMPLS > the layer > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, > OTS). A FA basically corresponds to a real trail in a circuit switched > network. > In GMPLS the label is also local to the link between the two devices > that perform the switching. For example for SDH the VC-N is identified > by the STM-N link/port and the SUKLM number according to > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is > identified by > the interface ID (I am not sure on this) and SUKLM is the SDH > label that > locates the VC within the STM-N. > From just the SDH viewpoint the STM-N connection is the > ultimate server > trail/FA. However the STM-N signal could be transported over a Optical > Channel or G.709 ODU. The OCh or ODU can already start in the > equipment > that performs the VC-N switching. So the STM-N signal is not the port, > but the WDM signal is the port and the STM-N signal makes use of a OCh > or ODU server layer trail. This server layer trail can be established > via management or using GMPLS. > Can someone explain how a label for a VC-4 is generated in this case > (pre-established OCh or ODU trail via management or setup > using GMPLS). > This interaction between the different technologies/labels need in my > view some further explanation. > > One special thing about the SDH label is, that it includes a hierarchy > as it identifies the lower order VC in a higher order VC in a STM-N > signal. Note that this is somehow in contradiction with a statement in > the GMPLS signaling document which says > "A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > Following this statement each layer should have its own label > independent of server layers. > The combination of hierarchies in labels is based on technology (e.g. > SDH, Sonet, G.709 ODU) but has in my view no real technical > reason. The > SDH label for example fits to standard STM-N signals, but not > to sub-STM > signals. > For the SDH the full SUKLM number is used if a e.g. VC-12 is > located in > relation to a STM-N interface. If it is located in relation to a VC-4 > (the VC-4 is in this case a FA) SUK are set to 0. For me it > is not clear > in which case I use the first and in which case I use the > second case as > a VC-4 trail is always needed for a VC-12 connection. This > VC-4 could be > established using management or GMPLS. However it should have no > influence on the label. > Some more information is needed in my view in this area. > > > Juergen > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Wednesday, December 12, 2001 6:54 AM > > To: Maarten Vissers; manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: RE: Lambda LSP establishment > > > > > > fortunately, this is just your opinion > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Tuesday, December 11, 2001 9:31 PM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: Lambda LSP establishment > > > > > > Manoj, > > > > Forget the FA stuff, it is not appropriate in circuit > > networks. It only > > applies > > to MPLS. We should remove it when it is used in relation with PDH, > > SDH/SONET, > > OTN and pre-OTN. The text in sdh-sonet draft should state > > that if there is a > > LOVC link (IETF: link bundle/TE link) then the LOVC signals > > use a label with > > "00KLM". > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > The concept of FA is mentioned for SDH/SONET in > > gmpls-sdh > > > -sonet draft. It says that if u have a HOVC trail as a FA > > (advertized > > > as a link) then u can allocate the lower level signals in > > it by making > > > the higher bits of label as 0s (i.e. S and U}. This is fine > > for the same > > > technology. What about the case where the TDM LSP has to > be tunneled > > through > > > the Lambda LSP ? What will be the form of label (i.e. > > {SUKLM} or lambda > > > etc.) ? > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Lambda LSP establishment > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > > > >Manoj, > > > > > > > >You refer to one wavelength to be available between A-E without > > wavelength > > > >conversion capability. This suggests that you operate at > > the OCh layer > > > >network. > > > >Then you specify the capacity of the 4 OCh link > > connections (A-B, B-C, > > C-D, > > > >D-E) > > > >to be "C". Say that C is about 10 Gbit/s. You then assume > > that there is a > > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > > Gbit/s) between C > > and > > > >E. > > > >The result is that the OCh link connections C-D and D-E > > are transporting > > > >the OCh > > > >signal (of e.g. 2.5G). These OCh link connections are now > > in service and > > > >not > > > >longer available to an other OCh connection request. I.e. > > a request for > > an > > > >OCh > > > >connection between A and E will be rejected. > > > > > > > >FAs are not applicable in the circuit layers. IF there is > > a trail in > > server > > > >layer X, then there is a link in its client layer Y. X and > > Y are thus > > > >different > > > >layer networks and signals. > > > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > > be an OCh trail > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > > connection. > > > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > > network. Such is > > not > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >OCh link connections > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I have 5 nodes A, B, C, D and E connected as > > shown. Assume > > > > > that only one wavelength is available on the path A to E (no > > wavelength > > > > > conversion capability is there on the complete path). > > Let the capacity > > > > > of the wavelength be C. Further assume a request arrives for > > connection > > > > > from node C to E for a line capacity of C/4. This > > request will be > > > > > successful as we have available wavelength. Now If > > another request > > > > > comes at node A to establish another connection from > > node A to node E > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > > Should this request > > > > > be successful as we have already allocated the wavelength ? > > > > > > > > > > If the previous connection from C to E of capacity > C/4 had been > > > > > advertised as a FA, in that case will the IInd > request succeed ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 > > had not been > > > > > advertised as FA then what will be the fate of IInd > connection ? > > > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: > http://mobile.msn.com > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 08:38:16 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' Cc: ccamp@ops.ietf.org Subject: RE: protection and restoration [was: Re: Moving right along ... generalized-signaling-06] Date: Fri, 21 Dec 2001 17:34:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Maarten, This is too big this time, usually you are more subtle :-) Last attempt to convince everybody that GMPLS is for pre-OTN only and G.ASON for OTN ? So that GMPLS becomes a secondary and temporary control plane until we have a G.ASON based ITU-T control plane that will be used for everything (and that we will have in several years) :-))) I liked your speech during the IESG plenary when you said that the "GMPLS work just started in CCAMP" and when you presented G.ASON as almost finished. From an honest perspective, it is exactly the opposite. Since one cannot stop GMPLS, let's try to reduce the scope :-))) You complained so many times that nobody is actively proposing GMPLS at the ITU-T. If you could have spent the same energy that you are spending here against GMPLS, rather proposing GMPLS at the ITU-T... The entire community could have saved a lot of time and energy (or at least people on this mailing list :-))) Rgds, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Wednesday, December 19, 2001 2:25 PM To: Mannie, Eric Cc: ccamp@ops.ietf.org Subject: protection and restoration [was: Re: Moving right along ... generalized-signaling-06] Eric, One of the requirements we have to meet is that traffic of user A is not delivered to user B. Also during recovery from a failed connection (either by means of protection swithcing, or restoration) we have to guarantee that user A traffic is not delivered to user B. This adds additional requirements to the operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc architectures; these have a potential to temporarily connect A to B. In protection switching this is guaranteed by means of the combination of protection architecture and protection switching protocol type (1-phase, 2-phase, 3-phase protocols). The tail end normal output #i of the protected domain will never select from the protection connection until it is guaranteed that normal input #i at the head end is bridged onto this protection connection. And vice versa, the tail end will deselect the protection connection before the head end will put a different signal onto that protection connection. I assume that for the case of restoration and fast restoration, the same requirement is applicable. Has this requirement been considered in the work on fast restoration? It looks like "fast restoration" is a control plane based protection switching. Is my understanding correct? If so, with transport plane based protection switching build into SDH/SONET and OTN, is fast restoration being a pre-OTN feature? I assume there is no need to replace SDH/SONET/OTN transport plane based protection switching by control plane based protection switching. As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching defined in the transport plane, pre-OTN has no alternative to control plane based protection. Regards, Maarten "Mannie, Eric" wrote: > > Hello Stephen, > > John refers to fast restoration schemes that are being studied at the IETF. > Such schemes are widely implemented in the new classes of optical/TDM > equipments. > > The wording of the text just need to use the terms "working" LSP and > "protecting" LSP, instead of primary and secondary. That's just an editing > modification. > > The bit itself is useful to qualify the LSP being established. > > The mechanisms to be applied to this qualification will be detailed in other > documents. > > In the mean time, I guess that this bit can be used by implementations for a > simple restoration scheme (e.g. first establish working and protecting LSPs, > resources of protecting LSP may be "soft reserved", i.e. for extra-traffic, > when a fault occur send an RSVP-TE rapid failure notification to the source, > send Path with bit set to "working" on protecting LSP, this kills all LSPs > using these resources, when acked switch to this LSP). > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:38 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > The problem here is that this is not compatible with transport plane > protection. > Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation > of > the protection group is controlled by exchange of the K1, K2 bytes in the > MSOH of the PROTECTION MS. If the control plane reuses the protection MS at > for a different LSP at a time when the state of the protection group is > "No Request" (assuming no extra traffic carried on the protection section in > the > transport plane), this disables the protection since the endpoints of the > protection group are no longer able to exchange K1, K2 over the protection > channel. Even though the payload is unused and irrelevant to the transport > plane at this point, the exchange of overhead is essential to proper > operation > of the protection group. > Regards, > Steve > > John Drake wrote: > > > > Steven, > > > > The basic idea is that if a connection is of type 'secondary', then other > > LSPs of type 'primary' between the same or different source/destination > > pairs MAY use its resources in intermediate nodes, until that LSP is > > converted into a 'primary' with a subsequent Path/Resv flow. At this > point, > > other LSPs that were using its resources may get pre-empted. Think of the > > primary/secondary mechanism as a way to ensure temporal priority while > > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > > is carrying no data. > > > > So in the 1:1 case the protect LSP could be established either as a > primary > > or secondary LSP, while in the 1:N case the protect LSP would be > established > > as a secondary. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 PM > > To: John Drake > > Cc: Maarten Vissers; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > John, > > It would seem from this standpoint, ANY transport plane protection > > must use "primary" for all trails. You have already made this argument > > for the 1+1 case to carry the permanently bridged copy of the payload. > > > > In 1:1 or 1:n, when protection is not being used to carry one/any of > > the normal traffic signals, it may either carry a null signal (no bridge) > > or transport plane extra traffic. Even if the transport plane has only > > a null signal on protection, the control plane cannot itself place extra > > traffic on any portion of the end-to-end protection channel as this is > > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > > The protection channel overhead is chosen to carry the APS since it is > > necessary to exchange APS bytes to complete a switch when working channels > > are failed. If the protection channel has failed and APS cannot be > > exchanged, > > normal traffic signals will not be selected from protection. > > Regards, > > Steve > > > > John Drake wrote: > > > > > > Maarten, > > > > > > That's fine, however it's beside the point. The semantics of > > > Primary/Secondary refer to the control plane and whether the node > > > establishing a given LSP is planning to use it at the time it's > > established > > > or at a later time. As I indicated in an earlier note, 1+1 transport > > plane > > > protection would be accomplished in the control plane by establishing > two > > > LSPs of type Primary. The control plane really doesn't care which LSP > the > > > transport plane is using as Working and which as Protect, although that > > > information is available to the control plane at the LSP endpoints. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Thursday, December 13, 2001 12:15 AM > > > To: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > There exist well defined protection terminology in ITU-T for the > transport > > > plane. "Working" and "Protection" are being used and not > > primary/secondary. > > > E.g. > > > a 1+1 architecture has one working connection, one protection connection > > and > > > a > > > permanent bridge. > > > > > > Besides working/protection indication for the transport entity, there is > > > - "active" and "standby" to indicate if the signal is selected from the > > > working > > > or protection transport entity; i.e. if selector selects from working, > the > > > working is active and protection is standby, if the selector selects > from > > > protection the working is standby and the protection is active. > > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > > > Regards, > > > > > > Maarten > > > > > > neil.2.harrison@bt.com wrote: > > > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > > > neil > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: 12 December 2001 17:46 > > > > > To: 'Ben Mack-Crane'; John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > Ben, > > > > > Please see inline. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > > To: John Drake > > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > > > Regards, > > > > > > Ben > > > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > > > Snipped > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > > To: Lou Berger > > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > > allocated for a > > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > > primary LSP fails > > > > > > > > > over to the secondary LSP." This may not always be > > > > > > the case. An > > > > > > > > > explicit flag indicating whether or not extra > > > > > > traffic may use the > > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > > as indicating > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > > protection the > > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > > being defined > > > > > > > before the protection framework and requirements are > > > > > done. Is this > > > > > > > presupposing some particular outcome of the recovery work in > CAMP? > > > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > > 1+1 and 1:1 > > > > > > > protection, there would be a pair of Primary LSPs between > > > > > the source > > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that > the > > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > > carrying user data > > > > > traffic and it is an endpoint decision as to which path is > > > > > actually the > > > > > working/recovery path. At a transit node, both paths need to > > > > > be treated as > > > > > primary, as the resources are currently being used and > > > > > obviously can't be > > > > > used for Extra Traffic. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 08:04:01 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' Cc: "'jonathan.sadler@tellabs.com'" , 'Stephen Trowbridge' , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: RE: GMPLS signaling documents updated per last calls Date: Fri, 21 Dec 2001 17:02:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, > It is not the intention to leave the choice of LSP encoding type and SU label structure to the vendor. This would give immediate interworking problems. Sorry but this comment doesn't make sense. Of course if one implements an IP-LSR it could not speak SDH ! The vendor has the choice of the type of box he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of course we leave the choice of the supported LSP encoding types to the vendors ! The label structure is defined in the draft. > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP encoding type "SDH". No, not necessarily. Why do you want to reject all SONET implementations ? > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. No, not necessarily. Why do you want to reject all SONET implementations ? > Looking at the label text in section 3 of the sonet-sdh document, I find it very confusing to read that SONET doesn't use the "U" field. This didn't change since 1 or 2 years. By the way, I thought that we reached an agreement ? > As we indicated before there is no STS type signal that isn't having an SDH equivalent; i.e. there are no specific higher order SONET signals left. It is therefore much better to take out the SONET text for the SU label part altogether. It is not only a matter of the signal type field in the draft, it is also a matter of how the network is monitored/operated. A SONET signal is not always 100% compatible with an SDH signal. It depends on the profile used in SDH and SONET. For sure there are different profiles for SONET and SDH (e.g. differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood that there is a join effort between T1 and ITU to reduce these differences, but you cannot assume that everybody will adapt to/implement the latest (draft) version of the transport plane standards. Indeed, I think that we should have much more than just than two LSP encoding types (SDH and SONET), but that we should in addition indentify profiles. Having SDH and SONET is a strict minimum. Making mandatory the use of one single LSP encoding type for both SONET and SDH is lying to the people. It will make GMPLS impossible to use in practice. Anyway, as you said there are different profiles in SDH, and different profiles in SONET. The difference between SDH and SONET comes from the fact that they use different profiles (they can also use the same). In the LSP encoding type, when we use SONET, we mean a different profile than SDH. We wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't want. If I understood, your idea is to have a second signaling protocol doing a second pass to setup the profile. Having a control plane with several signaling round trips and different signaling protocols to setup one single circuit is a complete mistake from my point of view and from my control plane design experience. Of course since you want to impose this second signaling pass, you need to impose a single unique LSP encoding type for both SDH and SONET so that we will be obliged to use another pass to make the distinction. I think that now everybody can understand what you have in mind but don't want to explain. >Otherwise we will get a lot of confusion in the marketplace. I think that you are creating the confusion by claiming that there is no difference at all between SDH and SONET. > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must thus use the "SDH" SU format. We are back at the beginning of the discussion... for the Xth time ! As usual. Rgds, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Wednesday, December 19, 2001 9:05 AM To: Mannie, Eric Cc: 'jonathan.sadler@tellabs.com'; 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Eric, It is not the intention to leave the choice of LSP encoding type and SU label structure to the vendor. This would give immediate interworking problems. VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP encoding type "SDH". VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. Looking at the label text in section 3 of the sonet-sdh document, I find it very confusing to read that SONET doesn't use the "U" field. As we indicated before there is no STS type signal that isn't having an SDH equivalent; i.e. there are no specific higher order SONET signals left. It is therefore much better to take out the SONET text for the SU label part altogether. Otherwise we will get a lot of confusion in the marketplace. Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must thus use the "SDH" SU format. ------- All, With the clarification on VT-3 given by Deborah, I would request to consider a further simplification of the GMPLS standard: delete the LSP encoding type "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there would be no ambiguity left at all. Regards, Maarten "Mannie, Eric" wrote: > > Hi Jonathan, > > > Why SHOULD and not MUST? This ambiguity is likely to create > interoperability problems in the future... > > To leave to the manufacturer and to the user the right to decide if he/she > wants to signal an LSP as either SDH or SONET. There is no interoperability > problem at all since you use EITHER SDH OR SONET. If you decide to request > an SDH signal with what do you want to have interoperability issue at this > stage ? The sentence means indeed "one should better use SDH than SONET" ! > Once you decided, there is no issue. > > > I'm curious what sort of backward compatability is necessary, as a > "standard" doesn't exist currently that this needs to be backward > compatible with... > > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with > the implementations that could not care of SDH, with implementations that > still do a distinction between SONET and SDH for some reasons, with the > implementations that could still use the VT3 (DS1C) (I don't have > confirmation that nobody is using it today, and this is not the goal of this > draft to state what is obsolete or not in SONET), etc. > > Anyway, there is no issue, the SONET label format is not used until SONET is > explicitly requested as such. This is not a primary feature of the draft, > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for > everything, consequently you don't care of the SONET label, you skip it in > the draft, you ignore it, you don't implement it and you just use a full SDH > implementation. > > I think that the solution is quite simple: if the SONET signal is indeed an > SDH signal, why do you bother with SONET ? Just ask for an SDH signal, > that's all. > > By the way, since according to some folks SONET is just a subset of SDH, why > do we care about SONET in these documents ? Why don't we simply remove all > references to SONET ? > > Is there somebody on this mailing list that cares about SONET ? If yes, why > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ? > > Kind regards, > > Eric > > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, December 18, 2001 9:57 PM > To: Mannie, Eric > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > dbrungard@att.com; lberger@movaz.com > Subject: Re: GMPLS signaling documents updated per last calls > > Eric - > > Comments inline... > > Jonathan Sadler > > "Mannie, Eric" wrote: > > "A SONET signal which has an identical SDH signal SHOULD be requested > using > > the same traffic parameters as for the equivalent SDH signal, and will > > consequently use the SDH label." > > Why SHOULD and not MUST? This ambiguity is likely to create > interoperability problems in the future... > > > We spend with Maarten a lot of time to write that sentence (not easy to > > write). > > > > Maybe that it should be better written: > > > > "A SONET signal which has an identical SDH signal SHOULD be requested as > an > > SDH signal using the same traffic parameters as for the equivalent SDH > > signal, and will consequently use the SDH label." > > Again, "SHOULD" needs to be replaced with "MUST"... > > > This doesn't mean that the SONET signal format disappear (simply not used > in > > that case), for backward compatibility we need to keep it. > > I'm curious what sort of backward compatability is necessary, as a > "standard" doesn't exist currently that this needs to be backward > compatible with... > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Tuesday, December 18, 2001 7:46 PM > > To: Kireeti Kompella > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > bwijnen@lucent.com; sob@harvard.edu > > Subject: Re: GMPLS signaling documents updated per last calls > > > > Kireeti, > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > > > Deborah Brungard wrote: > > > The VT3 (3M) structure was defined - but no services (mappings) were > ever > > defined for it. So there are no services/equip > > > with it. My take was if in the future it was ever defined (doubtful), we > > would be adding it to g707 also. So then it > > > would just be part of g707 too. > > > > So basically, there are no mappings or equipment functions for this rate, > > and as far as we know no network equipment or networks supporting it. > > Deborah suggests that if we were ever to define such mappings, that this > > would be proposed for addition to G.707 and hence be part of SDH. > > > > I think our agreement had been to use the SDH label for all signals that > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > > thought > > that this was everything except VT3. Given that VT3 seems not to be a > "real" > > signal at this point and will likely be added to SDH if it ever becomes > > real, does our agreement then become that we use SDH labels for > everything? > > > > Regards, > > Steve > > > > Kireeti Kompella wrote: > > > > > > Hi Deborah, > > > > > > > I previously made the > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > > several issues, among them this one. The upshot was that whenever > > > possible, the SDH label should be used, with the encoding type > > > set to SDH (i.e., G.707); however, there are signals that have > > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > > me!), so we will keep SONET labels and encoding types around > > > for that case and for legacy equipment. > > > > > > The revised SONET/SDH document will contain the exact wording. > > > I will also be sending a reply to the ITU communication stating > > > the agreement we came to. > > > > > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2001 07:12:57 -0800 Message-ID: From: "Mannie, Eric" To: 'Heiles Juergen' , "'ccamp@ops.ietf.org '" Cc: "'dimitri.papadimitriou@alcatel.be '" Subject: RE: Revised GMPLS SONET/SDH drafts Date: Fri, 21 Dec 2001 16:09:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, >a took me a while to detect the agreements related to the label in the updated text as the label section still defines SDH and SONET labels in full details without mentioning the SDH labels should be used also for SONET signals. This new sentence in the introduction is very likely to be forgotten/not noticed and in the end we might get even more confusion/interop problems. I will repeat the agreed sentence once more at the beginning of the section defining the label. >AS you mentioned in one of the other e-mails that the SONET label is kept for interoperability issues with existing implementations (e.g. OIF UNI1.0) No, that's not what I said. By the way, OIF UNI 1.0 is not an implementation but an Implementation Agreement (i.e. a standard from the point of view of a large part of the community). There were also several reasons mentioned in my e-mail. >it would be better to explicitly mention this and have the whole SONET definitions separate. Now you want to have two separate labels ! The SONET and SDH labels are jointly defined since they are very similar up to one given point. I am little bit confused now, you requested many times to have a common definition, and now you don't want it anymore. I will repeat the agreed sentence once more at the beginning of the section defining the label. I hope that we don't have to repeat each sentence twice in a standard, otherwise all RFCs will be twice longer :-) >At the end of the label section a new paragraph is added concerning transparent concatenated STM-N signals. Yes, it was requested during the last last call for clarification (by Manoj or you, I don't remember). >I assume this is a signal with signal type STM-N/STS-3*N, transparency flag set and NCC>1. No, NCC = 1 as defined in the NCC section (note 2). >This leads to two questions: >What is the SUKLM label for a transparent STM-N without concatenation explicitly requested (Do we need a SUKLM label at all)? In that example the label is exactly the same with or without concatenation, with or without transparency. We added this paragraph because we were told (by you ?) that the other cases were obvious but that this one (i.e. STM-N, transparency and concatenation) was not... Anyway, I will add "with or without" to further further clarify. As far as I know one always need a label with GMPLS, simply because the protocol and the code assume that a label will be returned in all cases. Simple. >Why is the case of transparency + contiguous concatenation (actually a contradiction in it self) special from the general transparency case and has to be mentioned. We already discussed this and I already answered several times. I don't have something more to say than the last time (and you didn't ask more :-). Kind regards, Eric -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Thursday, December 20, 2001 1:08 PM To: Mannie, Eric; 'ccamp@ops.ietf.org ' Cc: 'dimitri.papadimitriou@alcatel.be ' Subject: RE: Revised GMPLS SONET/SDH drafts Hi Eric, a took me a while to detect the agreements related to the label in the updated text as the label section still defines SDH and SONET labels in full details without mentioning the SDH labels should be used also for SONET signals. This new sentence in the introduction is very likely to be forgotten/not noticed and in the end we might get even more confusion/interop problems. AS you mentioned in one of the other e-mails that the SONET label is kept for interoperability issues with existing implementations (e.g. OIF UNI1.0) it would be better to explicitly mention this and have the whole SONET definitions separate. At the end of the label section a new paragraph is added concerning transparent concatenated STM-N signals. I assume this is a signal with signal type STM-N/STS-3*N, transparency flag set and NCC>1. This leads to two questions: What is the SUKLM label for a transparent STM-N without concatenation explicitly requested (Do we need a SUKLM label at all)? Why is the case of transparency + contiguous concatenation (actually a contradiction in it self) special from the general transparency case and has to be mentioned. The STM-0 SUKLM definition (S=0) is different from the STS-1 definition (S=1), also both are the same signal. As the STM-0 definition was just introduced it could have been made the same as the existing STS-1 definition. Regards Juergen > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Friday, December 14, 2001 1:00 AM > To: 'ccamp@ops.ietf.org ' > Cc: 'dimitri.papadimitriou@alcatel.be ' > Subject: Revised GMPLS SONET/SDH drafts > > > > Dear All, > > Please find attached the two GMPLS SDH/SONET drafts revised > according to the > comments received during the last period of comments, and > during the Salt > Lake City meeting: > > - draft-ietf-ccamp-gmpls-sonet-sdh-03.txt > - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt > > Please, send your comments to the mailing list AND to us. > > Kind regards, > > Eric and Dimitri > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 17:18:19 -0800 From: "Raju Venkatraman" To: pingpan@juniper.net, David.Charlap@marconi.com, ccamp@ops.ietf.org Cc: mpls@UU.NET Bcc: Subject: Re: Reception of RSVP packets at intermediate node Date: Fri, 21 Dec 2001 01:16:40 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can someone point me to these SunOS patches that were required to fix the problem of RSVP packets interception and reception at intermedite nodes. Are they publically available at some site????? How does the other protable implementations take care of it when they run over SunOS/Solaris??? Which socket option they use? Any help shall be greatly appreciated. Regards. Raju >From: Ping Pan >To: David Charlap >CC: mpls@UU.NET >Subject: Re: Reception of RSVP packets at intermediate node >Date: Thu, 13 Dec 2001 15:45:34 -0800 > >Hi, > >There are several ways to receive RSVP Path messages (the Resv messages >can be sent hop-by-hop): > >1. Both FreeBSD and Linux have modified the IP forwarding in the kernel >to send/receive IP Router Alert packets via a raw socket. > >2. You can also use ipfw to define some filters to intercept the messages. > >3. In my past life, I had written a kernel extension for FreeBSD that >can intercept all sort of IP option packets via a new socket family. >Check http://www.cs.columbia.edu/~pingpan/software_list.htm > >4. I recall Don Hoffman and Mike Speer had done SunOS patches. Check >http://www.isi.edu/div7/rsvp/release.html > >Take care! > >- Ping > > > >David Charlap wrote: > >>Raju Venkatraman wrote: >> >>>I'd appreciate any help to my question. >>> >>>Is there a socket option to intercept and receive RSVP protocol >>>messages at intermediate node on Sun Solaris [reception of packets >>>not destined to this intermediate node]? >>> >> >>Sounds like this question would be better asked on a forum for Solaris >>programming. Perhaps comp.unix.programmer, comp.unix.solaris, or one of >>the comp.sys.sun groups. >> >>I am, unfortunately not familiar with Solaris, but I seem to remember >>that a kernel patch was required to make router alert work on SunOS >>version 4.x. A similar patch may be required for Solaris. >> >>-- David >> >> > > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 14:51:38 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Fwd: Issue in Label Set Object structure Date: Thu, 20 Dec 2001 15:50:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Re-sending it .... Hi All, There seems to be some issue with the label set format. Can I include the virtually concatenated SDH/SONET signal in the label set ? If I want to have multiple subchannel elements in the label set (basically a set of labels in the label set instead of range) then how to determine that how many # of 4 byte octets comprise one virtual concatenated signal ? Or Is it that the subchannel element within the label set will also include the object header for generalized label ? Please let me know if I am missing something. Regards, manoj. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 12:28:54 -0800 From: "manoj juneja" To: sudheer@nayna.com Cc: dimitri.papadimitriou@alcatel.be, lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org Bcc: Subject: Re: Fwd: Comments on GMPLS signalling drafts Date: Wed, 19 Dec 2001 22:45:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Sudheer, I fully support your idea. My only concern was to atleast list down the features in the specifications/drafts that are 100 % complete and IETF community is in full or rough consensus and also the list of features (i.e. bandwidth modification and waveband) which are under study/discussion (for which agreement yet to be made). Furthermore, the bandwidth modification of all the technologies should be mentioned (not only TDM). If IETF is currently considering the bandwidth modification of TDM LSPs and want to start on the bandwidth modification of other technologies later on then this should be mentioned too. Regards, manoj. >From: Sudheer Dharanikota >To: manoj juneja >CC: dimitri.papadimitriou@alcatel.be, lberger@movaz.com, >Eric.Mannie@ebone.com, ccamp@ops.ietf.org >Subject: Re: Fwd: Comments on GMPLS signalling drafts >Date: Wed, 19 Dec 2001 17:59:49 -0800 > >Hi Manoj: > >You are asking for improvising GMPLS documents on bandwidth modification, >which is still in infacy stage at ITU. We should draw line some where, >as to which features will go into first version of the GMPLS standard. > >- sudheer > > >manoj juneja wrote: > > > Hi Dimitri, > > My main concern was that if some topic is still being > > discussed (like waveband and bandwidth modification for TDM LSPs), it > > should be mentioned in the drafts that these sections are still not > > complete and are under discussions/further study. To a reader of the > > GMPLS drafts it should be clear that what all features are fully > > specified by the IETF and there is no further conflict in the industry. > > I still feel that there should be some reference for the bandwidth > > modification for all the technologies (SDH/SONET, LSC and FSC) in the > > drafrs. > > > > After reading the drafts one can question that : > > > > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then > > how ? Even one can question that is it under the scope of GMPLS ? > > > > These comments are just for completeness of the drafts before proceeding >to > > the RFC status. > > > > Regards, > > manoj. > > > > >From: Dimitri Papadimitriou > > >To: manoj juneja > > >CC: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > >Date: Wed, 19 Dec 2001 18:35:55 +0100 > > > > > >Manoj, > > > > > >On the following "bandwidth modification" and "waveband switching": > > > > > >The first one is an ongoing topic discussed for instance in > > > >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > >that will be reviewed and updated for the next upcoming meetings > > > > > >On "waveband switching" the question is do we consider something > > >further than what's already included in the version -07.txt. We > > >have provided for this purpose some ideas in: > > > >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt > > > > > >CCAMP (and IETF) community should tell us if it is worth going on > > >with the latter topic. If there is any interest, etc. But anyhow > > >this is for further discussion (i.e. not within the scope of the > > >current last call). It is now greatly time to move on (as said by > > >Lou)... > > > > > >Regards, > > >- dimitri. > > > > > >manoj juneja wrote: > > > > > > > > Hi Lou/Eric/Dimitri, > > > > > > > > Please see the following para from gmpls-architecture draft : > > > > > > > > "LSP modification consists in changing some LSP parameters, but > > > > normally without changing the route. It is supported using the > > > > same mechanism as re-routing. However, the semantic of LSP > > > > modification will differ from one technology to the other. For > > > > instance, further studies are required to understand the impact > > > > of dynamically changing some SDH/SONET circuit characteristics >such > > > > as the bandwidth, the protection type, the transparency, the > > > > concatenation etc." > > > > > > > > If u say that SE style of reservation is supported then how are u >going > > >to > > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one > > >assign > > > > diferent labels (labels are the physical resources on the link) to > > >different > > > > senders that belong to the same RSVP session. Is it that the SE >style > > >of > > > > reservation only supported to modify the bandwidth of LSP ? Can I >modify > > >the > > > > bandwidth of LSC/FSC LSP ? If yes then how ? > > > > > > > > Do u people think that waveband section is compelte in the drafts ? > > > > > > > > Please see other comments inline. > > > > > > > > Regards, > > > > manoj. > > > > > > > > >From: Lou Berger > > > > >To: "manoj juneja" > > > > >CC: ,, > > > > > > > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > > > > > > > >see comments inline. > > > > > > > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > > > > > > > > > > > > > >> >From: "manoj juneja" > > > > >> >To: ccamp@ops.ietf.org > > > > >> >Subject: Comments on GMPLS signalling drafts > > > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > > >> > > > > > >> >Hi All, > > > > >> > > > > > >> >1. SE-style supported by GMPLS or not ? > > > > >> > > > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > > > >>As labels are the resources on the link, one can't allocate >different > > > > >> >label to different senders in the same RSVP session. > > > > >> > > > > > > > > > > >I don't think you fully understand SE. I suggest you read the base > > > > >documents. (2205 and RSVP-TE) > > > > > > > > > >> > > > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > > > > >> >separate draft for TDM LSP bandwidth modification but what about >the > > > > >> >bandwidth modification for other types of LSPs ? There is no >mention > > >of > > > > >> >these in any of the GMPLS drafts. > > > > >> > > > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > > > >> > > > > >> >3. It should be mentioned clearly that waveband section is still >not > > > > >> >complete in the drafts. > > > > >> > > > > > > > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. >What > > > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS > > >signalling > > > > >> >drafts ? > > > > >> > > > > > > > > > > >It's still in, see the drafts for explanations. > > > > > > > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and > > >Upstream > > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling >draft. > > >Do > > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is >there > > >any > > > > reason for keeping these ? > > > > > > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned >in > > >the > > > > >> >drafts (because it is a special case). > > > > >> > > > > > > > > > > >the sonet draft is the right place for this. I defer to Eric on >this. > > > > > > > > > [Manoj]: Thanks for putting this info in the new version of the >draft. > > > > >> > > > > >> >6. It should be mentioned that bandwidth encoding parameter is > > >useful > > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > > > >> > > > > > [Manoj]: I think u should include what all technologies will make >use of > > > > this parameter. > > > > > > > > >> >7. There is an example scenario for contention resolution in >case of > > >bi- > > > > >> >directional LSPs. It should be mentioned that : > > > > >> > > > > > >> >"contention resolution is an optimization, not a correctness >issue > > >... > > > > >> >and no procedure can provide optimal resolution in all cases. An > > > > >> >implementor > > > > >> >may do differently to provide better resolution." > > > > >> > > > > > >> >The above quotes are extracted from one of the mails from Fong >Liaw. > > > > >> > > > > > >> >If this is the case then this should be mentioned in the drafts. > > > > >> > > > > > > > > > > >Read the Acknowledgments section of the draft. (I'm sure Fong will >be > > > > >happy to see you protecting her interests!) > > > > > > > > > >> > > > > >> >8. The LSP hierarchy concept is still not clear. Some days back >I > > >posted > > > > >> >one > > > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the > > >concept > > > > >>of > > > > >> >forwarding adjacency and different people replied with different > > > > >>thoughts. > > > > >> >Does this mean this concept is not standardized in GMPLS ? > > > > >> >My question was : > > > > >> > > > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > > > > >> >established from A to D and if a new TDM LSP request comes to >node A > > > > >> >which is to be tunneled through the already established lambda > > >FA-LSP > > > > >> >then the node A sends the Path/label request message directly to > > >node > > > > >> >D. What label the node D will send back to node A in the >RESV/label > > > > >> >mapping message since the FA-LSP is just one label (lambda) ? >Does > > >it > > > > >> >mean that all the LSPs which are tunneled through the lambda >FA-LSP > > > > >> >will be allocated the same label by node D to node A ? If this >type > > >of > > > > >> >scenario can't exist in GMPLS then please let me know that too." > > > > > > > > > >I believe this topic is being covered in other threads. > > > > > > > > > >> > > > > > >> > > > > > >> >Regards, > > > > >> >manoj. > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > >_________________________________________________________________ > > > > >> >Join the world s largest e-mail service with MSN Hotmail. > > > > >> >http://www.hotmail.com > > > > >> > > > > > >> > > > > > >> > > > > >>_________________________________________________________________ > > > > >>Get your FREE download of MSN Explorer at > > > > > >>http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world’s largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > ><< dimitri.papadimitriou.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com ><< sudheer.vcf >> _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 10:44:27 -0800 From: "manoj juneja" To: sudheer@nayna.com Cc: dimitri.papadimitriou@alcatel.be, lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org Bcc: Subject: Re: Fwd: Comments on GMPLS signalling drafts Date: Thu, 20 Dec 2001 11:37:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Sudheer, I fully agree with you. My concern was to list down the GMPLS features which are completely/fully specified by IETF and are agreed upon by the IETF community and there is no further conflict for these in the industry. Furthermore, these drafts should also list down the features (in GMPLS functional Specification draft) which are under discussion/study and the consensus is yet to be reached. The inclusion of these is very important and going to help the implementors of GMPLS before moving forward for RFC status. Regards, manoj. >From: Sudheer Dharanikota >To: manoj juneja >CC: dimitri.papadimitriou@alcatel.be, lberger@movaz.com, >Eric.Mannie@ebone.com, ccamp@ops.ietf.org >Subject: Re: Fwd: Comments on GMPLS signalling drafts >Date: Wed, 19 Dec 2001 17:59:49 -0800 > >Hi Manoj: > >You are asking for improvising GMPLS documents on bandwidth modification, >which is still in infacy stage at ITU. We should draw line some where, >as to which features will go into first version of the GMPLS standard. > >- sudheer > > >manoj juneja wrote: > > > Hi Dimitri, > > My main concern was that if some topic is still being > > discussed (like waveband and bandwidth modification for TDM LSPs), it > > should be mentioned in the drafts that these sections are still not > > complete and are under discussions/further study. To a reader of the > > GMPLS drafts it should be clear that what all features are fully > > specified by the IETF and there is no further conflict in the industry. > > I still feel that there should be some reference for the bandwidth > > modification for all the technologies (SDH/SONET, LSC and FSC) in the > > drafrs. > > > > After reading the drafts one can question that : > > > > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then > > how ? Even one can question that is it under the scope of GMPLS ? > > > > These comments are just for completeness of the drafts before proceeding >to > > the RFC status. > > > > Regards, > > manoj. > > > > >From: Dimitri Papadimitriou > > >To: manoj juneja > > >CC: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > >Date: Wed, 19 Dec 2001 18:35:55 +0100 > > > > > >Manoj, > > > > > >On the following "bandwidth modification" and "waveband switching": > > > > > >The first one is an ongoing topic discussed for instance in > > > >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > >that will be reviewed and updated for the next upcoming meetings > > > > > >On "waveband switching" the question is do we consider something > > >further than what's already included in the version -07.txt. We > > >have provided for this purpose some ideas in: > > > >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt > > > > > >CCAMP (and IETF) community should tell us if it is worth going on > > >with the latter topic. If there is any interest, etc. But anyhow > > >this is for further discussion (i.e. not within the scope of the > > >current last call). It is now greatly time to move on (as said by > > >Lou)... > > > > > >Regards, > > >- dimitri. > > > > > >manoj juneja wrote: > > > > > > > > Hi Lou/Eric/Dimitri, > > > > > > > > Please see the following para from gmpls-architecture draft : > > > > > > > > "LSP modification consists in changing some LSP parameters, but > > > > normally without changing the route. It is supported using the > > > > same mechanism as re-routing. However, the semantic of LSP > > > > modification will differ from one technology to the other. For > > > > instance, further studies are required to understand the impact > > > > of dynamically changing some SDH/SONET circuit characteristics >such > > > > as the bandwidth, the protection type, the transparency, the > > > > concatenation etc." > > > > > > > > If u say that SE style of reservation is supported then how are u >going > > >to > > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one > > >assign > > > > diferent labels (labels are the physical resources on the link) to > > >different > > > > senders that belong to the same RSVP session. Is it that the SE >style > > >of > > > > reservation only supported to modify the bandwidth of LSP ? Can I >modify > > >the > > > > bandwidth of LSC/FSC LSP ? If yes then how ? > > > > > > > > Do u people think that waveband section is compelte in the drafts ? > > > > > > > > Please see other comments inline. > > > > > > > > Regards, > > > > manoj. > > > > > > > > >From: Lou Berger > > > > >To: "manoj juneja" > > > > >CC: ,, > > > > > > > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > > > > > > > >see comments inline. > > > > > > > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > > > > > > > > > > > > > >> >From: "manoj juneja" > > > > >> >To: ccamp@ops.ietf.org > > > > >> >Subject: Comments on GMPLS signalling drafts > > > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > > >> > > > > > >> >Hi All, > > > > >> > > > > > >> >1. SE-style supported by GMPLS or not ? > > > > >> > > > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > > > >>As labels are the resources on the link, one can't allocate >different > > > > >> >label to different senders in the same RSVP session. > > > > >> > > > > > > > > > > >I don't think you fully understand SE. I suggest you read the base > > > > >documents. (2205 and RSVP-TE) > > > > > > > > > >> > > > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > > > > >> >separate draft for TDM LSP bandwidth modification but what about >the > > > > >> >bandwidth modification for other types of LSPs ? There is no >mention > > >of > > > > >> >these in any of the GMPLS drafts. > > > > >> > > > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > > > >> > > > > >> >3. It should be mentioned clearly that waveband section is still >not > > > > >> >complete in the drafts. > > > > >> > > > > > > > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. >What > > > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS > > >signalling > > > > >> >drafts ? > > > > >> > > > > > > > > > > >It's still in, see the drafts for explanations. > > > > > > > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and > > >Upstream > > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling >draft. > > >Do > > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is >there > > >any > > > > reason for keeping these ? > > > > > > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned >in > > >the > > > > >> >drafts (because it is a special case). > > > > >> > > > > > > > > > > >the sonet draft is the right place for this. I defer to Eric on >this. > > > > > > > > > [Manoj]: Thanks for putting this info in the new version of the >draft. > > > > >> > > > > >> >6. It should be mentioned that bandwidth encoding parameter is > > >useful > > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > > > >> > > > > > [Manoj]: I think u should include what all technologies will make >use of > > > > this parameter. > > > > > > > > >> >7. There is an example scenario for contention resolution in >case of > > >bi- > > > > >> >directional LSPs. It should be mentioned that : > > > > >> > > > > > >> >"contention resolution is an optimization, not a correctness >issue > > >... > > > > >> >and no procedure can provide optimal resolution in all cases. An > > > > >> >implementor > > > > >> >may do differently to provide better resolution." > > > > >> > > > > > >> >The above quotes are extracted from one of the mails from Fong >Liaw. > > > > >> > > > > > >> >If this is the case then this should be mentioned in the drafts. > > > > >> > > > > > > > > > > >Read the Acknowledgments section of the draft. (I'm sure Fong will >be > > > > >happy to see you protecting her interests!) > > > > > > > > > >> > > > > >> >8. The LSP hierarchy concept is still not clear. Some days back >I > > >posted > > > > >> >one > > > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the > > >concept > > > > >>of > > > > >> >forwarding adjacency and different people replied with different > > > > >>thoughts. > > > > >> >Does this mean this concept is not standardized in GMPLS ? > > > > >> >My question was : > > > > >> > > > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > > > > >> >established from A to D and if a new TDM LSP request comes to >node A > > > > >> >which is to be tunneled through the already established lambda > > >FA-LSP > > > > >> >then the node A sends the Path/label request message directly to > > >node > > > > >> >D. What label the node D will send back to node A in the >RESV/label > > > > >> >mapping message since the FA-LSP is just one label (lambda) ? >Does > > >it > > > > >> >mean that all the LSPs which are tunneled through the lambda >FA-LSP > > > > >> >will be allocated the same label by node D to node A ? If this >type > > >of > > > > >> >scenario can't exist in GMPLS then please let me know that too." > > > > > > > > > >I believe this topic is being covered in other threads. > > > > > > > > > >> > > > > > >> > > > > > >> >Regards, > > > > >> >manoj. > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > >_________________________________________________________________ > > > > >> >Join the world s largest e-mail service with MSN Hotmail. > > > > >> >http://www.hotmail.com > > > > >> > > > > > >> > > > > > >> > > > > >>_________________________________________________________________ > > > > >>Get your FREE download of MSN Explorer at > > > > > >>http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Join the world’s largest e-mail service with MSN Hotmail. > > > > http://www.hotmail.com > > ><< dimitri.papadimitriou.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com ><< sudheer.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 09:09:17 -0800 Subject: RE: GMPLS signaling documents updated per last calls Date: Thu, 20 Dec 2001 12:00:48 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624016DE34A@OCCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: GMPLS signaling documents updated per last calls Thread-Index: AcGIs/WL3pHFk/SkEdWjbgCQJ60IGQAuuezg content-class: urn:content-classes:message From: "Brungard, Deborah A, ALCTA" To: "Dimitri Papadimitriou" , "Maarten Vissers" Cc: "Mannie, Eric" , , "Stephen Trowbridge" , "Kireeti Kompella" , , I will be brief... It was my understanding (from AT&T participants), there was agreement = for ITU and IETF to work together. As this discussion is clearly on = ITU/T1X1 standards and it is questioning individuals' interpretations of = those standards, the discussion should go (liaison) to ITU. And as = T1X1.5's chair, if questions on our standards, please liaison. Quick response on items addressed to my comments: - I have commented since last summer that sonet was a subset of sdh = (ITU-T G.707). And several months ago, when the VT3 was cited as = preventing the merging of the labels, I commented over the exploder, = that the VT3 had never been defined. Yes, Juergen, it can be deleted = from T1.105 - T1X1.5 is contribution based - it never was viewed as any = priority for clean-up;-) - 10 years ago, there was interest in having local standards. For the = last several years, this environment has changed among participants in = T1X1/ETSI/ITU. ANSI T1.105 was updated to reflect ITU-T terminology. It = maintains the SONET terminology for legacy equipment/people. In T1X1, = for the Optical Networking standards, we have chosen to use ITU-T = terminology. Important note - for T1/ITU - it is terminology - the = functionality is the same. Whereas, the use of differing GMPLS labels, = will impact implementations (and require gateways). IF the majority of = IETF/OIF want to maintain local implementations, than as in any = democratic forum, the majority's view holds (on the OIF documents, AT&T = made the same comment: use ITU-T terminology). - yes, we do have ANSI, ETSI, and ITU standards. It is based on = governments - not technical. As I said above, all efforts are to align = (no differences for LCAS). As for GR253, I do not know what is defined. = It is maintained by a private company. It is not an official standards = body. If your company funds the work/buys the product, your company can = reference it. If your comment is saying to reference the GR in the IETF = standard, you may want to check on copyrights. I view it similar to = buying a reference book on SONET. And I do not accept everything in a = book unconditionally;-) I do not see this discussion as useful for resolving the label = disagreements. If the IETF editors have final interpretation - than = that's the decision. Otherwise liaison the appropriate groups. Deborah > -----Original Message----- > From: Dimitri Papadimitriou [SMTP:dimitri.papadimitriou@alcatel.be] > Sent: Wednesday, December 19, 2001 12:37 PM > To: Maarten Vissers > Cc: Mannie, Eric; 'jonathan.sadler@tellabs.com'; 'Stephen Trowbridge'; = Kireeti Kompella; ccamp@ops.ietf.org; Brungard, Deborah A, ALCTA; = lberger@movaz.com > Subject: Re: GMPLS signaling documents updated per last calls >=20 > This discussion is going into limbos because once a solution =20 > is provided and agreed by all parties, afterwards the elements=20 > having enabled to come up to this decision disappear... for > instance, VT3 SPE now are not used anymore... were they used=20 > one week before and just stop now ?=20 >=20 > Mor generally, since it is not the job of the CCAMP community to=20 > verify if the content of ITU/T1X1 specifications are implemented=20 > in current networks it is for me irrelevant to state as done by=20 > Stephen that they are not used. How can i verify such assertion ? >=20 > At the end of the day i have got the following impression ITU > T1 people blind the differences they maintain in their own > documents... Deborah/Stephen sorry but GR.253 specification has=20 > just been extended to LCAS capabilities so T1X1 and ITU maintains > their own version (G.707 is also being extended)... in this=20 > context sorry but we are at a point where people maintains=20 > artificial discussions for reasons which are very difficult=20 > to understand ?=20 >=20 > Very interesting the following e-mail from Maarten, why do i=20 > have to keep two terms in order to translate the same entity>=20 > if Sonet is a subset of SDH ?=20 >=20 > Cheers, > - dimitri. >=20 > Maarten Vissers wrote: > >=20 > > Eric, > >=20 > > It is not the intention to leave the choice of LSP encoding type and = SU label > > structure to the vendor. This would give immediate interworking = problems. > >=20 > > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, = VC-4-4c/STS-12c, > > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all = have LSP > > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have = the LSP > > encoding type "SDH". > >=20 > > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, = VC-4-64c/STS-192c > > and VC-4-256c/STS-768c must all have the same SDH-based "SU" = structure. > >=20 > > Looking at the label text in section 3 of the sonet-sdh document, I = find it very > > confusing to read that SONET doesn't use the "U" field. As we = indicated before > > there is no STS type signal that isn't having an SDH equivalent; = i.e. there are > > no specific higher order SONET signals left. It is therefore much = better to take > > out the SONET text for the SU label part altogether. Otherwise we = will get a lot > > of confusion in the marketplace. > >=20 > > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use = the label > > with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in = SDH and must > > thus use the "SDH" SU format. > >=20 > > ------- > >=20 > > All, > >=20 > > With the clarification on VT-3 given by Deborah, I would request to = consider a > > further simplification of the GMPLS standard: delete the LSP = encoding type > > "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". = Then there > > would be no ambiguity left at all. > >=20 > > Regards, > >=20 > > Maarten > >=20 > > "Mannie, Eric" wrote: > > > > > > Hi Jonathan, > > > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > > interoperability problems in the future... > > > > > > To leave to the manufacturer and to the user the right to decide = if he/she > > > wants to signal an LSP as either SDH or SONET. There is no = interoperability > > > problem at all since you use EITHER SDH OR SONET. If you decide to = request > > > an SDH signal with what do you want to have interoperability issue = at this > > > stage ? The sentence means indeed "one should better use SDH than = SONET" ! > > > Once you decided, there is no issue. > > > > > > > I'm curious what sort of backward compatability is necessary, as = a > > > "standard" doesn't exist currently that this needs to be backward > > > compatible with... > > > > > > Backward compatibility with the OIF UNI 1.0 Implementation = Agreement, with > > > the implementations that could not care of SDH, with = implementations that > > > still do a distinction between SONET and SDH for some reasons, = with the > > > implementations that could still use the VT3 (DS1C) (I don't have > > > confirmation that nobody is using it today, and this is not the = goal of this > > > draft to state what is obsolete or not in SONET), etc. > > > > > > Anyway, there is no issue, the SONET label format is not used = until SONET is > > > explicitly requested as such. This is not a primary feature of the = draft, > > > but a *secondary feature*, for SONET lovers. Otherwise, SDH is = used for > > > everything, consequently you don't care of the SONET label, you = skip it in > > > the draft, you ignore it, you don't implement it and you just use = a full SDH > > > implementation. > > > > > > I think that the solution is quite simple: if the SONET signal is = indeed an > > > SDH signal, why do you bother with SONET ? Just ask for an SDH = signal, > > > that's all. > > > > > > By the way, since according to some folks SONET is just a subset = of SDH, why > > > do we care about SONET in these documents ? Why don't we simply = remove all > > > references to SONET ? > > > > > > Is there somebody on this mailing list that cares about SONET ? If = yes, why > > > ? Who is still manufacturing SONET boxes ? Why is that not called = SDH ?>=20 > > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > > > Sent: Tuesday, December 18, 2001 9:57 PM > > > To: Mannie, Eric > > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > > > dbrungard@att.com; lberger@movaz.com > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > Eric - > > > > > > Comments inline... > > > > > > Jonathan Sadler > > > > > > "Mannie, Eric" wrote: > > > > "A SONET signal which has an identical SDH signal SHOULD be = requested > > > using > > > > the same traffic parameters as for the equivalent SDH signal, = and will > > > > consequently use the SDH label." > > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > > interoperability problems in the future... > > > > > > > We spend with Maarten a lot of time to write that sentence (not = easy to > > > > write). > > > > > > > > Maybe that it should be better written: > > > > > > > > "A SONET signal which has an identical SDH signal SHOULD be = requested as > > > an > > > > SDH signal using the same traffic parameters as for the = equivalent SDH > > > > signal, and will consequently use the SDH label." > > > > > > Again, "SHOULD" needs to be replaced with "MUST"... > > > > > > > This doesn't mean that the SONET signal format disappear (simply = not used > > > in > > > > that case), for backward compatibility we need to keep it. > > > > > > I'm curious what sort of backward compatability is necessary, as a > > > "standard" doesn't exist currently that this needs to be backward > > > compatible with... > > > > > > > Kind regards, > > > > > > > > Eric > > > > > > > > -----Original Message----- > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > Sent: Tuesday, December 18, 2001 7:46 PM > > > > To: Kireeti Kompella > > > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > > > bwijnen@lucent.com; sob@harvard.edu > > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > > > Kireeti, > > > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely = popular > > > > rate in both SONET and SDH. I exchanged an email with Deborah = Brungard > > > > (T1X1.5 chair) on this one and I take the liberty of sharing her = response: > > > > > > > > Deborah Brungard wrote: > > > > > The VT3 (3M) structure was defined - but no services = (mappings) were > > > ever > > > > defined for it. So there are no services/equip > > > > > with it. My take was if in the future it was ever defined = (doubtful), we > > > > would be adding it to g707 also. So then it > > > > > would just be part of g707 too. > > > > > > > > So basically, there are no mappings or equipment functions for = this rate, > > > > and as far as we know no network equipment or networks = supporting it. > > > > Deborah suggests that if we were ever to define such mappings, = that this > > > > would be proposed for addition to G.707 and hence be part of = SDH. > > > > > > > > I think our agreement had been to use the SDH label for all = signals that > > > > had the same multiplex structure in SONET and SDH. In Salt Lake = City, we > > > > thought > > > > that this was everything except VT3. Given that VT3 seems not to = be a > > > "real" > > > > signal at this point and will likely be added to SDH if it ever = becomes > > > > real, does our agreement then become that we use SDH labels for > > > everything? > > > > > > > > Regards, > > > > Steve > > > > > > > > Kireeti Kompella wrote: > > > > > > > > > > Hi Deborah, > > > > > > > > > > > I previously made the > > > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs = on > > > > > several issues, among them this one. The upshot was that = whenever > > > > > possible, the SDH label should be used, with the encoding = type>=20 > > > > > set to SDH (i.e., G.707); however, there are signals that have > > > > > no SDH equivalent (if I remember right, VC-3 -- someone = correct > > > > > me!), so we will keep SONET labels and encoding types around > > > > > for that case and for legacy equipment. > > > > > > > > > > The revised SONET/SDH document will contain the exact wording. > > > > > I will also be sending a reply to the ITU communication = stating > > > > > the agreement we came to. > > > > > > > > > > Kireeti. << File: Card for Dimitri Papadimitriou >>=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 06:49:22 -0800 Message-ID: <3C21F7F5.4090807@acm.org> Date: Thu, 20 Dec 2001 09:38:45 -0500 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org, bwijnen@lucent.com, sob@harvard.edu, gkailad@acm.org, yxue@uu.net, jls@att.com, jyates@research.att.com, mei@research.att.com, ananth.nagarajan@mail.sprint.com, wesam.alanqar@mail.sprint.com, lynn.neir@mail.sprint.com, tammy.ferris@mail.sprint.com, hirokazu@japan-telecom.co.jp, olga.aparicio@cwusa.com, steven.wright@snt.bellsouth.com, mlazer@att.com Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te [ was Re: GMPLS signaling documents updated per last calls] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lou Berger wrote: > All, > As was discussed in this morning's SUB-IP session, the GMPLS > signaling documents have been updated to reflect comments received > during the extended last call. If you believe an issue that you have > previously raised has not been addressed in the drafts, please send a > message to the list. (We'll respond with either how the issue was > addressed or if it was missed.) > > Here's a summary of changes: > > draft-ietf-mpls-generalized-signaling-07.txt > see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version. > o changes were primarily in the area of GPID values. > (Juergen has a couple of additions that we'll incorporate in next > rev.) > > draft-ietf-mpls-generalized-rsvp-te-06.txt > see http://www.labn.net/docs/diff-rsvp-05-06.txt > o Minor editorial changes and clarifications based on comments from list > > draft-ietf-mpls-generalized-cr-ldp-05.txt > http://www.labn.net/docs/diff-ldp-04-05.txt > o Brings cr-ldp functionally in line with rsvp-te > o Revised Admin Status Usage (per comments and also removed potential > race condition) > o Clarified text related to interface bundling (To be consistent with > updated bundling draft.) > o Added IANA Considerations > o Minor editorial changes and clarifications > > Lou > > > > I had raised some questions on support for control plane resiliency and sent the following message to the ccamp list on 11/2. I believe these issues are still valid and are not addressed in the latest version of the RSVP signaling draft. If they have been addressed, I am interested in how they are addressed. Since I am referring to draft-ietf- ipo-carrier-requirements, I have copied the authors of that draft too. Thanks, Gopal -------- Original Message -------- Message-ID: <3BE2F2A1.2060000@acm.org> Date: Fri, 02 Nov 2001 14:23:13 -0500 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: yakov@juniper.net, gkailad@acm.org Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te-05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit One characteristic of traditional transport networks is that control plane failures do not affect established lightpaths or TDM channels. This is reflected by requirement 144 in draft-ietf-ipo-carrier-requirements-00: "Control plane failures shall not cause failure of established data plane connections." Note that there is no time limit imposed on how long a control plane failure can last without affecting established data plane connections. The Restart Time field in the Restart_Cap object supports a maximum value of about 49 days. In case of transport networks, this would mean that in case of a controller failure due to say, a natural disaster, if the node is not accessible, established connections will fail after 49 days even if data plane is not affected, which is unacceptable. Even if this is fixed so that a node can advertise that the restart time is infinite, there is another issue. In existing transport networks, established data plane connections do not fail even if multiple controllers fail. Accordingly, the requirement from draft-ietf-ipo-carrier-requirements-00 quoted above requires that there be no failure in the data plane in case of "control plane failures." This would effectively mean that the recovery time could also be indeterminate. Consider the following example with four nodes: A ---- B ---- C ---- D If B and C fail, and C restarts, it can not complete synchronization with D until B restarts and exchanges state with C. I believe this level of resiliency is not possible with the procedure specified. Just advertising 0xffffffff for recovery time will not be enough, as this could cause state to be held indefinitely when it should be deleted. So I suggest one of the following: - remove the restart section from the draft and consider it as a separate draft, so that the rest can move forward. - add a constraint in the beginning of section 9.5, after the first sentence: "The recovery mechanism specified in this section addresses restart issues only in case of PSC devices, and does not fulfil the requirements for transport networks. Recovery procedures for transport networks is for further study." - postpone the last call, and look at adding a solution that would also satisfy the requirements of transport networks. From a transport network perspective, this could be a starting point for discussion: - A new object called PERSISTENT_SESSION is introduced to indicate that a session is long lasting. This will be sent in the Path message associated with transport network sessions. This will be reflected back in the Resv message. The fact that a session is persistent is preserved along with forwarding plane information. - A new message (LRefresh) is introduced to synchronize the forwarding plane information for persistent sessions between peers, and it is transmitted periodically. - A new object called flags is added and this will be carried in Hello messages. This object has one field called flags, and a node supporting persistent sessions will set bit 0 of the Flags field. Support for persistent sessions implies support for the PERSISTENT_SESSION object as well as LRefresh. - For sessions that are marked persistent, state will be cleared only under these conditions: - State will never be cleared based on timeout. Exceptions listed below. - State will be cleared based on timeout only after sending the Resv with the D bit set in the Admin_Status object upstream, and only if graceful deletion was initiated by the headend. This information will be preserved along with forwarding plane information. - Reception of PathTear. - If a node learns that it has some state in the forwarding plane that is not in sync with that of the peer, the forwarding plane state as well as associated control plane state will be cleared on a timer basis. This timer will be more coarse-grained than the refresh timers for the control plane. - If a peer does not support persistent sessions, state that has to be refreshed by that peer will be timed out in the usual manner. Restart procedure as specified for PSC devices may be used if the two nodes support it. - Specify clearly what help is needed from outside RSVP. To support recovery of hierarchical LSPs, RSVP needs the following information upon restart: - Mapping between interface id. assigned by the peer and the interface id. assigned locally. (Related qn.: There was a suggestion on the list (from Yakov) that a node can learn this from the recovered link state database. But if the restart time is going to be indeterminate, isn't it possible that the TE-LSAs have expired when the node restarts? If so, a node might instead preserve this information across restart. But in any case, RSVP needs this information upon restart.) - Peers (LSR ids) with which Hello adjacencies were established dynamically as a result of FA-LSPs. Comments? Cheers, Gopal Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 04:57:29 -0800 Message-ID: From: Heiles Juergen To: "'Dimitri Papadimitriou'" , Maarten Vissers Cc: "Mannie, Eric" , "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: RE: GMPLS signaling documents updated per last calls Date: Thu, 20 Dec 2001 13:42:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi, it didn't attend the come together at the IETF meeting, put it seems to me that the agreements where reached with different assumptions in the two parties minds. I hear that the SONET labels was only left to support VT-3 and I hear that they are left for interworking with existing implementations (OIF UNI1.0). VT-3 is not a reason for me as - VT-3 is not used in SONET (Deborah may be think about removing it from T1.105!) - only a definition for the VT-3 label is needed, not for all other SONET signals. Furthermore it can be defined based on the SDH label. Providing interworking with implementations that are based on draft documents is a little bit strange in my view. The implementers know that these documents are drafts and may change and so they have to change their implementation. Otherwise giving drafts a higher status contradicts all decision and voting processes for the final version as one can always reject changes based on existing implementations. However it seems that is the way the IETF works. Ok, but in this case it should be clearly mentioned in the document. Furthermore the SONET definitions should be completely separated from the SDH definitions and but into a interworking part. Otherwise with the mixture of SONET and SDH within the text it is only confusing. Concerning SDH/ITU and SONET/T1 I think it is more a political issue to have still the T1 recommendations with the full description. ETSI makes a reference to G.707 and only mentions which parts of G.707 apply or don't apply (ETS300147). Regards Juergen > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Wednesday, December 19, 2001 6:37 PM > To: Maarten Vissers > Cc: Mannie, Eric; 'jonathan.sadler@tellabs.com'; 'Stephen Trowbridge'; > Kireeti Kompella; ccamp@ops.ietf.org; dbrungard@att.com; > lberger@movaz.com > Subject: Re: GMPLS signaling documents updated per last calls > > > This discussion is going into limbos because once a solution > is provided and agreed by all parties, afterwards the elements > having enabled to come up to this decision disappear... for > instance, VT3 SPE now are not used anymore... were they used > one week before and just stop now ? > > Mor generally, since it is not the job of the CCAMP community to > verify if the content of ITU/T1X1 specifications are implemented > in current networks it is for me irrelevant to state as done by > Stephen that they are not used. How can i verify such assertion ? > > At the end of the day i have got the following impression ITU > T1 people blind the differences they maintain in their own > documents... Deborah/Stephen sorry but GR.253 specification has > just been extended to LCAS capabilities so T1X1 and ITU maintains > their own version (G.707 is also being extended)... in this > context sorry but we are at a point where people maintains > artificial discussions for reasons which are very difficult > to understand ? > > Very interesting the following e-mail from Maarten, why do i > have to keep two terms in order to translate the same entity > if Sonet is a subset of SDH ? > > Cheers, > - dimitri. > > Maarten Vissers wrote: > > > > Eric, > > > > It is not the intention to leave the choice of LSP encoding > type and SU label > > structure to the vendor. This would give immediate > interworking problems. > > > > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, > VC-4/STS-3c, VC-4-4c/STS-12c, > > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c > must all have LSP > > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 > must have the LSP > > encoding type "SDH". > > > > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, > VC-4-64c/STS-192c > > and VC-4-256c/STS-768c must all have the same SDH-based > "SU" structure. > > > > Looking at the label text in section 3 of the sonet-sdh > document, I find it very > > confusing to read that SONET doesn't use the "U" field. As > we indicated before > > there is no STS type signal that isn't having an SDH > equivalent; i.e. there are > > no specific higher order SONET signals left. It is > therefore much better to take > > out the SONET text for the SU label part altogether. > Otherwise we will get a lot > > of confusion in the marketplace. > > > > Also the examples with STS-1 (examples 3 to 5 in secton 3) > must use the label > > with U in the range 2 to 4; the STS-1 is equivalent to the > VC-3 in SDH and must > > thus use the "SDH" SU format. > > > > ------- > > > > All, > > > > With the clarification on VT-3 given by Deborah, I would > request to consider a > > further simplification of the GMPLS standard: delete the > LSP encoding type > > "SONET" and rename the LSP encoding type "SDH" into > "SDH/SONET". Then there > > would be no ambiguity left at all. > > > > Regards, > > > > Maarten > > > > "Mannie, Eric" wrote: > > > > > > Hi Jonathan, > > > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > > interoperability problems in the future... > > > > > > To leave to the manufacturer and to the user the right to > decide if he/she > > > wants to signal an LSP as either SDH or SONET. There is > no interoperability > > > problem at all since you use EITHER SDH OR SONET. If you > decide to request > > > an SDH signal with what do you want to have > interoperability issue at this > > > stage ? The sentence means indeed "one should better use > SDH than SONET" ! > > > Once you decided, there is no issue. > > > > > > > I'm curious what sort of backward compatability is > necessary, as a > > > "standard" doesn't exist currently that this needs to be backward > > > compatible with... > > > > > > Backward compatibility with the OIF UNI 1.0 > Implementation Agreement, with > > > the implementations that could not care of SDH, with > implementations that > > > still do a distinction between SONET and SDH for some > reasons, with the > > > implementations that could still use the VT3 (DS1C) (I don't have > > > confirmation that nobody is using it today, and this is > not the goal of this > > > draft to state what is obsolete or not in SONET), etc. > > > > > > Anyway, there is no issue, the SONET label format is not > used until SONET is > > > explicitly requested as such. This is not a primary > feature of the draft, > > > but a *secondary feature*, for SONET lovers. Otherwise, > SDH is used for > > > everything, consequently you don't care of the SONET > label, you skip it in > > > the draft, you ignore it, you don't implement it and you > just use a full SDH > > > implementation. > > > > > > I think that the solution is quite simple: if the SONET > signal is indeed an > > > SDH signal, why do you bother with SONET ? Just ask for > an SDH signal, > > > that's all. > > > > > > By the way, since according to some folks SONET is just a > subset of SDH, why > > > do we care about SONET in these documents ? Why don't we > simply remove all > > > references to SONET ? > > > > > > Is there somebody on this mailing list that cares about > SONET ? If yes, why > > > ? Who is still manufacturing SONET boxes ? Why is that > not called SDH ? > > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > > > Sent: Tuesday, December 18, 2001 9:57 PM > > > To: Mannie, Eric > > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > > > dbrungard@att.com; lberger@movaz.com > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > Eric - > > > > > > Comments inline... > > > > > > Jonathan Sadler > > > > > > "Mannie, Eric" wrote: > > > > "A SONET signal which has an identical SDH signal > SHOULD be requested > > > using > > > > the same traffic parameters as for the equivalent SDH > signal, and will > > > > consequently use the SDH label." > > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > > interoperability problems in the future... > > > > > > > We spend with Maarten a lot of time to write that > sentence (not easy to > > > > write). > > > > > > > > Maybe that it should be better written: > > > > > > > > "A SONET signal which has an identical SDH signal > SHOULD be requested as > > > an > > > > SDH signal using the same traffic parameters as for the > equivalent SDH > > > > signal, and will consequently use the SDH label." > > > > > > Again, "SHOULD" needs to be replaced with "MUST"... > > > > > > > This doesn't mean that the SONET signal format > disappear (simply not used > > > in > > > > that case), for backward compatibility we need to keep it. > > > > > > I'm curious what sort of backward compatability is necessary, as a > > > "standard" doesn't exist currently that this needs to be backward > > > compatible with... > > > > > > > Kind regards, > > > > > > > > Eric > > > > > > > > -----Original Message----- > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > Sent: Tuesday, December 18, 2001 7:46 PM > > > > To: Kireeti Kompella > > > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > > > bwijnen@lucent.com; sob@harvard.edu > > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > > > Kireeti, > > > > The one outlyer is VT3 (3 Megabits). VC-3 is an > extremely popular > > > > rate in both SONET and SDH. I exchanged an email with > Deborah Brungard > > > > (T1X1.5 chair) on this one and I take the liberty of > sharing her response: > > > > > > > > Deborah Brungard wrote: > > > > > The VT3 (3M) structure was defined - but no services > (mappings) were > > > ever > > > > defined for it. So there are no services/equip > > > > > with it. My take was if in the future it was ever > defined (doubtful), we > > > > would be adding it to g707 also. So then it > > > > > would just be part of g707 too. > > > > > > > > So basically, there are no mappings or equipment > functions for this rate, > > > > and as far as we know no network equipment or networks > supporting it. > > > > Deborah suggests that if we were ever to define such > mappings, that this > > > > would be proposed for addition to G.707 and hence be > part of SDH. > > > > > > > > I think our agreement had been to use the SDH label for > all signals that > > > > had the same multiplex structure in SONET and SDH. In > Salt Lake City, we > > > > thought > > > > that this was everything except VT3. Given that VT3 > seems not to be a > > > "real" > > > > signal at this point and will likely be added to SDH if > it ever becomes > > > > real, does our agreement then become that we use SDH labels for > > > everything? > > > > > > > > Regards, > > > > Steve > > > > > > > > Kireeti Kompella wrote: > > > > > > > > > > Hi Deborah, > > > > > > > > > > > I previously made the > > > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and > chairs on > > > > > several issues, among them this one. The upshot was > that whenever > > > > > possible, the SDH label should be used, with the encoding type > > > > > set to SDH (i.e., G.707); however, there are signals that have > > > > > no SDH equivalent (if I remember right, VC-3 -- > someone correct > > > > > me!), so we will keep SONET labels and encoding types around > > > > > for that case and for legacy equipment. > > > > > > > > > > The revised SONET/SDH document will contain the exact wording. > > > > > I will also be sending a reply to the ITU > communication stating > > > > > the agreement we came to. > > > > > > > > > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 04:21:49 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , "'ccamp@ops.ietf.org '" Cc: "'dimitri.papadimitriou@alcatel.be '" Subject: RE: Revised GMPLS SONET/SDH drafts Date: Thu, 20 Dec 2001 13:08:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi Eric, a took me a while to detect the agreements related to the label in the updated text as the label section still defines SDH and SONET labels in full details without mentioning the SDH labels should be used also for SONET signals. This new sentence in the introduction is very likely to be forgotten/not noticed and in the end we might get even more confusion/interop problems. AS you mentioned in one of the other e-mails that the SONET label is kept for interoperability issues with existing implementations (e.g. OIF UNI1.0) it would be better to explicitly mention this and have the whole SONET definitions separate. At the end of the label section a new paragraph is added concerning transparent concatenated STM-N signals. I assume this is a signal with signal type STM-N/STS-3*N, transparency flag set and NCC>1. This leads to two questions: What is the SUKLM label for a transparent STM-N without concatenation explicitly requested (Do we need a SUKLM label at all)? Why is the case of transparency + contiguous concatenation (actually a contradiction in it self) special from the general transparency case and has to be mentioned. The STM-0 SUKLM definition (S=0) is different from the STS-1 definition (S=1), also both are the same signal. As the STM-0 definition was just introduced it could have been made the same as the existing STS-1 definition. Regards Juergen > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Friday, December 14, 2001 1:00 AM > To: 'ccamp@ops.ietf.org ' > Cc: 'dimitri.papadimitriou@alcatel.be ' > Subject: Revised GMPLS SONET/SDH drafts > > > > Dear All, > > Please find attached the two GMPLS SDH/SONET drafts revised > according to the > comments received during the last period of comments, and > during the Salt > Lake City meeting: > > - draft-ietf-ccamp-gmpls-sonet-sdh-03.txt > - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt > > Please, send your comments to the mailing list AND to us. > > Kind regards, > > Eric and Dimitri > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2001 02:19:43 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , Heiles Juergen , "''John Drake' '" , "'Maarten Vissers '" , "'manoj juneja '" Cc: "'ccamp@ops.ietf.org '" Subject: RE: Lambda LSP establishment Date: Thu, 20 Dec 2001 11:03:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi Eric, thanks for the explanation below. I have some further questions for clarification and I also think an informational I-D would be helpful. You said that from the routing point of view a link and an FA are two different things. There is a routing adjacency "over" a link but not over a FA. I don't see the difference between a "physical link" and a FA as routing can use both to establish a connection. Furthermore for the SDH case if a VC-12 connection is setup via an existing VC-4 connection the VC-4 connection is an FA according to my understanding. However if a VC-4 connection is setup over a STM-16, the STM-16 is not a FA, it is a link. Is this correct? From the VC-12 or VC-4 routing view point I don't see a difference between the FA or link. Furthermore the STM-16 connection itself could be transported via an OCh or ODUk in a WDM system. So it is not the physical interface of the equipment. Is it still a link and no FA as from the physical topology only WDM (OTM-n) interfaces are seen. Now concerning the setup of a VC-12 over a STM-16. In this case you use the full SUKLM number. owever in order to make this connection a VC-4 or HO VC-3 connection has to be established prior to the VC-12 connection. Is this implicitly assumed? After the setup of the VC-12 this V-4 or HO VC-3 exists. Is it now seen as a FA? Lets have a look on two examples: (1) HO/LO(4/1)-DXC <---STM-16---> HO/LO(4/1)-DXC (2) HO/LO(4/1)-DXC <---STM-16---> HO(4/4)-DXC <--- STM-16---> HO/LO(4/1)-DXC In example 1 two 4/1 SDH cross-connects that support VC-12 and VC-4 switching are directly interconnected via a STM-16. In this case the VC-12 label could be defined in relation to the STM-16 interface with the full SUKLM set. In the second example the two 4/1 cross-connects are interconnected via a 4/4 cross-connect that supports only VC-4 switching. Do we need a VC-4 FA in this case between the two 4/1 cross-connects to setup the VC-12 connection? Regards Juergen > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Thursday, December 13, 2001 6:57 PM > To: 'Heiles Juergen '; ''John Drake' '; 'Maarten Vissers '; 'manoj > juneja ' > Cc: 'ccamp@ops.ietf.org ' > Subject: RE: Lambda LSP establishment > > > Hi All, > > A few comments, > > >In MPLS the FA establishes "virtual" layer networks. In > GMPLS the layer > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, > OCh, OMS, OTS). A > FA basically corresponds to a real trail in a circuit > switched network. > > Eric: ...and this trail is setup dynamically using GMPLS. That's the > interest. One can think of SDH/SONET FAs as shortcuts or > express-routes. > > >One special thing about the SDH label is, that it includes a > hierarchy as > it identifies the lower order VC in a higher order VC in a > STM-N signal. > Note that this is somehow in contradiction with a statement > in the GMPLS > signaling document which says > > >"A Generalized Label only carries a single level of label, > i.e., it is > non-hierarchical. When multiple levels of label (LSPs > within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > > No, hierarchy of labels is not hierarchy of layers. And even > one should have > a common definition of what means a "layer". This text says > that we cannot > have multiple embedded labels, e.g. one label containting a > label stack. > This is a signaling stuff that doesn't imply anything on the transport > plane. > > Now, a label identifies ONE LSP at an interface. This LSP can > be HO or LO in > SDH. The label can be fully specified or partially specified, > depending on > the context where the LSP is established. > > E.g. when an LSP is established over a FA, the highest part > of the LSP label > is not relevant. When the FA LSP is established the lowest > part of the FA > LSP label is not relevant. > > If a low order LSP is established without any higher order > FA, the label is > fully specified. As you said the link is indeed the "ultimate > FA" in that > case. Except that from the routing point of view a link and > an FA are two > different things. There is a routing adjacency "over" a link > but not over a > FA. > > The SDH/SONET label just includes what you need to include in > each scenario. > > Moreover, the label MUST be interpreted according to the type > of interface > for which it is used. It is possible to code two labels > having the same > value but a complete different meaning. Labels are context > sensitive of > course. > > For instance, an LSP over an STM-0 interface or over a FA > will have the > highest part set to zero, and could possibly have the same > lowest part. You > cannot understand what means the label without knowning the > detail of the > interface. In that case, the interface is either an STM-0 > interface or a > VC-3 FA. And of course that FA and STM-0 interface are two > different things, > but from the LSP point of view, in both cases what it wants > is a VC-3 in > which it can be multiplexed. > > Hope this helps. > > I start to wonder if we should have an informational draft describing > different scenarios of SDH/SONET LSP establishment. That > could complement > the SDH/SONET signaling drafts and the GMPLS architecture. > That could solve > many terminology and modeling issues. > > Kind regards, > > Eric > > -----Original Message----- > From: Heiles Juergen > To: 'John Drake'; Maarten Vissers; manoj juneja > Cc: ccamp@ops.ietf.org > Sent: 12/13/01 11:15 AM > Subject: RE: Lambda LSP establishment > > Let me express my understanding of FAs in MPLS/GMPLS, please > correct me > if I am wrong. I have also some questions related to the label > generation and interactions between layer networks. > > The label in MPLS is local to the link between two adjacent MPLS > switches, it indicates a LSP in this link. This link is therefore the > ultimate FA. An already established LSP between two MPLS > switches, which > don't have to be adjacent, can be used to transport/tunnel other LSPs > between this two nodes. This already established LSP > generates a virtual > adjacency between the two nodes, the FA. As several LSPs can > use this FA > it is also a kind of virtual multiplexing. > If you compare it with a circuit switched network the FA is a server > layer trail that provides transport (a link connection) for > one or more > client layer signals. > In MPLS the FA establishes "virtual" layer networks. In GMPLS > the layer > networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, > OTS). A FA basically corresponds to a real trail in a circuit switched > network. > In GMPLS the label is also local to the link between the two devices > that perform the switching. For example for SDH the VC-N is identified > by the STM-N link/port and the SUKLM number according to > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is > identified by > the interface ID (I am not sure on this) and SUKLM is the SDH > label that > locates the VC within the STM-N. > From just the SDH viewpoint the STM-N connection is the > ultimate server > trail/FA. However the STM-N signal could be transported over a Optical > Channel or G.709 ODU. The OCh or ODU can already start in the > equipment > that performs the VC-N switching. So the STM-N signal is not the port, > but the WDM signal is the port and the STM-N signal makes use of a OCh > or ODU server layer trail. This server layer trail can be established > via management or using GMPLS. > Can someone explain how a label for a VC-4 is generated in this case > (pre-established OCh or ODU trail via management or setup > using GMPLS). > This interaction between the different technologies/labels need in my > view some further explanation. > > One special thing about the SDH label is, that it includes a hierarchy > as it identifies the lower order VC in a higher order VC in a STM-N > signal. Note that this is somehow in contradiction with a statement in > the GMPLS signaling document which says > "A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > Following this statement each layer should have its own label > independent of server layers. > The combination of hierarchies in labels is based on technology (e.g. > SDH, Sonet, G.709 ODU) but has in my view no real technical > reason. The > SDH label for example fits to standard STM-N signals, but not > to sub-STM > signals. > For the SDH the full SUKLM number is used if a e.g. VC-12 is > located in > relation to a STM-N interface. If it is located in relation to a VC-4 > (the VC-4 is in this case a FA) SUK are set to 0. For me it > is not clear > in which case I use the first and in which case I use the > second case as > a VC-4 trail is always needed for a VC-12 connection. This > VC-4 could be > established using management or GMPLS. However it should have no > influence on the label. > Some more information is needed in my view in this area. > > > Juergen > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Wednesday, December 12, 2001 6:54 AM > > To: Maarten Vissers; manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: RE: Lambda LSP establishment > > > > > > fortunately, this is just your opinion > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Tuesday, December 11, 2001 9:31 PM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: Lambda LSP establishment > > > > > > Manoj, > > > > Forget the FA stuff, it is not appropriate in circuit > > networks. It only > > applies > > to MPLS. We should remove it when it is used in relation with PDH, > > SDH/SONET, > > OTN and pre-OTN. The text in sdh-sonet draft should state > > that if there is a > > LOVC link (IETF: link bundle/TE link) then the LOVC signals > > use a label with > > "00KLM". > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > The concept of FA is mentioned for SDH/SONET in > > gmpls-sdh > > > -sonet draft. It says that if u have a HOVC trail as a FA > > (advertized > > > as a link) then u can allocate the lower level signals in > > it by making > > > the higher bits of label as 0s (i.e. S and U}. This is fine > > for the same > > > technology. What about the case where the TDM LSP has to > be tunneled > > through > > > the Lambda LSP ? What will be the form of label (i.e. > > {SUKLM} or lambda > > > etc.) ? > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Lambda LSP establishment > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > > > >Manoj, > > > > > > > >You refer to one wavelength to be available between A-E without > > wavelength > > > >conversion capability. This suggests that you operate at > > the OCh layer > > > >network. > > > >Then you specify the capacity of the 4 OCh link > > connections (A-B, B-C, > > C-D, > > > >D-E) > > > >to be "C". Say that C is about 10 Gbit/s. You then assume > > that there is a > > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > > Gbit/s) between C > > and > > > >E. > > > >The result is that the OCh link connections C-D and D-E > > are transporting > > > >the OCh > > > >signal (of e.g. 2.5G). These OCh link connections are now > > in service and > > > >not > > > >longer available to an other OCh connection request. I.e. > > a request for > > an > > > >OCh > > > >connection between A and E will be rejected. > > > > > > > >FAs are not applicable in the circuit layers. IF there is > > a trail in > > server > > > >layer X, then there is a link in its client layer Y. X and > > Y are thus > > > >different > > > >layer networks and signals. > > > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > > be an OCh trail > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > > connection. > > > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > > network. Such is > > not > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >OCh link connections > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I have 5 nodes A, B, C, D and E connected as > > shown. Assume > > > > > that only one wavelength is available on the path A to E (no > > wavelength > > > > > conversion capability is there on the complete path). > > Let the capacity > > > > > of the wavelength be C. Further assume a request arrives for > > connection > > > > > from node C to E for a line capacity of C/4. This > > request will be > > > > > successful as we have available wavelength. Now If > > another request > > > > > comes at node A to establish another connection from > > node A to node E > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > > Should this request > > > > > be successful as we have already allocated the wavelength ? > > > > > > > > > > If the previous connection from C to E of capacity > C/4 had been > > > > > advertised as a FA, in that case will the IInd > request succeed ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 > > had not been > > > > > advertised as FA then what will be the fate of IInd > connection ? > > > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: > http://mobile.msn.com > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 18:13:41 -0800 Message-ID: <3C214614.974354AA@nayna.com> Date: Wed, 19 Dec 2001 17:59:49 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: manoj juneja CC: dimitri.papadimitriou@alcatel.be, lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org Subject: Re: Fwd: Comments on GMPLS signalling drafts Content-Type: multipart/mixed; boundary="------------C41D4996C586D52DAD4E08CC" This is a multi-part message in MIME format. --------------C41D4996C586D52DAD4E08CC Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Manoj: You are asking for improvising GMPLS documents on bandwidth modification, which is still in infacy stage at ITU. We should draw line some where, as to which features will go into first version of the GMPLS standard. - sudheer manoj juneja wrote: > Hi Dimitri, > My main concern was that if some topic is still being > discussed (like waveband and bandwidth modification for TDM LSPs), it > should be mentioned in the drafts that these sections are still not > complete and are under discussions/further study. To a reader of the > GMPLS drafts it should be clear that what all features are fully > specified by the IETF and there is no further conflict in the industry. > I still feel that there should be some reference for the bandwidth > modification for all the technologies (SDH/SONET, LSC and FSC) in the > drafrs. > > After reading the drafts one can question that : > > a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then > how ? Even one can question that is it under the scope of GMPLS ? > > These comments are just for completeness of the drafts before proceeding to > the RFC status. > > Regards, > manoj. > > >From: Dimitri Papadimitriou > >To: manoj juneja > >CC: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > >Date: Wed, 19 Dec 2001 18:35:55 +0100 > > > >Manoj, > > > >On the following "bandwidth modification" and "waveband switching": > > > >The first one is an ongoing topic discussed for instance in > >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > >that will be reviewed and updated for the next upcoming meetings > > > >On "waveband switching" the question is do we consider something > >further than what's already included in the version -07.txt. We > >have provided for this purpose some ideas in: > >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt > > > >CCAMP (and IETF) community should tell us if it is worth going on > >with the latter topic. If there is any interest, etc. But anyhow > >this is for further discussion (i.e. not within the scope of the > >current last call). It is now greatly time to move on (as said by > >Lou)... > > > >Regards, > >- dimitri. > > > >manoj juneja wrote: > > > > > > Hi Lou/Eric/Dimitri, > > > > > > Please see the following para from gmpls-architecture draft : > > > > > > "LSP modification consists in changing some LSP parameters, but > > > normally without changing the route. It is supported using the > > > same mechanism as re-routing. However, the semantic of LSP > > > modification will differ from one technology to the other. For > > > instance, further studies are required to understand the impact > > > of dynamically changing some SDH/SONET circuit characteristics such > > > as the bandwidth, the protection type, the transparency, the > > > concatenation etc." > > > > > > If u say that SE style of reservation is supported then how are u going > >to > > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one > >assign > > > diferent labels (labels are the physical resources on the link) to > >different > > > senders that belong to the same RSVP session. Is it that the SE style > >of > > > reservation only supported to modify the bandwidth of LSP ? Can I modify > >the > > > bandwidth of LSC/FSC LSP ? If yes then how ? > > > > > > Do u people think that waveband section is compelte in the drafts ? > > > > > > Please see other comments inline. > > > > > > Regards, > > > manoj. > > > > > > >From: Lou Berger > > > >To: "manoj juneja" > > > >CC: ,, > > > > > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > > > > > >see comments inline. > > > > > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > > > > > > > > > >> >From: "manoj juneja" > > > >> >To: ccamp@ops.ietf.org > > > >> >Subject: Comments on GMPLS signalling drafts > > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > >> > > > > >> >Hi All, > > > >> > > > > >> >1. SE-style supported by GMPLS or not ? > > > >> > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > >>As labels are the resources on the link, one can't allocate different > > > >> >label to different senders in the same RSVP session. > > > >> > > > > > > > > >I don't think you fully understand SE. I suggest you read the base > > > >documents. (2205 and RSVP-TE) > > > > > > > >> > > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > > > >> >separate draft for TDM LSP bandwidth modification but what about the > > > >> >bandwidth modification for other types of LSPs ? There is no mention > >of > > > >> >these in any of the GMPLS drafts. > > > >> > > > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > > > >> > > > >> >3. It should be mentioned clearly that waveband section is still not > > > >> >complete in the drafts. > > > >> > > > > > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What > > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS > >signalling > > > >> >drafts ? > > > >> > > > > > > > > >It's still in, see the drafts for explanations. > > > > > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and > >Upstream > > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. > >Do > > > u still want to keep these TLVs in GMPLS drafts ? If yes then is there > >any > > > reason for keeping these ? > > > > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned in > >the > > > >> >drafts (because it is a special case). > > > >> > > > > > > > > >the sonet draft is the right place for this. I defer to Eric on this. > > > > > > > [Manoj]: Thanks for putting this info in the new version of the draft. > > > >> > > > >> >6. It should be mentioned that bandwidth encoding parameter is > >useful > > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > > >> > > > > [Manoj]: I think u should include what all technologies will make use of > > > this parameter. > > > > > > >> >7. There is an example scenario for contention resolution in case of > >bi- > > > >> >directional LSPs. It should be mentioned that : > > > >> > > > > >> >"contention resolution is an optimization, not a correctness issue > >... > > > >> >and no procedure can provide optimal resolution in all cases. An > > > >> >implementor > > > >> >may do differently to provide better resolution." > > > >> > > > > >> >The above quotes are extracted from one of the mails from Fong Liaw. > > > >> > > > > >> >If this is the case then this should be mentioned in the drafts. > > > >> > > > > > > > > >Read the Acknowledgments section of the draft. (I'm sure Fong will be > > > >happy to see you protecting her interests!) > > > > > > > >> > > > >> >8. The LSP hierarchy concept is still not clear. Some days back I > >posted > > > >> >one > > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the > >concept > > > >>of > > > >> >forwarding adjacency and different people replied with different > > > >>thoughts. > > > >> >Does this mean this concept is not standardized in GMPLS ? > > > >> >My question was : > > > >> > > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > > > >> >established from A to D and if a new TDM LSP request comes to node A > > > >> >which is to be tunneled through the already established lambda > >FA-LSP > > > >> >then the node A sends the Path/label request message directly to > >node > > > >> >D. What label the node D will send back to node A in the RESV/label > > > >> >mapping message since the FA-LSP is just one label (lambda) ? Does > >it > > > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP > > > >> >will be allocated the same label by node D to node A ? If this type > >of > > > >> >scenario can't exist in GMPLS then please let me know that too." > > > > > > > >I believe this topic is being covered in other threads. > > > > > > > >> > > > > >> > > > > >> >Regards, > > > >> >manoj. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> >_________________________________________________________________ > > > >> >Join the world s largest e-mail service with MSN Hotmail. > > > >> >http://www.hotmail.com > > > >> > > > > >> > > > > >> > > > >>_________________________________________________________________ > > > >>Get your FREE download of MSN Explorer at > > > >>http://explorer.msn.com/intl.asp. > > > > > > > > > > > > > > _________________________________________________________________ > > > Join the world’s largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > ><< dimitri.papadimitriou.vcf >> > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com --------------C41D4996C586D52DAD4E08CC Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------C41D4996C586D52DAD4E08CC-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 17:47:29 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: dimitri.papadimitriou@alcatel.be Bcc: Subject: Issue in Label Set Object structure Date: Wed, 19 Dec 2001 18:37:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There seems to be some issue with the label set format. Can I include the virtually concatenated SDH/SONET signal in the label set ? If I want to have multiple subchannel elements in the label set (basically a set of labels in the label set instead of range) then how to determine that how many # of 4 byte octets comprise one virtual concatenated signal ? Or Is it that the subchannel element within the label set will also include the object header for generalized label ? Please let me know if I am missing something. Regards, manoj. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 17:40:37 -0800 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be Cc: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org Bcc: Subject: Re: Fwd: Comments on GMPLS signalling drafts Date: Wed, 19 Dec 2001 18:29:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri, My main concern was that if some topic is still being discussed (like waveband and bandwidth modification for TDM LSPs), it should be mentioned in the drafts that these sections are still not complete and are under discussions/further study. To a reader of the GMPLS drafts it should be clear that what all features are fully specified by the IETF and there is no further conflict in the industry. I still feel that there should be some reference for the bandwidth modification for all the technologies (SDH/SONET, LSC and FSC) in the drafrs. After reading the drafts one can question that : a) Can I increase the bandwidth of a TDM/FSC/LSC LSP ? If yes then how ? Even one can question that is it under the scope of GMPLS ? These comments are just for completeness of the drafts before proceeding to the RFC status. Regards, manoj. >From: Dimitri Papadimitriou >To: manoj juneja >CC: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org >Subject: Re: Fwd: Comments on GMPLS signalling drafts >Date: Wed, 19 Dec 2001 18:35:55 +0100 > >Manoj, > >On the following "bandwidth modification" and "waveband switching": > >The first one is an ongoing topic discussed for instance in >http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt >that will be reviewed and updated for the next upcoming meetings > >On "waveband switching" the question is do we consider something >further than what's already included in the version -07.txt. We >have provided for this purpose some ideas in: >http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt > >CCAMP (and IETF) community should tell us if it is worth going on >with the latter topic. If there is any interest, etc. But anyhow >this is for further discussion (i.e. not within the scope of the >current last call). It is now greatly time to move on (as said by >Lou)... > >Regards, >- dimitri. > >manoj juneja wrote: > > > > Hi Lou/Eric/Dimitri, > > > > Please see the following para from gmpls-architecture draft : > > > > "LSP modification consists in changing some LSP parameters, but > > normally without changing the route. It is supported using the > > same mechanism as re-routing. However, the semantic of LSP > > modification will differ from one technology to the other. For > > instance, further studies are required to understand the impact > > of dynamically changing some SDH/SONET circuit characteristics such > > as the bandwidth, the protection type, the transparency, the > > concatenation etc." > > > > If u say that SE style of reservation is supported then how are u going >to > > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one >assign > > diferent labels (labels are the physical resources on the link) to >different > > senders that belong to the same RSVP session. Is it that the SE style >of > > reservation only supported to modify the bandwidth of LSP ? Can I modify >the > > bandwidth of LSC/FSC LSP ? If yes then how ? > > > > Do u people think that waveband section is compelte in the drafts ? > > > > Please see other comments inline. > > > > Regards, > > manoj. > > > > >From: Lou Berger > > >To: "manoj juneja" > > >CC: ,, > > > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > > > >see comments inline. > > > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > > > > > >> >From: "manoj juneja" > > >> >To: ccamp@ops.ietf.org > > >> >Subject: Comments on GMPLS signalling drafts > > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > >> > > > >> >Hi All, > > >> > > > >> >1. SE-style supported by GMPLS or not ? > > >> > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > >>As labels are the resources on the link, one can't allocate different > > >> >label to different senders in the same RSVP session. > > >> > > > > > > >I don't think you fully understand SE. I suggest you read the base > > >documents. (2205 and RSVP-TE) > > > > > >> > > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > > >> >separate draft for TDM LSP bandwidth modification but what about the > > >> >bandwidth modification for other types of LSPs ? There is no mention >of > > >> >these in any of the GMPLS drafts. > > >> > > > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > >> > > >> >3. It should be mentioned clearly that waveband section is still not > > >> >complete in the drafts. > > >> > > > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What > > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > >> >bundling draft has removed these 2 TLVs. What about the GMPLS >signalling > > >> >drafts ? > > >> > > > > > > >It's still in, see the drafts for explanations. > > > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and >Upstream > > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. >Do > > u still want to keep these TLVs in GMPLS drafts ? If yes then is there >any > > reason for keeping these ? > > > > >> >5. STM-0 label representation using {SUKLM} should be mentioned in >the > > >> >drafts (because it is a special case). > > >> > > > > > > >the sonet draft is the right place for this. I defer to Eric on this. > > > > > [Manoj]: Thanks for putting this info in the new version of the draft. > > >> > > >> >6. It should be mentioned that bandwidth encoding parameter is >useful > > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > >> > > > [Manoj]: I think u should include what all technologies will make use of > > this parameter. > > > > >> >7. There is an example scenario for contention resolution in case of >bi- > > >> >directional LSPs. It should be mentioned that : > > >> > > > >> >"contention resolution is an optimization, not a correctness issue >... > > >> >and no procedure can provide optimal resolution in all cases. An > > >> >implementor > > >> >may do differently to provide better resolution." > > >> > > > >> >The above quotes are extracted from one of the mails from Fong Liaw. > > >> > > > >> >If this is the case then this should be mentioned in the drafts. > > >> > > > > > > >Read the Acknowledgments section of the draft. (I'm sure Fong will be > > >happy to see you protecting her interests!) > > > > > >> > > >> >8. The LSP hierarchy concept is still not clear. Some days back I >posted > > >> >one > > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the >concept > > >>of > > >> >forwarding adjacency and different people replied with different > > >>thoughts. > > >> >Does this mean this concept is not standardized in GMPLS ? > > >> >My question was : > > >> > > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > > >> >established from A to D and if a new TDM LSP request comes to node A > > >> >which is to be tunneled through the already established lambda >FA-LSP > > >> >then the node A sends the Path/label request message directly to >node > > >> >D. What label the node D will send back to node A in the RESV/label > > >> >mapping message since the FA-LSP is just one label (lambda) ? Does >it > > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP > > >> >will be allocated the same label by node D to node A ? If this type >of > > >> >scenario can't exist in GMPLS then please let me know that too." > > > > > >I believe this topic is being covered in other threads. > > > > > >> > > > >> > > > >> >Regards, > > >> >manoj. > > >> > > > >> > > > >> > > > >> > > > >> >_________________________________________________________________ > > >> >Join the world s largest e-mail service with MSN Hotmail. > > >> >http://www.hotmail.com > > >> > > > >> > > > >> > > >>_________________________________________________________________ > > >>Get your FREE download of MSN Explorer at > > >>http://explorer.msn.com/intl.asp. > > > > > > > > > > _________________________________________________________________ > > Join the world’s largest e-mail service with MSN Hotmail. > > http://www.hotmail.com ><< dimitri.papadimitriou.vcf >> _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 16:26:24 -0800 content-class: urn:content-classes:message Subject: RE: Intra-area Crankback Date: Wed, 19 Dec 2001 19:15:00 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170B24E9@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Intra-area Crankback Thread-Index: AcGIvsPN4FobUvSuEdWnAQCQJ3s5nwAJsWOw From: "Ash, Gerald R (Jerry), ALCTA" To: "Don Fedyk" Cc: "Ash, Gerald R (Jerry), ALCTA" , "Adrian Farrel" , "Atsushi Iwata" , "Norihito Fujita" , "Simon Marshall-Unitt" , "ccamp" Don, >The issue is that if people implement crank back only they don't=20 >get the benefit of feedback and therefore have only solved part=20 >of the problem. I agree that they can be independent. I think there=20 >is benefit to linking them.=20 Agreed that there is benefit in having both crankback and feedback in = play. >Also note that feedback does not alone imply that rerouting=20 >can be performed. A proper notify or failure reason must also=20 >be taken into account.=20 Agreed, this is what we were trying to point out in distinguishing = crankback and feedback.=20 >From draft-iwata-mpls-crankback-02.txt=20 > "In the feedback case [ASHW],=20 > or in the current error sub-codes of the Notification message [CR-=20 > LDP], one can infer a situation where rerouting can be done, but it=20 > also can lead to other problems, which have been experienced in=20 > practice, as illustrated below."=20 >This implies to me that the authors feel that feedback is somehow=20 >inferior to crankback. Not at all. We were trying to point out that crankback is a = reroute-notify mechanism and if one emulates a 'crankback' (e.g., with a = failure-notify), it is not a replacement for it. We were not saying = either feedback or crankback is superior or inferior, they do different = things and both can provide needed functionality. We have in fact = pointed out the benefit of feedback in other drafts, e.g. = http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt= . We'll revise the text in the next rev to remove any implied = criticism, which was not intended.=20 Regards, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 11:04:46 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6D83742@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: "Ash, Gerald R (Jerry), ALCTA" Cc: "Ash, Gerald R (Jerry), ALCTA" , Adrian Farrel , Atsushi Iwata , Norihito Fujita , Simon Marshall-Unitt , ccamp Subject: RE: Intra-area Crankback Date: Wed, 19 Dec 2001 13:53:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188BE.7E5D92F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C188BE.7E5D92F0 Content-Type: text/plain; charset="iso-8859-1" Jerry The effect of feedback is to alleviate the race conditions that occur within a domain wrt updating the TE database. Crankback is the only form of information that can travel between domains since intimate topology knowledge is not useful. The issue is that if people implement crank back only they don't get the benefit of feedback and therefore have only solved part of the problem. I agree that they can be independent. I think there is benefit to linking them. Crankback within a domain does nothing to alleviate the race conditions each LSP must learn the same lessons. I guess what frustrates me about this is we specifically saw feedback as have an advantage over crankback and having crankback specified as an alternative to feeback means the message didn't get through. For example out of your draft you point out drawbacks in feedback which I disagree do not exist. Also note that feedback does not alone imply that rerouting can be performed. A proper notify or failure reason must also be taken into account. >From draft-iwata-mpls-crankback-02.txt " 2. Explicit versus implicit rerouting indications There have been problems in service provider networks when "inferring" from indirect information that rerouting is allowed. In the case of using an explicit rerouting indication, rerouting is explicitly authorized and not inferred. In the feedback case [ASHW], or in the current error sub-codes of the Notification message [CR- LDP], one can infer a situation where rerouting can be done, but it also can lead to other problems, which have been experienced in practice, as illustrated below." This implies to me that the authors feel that feedback is somehow inferior to crankback. No mechanism is perfect. There are always situations where under heavy load you don't make the best route decisions. I do however fail to see the extra information that feedback provides within a domain as being inferior to crankback. Don > -----Original Message----- > From: Ash, Gerald R (Jerry), ALCTA [mailto:gash@att.com] > Sent: Monday, December 17, 2001 12:17 PM > To: Fedyk, Don [BL60:1A00:EXCH] > Cc: Ash, Gerald R (Jerry), ALCTA; Adrian Farrel; Atsushi > Iwata; Norihito > Fujita; Simon Marshall-Unitt; ccamp > Subject: RE: Intra-area Crankback > > > Hi Don, > > don> The feedback draft is intended for this type of operation. > don> Feedback is best within the area crank back is best outside > don> the area. We discussed all of this with the original authors > don> many many times. > don> Crankback is a primitive from of feedback. > > I recall perhaps one or two 'hallway discussions' along this > line. Personally I think that feedback and crankback do > different things, one is not a replacement for the other. > Feedback feeds information to the TED, crankback is a > reroute-notify to the head-end or border LSR. One can > emulate a 'crankback' with a failure-notify, just as well as > interpreting a feedback TLV as a 'crankback'. It is not the > same as crankback nor a replacement for it. > > Both can provide needed functionality. > > Regards, > Jerry > ------_=_NextPart_001_01C188BE.7E5D92F0 Content-Type: text/html; charset="iso-8859-1" RE: Intra-area Crankback

Jerry

The effect of feedback is to alleviate the race conditions
that occur within a domain wrt updating the TE database.
Crankback is the only form of information that can travel
between domains since intimate topology knowledge is not useful.
The issue is that if people implement crank back only they don't
get the benefit of feedback and therefore have only solved part
of the problem. I agree that they can be independent. I think there
is benefit to linking them. Crankback within a domain does nothing
to alleviate the race conditions each LSP must learn the same
lessons. 

I guess what frustrates me about this is we specifically
saw feedback as have an advantage over crankback and having
crankback specified as an alternative to feeback means the
message didn't get through. For example out of your draft you
point out drawbacks in feedback which I disagree do not exist.
Also note that feedback does not alone imply that rerouting
can be performed. A proper notify or failure reason must also
be taken into account.

From draft-iwata-mpls-crankback-02.txt
"
2. Explicit versus implicit rerouting indications

   There have been problems in service provider networks when
   "inferring" from indirect information that rerouting is allowed.  In
   the case of using an explicit rerouting indication, rerouting is
   explicitly authorized and not inferred.  In the feedback case [ASHW],
   or in the current error sub-codes of the Notification message [CR-
   LDP], one can infer a situation where rerouting can be done, but it
   also can lead to other problems, which have been experienced in
   practice, as illustrated below."

This implies to me that the authors feel that feedback is somehow
inferior to crankback. No mechanism is perfect. There are always
situations where under heavy load you don't make the best route
decisions. I do however fail to see the extra information that
feedback provides within a domain as being inferior to crankback.

Don


> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALCTA [mailto:gash@att.com]
> Sent: Monday, December 17, 2001 12:17 PM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: Ash, Gerald R (Jerry), ALCTA; Adrian Farrel; Atsushi
> Iwata; Norihito
> Fujita; Simon Marshall-Unitt; ccamp
> Subject: RE: Intra-area Crankback
>
>
> Hi Don,
>
> don> The feedback draft is intended for this type of operation.
> don> Feedback is best within the area crank back is best outside
> don> the area. We discussed all of this with the original authors
> don> many many times.
> don> Crankback is a primitive from of feedback.
>
> I recall perhaps one or two 'hallway discussions' along this
> line.  Personally I think that feedback and crankback do
> different things, one is not a replacement for the other. 
> Feedback feeds information to the TED, crankback is a
> reroute-notify to the head-end or border LSR.  One can
> emulate a 'crankback' with a failure-notify, just as well as
> interpreting a feedback TLV as a 'crankback'.  It is not the
> same as crankback nor a replacement for it.
>
> Both can provide needed functionality.
>
> Regards,
> Jerry
>

------_=_NextPart_001_01C188BE.7E5D92F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 10:10:11 -0800 Message-ID: From: neil.2.harrison@bt.com To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: protection and restoration [was: Re: Moving right along ... g eneralized-signaling-06] Date: Wed, 19 Dec 2001 18:03:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten, Maarten Vissers wrote 19 December 2001 13:25 > One of the requirements we have to meet is that traffic of > user A is not > delivered to user B. Also during recovery from a failed > connection (either by > means of protection swithcing, or restoration) we have to > guarantee that user A > traffic is not delivered to user B. NH=> Can I ask, is there a general agreement on this principle in this group? It's something operators usually insist on, so I'd like to know if its agreed here and the mechanism that ensures this. thanks, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:52:05 -0800 Message-ID: <3C20CFFB.710C8680@alcatel.be> Date: Wed, 19 Dec 2001 18:35:55 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: manoj juneja CC: lberger@movaz.com, Eric.Mannie@ebone.com, ccamp@ops.ietf.org Subject: Re: Fwd: Comments on GMPLS signalling drafts Content-Type: multipart/mixed; boundary="------------20F81BC6C531111832E03726" This is a multi-part message in MIME format. --------------20F81BC6C531111832E03726 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Manoj, On the following "bandwidth modification" and "waveband switching": The first one is an ongoing topic discussed for instance in http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt that will be reviewed and updated for the next upcoming meetings On "waveband switching" the question is do we consider something further than what's already included in the version -07.txt. We have provided for this purpose some ideas in: http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt CCAMP (and IETF) community should tell us if it is worth going on with the latter topic. If there is any interest, etc. But anyhow this is for further discussion (i.e. not within the scope of the current last call). It is now greatly time to move on (as said by Lou)... Regards, - dimitri. manoj juneja wrote: > > Hi Lou/Eric/Dimitri, > > Please see the following para from gmpls-architecture draft : > > "LSP modification consists in changing some LSP parameters, but > normally without changing the route. It is supported using the > same mechanism as re-routing. However, the semantic of LSP > modification will differ from one technology to the other. For > instance, further studies are required to understand the impact > of dynamically changing some SDH/SONET circuit characteristics such > as the bandwidth, the protection type, the transparency, the > concatenation etc." > > If u say that SE style of reservation is supported then how are u going to > share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one assign > diferent labels (labels are the physical resources on the link) to different > senders that belong to the same RSVP session. Is it that the SE style of > reservation only supported to modify the bandwidth of LSP ? Can I modify the > bandwidth of LSC/FSC LSP ? If yes then how ? > > Do u people think that waveband section is compelte in the drafts ? > > Please see other comments inline. > > Regards, > manoj. > > >From: Lou Berger > >To: "manoj juneja" > >CC: ,, > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > >see comments inline. > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > >> >From: "manoj juneja" > >> >To: ccamp@ops.ietf.org > >> >Subject: Comments on GMPLS signalling drafts > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > >> > > >> >Hi All, > >> > > >> >1. SE-style supported by GMPLS or not ? > >> > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > >>As labels are the resources on the link, one can't allocate different > >> >label to different senders in the same RSVP session. > >> > > > > >I don't think you fully understand SE. I suggest you read the base > >documents. (2205 and RSVP-TE) > > > >> > >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > >> >separate draft for TDM LSP bandwidth modification but what about the > >> >bandwidth modification for other types of LSPs ? There is no mention of > >> >these in any of the GMPLS drafts. > >> > > > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > > > >> > >> >3. It should be mentioned clearly that waveband section is still not > >> >complete in the drafts. > >> > > > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What > >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised > >> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling > >> >drafts ? > >> > > > > >It's still in, see the drafts for explanations. > > > [Manoj]: What I want to say is that Component_If_Id_Downstream and Upstream > TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. Do > u still want to keep these TLVs in GMPLS drafts ? If yes then is there any > reason for keeping these ? > > >> >5. STM-0 label representation using {SUKLM} should be mentioned in the > >> >drafts (because it is a special case). > >> > > > > >the sonet draft is the right place for this. I defer to Eric on this. > > > [Manoj]: Thanks for putting this info in the new version of the draft. > >> > >> >6. It should be mentioned that bandwidth encoding parameter is useful > >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > >> > > [Manoj]: I think u should include what all technologies will make use of > this parameter. > > >> >7. There is an example scenario for contention resolution in case of bi- > >> >directional LSPs. It should be mentioned that : > >> > > >> >"contention resolution is an optimization, not a correctness issue ... > >> >and no procedure can provide optimal resolution in all cases. An > >> >implementor > >> >may do differently to provide better resolution." > >> > > >> >The above quotes are extracted from one of the mails from Fong Liaw. > >> > > >> >If this is the case then this should be mentioned in the drafts. > >> > > > > >Read the Acknowledgments section of the draft. (I'm sure Fong will be > >happy to see you protecting her interests!) > > > >> > >> >8. The LSP hierarchy concept is still not clear. Some days back I posted > >> >one > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept > >>of > >> >forwarding adjacency and different people replied with different > >>thoughts. > >> >Does this mean this concept is not standardized in GMPLS ? > >> >My question was : > >> > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > >> >established from A to D and if a new TDM LSP request comes to node A > >> >which is to be tunneled through the already established lambda FA-LSP > >> >then the node A sends the Path/label request message directly to node > >> >D. What label the node D will send back to node A in the RESV/label > >> >mapping message since the FA-LSP is just one label (lambda) ? Does it > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP > >> >will be allocated the same label by node D to node A ? If this type of > >> >scenario can't exist in GMPLS then please let me know that too." > > > >I believe this topic is being covered in other threads. > > > >> > > >> > > >> >Regards, > >> >manoj. > >> > > >> > > >> > > >> > > >> >_________________________________________________________________ > >> >Join the world s largest e-mail service with MSN Hotmail. > >> >http://www.hotmail.com > >> > > >> > > >> > >>_________________________________________________________________ > >>Get your FREE download of MSN Explorer at > >>http://explorer.msn.com/intl.asp. > > > > > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com --------------20F81BC6C531111832E03726 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------20F81BC6C531111832E03726-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:51:56 -0800 Message-ID: <3C20CFED.B848A43B@alcatel.be> Date: Wed, 19 Dec 2001 18:35:41 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: Markus Jork , Lou Berger , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Content-Type: multipart/mixed; boundary="------------30E4F400DC439DD6286C7FD3" This is a multi-part message in MIME format. --------------30E4F400DC439DD6286C7FD3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten Switching Type has been defined to enable for instance the following case if i well understood the explanations given in the existing I-Ds: --- CF --- | | link 1 | | link 2 ----------- --------- - link 1 supports TDM LSP Encoding Type - link 2 supports TDM LSP Encoding Type however at the end of - link 1: PSC or LSC Switching capability can be provided - link 2: PSC or LSC Switching capability can be provided Notice that a Lambda LSP does not have to be established before the setup of the packet LSP. Consequently this feature provides additional about the implementation the Connection Function (CF) into the switch. So i can understand why you have some problem to understand this concept since typically CF implementation are left unspecified. Typically what do you have in such circumstances is the following: link1 - CF1 - link3 | | | | link2 -|- CF2 -|- link4 | | | | ---------- --------- where CF_1=PSC and CF_2=LSC with link 1 and link 3 supporting "packet" LSP Encoding and link 2 and link 4 supporting "lambda" LSP Encoding In all the examples that you have listed: - either the switching type through the LSP EncType and Signal Type - or only the LSP Encoding Type (in case of Ethernet for instance) so in such cases the Switching Type provides a redundant information. Hope this helps you to understand the underlying concept. Cheers, - dimitri. Maarten Vissers wrote: > > Markus, John, Lou, Manoj, > > I also still have a major issue to understand the switching type... or more > precise I have the feeling it is too coarse and ill defined. Let me provide some > more examples to evaluate: > > Frist Markus' network example... it will look like the following in reality > > R1 ------ OXC1 ------ OXC2 ------ R2 > OC-N OC-N OC-N > > OC-N trail > |<------------------------------>| > > STS-Nc trail > |<-------------------------------->| > > IP Link > |<---------------------------------->| > > I assume that OXC1/2 are all optical cross connects which pass through the > complete OC-N signals. > > In order to route IP packets between R1 and R2, you need to set up an OC-N trail > between R1 and R2. Once this is done, you need to set up a STS-Nc trail between > R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 640 > kbit/s established between R1 and R2. Now IP signals can flow between R1 and R2. > > Now make the example a bit more complex and let me add a SONET cross connect in > the chain. > > R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2 > OC-N OC-N OC-N OC-N > > OC-N trail OC-N trail > |<------------------------------>| |<------>| > > STS-Nc trail > |<-------------------------------------------->| > > IP Link > |<---------------------------------------------->| > > The physical interface in each case is an OC-N. The DXC1 is a SONET cross > connect, which terminates the OC-N Section and Line layers and forwards the > STS-Nc signal. > > What would the switching types be in this case when an LSP is requested between > R1 and R2? > > Now assume that the transport network contains some OTN OXCs interconnected via > 40G wavelengths. The Routers are having STM-16 physical interfaces with VC-4-16c > path signal carrying IP traffic. The DXC1 is a SDH cross connect with an OTN > OTM-0.3 (i.e. 40G) interface, which is carrying ODU1 (2G5) signals with STM-16 > inside. > > R1 -------- OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2 > STM-16 OTM-64.3 OTM-40.3 OTM-0.3 STM-16 > > OCh trail > |<-------------------------->| > > ODU3 trail > |<----------------------------------------->| > > ODU1 trail > |<-------------------------------------------->| > > STM-16 trail STM-16 trail > |<-------------------------------------------------------->||<-------->| > > VC-4-16c trail > |<---------------------------------------------------------------------->| > > IP Link > |<------------------------------------------------------------------------>| > > What would the switching types be in this case when an LSP is requested between > R1 and R2? > > But a router may also connect via a GE interface. The ethernet frames are then > forwarded in OXC1 via a virtual concatenated VC-4-Xv to R2 (which has a STM-16 > interface supporting VC-4-Xv). As VC-4-Xv signals can only be carried in sTM-N > signals, there is an STM-16 trail between OXC1 and DXC1. There is another STM-16 > trail between DXC1 and R2. > The OXCs are part of an OTN network, so the STM-16 that is created in the OXC1 > is mapped into an ODU1 and this ODU1 is switched to an OTM-64.3 port. In this > port the ODU1 signal is TDM multiplexed into an ODU3 and this ODU3 is put onto a > wavelenght (via OTU3V and OCh). OXC2 is an OCh (all optical) switch, capable to > forward the true wavelenght signal between the two OTM-64.3 and OTM-40.3 line > ports. The OCh signal is terminated in the OTM-40.3 line port in OXC3 and the > ODU3 is switched to the egress OTM-0.3 interface port. Arriving at DXC1, the > ODu3 is terminated, the ODU1 is demultiplexed from the ODU3, the ODU1 is > terminated and the STM-16 is extracted. Then the sTM-16 is terminated and the X > VC-4 signals are switched to the egress STM-16 signal. At R2 the STM-16 signal > is terminated, the X-VC-4 signals are connected to the VC-4-Xv port and > terminated making the ethernet frames available. The ehternet frames are > terminated and the IP packets are now accessible. > > R1 ------ OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2 > 1 GE OTM-64.3 OTM-40.3 OTM-0.3 STM-16 > > OCh trail > |<-------------------------->| > > ODU3 trail > |<----------------------------------------->| > > ODU1 trail > |<-------------------------------------------->| > > GE trail STM-16 trail STM-16 trail > |<----->||<---------------------------------------------->||<-------->| > > VC-4-Xv (X=1..7) trail > |<------------------------------------------------------------>| > > Ethernet MAC link > |<---------------------------------------------------------------------->| > > IP Link > |<------------------------------------------------------------------------>| > > Question is again the switching types you will see when requesting a LSP between > R1 and R2. > > Regards, > > Maarten > > Markus Jork wrote: > > Let's look at the example of two IP routers connected to a cloud of > > opaque OXCs: > > > > R1 ----- OXC1 ----- OXC2 ----- R2 > > LSC LSC PSC > > > > OXC1 and OXC2 switch the Sonet stream from an incoming interface to > > some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 > > are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks > > at the incoming IP packets. The encoding on the links is OC192. > > > > Now I want to setup an LSP between R1 and R2. (This LSP is essentially > > a "lightpath" through the optical cloud and will be advertised as FA > > so that PSC LSPs can be tunneled through it later.) > > What is the switching type requested in the Generalized Label Request > > object? I would expect LSC. > > But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: > > > > A Generalized Label Request object is set by the ingress node, > > transparently passed by transit nodes, and used by the egress node. > > > > This would suggest the switching type needs to be PSC. > > But then the text in 2.1.1 says: > > > > Nodes MUST verify that the type indicated in the Switching Type > > parameter is supported on the corresponding incoming interface. If > > the type cannot be supported, the node MUST generate a PathErr > > message with a "Routing problem/Switching Type" indication. > > > > So when the Path message requested PSC, it would be rejected by OXC1 > > and OXC2. When it requested LSC it would be rejected by R2. > > The transit nodes can't modify the switching type in the Path message > > because they don't have enough knowledge to pick the right one. > > How is this supposed to work? > > > > thanks for any clarification, > > Markus --------------30E4F400DC439DD6286C7FD3 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------30E4F400DC439DD6286C7FD3-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:51:28 -0800 Message-ID: <3C20CFDA.BBABC8EA@alcatel.be> Date: Wed, 19 Dec 2001 18:35:22 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Stephen Trowbridge'" , John Drake , Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------986C2E8614D315EF8C772696" This is a multi-part message in MIME format. --------------986C2E8614D315EF8C772696 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, all, Yes of course, whatever you call it "working" and "protection" / "primary" and "secondary" / "apple" and "orange" the important think is that the semantic of these words is interpreted in the same way by the ingress and egress LSR. Back to e-mails we have exchanged in May/June on this issue, we had already determine that the semantic of the LSP we have provided up to now in the current context is only "primary" and "secondary" and that using a fast notification mechanism and Path activation will cover basic needs today. Back to previous meetings, we also discussed these issues and concluded (i think it was in March) that protection and restoration will be covered in details during the next GMPLS steps. More complex one can be defined (standardized in further work i think this is purpose of this charter item). Hope this clarifies, - dimitri. "Mannie, Eric" wrote: > > Hello Stephen, > > John refers to fast restoration schemes that are being studied at the IETF. > Such schemes are widely implemented in the new classes of optical/TDM > equipments. > > The wording of the text just need to use the terms "working" LSP and > "protecting" LSP, instead of primary and secondary. That's just an editing > modification. > > The bit itself is useful to qualify the LSP being established. > > The mechanisms to be applied to this qualification will be detailed in other > documents. > > In the mean time, I guess that this bit can be used by implementations for a > simple restoration scheme (e.g. first establish working and protecting LSPs, > resources of protecting LSP may be "soft reserved", i.e. for extra-traffic, > when a fault occur send an RSVP-TE rapid failure notification to the source, > send Path with bit set to "working" on protecting LSP, this kills all LSPs > using these resources, when acked switch to this LSP). > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:38 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > The problem here is that this is not compatible with transport plane > protection. > Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation > of > the protection group is controlled by exchange of the K1, K2 bytes in the > MSOH of the PROTECTION MS. If the control plane reuses the protection MS at > for a different LSP at a time when the state of the protection group is > "No Request" (assuming no extra traffic carried on the protection section in > the > transport plane), this disables the protection since the endpoints of the > protection group are no longer able to exchange K1, K2 over the protection > channel. Even though the payload is unused and irrelevant to the transport > plane at this point, the exchange of overhead is essential to proper > operation > of the protection group. > Regards, > Steve > > John Drake wrote: > > > > Steven, > > > > The basic idea is that if a connection is of type 'secondary', then other > > LSPs of type 'primary' between the same or different source/destination > > pairs MAY use its resources in intermediate nodes, until that LSP is > > converted into a 'primary' with a subsequent Path/Resv flow. At this > point, > > other LSPs that were using its resources may get pre-empted. Think of the > > primary/secondary mechanism as a way to ensure temporal priority while > > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > > is carrying no data. > > > > So in the 1:1 case the protect LSP could be established either as a > primary > > or secondary LSP, while in the 1:N case the protect LSP would be > established > > as a secondary. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 PM > > To: John Drake > > Cc: Maarten Vissers; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > John, > > It would seem from this standpoint, ANY transport plane protection > > must use "primary" for all trails. You have already made this argument > > for the 1+1 case to carry the permanently bridged copy of the payload. > > > > In 1:1 or 1:n, when protection is not being used to carry one/any of > > the normal traffic signals, it may either carry a null signal (no bridge) > > or transport plane extra traffic. Even if the transport plane has only > > a null signal on protection, the control plane cannot itself place extra > > traffic on any portion of the end-to-end protection channel as this is > > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > > The protection channel overhead is chosen to carry the APS since it is > > necessary to exchange APS bytes to complete a switch when working channels > > are failed. If the protection channel has failed and APS cannot be > > exchanged, > > normal traffic signals will not be selected from protection. > > Regards, > > Steve > > > > John Drake wrote: > > > > > > Maarten, > > > > > > That's fine, however it's beside the point. The semantics of > > > Primary/Secondary refer to the control plane and whether the node > > > establishing a given LSP is planning to use it at the time it's > > established > > > or at a later time. As I indicated in an earlier note, 1+1 transport > > plane > > > protection would be accomplished in the control plane by establishing > two > > > LSPs of type Primary. The control plane really doesn't care which LSP > the > > > transport plane is using as Working and which as Protect, although that > > > information is available to the control plane at the LSP endpoints. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Thursday, December 13, 2001 12:15 AM > > > To: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > There exist well defined protection terminology in ITU-T for the > transport > > > plane. "Working" and "Protection" are being used and not > > primary/secondary. > > > E.g. > > > a 1+1 architecture has one working connection, one protection connection > > and > > > a > > > permanent bridge. > > > > > > Besides working/protection indication for the transport entity, there is > > > - "active" and "standby" to indicate if the signal is selected from the > > > working > > > or protection transport entity; i.e. if selector selects from working, > the > > > working is active and protection is standby, if the selector selects > from > > > protection the working is standby and the protection is active. > > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > > > Regards, > > > > > > Maarten > > > > > > neil.2.harrison@bt.com wrote: > > > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > > > neil > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: 12 December 2001 17:46 > > > > > To: 'Ben Mack-Crane'; John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > Ben, > > > > > Please see inline. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > > To: John Drake > > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > > > Regards, > > > > > > Ben > > > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > > > Snipped > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > > To: Lou Berger > > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > > allocated for a > > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > > primary LSP fails > > > > > > > > > over to the secondary LSP." This may not always be > > > > > > the case. An > > > > > > > > > explicit flag indicating whether or not extra > > > > > > traffic may use the > > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > > as indicating > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > > protection the > > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > > being defined > > > > > > > before the protection framework and requirements are > > > > > done. Is this > > > > > > > presupposing some particular outcome of the recovery work in > CAMP? > > > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > > 1+1 and 1:1 > > > > > > > protection, there would be a pair of Primary LSPs between > > > > > the source > > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that > the > > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > > carrying user data > > > > > traffic and it is an endpoint decision as to which path is > > > > > actually the > > > > > working/recovery path. At a transit node, both paths need to > > > > > be treated as > > > > > primary, as the resources are currently being used and > > > > > obviously can't be > > > > > used for Extra Traffic. > > > > > --------------986C2E8614D315EF8C772696 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------986C2E8614D315EF8C772696-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:51:18 -0800 Message-ID: <3C20CFAF.4AC5E85C@alcatel.be> Date: Wed, 19 Dec 2001 18:34:39 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: John Drake CC: "'Stephen Trowbridge'" , Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------8986464869B5E4647CEE556F" This is a multi-part message in MIME format. --------------8986464869B5E4647CEE556F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, To be more generic, any technology that does not support associated overhead (SDH/Sonet) or non-associated overhead (G.709 OCh) can use the control plane for protection switching purposes. In addition to the references you have provided i would like to add the following one: http://search.ietf.org/internet-drafts/draft-many-optical-restoration-01.txt Cheers, - dimitri. John Drake wrote: > > Stephen, > > You're absolutely right if you want to use K1/K2 to signal the switchover > from working to protect. We were planning to use the control plane > signalling protocols, since we have to deal with more than just SONET/SDH. > See for example: > > http://search.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-01.t > xt > > http://search.ietf.org/internet-drafts/draft-bala-protection-restoration-sig > naling-00.txt > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 10:38 AM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > The problem here is that this is not compatible with transport plane > protection. > Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation > of > the protection group is controlled by exchange of the K1, K2 bytes in the > MSOH of the PROTECTION MS. If the control plane reuses the protection MS at > for a different LSP at a time when the state of the protection group is > "No Request" (assuming no extra traffic carried on the protection section in > the > transport plane), this disables the protection since the endpoints of the > protection group are no longer able to exchange K1, K2 over the protection > channel. Even though the payload is unused and irrelevant to the transport > plane at this point, the exchange of overhead is essential to proper > operation > of the protection group. > Regards, > Steve > > John Drake wrote: > > > > Steven, > > > > The basic idea is that if a connection is of type 'secondary', then other > > LSPs of type 'primary' between the same or different source/destination > > pairs MAY use its resources in intermediate nodes, until that LSP is > > converted into a 'primary' with a subsequent Path/Resv flow. At this > point, > > other LSPs that were using its resources may get pre-empted. Think of the > > primary/secondary mechanism as a way to ensure temporal priority while > > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > > is carrying no data. > > > > So in the 1:1 case the protect LSP could be established either as a > primary > > or secondary LSP, while in the 1:N case the protect LSP would be > established > > as a secondary. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 PM > > To: John Drake > > Cc: Maarten Vissers; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > John, > > It would seem from this standpoint, ANY transport plane protection > > must use "primary" for all trails. You have already made this argument > > for the 1+1 case to carry the permanently bridged copy of the payload. > > > > In 1:1 or 1:n, when protection is not being used to carry one/any of > > the normal traffic signals, it may either carry a null signal (no bridge) > > or transport plane extra traffic. Even if the transport plane has only > > a null signal on protection, the control plane cannot itself place extra > > traffic on any portion of the end-to-end protection channel as this is > > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > > The protection channel overhead is chosen to carry the APS since it is > > necessary to exchange APS bytes to complete a switch when working channels > > are failed. If the protection channel has failed and APS cannot be > > exchanged, > > normal traffic signals will not be selected from protection. > > Regards, > > Steve > > > > John Drake wrote: > > > > > > Maarten, > > > > > > That's fine, however it's beside the point. The semantics of > > > Primary/Secondary refer to the control plane and whether the node > > > establishing a given LSP is planning to use it at the time it's > > established > > > or at a later time. As I indicated in an earlier note, 1+1 transport > > plane > > > protection would be accomplished in the control plane by establishing > two > > > LSPs of type Primary. The control plane really doesn't care which LSP > the > > > transport plane is using as Working and which as Protect, although that > > > information is available to the control plane at the LSP endpoints. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Thursday, December 13, 2001 12:15 AM > > > To: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > There exist well defined protection terminology in ITU-T for the > transport > > > plane. "Working" and "Protection" are being used and not > > primary/secondary. > > > E.g. > > > a 1+1 architecture has one working connection, one protection connection > > and > > > a > > > permanent bridge. > > > > > > Besides working/protection indication for the transport entity, there is > > > - "active" and "standby" to indicate if the signal is selected from the > > > working > > > or protection transport entity; i.e. if selector selects from working, > the > > > working is active and protection is standby, if the selector selects > from > > > protection the working is standby and the protection is active. > > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > > > Regards, > > > > > > Maarten > > > > > > neil.2.harrison@bt.com wrote: > > > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > > > neil > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: 12 December 2001 17:46 > > > > > To: 'Ben Mack-Crane'; John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > Ben, > > > > > Please see inline. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > > To: John Drake > > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > > > Regards, > > > > > > Ben > > > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > > > Snipped > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > > To: Lou Berger > > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > > allocated for a > > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > > primary LSP fails > > > > > > > > > over to the secondary LSP." This may not always be > > > > > > the case. An > > > > > > > > > explicit flag indicating whether or not extra > > > > > > traffic may use the > > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > > as indicating > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > > protection the > > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > > being defined > > > > > > > before the protection framework and requirements are > > > > > done. Is this > > > > > > > presupposing some particular outcome of the recovery work in > CAMP? > > > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > > 1+1 and 1:1 > > > > > > > protection, there would be a pair of Primary LSPs between > > > > > the source > > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that > the > > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > > carrying user data > > > > > traffic and it is an endpoint decision as to which path is > > > > > actually the > > > > > working/recovery path. At a transit node, both paths need to > > > > > be treated as > > > > > primary, as the resources are currently being used and > > > > > obviously can't be > > > > > used for Extra Traffic. > > > > > --------------8986464869B5E4647CEE556F Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------8986464869B5E4647CEE556F-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:46:23 -0800 Message-ID: <3C20D03C.F85B808A@alcatel.be> Date: Wed, 19 Dec 2001 18:37:00 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: "Mannie, Eric" , "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Content-Type: multipart/mixed; boundary="------------C98D972D8359A4EA3CF28E63" This is a multi-part message in MIME format. --------------C98D972D8359A4EA3CF28E63 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This discussion is going into limbos because once a solution is provided and agreed by all parties, afterwards the elements having enabled to come up to this decision disappear... for instance, VT3 SPE now are not used anymore... were they used one week before and just stop now ? Mor generally, since it is not the job of the CCAMP community to verify if the content of ITU/T1X1 specifications are implemented in current networks it is for me irrelevant to state as done by Stephen that they are not used. How can i verify such assertion ? At the end of the day i have got the following impression ITU T1 people blind the differences they maintain in their own documents... Deborah/Stephen sorry but GR.253 specification has just been extended to LCAS capabilities so T1X1 and ITU maintains their own version (G.707 is also being extended)... in this context sorry but we are at a point where people maintains artificial discussions for reasons which are very difficult to understand ? Very interesting the following e-mail from Maarten, why do i have to keep two terms in order to translate the same entity if Sonet is a subset of SDH ? Cheers, - dimitri. Maarten Vissers wrote: > > Eric, > > It is not the intention to leave the choice of LSP encoding type and SU label > structure to the vendor. This would give immediate interworking problems. > > VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, > VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP > encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP > encoding type "SDH". > > VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c > and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. > > Looking at the label text in section 3 of the sonet-sdh document, I find it very > confusing to read that SONET doesn't use the "U" field. As we indicated before > there is no STS type signal that isn't having an SDH equivalent; i.e. there are > no specific higher order SONET signals left. It is therefore much better to take > out the SONET text for the SU label part altogether. Otherwise we will get a lot > of confusion in the marketplace. > > Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label > with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must > thus use the "SDH" SU format. > > ------- > > All, > > With the clarification on VT-3 given by Deborah, I would request to consider a > further simplification of the GMPLS standard: delete the LSP encoding type > "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there > would be no ambiguity left at all. > > Regards, > > Maarten > > "Mannie, Eric" wrote: > > > > Hi Jonathan, > > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > interoperability problems in the future... > > > > To leave to the manufacturer and to the user the right to decide if he/she > > wants to signal an LSP as either SDH or SONET. There is no interoperability > > problem at all since you use EITHER SDH OR SONET. If you decide to request > > an SDH signal with what do you want to have interoperability issue at this > > stage ? The sentence means indeed "one should better use SDH than SONET" ! > > Once you decided, there is no issue. > > > > > I'm curious what sort of backward compatability is necessary, as a > > "standard" doesn't exist currently that this needs to be backward > > compatible with... > > > > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with > > the implementations that could not care of SDH, with implementations that > > still do a distinction between SONET and SDH for some reasons, with the > > implementations that could still use the VT3 (DS1C) (I don't have > > confirmation that nobody is using it today, and this is not the goal of this > > draft to state what is obsolete or not in SONET), etc. > > > > Anyway, there is no issue, the SONET label format is not used until SONET is > > explicitly requested as such. This is not a primary feature of the draft, > > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for > > everything, consequently you don't care of the SONET label, you skip it in > > the draft, you ignore it, you don't implement it and you just use a full SDH > > implementation. > > > > I think that the solution is quite simple: if the SONET signal is indeed an > > SDH signal, why do you bother with SONET ? Just ask for an SDH signal, > > that's all. > > > > By the way, since according to some folks SONET is just a subset of SDH, why > > do we care about SONET in these documents ? Why don't we simply remove all > > references to SONET ? > > > > Is there somebody on this mailing list that cares about SONET ? If yes, why > > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ? > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > > Sent: Tuesday, December 18, 2001 9:57 PM > > To: Mannie, Eric > > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > > dbrungard@att.com; lberger@movaz.com > > Subject: Re: GMPLS signaling documents updated per last calls > > > > Eric - > > > > Comments inline... > > > > Jonathan Sadler > > > > "Mannie, Eric" wrote: > > > "A SONET signal which has an identical SDH signal SHOULD be requested > > using > > > the same traffic parameters as for the equivalent SDH signal, and will > > > consequently use the SDH label." > > > > Why SHOULD and not MUST? This ambiguity is likely to create > > interoperability problems in the future... > > > > > We spend with Maarten a lot of time to write that sentence (not easy to > > > write). > > > > > > Maybe that it should be better written: > > > > > > "A SONET signal which has an identical SDH signal SHOULD be requested as > > an > > > SDH signal using the same traffic parameters as for the equivalent SDH > > > signal, and will consequently use the SDH label." > > > > Again, "SHOULD" needs to be replaced with "MUST"... > > > > > This doesn't mean that the SONET signal format disappear (simply not used > > in > > > that case), for backward compatibility we need to keep it. > > > > I'm curious what sort of backward compatability is necessary, as a > > "standard" doesn't exist currently that this needs to be backward > > compatible with... > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Tuesday, December 18, 2001 7:46 PM > > > To: Kireeti Kompella > > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > > bwijnen@lucent.com; sob@harvard.edu > > > Subject: Re: GMPLS signaling documents updated per last calls > > > > > > Kireeti, > > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > > > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > > > > > Deborah Brungard wrote: > > > > The VT3 (3M) structure was defined - but no services (mappings) were > > ever > > > defined for it. So there are no services/equip > > > > with it. My take was if in the future it was ever defined (doubtful), we > > > would be adding it to g707 also. So then it > > > > would just be part of g707 too. > > > > > > So basically, there are no mappings or equipment functions for this rate, > > > and as far as we know no network equipment or networks supporting it. > > > Deborah suggests that if we were ever to define such mappings, that this > > > would be proposed for addition to G.707 and hence be part of SDH. > > > > > > I think our agreement had been to use the SDH label for all signals that > > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > > > thought > > > that this was everything except VT3. Given that VT3 seems not to be a > > "real" > > > signal at this point and will likely be added to SDH if it ever becomes > > > real, does our agreement then become that we use SDH labels for > > everything? > > > > > > Regards, > > > Steve > > > > > > Kireeti Kompella wrote: > > > > > > > > Hi Deborah, > > > > > > > > > I previously made the > > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > > > several issues, among them this one. The upshot was that whenever > > > > possible, the SDH label should be used, with the encoding type > > > > set to SDH (i.e., G.707); however, there are signals that have > > > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > > > me!), so we will keep SONET labels and encoding types around > > > > for that case and for legacy equipment. > > > > > > > > The revised SONET/SDH document will contain the exact wording. > > > > I will also be sending a reply to the ITU communication stating > > > > the agreement we came to. > > > > > > > > Kireeti. --------------C98D972D8359A4EA3CF28E63 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------C98D972D8359A4EA3CF28E63-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 09:28:51 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Philip Matthews Cc: "'ccamp@ops.ietf.org'" Subject: Re: FYI - Discussion of LDP resiliency in MPLS WG Message-Id: Date: Wed, 19 Dec 2001 09:24:35 -0800 you must post from your subscription address randy > Message-ID: <8812A03F65CDD511AE98006008F5E87101063374@hermes.hyperchip.com> > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C188B1.8B73B710" > From: Philip Matthews > To: "'ccamp@ops.ietf.org'" > Subject: FYI - Discussion of LDP resiliency in MPLS WG > Date: Wed, 19 Dec 2001 12:21:07 -0500 > > For those not subscribed to the MPLS WG list, > I just posted a note on the status of the various proposals > for LDP resiliency to the MPLS WG mailing list. > > People in CCAMP might also be interested in this work, > because some of it also applies to CR-LDP, and because > there are similar proposals for RSVP-TE, as well as > for various routing protocols. > > I will ask that people interesting in contributing > post their comments to the MPLS WG, and not to CCAMP, > since the work is happening in the former. > > - Philip > > > > > > > FYI - Discussion of LDP resiliency in MPLS WG > > > >

For those not subscribed to the MPLS WG list, >
I just posted a note on the status of the various proposals >
for LDP resiliency to the MPLS WG mailing list. >

> >

People in CCAMP might also be interested in this work, >
because some of it also applies to CR-LDP, and because >
there are similar proposals for RSVP-TE, as well as >
for various routing protocols. >

> >

I will ask that people interesting in contributing >
post their comments to the MPLS WG, and not to CCAMP, >
since the work is happening in the former. >

> >

- Philip >

> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 07:55:29 -0800 Message-Id: <200112191534.fBJFYW622454@merlot.juniper.net> To: George Newsome cc: CCAMP Subject: Re: GMPLS Issue - Ethernet LSP Enc Type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98215.1008776072.1@juniper.net> Date: Wed, 19 Dec 2001 07:34:32 -0800 From: Yakov Rekhter George, > > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: > > > > > > > > >The following issue raised 10/29/01 has not been addressed. > > > > > ........................ > > > > > > > > The current wording is what was agreed to. > > > > > > > > > >So if I understand this correctly, the wording that you allude to was > > >agreed in private discusions? > > > > To be precise, the wording was agreed to among all the authors. > > > I stand corrected - agreed to in private discussions among all the > authors. > > > >Without public discussion, > > > > I think you'd agree that it's impractical to review in detail every change > > in a draft, prior to it being made, on the ccamp list. What we have done > > is to reach agreement first among the co-authors and then to review the > > changes as part of issuing the new drafts. The encoding type change was > > made *9* months ago. There has been ample opportunity for review and comme > > comment. > > > Actually I disagree. In other bodies documents are reviewed on a line by > line basis until all parties indicate agreement. I hope it would not surprise you that the rules of "other bodies" may not apply to the IETF, as in the IETF there is a need only for "rough consensus", and not for all parties to reach an agreement. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 07:53:36 -0800 Message-Id: <4.3.2.7.2.20011219102136.02eba6b0@mo-ex1> Date: Wed, 19 Dec 2001 10:31:15 -0500 To: "George Newsome" From: Lou Berger Subject: Re: GMPLS Issue - Ethernet LSP Enc Type Cc: "Berger, Lou" , "Ben Mack-Crane" , "CCAMP" ,kireeti@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed George, See responses below. At 10:14 AM 12/19/2001, George Newsome wrote: >Lou Berger wrote: > > > > At 09:19 AM 12/19/2001, George Newsome wrote: > > >Lou Berger wrote: > > > > > > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: > > > > > > > > >The following issue raised 10/29/01 has not been addressed. > > > > >........................ > > > > > > > > The current wording is what was agreed to. > > > > > > > > > >So if I understand this correctly, the wording that you allude to was > > >agreed in private discusions? > > > > To be precise, the wording was agreed to among all the authors. > > >I stand corrected - agreed to in private discussions among all the >authors. I was clarifying my earlier statement, my apologies if it came off as correcting you. > > >Without public discussion, > > > > I think you'd agree that it's impractical to review in detail every change > > in a draft, prior to it being made, on the ccamp list. What we have done > > is to reach agreement first among the co-authors and then to review the > > changes as part of issuing the new drafts. The encoding type change was > > made *9* months ago. There has been ample opportunity for review and > comment. > > >Actually I disagree. In other bodies documents are reviewed on a line by >line basis until all parties indicate agreement. I'm surprised to see you say this as you must know this is not how things work in the IETF. >........ > > > > isn't there some quote about pleasing all the people all the time... > > >Isn't there also some quote that in science and engineering, volume of >opinion != correctness? Again, per my last message: >again, one person objecting != lack of "rough consensus". > >Remember this item has not changed since March. > >Unless the WG chair says otherwise, I see this issues as closed. Lou >Regards > > George Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 07:20:05 -0800 Message-ID: <3C20AEE0.E9CB570@lucent.com> Date: Wed, 19 Dec 2001 10:14:40 -0500 From: George Newsome Organization: Lucent Technologies, Bell Labs MIME-Version: 1.0 To: Lou Berger CC: Ben Mack-Crane , CCAMP Subject: Re: GMPLS Issue - Ethernet LSP Enc Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lou Berger wrote: > > At 09:19 AM 12/19/2001, George Newsome wrote: > >Lou Berger wrote: > > > > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: > > > > > > >The following issue raised 10/29/01 has not been addressed. > > > ........................ > > > > > > The current wording is what was agreed to. > > > > > > >So if I understand this correctly, the wording that you allude to was > >agreed in private discusions? > > To be precise, the wording was agreed to among all the authors. > I stand corrected - agreed to in private discussions among all the authors. > >Without public discussion, > > I think you'd agree that it's impractical to review in detail every change > in a draft, prior to it being made, on the ccamp list. What we have done > is to reach agreement first among the co-authors and then to review the > changes as part of issuing the new drafts. The encoding type change was > made *9* months ago. There has been ample opportunity for review and comment. > Actually I disagree. In other bodies documents are reviewed on a line by line basis until all parties indicate agreement. ........ > > isn't there some quote about pleasing all the people all the time... > Isn't there also some quote that in science and engineering, volume of opinion != correctness? Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 06:43:27 -0800 Message-Id: <4.3.2.7.2.20011219092558.01d20818@mo-ex1> Date: Wed, 19 Dec 2001 09:40:46 -0500 To: George Newsome From: Lou Berger Subject: Re: GMPLS Issue - Ethernet LSP Enc Type Cc: Lou Berger , Ben Mack-Crane ,CCAMP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:19 AM 12/19/2001, George Newsome wrote: >Lou Berger wrote: > > > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: > > > > >The following issue raised 10/29/01 has not been addressed. > > > > I disagree. We talked in person on this and I said the same thing on > the list. > > > > > > >1) There seems to be no difference as far as label allocation > > > > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > > > > and Ethernet 802.3 (10). One Encoding type would seem to > > > > > be sufficient. > > > > > > > > I agree, but some feel that this is needed to properly establish > LSPs in > > > > systems what would terminate each type differently. > > > > > >I don't recall seeing anything on the list about the reasoning about this. > > >can someone provide a pointer to where this was described? > > > > As I mentioned at the IETF, it was in private discussions. > > > > >Since LSP Encoding type is intended to describe the LSP for transit nodes > > >and G-PID is intended to describe the LSP contents for the purpose of > > >terminating it at the ends, information relevant only to termination > > >should be conveyed in G-PID. > > > > > >Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" > > >would make this clearer. > > > > The current wording is what was agreed to. > > > >So if I understand this correctly, the wording that you allude to was >agreed in private discusions? To be precise, the wording was agreed to among all the authors. >Without public discussion, I think you'd agree that it's impractical to review in detail every change in a draft, prior to it being made, on the ccamp list. What we have done is to reach agreement first among the co-authors and then to review the changes as part of issuing the new drafts. The encoding type change was made *9* months ago. There has been ample opportunity for review and comment. > it seems hard to claim that the issue has >been resolved, again, one person objecting != lack of "rough consensus". Remember this item has not changed since March. Unless the WG chair says otherwise, I see this issues as closed. >and Ben is clearly not satisfied. isn't there some quote about pleasing all the people all the time... Lou >Regards > > George Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 06:32:14 -0800 Message-Id: <200112191420.fBJEKu621057@merlot.juniper.net> To: "Maarten Vissers" cc: "Markus Jork" , "Berger, Lou" , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88102.1008771655.1@juniper.net> Date: Wed, 19 Dec 2001 06:20:56 -0800 From: Yakov Rekhter Maarten, >Markus, John, Lou, Manoj, > >I also still have a major issue to understand the switching type... or more >precise I have the feeling it is too coarse and ill defined. Let me >provide some more examples to evaluate: > >Frist Markus' network example... it will look like the following in reality > > R1 ------ OXC1 ------ OXC2 ------ R2 > OC-N OC-N OC-N > > OC-N trail > |<------------------------------>| > > STS-Nc trail > |<-------------------------------->| > > IP Link >|<---------------------------------->| > >I assume that OXC1/2 are all optical cross connects which pass through the >complete OC-N signals. > >In order to route IP packets between R1 and R2, you need to set up an OC-N >trail between R1 and R2. Correct. (Stating the obvious) the Switching Type for that LSP will be set to LSC. > Once this is done, you need to set up a STS-Nc trail between > R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 > 640 kbit/s established between R1 and R2. > Now IP signals can flow between R1 and R2. There is no need to establish an STS-Nc trail between R1 and R2 - the OC-N LSP is sufficient. >Now make the example a bit more complex and let me add a SONET cross >connect in the chain. > > R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2 > OC-N OC-N OC-N OC-N > > OC-N trail OC-N trail > |<------------------------------>| |<------>| > > STS-Nc trail > |<-------------------------------------------->| > > IP Link >|<---------------------------------------------->| > >The physical interface in each case is an OC-N. The DXC1 is a SONET cross >connect, which terminates the OC-N Section and Line layers and forwards the >STS-Nc signal. > >What would the switching types be in this case when an LSP is requested >between R1 and R2? (stating the obvious) TDM. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 06:31:29 -0800 Message-ID: <3C20A1FF.1A4A679B@lucent.com> Date: Wed, 19 Dec 2001 09:19:43 -0500 From: George Newsome Organization: Lucent Technologies, Bell Labs MIME-Version: 1.0 To: Lou Berger CC: Ben Mack-Crane , CCAMP Subject: Re: GMPLS Issue - Ethernet LSP Enc Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lou Berger wrote: > > At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: > > >The following issue raised 10/29/01 has not been addressed. > > I disagree. We talked in person on this and I said the same thing on the list. > > > > >1) There seems to be no difference as far as label allocation > > > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > > > and Ethernet 802.3 (10). One Encoding type would seem to > > > > be sufficient. > > > > > > I agree, but some feel that this is needed to properly establish LSPs in > > > systems what would terminate each type differently. > > > >I don't recall seeing anything on the list about the reasoning about this. > >can someone provide a pointer to where this was described? > > As I mentioned at the IETF, it was in private discussions. > > >Since LSP Encoding type is intended to describe the LSP for transit nodes > >and G-PID is intended to describe the LSP contents for the purpose of > >terminating it at the ends, information relevant only to termination > >should be conveyed in G-PID. > > > >Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" > >would make this clearer. > > The current wording is what was agreed to. > So if I understand this correctly, the wording that you allude to was agreed in private discusions? Without public discussion, it seems hard to claim that the issue has been resolved, and Ben is clearly not satisfied. Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 06:09:27 -0800 Message-Id: <4.3.2.7.2.20011219085152.02bd25d8@mo-ex1> Date: Wed, 19 Dec 2001 08:57:13 -0500 To: From: Lou Berger Subject: RE: Fwd: Comments on GMPLS signalling drafts Cc: "Berger, Lou" , "manoj juneja" ,, , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Fong, Thank you for the explanation. Given where we are in the process and that it is acceptable, we should leave it as it stands. As usual, thank you for the comments. Lou PS Yes, I misread Manoj's comments. Obviously, I thought he was saying that we used your text without reference. As you know, and as indicated in the document, we have integrated text that you have proposed. At 09:26 PM 12/18/2001, Fong Liaw wrote: >Lou > >I was not in London, so probably just not being informed. >The proposed change does not create interoperability problem >since there is only one node that would resolves it, >but I have no problem keeping the current text either. The problem >seems to be that the same question keeps on coming back and >there are situations where a different resolution will result >in slightly better call setup. A typical scenario is that >a call coming from network to user has gone a long way and >usually has priority on getting the resources. > >The question we are facing here is whether different >behavior, if does not create interoperability issue, >is allowed. From my read of the draft, it is not .. >Again, I have no problem with current text so you don't >have to convince me, I thought you agree with manoj's >comment and in that case the current text does not >reflect it. > >Regards, >-Fong > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Lou Berger > > Sent: Tuesday, December 18, 2001 3:22 PM > > To: Fong Liaw > > Cc: Berger, Lou; manoj juneja; Eric.Mannie@ebone.com; > > dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org > > Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > > > > Fong, > > As you know, we've discussed this many times. The last time it > > was discussed in detail (London if memory serves) my memory is that we > > decided to keep current working as is because (a) different vendor > > approaches can lead to interoperability issues and (b) this is a common > > tie-breaker solution. > > > > Lou > > > > > > At 04:33 PM 12/14/2001, Fong Liaw wrote: > > > > >Lou > > > > > >I am happy to see my interest protected, however > > >I think manoj is asking to insert the "optimization > > >vs. correctness" text into the draft. Right now, > > >-07 text says a node with higher node id MUST send > > >a PathErr etc. this does not allow for different > > >behavior. > > > > > >I would suggest to change the text slightly as > > >following: > > > > > >"To resolve contention, the node with the higher node > > >ID will > > > win the contention and it MUST issue a > > > ^^^ resolve > > >PathErr/NOTIFICATION message > > >^^^^^^^PathErr/Path/Notification > > > with a "Routing problem/Label allocation failure" > > >indication. " > > > ^ for the LSP that loses in the > > >resolution. > > > > > >We can also specify the default behavior is that > > >"the LSP requested by a higher node id wins the > > >resolution." > > > > > >Regards, > > >-Fong > > > > > > > > > > > > > > >7. There is an example scenario for contention > > > > resolution in case of bi- > > > > > >directional LSPs. It should be mentioned that : > > > > > > > > > > > >"contention resolution is an optimization, not a > > > > correctness issue ... > > > > > >and no procedure can provide optimal resolution > > > > in all cases. An > > > > > >implementor > > > > > >may do differently to provide better resolution." > > > > > > > > > > > >The above quotes are extracted from one of the > > > > mails from Fong Liaw. > > > > > > > > > > > >If this is the case then this should be mentioned > > > > in the drafts. > > > > > > > > > > > > > > Read the Acknowledgments section of the draft. (I'm > > > > sure Fong will be > > > > happy to see you protecting her interests!) > > > > > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Check out Yahoo! Shopping and Yahoo! Auctions for all of > > >your unique holiday gifts! Buy at > > ><http://shopping.yahoo.com>http://shopping.y > ahoo.com > > >or bid at > <http://auctions.yahoo.com>http://auctions.yahoo.com > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at >http://mail.yahoo.com > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 06:02:58 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C209526.FD418DF4@lucent.com> Date: Wed, 19 Dec 2001 14:24:54 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: ccamp@ops.ietf.org Subject: protection and restoration [was: Re: Moving right along ... generalized-signaling-06] Content-Type: multipart/mixed; boundary="------------85E34B708726E670AEA44156" This is a multi-part message in MIME format. --------------85E34B708726E670AEA44156 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, One of the requirements we have to meet is that traffic of user A is not delivered to user B. Also during recovery from a failed connection (either by means of protection swithcing, or restoration) we have to guarantee that user A traffic is not delivered to user B. This adds additional requirements to the operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc architectures; these have a potential to temporarily connect A to B. In protection switching this is guaranteed by means of the combination of protection architecture and protection switching protocol type (1-phase, 2-phase, 3-phase protocols). The tail end normal output #i of the protected domain will never select from the protection connection until it is guaranteed that normal input #i at the head end is bridged onto this protection connection. And vice versa, the tail end will deselect the protection connection before the head end will put a different signal onto that protection connection. I assume that for the case of restoration and fast restoration, the same requirement is applicable. Has this requirement been considered in the work on fast restoration? It looks like "fast restoration" is a control plane based protection switching. Is my understanding correct? If so, with transport plane based protection switching build into SDH/SONET and OTN, is fast restoration being a pre-OTN feature? I assume there is no need to replace SDH/SONET/OTN transport plane based protection switching by control plane based protection switching. As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching defined in the transport plane, pre-OTN has no alternative to control plane based protection. Regards, Maarten "Mannie, Eric" wrote: > > Hello Stephen, > > John refers to fast restoration schemes that are being studied at the IETF. > Such schemes are widely implemented in the new classes of optical/TDM > equipments. > > The wording of the text just need to use the terms "working" LSP and > "protecting" LSP, instead of primary and secondary. That's just an editing > modification. > > The bit itself is useful to qualify the LSP being established. > > The mechanisms to be applied to this qualification will be detailed in other > documents. > > In the mean time, I guess that this bit can be used by implementations for a > simple restoration scheme (e.g. first establish working and protecting LSPs, > resources of protecting LSP may be "soft reserved", i.e. for extra-traffic, > when a fault occur send an RSVP-TE rapid failure notification to the source, > send Path with bit set to "working" on protecting LSP, this kills all LSPs > using these resources, when acked switch to this LSP). > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:38 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > The problem here is that this is not compatible with transport plane > protection. > Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation > of > the protection group is controlled by exchange of the K1, K2 bytes in the > MSOH of the PROTECTION MS. If the control plane reuses the protection MS at > for a different LSP at a time when the state of the protection group is > "No Request" (assuming no extra traffic carried on the protection section in > the > transport plane), this disables the protection since the endpoints of the > protection group are no longer able to exchange K1, K2 over the protection > channel. Even though the payload is unused and irrelevant to the transport > plane at this point, the exchange of overhead is essential to proper > operation > of the protection group. > Regards, > Steve > > John Drake wrote: > > > > Steven, > > > > The basic idea is that if a connection is of type 'secondary', then other > > LSPs of type 'primary' between the same or different source/destination > > pairs MAY use its resources in intermediate nodes, until that LSP is > > converted into a 'primary' with a subsequent Path/Resv flow. At this > point, > > other LSPs that were using its resources may get pre-empted. Think of the > > primary/secondary mechanism as a way to ensure temporal priority while > > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > > is carrying no data. > > > > So in the 1:1 case the protect LSP could be established either as a > primary > > or secondary LSP, while in the 1:N case the protect LSP would be > established > > as a secondary. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 PM > > To: John Drake > > Cc: Maarten Vissers; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > John, > > It would seem from this standpoint, ANY transport plane protection > > must use "primary" for all trails. You have already made this argument > > for the 1+1 case to carry the permanently bridged copy of the payload. > > > > In 1:1 or 1:n, when protection is not being used to carry one/any of > > the normal traffic signals, it may either carry a null signal (no bridge) > > or transport plane extra traffic. Even if the transport plane has only > > a null signal on protection, the control plane cannot itself place extra > > traffic on any portion of the end-to-end protection channel as this is > > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > > The protection channel overhead is chosen to carry the APS since it is > > necessary to exchange APS bytes to complete a switch when working channels > > are failed. If the protection channel has failed and APS cannot be > > exchanged, > > normal traffic signals will not be selected from protection. > > Regards, > > Steve > > > > John Drake wrote: > > > > > > Maarten, > > > > > > That's fine, however it's beside the point. The semantics of > > > Primary/Secondary refer to the control plane and whether the node > > > establishing a given LSP is planning to use it at the time it's > > established > > > or at a later time. As I indicated in an earlier note, 1+1 transport > > plane > > > protection would be accomplished in the control plane by establishing > two > > > LSPs of type Primary. The control plane really doesn't care which LSP > the > > > transport plane is using as Working and which as Protect, although that > > > information is available to the control plane at the LSP endpoints. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Thursday, December 13, 2001 12:15 AM > > > To: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > There exist well defined protection terminology in ITU-T for the > transport > > > plane. "Working" and "Protection" are being used and not > > primary/secondary. > > > E.g. > > > a 1+1 architecture has one working connection, one protection connection > > and > > > a > > > permanent bridge. > > > > > > Besides working/protection indication for the transport entity, there is > > > - "active" and "standby" to indicate if the signal is selected from the > > > working > > > or protection transport entity; i.e. if selector selects from working, > the > > > working is active and protection is standby, if the selector selects > from > > > protection the working is standby and the protection is active. > > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > > > Regards, > > > > > > Maarten > > > > > > neil.2.harrison@bt.com wrote: > > > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > > > neil > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: 12 December 2001 17:46 > > > > > To: 'Ben Mack-Crane'; John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > Ben, > > > > > Please see inline. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > > To: John Drake > > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > > > Regards, > > > > > > Ben > > > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > > > Snipped > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > > To: Lou Berger > > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > > allocated for a > > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > > primary LSP fails > > > > > > > > > over to the secondary LSP." This may not always be > > > > > > the case. An > > > > > > > > > explicit flag indicating whether or not extra > > > > > > traffic may use the > > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > > as indicating > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > > protection the > > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > > being defined > > > > > > > before the protection framework and requirements are > > > > > done. Is this > > > > > > > presupposing some particular outcome of the recovery work in > CAMP? > > > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > > 1+1 and 1:1 > > > > > > > protection, there would be a pair of Primary LSPs between > > > > > the source > > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that > the > > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > > carrying user data > > > > > traffic and it is an endpoint decision as to which path is > > > > > actually the > > > > > working/recovery path. At a transit node, both paths need to > > > > > be treated as > > > > > primary, as the resources are currently being used and > > > > > obviously can't be > > > > > used for Extra Traffic. > > > > > --------------85E34B708726E670AEA44156 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------85E34B708726E670AEA44156-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 01:19:51 -0800 Message-ID: <3C205A5D.6B18F33@lucent.com> Date: Wed, 19 Dec 2001 10:14:05 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------6BA58095FEA1B65CE1735158" This is a multi-part message in MIME format. --------------6BA58095FEA1B65CE1735158 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Zhi-Wei Lin wrote: > > Hi, > > I think active/standby and extra-traffic/normal-traffic are also two > separate descriptors. They are indeed separate descriptors. See e.g. draft G.gps. > Extra traffic may be carried on a standby connection (but a standby > connection does not necessarily have extra traffic on it). Correct. 1+1 prot architecture can't even support extra traffic. E.g. 1:1 and 1:n architectures can support extra traffic. As a 1:1 architecture is more complex than a 1+1 scheme, such 1:1 architecture will typically be deployed when extra traffic support is required. See for advantages/disadvantages associated with each protection architecture section 6.2 of draft G.gps: Possible advantages of the 1+1 architecture include: 1) low complexity. 2) for the case of unidirectional switching, the possibility to support dual node interconnect of protected subnetworks. Possible disadvantages of the 1+1 architecture include: 3) 100% extra capacity. Possible advantages of the 1:n, m:n, (1:1)n architecture include: 1) possibility to provide protection access; the protection transport entity/bandwidth can transport an extra traffic signal during periods the protection transport entity/bandwidth is not required to transport a normal traffic signal. 2) extra capacity restricted to 100/n % or m x 100/n % 3) for case of m:n, protection is possible for up to m faults. Possible disadvantages of the 1:n, m:n, (1:1)n architecture include: 4) complexity. 5) for case of SNC protection class, the need for additional sublayer termination functions at ingress and egress points of the protected domain on each working and protection transport entity. 6) does not support dual node interconnect of protected subnetworks. 7) n >= 2: each of the n working transport entities must be routed via different facilities and equipment to prevent the existence of common points of failure that can not be protected by the single protection transport entity in a 1:n and (1:1)n architecture. NOTE: Typically, n+1 alternative paths between two nodes in the network will not be available. As such, 1:n and (1:1)n, with n >= 2, architectures will not provide adequate protection for the n normal signals transported normally via the n working transport entities. n = 1 seems the only reasonable choice. NOTE: In ATM, protection access is not explicitly required to allow usage of the normally unused protection bandwidth; ABR and UBR traffic could use this protection bandwidth by means of a over-subscription of the bandwidth of the server signal containing the protection transport entity. The ABR/UBR higher layer control mechanism is assumed to reduce the traffic when the protection is actually used. The ingress/egress nodes of the protection domain do not have to align with ingress/egress nodes of ABR/UBR traffic. This adds flexibility to the network, and reduces complexity. > > How do we define normal traffic? Is this user traffic carried by working > path (when working is active), or also carried by recovery path (when > recovery is active)? Normal traffic signal is defined as follows (see G.gps): 3.10.1 Normal traffic signal - Traffic signal that is protected by two alternative transport entities, called working and protection entities. 3.10.2 Extra traffic signal - Traffic signal that is carried over the protection transport entity and/or bandwidth when that transport entity/bandwidth is not being used for the protection of a normal traffic signal; i.e. when protection transport entity is standby. Whenever the protection transport entity/bandwidth is required to protect or restore the normal traffic on the working entity, the extra traffic is pre-empted. Extra traffic is not protected. 3.10.3 Null signal - The null signal is indicated on the protection transport entity if it is not used to carry normal or extra traffic. The null signal can be any kind of signal that conforms to the signal structure of the specific layer and is ignored (not selected) at the tail end of the protection. > > And once you defined these, I think you still may need to specify > whether a connection is revertive or non-revertive. Revertive and non-revertive are protection "operation types". > > For example, take the case of 1+1. One operator may decide to use > non-revertive (because both paths are "equivalent") so avoid a switching > hit on the traffic (order of milliseconds?), while another operator may > decide to use revertive (because the recovery path is much longer/more > hops). Section 6.4/G.gps lists 5 cases where revertive operation may be appropriate: 1) Where parts of the protection transport entity may be taken to provide capacity to meet a more urgent need. For example, where protection transport entity can be taken out of service to release capacity for use in restoring other traffic. 2) Where the protection transport entity may be subject to frequent re-arrangement. For example, where a network has limited capacity and protection routes are frequently re-arranged to maximize network efficiency when changes occur in the network. 3) Where the protection transport entity is of significantly lower performance than the working transport entity. For example, where the protection transport entity has a worse error performance or longer delay than the working transport entity. 4) When an operator needs to know which transport entities are carrying normal traffic in order to simplify the management of the network. 5) Where dual node interconnect mechanism is applied to reliably interconnect two protected subnetworks. > Could these decisions be made per protected LSP basis? Yes. > If yes, then would tail-end need to know which mode it is operating/to > use (the intermediate nodes don't need to know this)? For the case of 1+1 architecture with "uni-directional switching" (switching type is another parameter) only the tail end needs to know the operation type. For a bi-directional connection, each tail end needs to know its operation type... in principle one direction can use non-revertive whereas the other direction can use revertive... but this is not logical, so default is to have both tail ends operating with the same operation type. For 1+1/1:n "bi-directional switching" both head end and tail ends need to know operation type, and the operation type must be the same at both ends. Intermediate nodes don't need to know about any of those protection parameters. Those protection parameters are allocated to the protection processes at the edge of the protected domain. See also figure 3 in section 3.2 in VBI contribution D.301 (SG15, Oct. 2001). Regards, Maarten > > Zhi > > Ben Mack-Crane wrote: > > > Maarten, > > > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > > because it seemed a more neutral term given that we were including both protection > > switching and reroute recovery mechanisms. > > > > We did not address the state (active/standby). We use the terms "extra traffic" and > > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > > > It would be useful in moving forward in CCAMP if we could try to adopt terms > > that are consistent with those in current use elsewhere. > > > > Regards, > > Ben > > > > Maarten Vissers wrote: > > > >>There exist well defined protection terminology in ITU-T for the transport > >>plane. "Working" and "Protection" are being used and not primary/secondary. E.g. > >>a 1+1 architecture has one working connection, one protection connection and a > >>permanent bridge. > >> > >>Besides working/protection indication for the transport entity, there is > >>- "active" and "standby" to indicate if the signal is selected from the working > >>or protection transport entity; i.e. if selector selects from working, the > >>working is active and protection is standby, if the selector selects from > >>protection the working is standby and the protection is active. > >>- "normal" and "extra traffic" signal. The normal signal is protected. > >> > >>Regards, > >> > >>Maarten > >> > >>neil.2.harrison@bt.com wrote: > >> > >>>Jonathan....review the text below....I think the problem is 1:1. > >>> > >>>neil > >>> > >>> > >>>>-----Original Message----- > >>>>From: Jonathan Lang [mailto:jplang@calient.net] > >>>>Sent: 12 December 2001 17:46 > >>>>To: 'Ben Mack-Crane'; John Drake > >>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > >>>>Subject: RE: Moving right along ... generalized-signaling-06 > >>>> > >>>> > >>>>Ben, > >>>> Please see inline. > >>>> > >>>>Thanks, > >>>>Jonathan > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > >>>>>Sent: Wednesday, December 12, 2001 8:56 AM > >>>>>To: John Drake > >>>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > >>>>>Subject: Re: Moving right along ... generalized-signaling-06 > >>>>> > >>>>> > >>>>>See comment below. > >>>>> > >>>>>Regards, > >>>>>Ben > >>>>> > >>>>>John Drake wrote: > >>>>> > >>>>>>Snipped > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM > >>>>>>To: Lou Berger > >>>>>>Cc: Kireeti Kompella; ccamp@ops.ietf.org > >>>>>>Subject: Re: Moving right along ... generalized-signaling-06 > >>>>>> > >>>>>> > >>>>>>>>7) In Protection Information it states "The resources > >>>>>>>> > >>>>>allocated for a > >>>>> > >>>>>>>> secondary LSP MAY be used by other LSPs until the > >>>>>>>> > >>>>>primary LSP fails > >>>>> > >>>>>>>> over to the secondary LSP." This may not always be > >>>>>>>> > >>>>>the case. An > >>>>> > >>>>>>>> explicit flag indicating whether or not extra > >>>>>>>> > >>>>>traffic may use the > >>>>> > >>>>>>>> secondary path resources is needed. > >>>>>>>> > >>>>>>>??? This is the purpose of this bit. > >>>>>>> > >>>>>>This is not clear from the definition. The bit is defined > >>>>>> > >>>>>as indicating > >>>>> > >>>>>>the LSP is a secondary (or protecting) LSP and in 1+1 > >>>>>> > >>>>protection the > >>>> > >>>>>>secondary LSP may not be used for extra traffic. > >>>>>> > >>>>>>Perhaps the problem here is that protection features are > >>>>>> > >>>>>being defined > >>>>> > >>>>>>before the protection framework and requirements are > >>>>>> > >>>>done. Is this > >>>> > >>>>>>presupposing some particular outcome of the recovery work in CAMP? > >>>>>> > >>>>>>JD: I think the definition of the bit is fine. For both > >>>>>> > >>>>>1+1 and 1:1 > >>>>> > >>>>>>protection, there would be a pair of Primary LSPs between > >>>>>> > >>>>the source > >>>> > >>>>>>and destination, rather than a Primary and a Secondary. > >>>>>> > >>>>>This is an unusual use of terms. I have never encountered a case > >>>>>where both the working and recovery paths are call "primary." > >>>>> > >>>>>This is not consistent with either draft-mpls-recovery-framework > >>>>>or with draft-lang-ccamp-recovery. I think this is a sign that the > >>>>>protection work is immature and not ready for progressing to RFC. > >>>>> > >>>>> > >>>>For 1+1 path protection, both working/recovery paths are > >>>>carrying user data > >>>>traffic and it is an endpoint decision as to which path is > >>>>actually the > >>>>working/recovery path. At a transit node, both paths need to > >>>>be treated as > >>>>primary, as the resources are currently being used and > >>>>obviously can't be > >>>>used for Extra Traffic. > >>>> > >>>> > > --------------6BA58095FEA1B65CE1735158 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------6BA58095FEA1B65CE1735158-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 00:42:08 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C20522B.622638F2@lucent.com> Date: Wed, 19 Dec 2001 09:39:07 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Ben Mack-Crane Original-CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------F4686F4EFA632F5479589A26" This is a multi-part message in MIME format. --------------F4686F4EFA632F5479589A26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben, GMPLS is a control plane with the intention to perform a connection management role for the transport plane. Protection is a transport plane build in feature, and it would certainly be wise that GMPLS uses the same terminology as the transport plane. It will definitely reduce the amount of misunderstanding and thus interworking problems. A major difference between protection and restoration is that protection makes use of pre-assigned capacity between nodes, whereas restoration makes use of any capacity available between nodes. I.e. this latter capacity is not typically pre-assigned to a particular connection. Therefore, it is better to have terminology associated with those differences. I.e. for protection "working" and "protection" connections and "normal" and "extra traffic" signals are applicable and should be used. For restoration there is only one connection active at any time, so the working/protection doesn't apply here... I do not have terminology yet, I can only offer some suggestions... Before there is a signal fail condition in the network, all traffic is transported over one connection between ingress and egress points of the network. What is the terminology we use for such connections? E.g. "normal connection" or just "connection"? Some of the unused (G.805) link capacity and fabric capacity may be reserved for rerouting of the normal signals when their transport is interrupted. When a signal fail condition exists, alternate connections or connection segments are to be computed and set up after which the original connection or connection segment is released. At this point there is just one connection present... i.e. the normal connection or just the connection. So we need terminology to identify the alternate connection (segment), which exists as alternate connection (segment) for the period up to the release of the original connection (segment). I.e. it is a temporary indication, and thus more like a state. So perhaps "alternate" and "original" connection (segment) are the appropriate terms to use to indicate the temporary states assigned to existing interrupted connection (segment) and its replacement. Regards, Maarten PS. the term "path" is a reserved term in the transport plane. A "path" is a "trail in a path layer network". Restoration typically implies the replacement of one (serial compound) link connection by another (serial compound) link connection. Restoration doesn't replace trails. Ben Mack-Crane wrote: > > Maarten, > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > because it seemed a more neutral term given that we were including both protection > switching and reroute recovery mechanisms. > > We did not address the state (active/standby). We use the terms "extra traffic" and > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > It would be useful in moving forward in CCAMP if we could try to adopt terms > that are consistent with those in current use elsewhere. > > Regards, > Ben > > Maarten Vissers wrote: > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not primary/secondary. E.g. > > a 1+1 architecture has one working connection, one protection connection and a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > > --------------F4686F4EFA632F5479589A26 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------F4686F4EFA632F5479589A26-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Dec 2001 00:09:25 -0800 Cc: "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Message-ID: <3C204A1B.815B5DF2@lucent.com> Date: Wed, 19 Dec 2001 09:04:43 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'jonathan.sadler@tellabs.com'" , "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Content-Type: multipart/mixed; boundary="------------B7B3EC8D37E3A20AD0A18BEF" This is a multi-part message in MIME format. --------------B7B3EC8D37E3A20AD0A18BEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, It is not the intention to leave the choice of LSP encoding type and SU label structure to the vendor. This would give immediate interworking problems. VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP encoding type "SDH". VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. Looking at the label text in section 3 of the sonet-sdh document, I find it very confusing to read that SONET doesn't use the "U" field. As we indicated before there is no STS type signal that isn't having an SDH equivalent; i.e. there are no specific higher order SONET signals left. It is therefore much better to take out the SONET text for the SU label part altogether. Otherwise we will get a lot of confusion in the marketplace. Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must thus use the "SDH" SU format. ------- All, With the clarification on VT-3 given by Deborah, I would request to consider a further simplification of the GMPLS standard: delete the LSP encoding type "SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there would be no ambiguity left at all. Regards, Maarten "Mannie, Eric" wrote: > > Hi Jonathan, > > > Why SHOULD and not MUST? This ambiguity is likely to create > interoperability problems in the future... > > To leave to the manufacturer and to the user the right to decide if he/she > wants to signal an LSP as either SDH or SONET. There is no interoperability > problem at all since you use EITHER SDH OR SONET. If you decide to request > an SDH signal with what do you want to have interoperability issue at this > stage ? The sentence means indeed "one should better use SDH than SONET" ! > Once you decided, there is no issue. > > > I'm curious what sort of backward compatability is necessary, as a > "standard" doesn't exist currently that this needs to be backward > compatible with... > > Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with > the implementations that could not care of SDH, with implementations that > still do a distinction between SONET and SDH for some reasons, with the > implementations that could still use the VT3 (DS1C) (I don't have > confirmation that nobody is using it today, and this is not the goal of this > draft to state what is obsolete or not in SONET), etc. > > Anyway, there is no issue, the SONET label format is not used until SONET is > explicitly requested as such. This is not a primary feature of the draft, > but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for > everything, consequently you don't care of the SONET label, you skip it in > the draft, you ignore it, you don't implement it and you just use a full SDH > implementation. > > I think that the solution is quite simple: if the SONET signal is indeed an > SDH signal, why do you bother with SONET ? Just ask for an SDH signal, > that's all. > > By the way, since according to some folks SONET is just a subset of SDH, why > do we care about SONET in these documents ? Why don't we simply remove all > references to SONET ? > > Is there somebody on this mailing list that cares about SONET ? If yes, why > ? Who is still manufacturing SONET boxes ? Why is that not called SDH ? > > Kind regards, > > Eric > > -----Original Message----- > From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] > Sent: Tuesday, December 18, 2001 9:57 PM > To: Mannie, Eric > Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; > dbrungard@att.com; lberger@movaz.com > Subject: Re: GMPLS signaling documents updated per last calls > > Eric - > > Comments inline... > > Jonathan Sadler > > "Mannie, Eric" wrote: > > "A SONET signal which has an identical SDH signal SHOULD be requested > using > > the same traffic parameters as for the equivalent SDH signal, and will > > consequently use the SDH label." > > Why SHOULD and not MUST? This ambiguity is likely to create > interoperability problems in the future... > > > We spend with Maarten a lot of time to write that sentence (not easy to > > write). > > > > Maybe that it should be better written: > > > > "A SONET signal which has an identical SDH signal SHOULD be requested as > an > > SDH signal using the same traffic parameters as for the equivalent SDH > > signal, and will consequently use the SDH label." > > Again, "SHOULD" needs to be replaced with "MUST"... > > > This doesn't mean that the SONET signal format disappear (simply not used > in > > that case), for backward compatibility we need to keep it. > > I'm curious what sort of backward compatability is necessary, as a > "standard" doesn't exist currently that this needs to be backward > compatible with... > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Tuesday, December 18, 2001 7:46 PM > > To: Kireeti Kompella > > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > > bwijnen@lucent.com; sob@harvard.edu > > Subject: Re: GMPLS signaling documents updated per last calls > > > > Kireeti, > > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > > > Deborah Brungard wrote: > > > The VT3 (3M) structure was defined - but no services (mappings) were > ever > > defined for it. So there are no services/equip > > > with it. My take was if in the future it was ever defined (doubtful), we > > would be adding it to g707 also. So then it > > > would just be part of g707 too. > > > > So basically, there are no mappings or equipment functions for this rate, > > and as far as we know no network equipment or networks supporting it. > > Deborah suggests that if we were ever to define such mappings, that this > > would be proposed for addition to G.707 and hence be part of SDH. > > > > I think our agreement had been to use the SDH label for all signals that > > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > > thought > > that this was everything except VT3. Given that VT3 seems not to be a > "real" > > signal at this point and will likely be added to SDH if it ever becomes > > real, does our agreement then become that we use SDH labels for > everything? > > > > Regards, > > Steve > > > > Kireeti Kompella wrote: > > > > > > Hi Deborah, > > > > > > > I previously made the > > > > comments to merge the (1) SDH and SONET values as one value > > > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > > several issues, among them this one. The upshot was that whenever > > > possible, the SDH label should be used, with the encoding type > > > set to SDH (i.e., G.707); however, there are signals that have > > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > > me!), so we will keep SONET labels and encoding types around > > > for that case and for legacy equipment. > > > > > > The revised SONET/SDH document will contain the exact wording. > > > I will also be sending a reply to the ITU communication stating > > > the agreement we came to. > > > > > > Kireeti. --------------B7B3EC8D37E3A20AD0A18BEF Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------B7B3EC8D37E3A20AD0A18BEF-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 18:28:42 -0800 Reply-To: From: "Fong Liaw" To: "Lou Berger" Cc: "manoj juneja" , , , Subject: RE: Fwd: Comments on GMPLS signalling drafts Date: Tue, 18 Dec 2001 18:26:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lou I was not in London, so probably just not being informed. The proposed change does not create interoperability problem since there is only one node that would resolves it, but I have no problem keeping the current text either. The problem seems to be that the same question keeps on coming back and there are situations where a different resolution will result in slightly better call setup. A typical scenario is that a call coming from network to user has gone a long way and usually has priority on getting the resources. The question we are facing here is whether different behavior, if does not create interoperability issue, is allowed. From my read of the draft, it is not ... Again, I have no problem with current text so you don't have to convince me, I thought you agree with manoj's comment and in that case the current text does not reflect it. Regards, -Fong > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Lou Berger > Sent: Tuesday, December 18, 2001 3:22 PM > To: Fong Liaw > Cc: Berger, Lou; manoj juneja; Eric.Mannie@ebone.com; > dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org > Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > Fong, > As you know, we've discussed this many times. The last time it > was discussed in detail (London if memory serves) my memory is that we > decided to keep current working as is because (a) different vendor > approaches can lead to interoperability issues and (b) this is a common > tie-breaker solution. > > Lou > > > At 04:33 PM 12/14/2001, Fong Liaw wrote: > > >Lou > > > >I am happy to see my interest protected, however > >I think manoj is asking to insert the "optimization > >vs. correctness" text into the draft. Right now, > >-07 text says a node with higher node id MUST send > >a PathErr etc. this does not allow for different > >behavior. > > > >I would suggest to change the text slightly as > >following: > > > >"To resolve contention, the node with the higher node > >ID will > > win the contention and it MUST issue a > > ^^^ resolve > >PathErr/NOTIFICATION message > >^^^^^^^PathErr/Path/Notification > > with a "Routing problem/Label allocation failure" > >indication. " > > ^ for the LSP that loses in the > >resolution. > > > >We can also specify the default behavior is that > >"the LSP requested by a higher node id wins the > >resolution." > > > >Regards, > >-Fong > > > > > > > > > > > >7. There is an example scenario for contention > > > resolution in case of bi- > > > > >directional LSPs. It should be mentioned that : > > > > > > > > > >"contention resolution is an optimization, not a > > > correctness issue ... > > > > >and no procedure can provide optimal resolution > > > in all cases. An > > > > >implementor > > > > >may do differently to provide better resolution." > > > > > > > > > >The above quotes are extracted from one of the > > > mails from Fong Liaw. > > > > > > > > > >If this is the case then this should be mentioned > > > in the drafts. > > > > > > > > > > > Read the Acknowledgments section of the draft. (I'm > > > sure Fong will be > > > happy to see you protecting her interests!) > > > > > > >__________________________________________________ > >Do You Yahoo!? > >Check out Yahoo! Shopping and Yahoo! Auctions for all of > >your unique holiday gifts! Buy at > >http://shopping.yahoo.com > >or bid at http://auctions.yahoo.com > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:28 -0800 Message-Id: <4.3.2.7.2.20011218183102.01fc3668@mo-ex1> Date: Tue, 18 Dec 2001 18:39:08 -0500 To: "Markus Jork" From: Lou Berger Subject: Re: Moving right along ... generalized-rsvp-te-05 Cc: "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:39 PM 12/17/2001, Markus Jork wrote: >But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: > > A Generalized Label Request object is set by the ingress node, > transparently passed by transit nodes, and used by the egress node. Markus, You are correct that this text is no longer accurate with respect to the switching type parameter. (It predates the reintroduction of this field.) I'll update the text. Thanks, Lou Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:24 -0800 Message-Id: <4.3.2.7.2.20011218190358.021fe590@mo-ex1> Date: Tue, 18 Dec 2001 19:13:48 -0500 To: "Ben Mack-Crane" From: Lou Berger Subject: Re: GMPLS Issue - Switching Type Cc: "CCAMP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ben, how many times do you want me to restate this? I'm getting the feeling you don't like my response, so you ask the question a different way. See direct responses below: Lou At 11:15 AM 12/18/2001, Ben Mack-Crane wrote: >In a brief discussion at the IETF meeting I was told that >Switching Type really is Multiplexing Type not by me! This was one person's way of trying to explain this to you. The text doesn't use these words. >, that is, HOW the >LSP is to be carried over a link (not what is switched or >how it is switched). > >This raises a set of issues that have not yet been discussed. It was discussed as part of the original documents. It was removed and then reintroduced to match the routing draft. I mentioned this to you at the IETF and in the text below. >The first of these is: What problem is this solving? See text below. Lou >Regards, >Ben Mack-Crane > >The following issue raised 10/29/01 has not been addressed: > > >Switching Type continues to be ill-defined. I have heard that the real > >definition is different from that given in the current drafts. If the > >signaling information is not clearly defined and it's use described, we > >can hardly expect interoperability. > >I can't speak for others. My belief is that there is a very concrete >definition. I thought the text in the draft was clear as well, but let me >try again: > > Switching Type: 8 bits > > Indicates the type of switching that should be performed > on a particular link. This field is needed for links that > advertise more than one type of switching capability. > This field contains one of the values advertised for the > corresponding link in the routing Switching Capability > field as defined in [GMPLS-RTG]. > >In other words, on links where one Switching Capability is advertised >(which will be all the time for most equipment) Switching Type is set to >the same value as advertised in routing. On links where multiple Switching >Capabilities are advertised, Switching Type is set to the value advertised >in Switching Capability that matches the type of switching to be performed. > >[I'll put the revised text in the next rev...] Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:24 -0800 Message-Id: <4.3.2.7.2.20011218181622.01f91de0@mo-ex1> Date: Tue, 18 Dec 2001 18:22:27 -0500 To: "Fong Liaw" From: Lou Berger Subject: Re: Fwd: Comments on GMPLS signalling drafts Cc: "Berger, Lou" , "manoj juneja" ,, , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Fong, As you know, we've discussed this many times. The last time it was discussed in detail (London if memory serves) my memory is that we decided to keep current working as is because (a) different vendor approaches can lead to interoperability issues and (b) this is a common tie-breaker solution. Lou At 04:33 PM 12/14/2001, Fong Liaw wrote: >Lou > >I am happy to see my interest protected, however >I think manoj is asking to insert the "optimization >vs. correctness" text into the draft. Right now, >-07 text says a node with higher node id MUST send >a PathErr etc. this does not allow for different >behavior. > >I would suggest to change the text slightly as >following: > >"To resolve contention, the node with the higher node >ID will > win the contention and it MUST issue a > ^^^ resolve >PathErr/NOTIFICATION message >^^^^^^^PathErr/Path/Notification > with a "Routing problem/Label allocation failure" >indication. " > ^ for the LSP that loses in the >resolution. > >We can also specify the default behavior is that >"the LSP requested by a higher node id wins the >resolution." > >Regards, >-Fong > > > > > > > > >7. There is an example scenario for contention > > resolution in case of bi- > > > >directional LSPs. It should be mentioned that : > > > > > > > >"contention resolution is an optimization, not a > > correctness issue ... > > > >and no procedure can provide optimal resolution > > in all cases. An > > > >implementor > > > >may do differently to provide better resolution." > > > > > > > >The above quotes are extracted from one of the > > mails from Fong Liaw. > > > > > > > >If this is the case then this should be mentioned > > in the drafts. > > > > > > > > Read the Acknowledgments section of the draft. (I'm > > sure Fong will be > > happy to see you protecting her interests!) > > > >__________________________________________________ >Do You Yahoo!? >Check out Yahoo! Shopping and Yahoo! Auctions for all of >your unique holiday gifts! Buy at >http://shopping.yahoo.com >or bid at http://auctions.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:20 -0800 Message-Id: <4.3.2.7.2.20011218191509.021fa590@mo-ex1> Date: Tue, 18 Dec 2001 19:19:00 -0500 To: "Ben Mack-Crane" From: Lou Berger Subject: Re: GMPLS Issue - Notify Message Cc: "CCAMP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ben, To be precise your message said: >Well? Does anyone else have thoughts on this? Your previous mail was a statement and a request for comments. I didn't see much support for this on the list. Please remember the process is about "rough consensus" not individual vetoes. Lou At 11:16 AM 12/18/2001, Ben Mack-Crane wrote: >The following issue raised 10/29/01 has not been addressed: > > > > >7) The Notify message is intended to "enable expedited notification of > > > > failures," but it relies on the IP layer which may be affected > by the > > > > failure that the Notify is reporting. This could defeat the goal > > > > of rapid notification. Without some means of guaranteeing the > Notify > > > > doesn't have to wait for IP routing convergence to be delivered, > > > > it isn't a satisfactory solution. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:12 -0800 Message-Id: <4.3.2.7.2.20011218185818.02219120@mo-ex1> Date: Tue, 18 Dec 2001 19:00:50 -0500 To: "Ben Mack-Crane" From: Lou Berger Subject: Re: GMPLS Issue - Bandwidth Encoding Cc: "CCAMP" ,kireeti@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:59 AM 12/18/2001, Ben Mack-Crane wrote: >The following issue raised 10/29/01 has not been addressed: Ben, Again, this has something that has been discussed many times. My reading is that we have "rough consensus". If you disagree, please take it up with the WG chair. Lou > > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it > > > is useful to define discrete values to identify the bandwidth of the > > > LSP." For SONET/SDH this is unnecessary given the Signal Type is > > > provided. For the other non-packet LSP types (Lambda and Fiber) > > > it is not clear that all the values cited in the example are relevant > > > (for example, a DS0 lambda would seem wasteful...). > > > > > This is confusing, and should be clarified. In fact, a > description of > > > exactly why this field is required is needed. > > > > We've gone over this text multiple times. Do you have any suggested > wording. > > > >I would gladly suggest wording if I understood the use for this. It has >no use >for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for >Lambda >or Fiber. However, several of the examples are not appropriate for this. >Perhaps this should be moved to a technology specific document since it is >not really general anyway. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 16:35:03 -0800 Message-Id: <4.3.2.7.2.20011218185313.021abef8@mo-ex1> Date: Tue, 18 Dec 2001 18:57:24 -0500 To: "Ben Mack-Crane" From: Lou Berger Subject: Re: GMPLS Issue - Ethernet LSP Enc Type Cc: "CCAMP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:55 AM 12/18/2001, Ben Mack-Crane wrote: >The following issue raised 10/29/01 has not been addressed. I disagree. We talked in person on this and I said the same thing on the list. > > >1) There seems to be no difference as far as label allocation > > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > > and Ethernet 802.3 (10). One Encoding type would seem to > > > be sufficient. > > > > I agree, but some feel that this is needed to properly establish LSPs in > > systems what would terminate each type differently. > >I don't recall seeing anything on the list about the reasoning about this. >can someone provide a pointer to where this was described? As I mentioned at the IETF, it was in private discussions. >Since LSP Encoding type is intended to describe the LSP for transit nodes >and G-PID is intended to describe the LSP contents for the purpose of >terminating it at the ends, information relevant only to termination >should be conveyed in G-PID. > >Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" >would make this clearer. The current wording is what was agreed to. Lou Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 15:48:04 -0800 Message-ID: <3C1FD551.D8F23894@lucent.com> Date: Tue, 18 Dec 2001 16:46:25 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com, bwijnen@lucent.com, sob@harvard.edu Subject: Re: GMPLS signaling documents updated per last calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, I understand that it took some effort to come up with the sentence to which everyone agreed. The new information since SLC is, however, that the VT3 SONET format, which we thought was the only unique format to SONET, seems to have no mappings and is not used. With this new information, would it be better to have a different sentence? Certainly there is nothing incorrect the way it is written, but it may be more helpful to readers to know to just use the SDH labels. Regards, Steve "Mannie, Eric" wrote: > > Hi Stephen, > > The current wording is (as it is written in the updated draft that I sent > last week on the ccamp mailing list): > > "A SONET signal which has an identical SDH signal SHOULD be requested using > the same traffic parameters as for the equivalent SDH signal, and will > consequently use the SDH label." > > We spend with Maarten a lot of time to write that sentence (not easy to > write). > > Maybe that it should be better written: > > "A SONET signal which has an identical SDH signal SHOULD be requested as an > SDH signal using the same traffic parameters as for the equivalent SDH > signal, and will consequently use the SDH label." > > This means in practice: request an SDH signal when identical to a SONET > signal. In that case, from the control plane point of view everything is > SDH, i.e. the control plane is not aware of SONET at all. Of course, if an > SDH signal is requested the SDH label is used. The distinction between SDH > and SONET in that case being only at the connection monitoring level if I am > right (please confirm). > > This doesn't mean that the SONET signal format disappear (simply not used in > that case), for backward compatibility we need to keep it. > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:46 PM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > bwijnen@lucent.com; sob@harvard.edu > Subject: Re: GMPLS signaling documents updated per last calls > > Kireeti, > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > Deborah Brungard wrote: > > The VT3 (3M) structure was defined - but no services (mappings) were ever > defined for it. So there are no services/equip > > with it. My take was if in the future it was ever defined (doubtful), we > would be adding it to g707 also. So then it > > would just be part of g707 too. > > So basically, there are no mappings or equipment functions for this rate, > and as far as we know no network equipment or networks supporting it. > Deborah suggests that if we were ever to define such mappings, that this > would be proposed for addition to G.707 and hence be part of SDH. > > I think our agreement had been to use the SDH label for all signals that > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > thought > that this was everything except VT3. Given that VT3 seems not to be a "real" > signal at this point and will likely be added to SDH if it ever becomes > real, does our agreement then become that we use SDH labels for everything? > > Regards, > Steve > > Kireeti Kompella wrote: > > > > Hi Deborah, > > > > > I previously made the > > > comments to merge the (1) SDH and SONET values as one value > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > several issues, among them this one. The upshot was that whenever > > possible, the SDH label should be used, with the encoding type > > set to SDH (i.e., G.707); however, there are signals that have > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > me!), so we will keep SONET labels and encoding types around > > for that case and for legacy equipment. > > > > The revised SONET/SDH document will contain the exact wording. > > I will also be sending a reply to the ITU communication stating > > the agreement we came to. > > > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 14:02:06 -0800 Message-ID: From: John Drake To: 'Stephen Trowbridge' Cc: Maarten Vissers , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Tue, 18 Dec 2001 13:56:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Stephen, You're absolutely right if you want to use K1/K2 to signal the switchover from working to protect. We were planning to use the control plane signalling protocols, since we have to deal with more than just SONET/SDH. See for example: http://search.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-01.t xt http://search.ietf.org/internet-drafts/draft-bala-protection-restoration-sig naling-00.txt Thanks, John -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Tuesday, December 18, 2001 10:38 AM To: John Drake Cc: Maarten Vissers; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 John, The problem here is that this is not compatible with transport plane protection. Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation of the protection group is controlled by exchange of the K1, K2 bytes in the MSOH of the PROTECTION MS. If the control plane reuses the protection MS at for a different LSP at a time when the state of the protection group is "No Request" (assuming no extra traffic carried on the protection section in the transport plane), this disables the protection since the endpoints of the protection group are no longer able to exchange K1, K2 over the protection channel. Even though the payload is unused and irrelevant to the transport plane at this point, the exchange of overhead is essential to proper operation of the protection group. Regards, Steve John Drake wrote: > > Steven, > > The basic idea is that if a connection is of type 'secondary', then other > LSPs of type 'primary' between the same or different source/destination > pairs MAY use its resources in intermediate nodes, until that LSP is > converted into a 'primary' with a subsequent Path/Resv flow. At this point, > other LSPs that were using its resources may get pre-empted. Think of the > primary/secondary mechanism as a way to ensure temporal priority while > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > is carrying no data. > > So in the 1:1 case the protect LSP could be established either as a primary > or secondary LSP, while in the 1:N case the protect LSP would be established > as a secondary. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, December 13, 2001 12:15 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > It would seem from this standpoint, ANY transport plane protection > must use "primary" for all trails. You have already made this argument > for the 1+1 case to carry the permanently bridged copy of the payload. > > In 1:1 or 1:n, when protection is not being used to carry one/any of > the normal traffic signals, it may either carry a null signal (no bridge) > or transport plane extra traffic. Even if the transport plane has only > a null signal on protection, the control plane cannot itself place extra > traffic on any portion of the end-to-end protection channel as this is > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > The protection channel overhead is chosen to carry the APS since it is > necessary to exchange APS bytes to complete a switch when working channels > are failed. If the protection channel has failed and APS cannot be > exchanged, > normal traffic signals will not be selected from protection. > Regards, > Steve > > John Drake wrote: > > > > Maarten, > > > > That's fine, however it's beside the point. The semantics of > > Primary/Secondary refer to the control plane and whether the node > > establishing a given LSP is planning to use it at the time it's > established > > or at a later time. As I indicated in an earlier note, 1+1 transport > plane > > protection would be accomplished in the control plane by establishing two > > LSPs of type Primary. The control plane really doesn't care which LSP the > > transport plane is using as Working and which as Protect, although that > > information is available to the control plane at the LSP endpoints. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 AM > > To: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not > primary/secondary. > > E.g. > > a 1+1 architecture has one working connection, one protection connection > and > > a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the > > working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 13:48:30 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' , John Drake Cc: Maarten Vissers , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Tue, 18 Dec 2001 22:40:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Stephen, John refers to fast restoration schemes that are being studied at the IETF. Such schemes are widely implemented in the new classes of optical/TDM equipments. The wording of the text just need to use the terms "working" LSP and "protecting" LSP, instead of primary and secondary. That's just an editing modification. The bit itself is useful to qualify the LSP being established. The mechanisms to be applied to this qualification will be detailed in other documents. In the mean time, I guess that this bit can be used by implementations for a simple restoration scheme (e.g. first establish working and protecting LSPs, resources of protecting LSP may be "soft reserved", i.e. for extra-traffic, when a fault occur send an RSVP-TE rapid failure notification to the source, send Path with bit set to "working" on protecting LSP, this kills all LSPs using these resources, when acked switch to this LSP). Kind regards, Eric -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Tuesday, December 18, 2001 7:38 PM To: John Drake Cc: Maarten Vissers; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 John, The problem here is that this is not compatible with transport plane protection. Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation of the protection group is controlled by exchange of the K1, K2 bytes in the MSOH of the PROTECTION MS. If the control plane reuses the protection MS at for a different LSP at a time when the state of the protection group is "No Request" (assuming no extra traffic carried on the protection section in the transport plane), this disables the protection since the endpoints of the protection group are no longer able to exchange K1, K2 over the protection channel. Even though the payload is unused and irrelevant to the transport plane at this point, the exchange of overhead is essential to proper operation of the protection group. Regards, Steve John Drake wrote: > > Steven, > > The basic idea is that if a connection is of type 'secondary', then other > LSPs of type 'primary' between the same or different source/destination > pairs MAY use its resources in intermediate nodes, until that LSP is > converted into a 'primary' with a subsequent Path/Resv flow. At this point, > other LSPs that were using its resources may get pre-empted. Think of the > primary/secondary mechanism as a way to ensure temporal priority while > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > is carrying no data. > > So in the 1:1 case the protect LSP could be established either as a primary > or secondary LSP, while in the 1:N case the protect LSP would be established > as a secondary. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, December 13, 2001 12:15 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > It would seem from this standpoint, ANY transport plane protection > must use "primary" for all trails. You have already made this argument > for the 1+1 case to carry the permanently bridged copy of the payload. > > In 1:1 or 1:n, when protection is not being used to carry one/any of > the normal traffic signals, it may either carry a null signal (no bridge) > or transport plane extra traffic. Even if the transport plane has only > a null signal on protection, the control plane cannot itself place extra > traffic on any portion of the end-to-end protection channel as this is > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > The protection channel overhead is chosen to carry the APS since it is > necessary to exchange APS bytes to complete a switch when working channels > are failed. If the protection channel has failed and APS cannot be > exchanged, > normal traffic signals will not be selected from protection. > Regards, > Steve > > John Drake wrote: > > > > Maarten, > > > > That's fine, however it's beside the point. The semantics of > > Primary/Secondary refer to the control plane and whether the node > > establishing a given LSP is planning to use it at the time it's > established > > or at a later time. As I indicated in an earlier note, 1+1 transport > plane > > protection would be accomplished in the control plane by establishing two > > LSPs of type Primary. The control plane really doesn't care which LSP the > > transport plane is using as Working and which as Protect, although that > > information is available to the control plane at the LSP endpoints. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 AM > > To: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not > primary/secondary. > > E.g. > > a 1+1 architecture has one working connection, one protection connection > and > > a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the > > working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 13:43:48 -0800 Message-ID: From: "Mannie, Eric" To: "'jonathan.sadler@tellabs.com'" Cc: 'Stephen Trowbridge' , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: RE: GMPLS signaling documents updated per last calls Date: Tue, 18 Dec 2001 22:39:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Jonathan, > Why SHOULD and not MUST? This ambiguity is likely to create interoperability problems in the future... To leave to the manufacturer and to the user the right to decide if he/she wants to signal an LSP as either SDH or SONET. There is no interoperability problem at all since you use EITHER SDH OR SONET. If you decide to request an SDH signal with what do you want to have interoperability issue at this stage ? The sentence means indeed "one should better use SDH than SONET" ! Once you decided, there is no issue. > I'm curious what sort of backward compatability is necessary, as a "standard" doesn't exist currently that this needs to be backward compatible with... Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with the implementations that could not care of SDH, with implementations that still do a distinction between SONET and SDH for some reasons, with the implementations that could still use the VT3 (DS1C) (I don't have confirmation that nobody is using it today, and this is not the goal of this draft to state what is obsolete or not in SONET), etc. Anyway, there is no issue, the SONET label format is not used until SONET is explicitly requested as such. This is not a primary feature of the draft, but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for everything, consequently you don't care of the SONET label, you skip it in the draft, you ignore it, you don't implement it and you just use a full SDH implementation. I think that the solution is quite simple: if the SONET signal is indeed an SDH signal, why do you bother with SONET ? Just ask for an SDH signal, that's all. By the way, since according to some folks SONET is just a subset of SDH, why do we care about SONET in these documents ? Why don't we simply remove all references to SONET ? Is there somebody on this mailing list that cares about SONET ? If yes, why ? Who is still manufacturing SONET boxes ? Why is that not called SDH ? Kind regards, Eric -----Original Message----- From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] Sent: Tuesday, December 18, 2001 9:57 PM To: Mannie, Eric Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Eric - Comments inline... Jonathan Sadler "Mannie, Eric" wrote: > "A SONET signal which has an identical SDH signal SHOULD be requested using > the same traffic parameters as for the equivalent SDH signal, and will > consequently use the SDH label." Why SHOULD and not MUST? This ambiguity is likely to create interoperability problems in the future... > We spend with Maarten a lot of time to write that sentence (not easy to > write). > > Maybe that it should be better written: > > "A SONET signal which has an identical SDH signal SHOULD be requested as an > SDH signal using the same traffic parameters as for the equivalent SDH > signal, and will consequently use the SDH label." Again, "SHOULD" needs to be replaced with "MUST"... > This doesn't mean that the SONET signal format disappear (simply not used in > that case), for backward compatibility we need to keep it. I'm curious what sort of backward compatability is necessary, as a "standard" doesn't exist currently that this needs to be backward compatible with... > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:46 PM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > bwijnen@lucent.com; sob@harvard.edu > Subject: Re: GMPLS signaling documents updated per last calls > > Kireeti, > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > Deborah Brungard wrote: > > The VT3 (3M) structure was defined - but no services (mappings) were ever > defined for it. So there are no services/equip > > with it. My take was if in the future it was ever defined (doubtful), we > would be adding it to g707 also. So then it > > would just be part of g707 too. > > So basically, there are no mappings or equipment functions for this rate, > and as far as we know no network equipment or networks supporting it. > Deborah suggests that if we were ever to define such mappings, that this > would be proposed for addition to G.707 and hence be part of SDH. > > I think our agreement had been to use the SDH label for all signals that > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > thought > that this was everything except VT3. Given that VT3 seems not to be a "real" > signal at this point and will likely be added to SDH if it ever becomes > real, does our agreement then become that we use SDH labels for everything? > > Regards, > Steve > > Kireeti Kompella wrote: > > > > Hi Deborah, > > > > > I previously made the > > > comments to merge the (1) SDH and SONET values as one value > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > several issues, among them this one. The upshot was that whenever > > possible, the SDH label should be used, with the encoding type > > set to SDH (i.e., G.707); however, there are signals that have > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > me!), so we will keep SONET labels and encoding types around > > for that case and for legacy equipment. > > > > The revised SONET/SDH document will contain the exact wording. > > I will also be sending a reply to the ITU communication stating > > the agreement we came to. > > > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 13:03:04 -0800 Message-ID: <3C1FAD9F.28F9705C@tellabs.com> Date: Tue, 18 Dec 2001 14:57:03 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: Re: GMPLS signaling documents updated per last calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric - Comments inline... Jonathan Sadler "Mannie, Eric" wrote: > "A SONET signal which has an identical SDH signal SHOULD be requested using > the same traffic parameters as for the equivalent SDH signal, and will > consequently use the SDH label." Why SHOULD and not MUST? This ambiguity is likely to create interoperability problems in the future... > We spend with Maarten a lot of time to write that sentence (not easy to > write). > > Maybe that it should be better written: > > "A SONET signal which has an identical SDH signal SHOULD be requested as an > SDH signal using the same traffic parameters as for the equivalent SDH > signal, and will consequently use the SDH label." Again, "SHOULD" needs to be replaced with "MUST"... > This doesn't mean that the SONET signal format disappear (simply not used in > that case), for backward compatibility we need to keep it. I'm curious what sort of backward compatability is necessary, as a "standard" doesn't exist currently that this needs to be backward compatible with... > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Tuesday, December 18, 2001 7:46 PM > To: Kireeti Kompella > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; > bwijnen@lucent.com; sob@harvard.edu > Subject: Re: GMPLS signaling documents updated per last calls > > Kireeti, > The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular > rate in both SONET and SDH. I exchanged an email with Deborah Brungard > (T1X1.5 chair) on this one and I take the liberty of sharing her response: > > Deborah Brungard wrote: > > The VT3 (3M) structure was defined - but no services (mappings) were ever > defined for it. So there are no services/equip > > with it. My take was if in the future it was ever defined (doubtful), we > would be adding it to g707 also. So then it > > would just be part of g707 too. > > So basically, there are no mappings or equipment functions for this rate, > and as far as we know no network equipment or networks supporting it. > Deborah suggests that if we were ever to define such mappings, that this > would be proposed for addition to G.707 and hence be part of SDH. > > I think our agreement had been to use the SDH label for all signals that > had the same multiplex structure in SONET and SDH. In Salt Lake City, we > thought > that this was everything except VT3. Given that VT3 seems not to be a "real" > signal at this point and will likely be added to SDH if it ever becomes > real, does our agreement then become that we use SDH labels for everything? > > Regards, > Steve > > Kireeti Kompella wrote: > > > > Hi Deborah, > > > > > I previously made the > > > comments to merge the (1) SDH and SONET values as one value > > > > There was a meeting among Steve Trowbridge, Maarten Vissers, > > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > > several issues, among them this one. The upshot was that whenever > > possible, the SDH label should be used, with the encoding type > > set to SDH (i.e., G.707); however, there are signals that have > > no SDH equivalent (if I remember right, VC-3 -- someone correct > > me!), so we will keep SONET labels and encoding types around > > for that case and for legacy equipment. > > > > The revised SONET/SDH document will contain the exact wording. > > I will also be sending a reply to the ITU communication stating > > the agreement we came to. > > > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 12:24:21 -0800 Message-Id: <200112182023.fBIKNcj10169@mailhost.avici.com> From: Markus Jork To: John Drake cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Dec 2001 15:23:37 -0500 > Markus, > > The router would specify LSC in the generalized label request. The > Router/OXC links are PSC at the router end and LSC at the OXC end. > > Thanks, > > John Good, this is what I expected. But as I said the spec seems to be in conflict with this interpretation. How about we change the sentence: Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. to: Transit nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. I guess egress nodes could check that the Switching Type parameter is supported on the far end of the incoming link. Thanks, Markus > -----Original Message----- > From: Markus Jork [mailto:mjork@avici.com] > Sent: Monday, December 17, 2001 1:39 PM > To: Lou Berger > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-rsvp-te-05 > > > Lou, > > I think there is still some confusion in the draft regarding > the switching type. Of course it could also be that the draft > is perfectly clear and I'm confused... > > Quoting a response you gave to Manoj/Ben: > > > > > > > > > >A Tunnel (FA) is a type > > > > > of link, not a class of switching. This adds to the > > > > > confusion I've noted about the need for and use of Switching > > > > > Type. > > > > > >Switching Type continues to be ill-defined. I have heard that the real > > >definition is different from that given in the current drafts. If the > > >signaling information is not clearly defined and it's use described, we > > >can hardly expect interoperability. > > > > I can't speak for others. My belief is that there is a very concrete > > definition. I thought the text in the draft was clear as well, but let > me > > try again: > > > > > > Switching Type: 8 bits > > > > Indicates the type of switching that should be performed > > on a particular link. This field is needed for links that > > advertise more than one type of switching capability. > > This field contains one of the values advertised for the > > corresponding link in the routing Switching Capability > > field as defined in [GMPLS-RTG]. > > > > In other words, on links where one Switching Capability is advertised > > (which will be all the time for most equipment) Switching Type is set to > > the same value as advertised in routing. On links where multiple > Switching > > Capabilities are advertised, Switching Type is set to the value advertised > > > in Switching Capability that matches the type of switching to be > performed. > > > > [I'll put the revised text in the next rev...] > > > > Let's look at the example of two IP routers connected to a cloud of > opaque OXCs: > > R1 ----- OXC1 ----- OXC2 ----- R2 > LSC LSC PSC > > OXC1 and OXC2 switch the Sonet stream from an incoming interface to > some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 > are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks > at the incoming IP packets. The encoding on the links is OC192. > > Now I want to setup an LSP between R1 and R2. (This LSP is essentially > a "lightpath" through the optical cloud and will be advertised as FA > so that PSC LSPs can be tunneled through it later.) > What is the switching type requested in the Generalized Label Request > object? I would expect LSC. > But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: > > A Generalized Label Request object is set by the ingress node, > transparently passed by transit nodes, and used by the egress node. > > This would suggest the switching type needs to be PSC. > But then the text in 2.1.1 says: > > Nodes MUST verify that the type indicated in the Switching Type > parameter is supported on the corresponding incoming interface. If > the type cannot be supported, the node MUST generate a PathErr > message with a "Routing problem/Switching Type" indication. > > So when the Path message requested PSC, it would be rejected by OXC1 > and OXC2. When it requested LSC it would be rejected by R2. > The transit nodes can't modify the switching type in the Path message > because they don't have enough knowledge to pick the right one. > How is this supposed to work? > > thanks for any clarification, > Markus > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 12:20:49 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' , Kireeti Kompella Cc: ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com, bwijnen@lucent.com, sob@harvard.edu Subject: RE: GMPLS signaling documents updated per last calls Date: Tue, 18 Dec 2001 21:16:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Stephen, The current wording is (as it is written in the updated draft that I sent last week on the ccamp mailing list): "A SONET signal which has an identical SDH signal SHOULD be requested using the same traffic parameters as for the equivalent SDH signal, and will consequently use the SDH label." We spend with Maarten a lot of time to write that sentence (not easy to write). Maybe that it should be better written: "A SONET signal which has an identical SDH signal SHOULD be requested as an SDH signal using the same traffic parameters as for the equivalent SDH signal, and will consequently use the SDH label." This means in practice: request an SDH signal when identical to a SONET signal. In that case, from the control plane point of view everything is SDH, i.e. the control plane is not aware of SONET at all. Of course, if an SDH signal is requested the SDH label is used. The distinction between SDH and SONET in that case being only at the connection monitoring level if I am right (please confirm). This doesn't mean that the SONET signal format disappear (simply not used in that case), for backward compatibility we need to keep it. Kind regards, Eric -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Tuesday, December 18, 2001 7:46 PM To: Kireeti Kompella Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com; bwijnen@lucent.com; sob@harvard.edu Subject: Re: GMPLS signaling documents updated per last calls Kireeti, The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular rate in both SONET and SDH. I exchanged an email with Deborah Brungard (T1X1.5 chair) on this one and I take the liberty of sharing her response: Deborah Brungard wrote: > The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip > with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it > would just be part of g707 too. So basically, there are no mappings or equipment functions for this rate, and as far as we know no network equipment or networks supporting it. Deborah suggests that if we were ever to define such mappings, that this would be proposed for addition to G.707 and hence be part of SDH. I think our agreement had been to use the SDH label for all signals that had the same multiplex structure in SONET and SDH. In Salt Lake City, we thought that this was everything except VT3. Given that VT3 seems not to be a "real" signal at this point and will likely be added to SDH if it ever becomes real, does our agreement then become that we use SDH labels for everything? Regards, Steve Kireeti Kompella wrote: > > Hi Deborah, > > > I previously made the > > comments to merge the (1) SDH and SONET values as one value > > There was a meeting among Steve Trowbridge, Maarten Vissers, > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > several issues, among them this one. The upshot was that whenever > possible, the SDH label should be used, with the encoding type > set to SDH (i.e., G.707); however, there are signals that have > no SDH equivalent (if I remember right, VC-3 -- someone correct > me!), so we will keep SONET labels and encoding types around > for that case and for legacy equipment. > > The revised SONET/SDH document will contain the exact wording. > I will also be sending a reply to the ITU communication stating > the agreement we came to. > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 11:04:30 -0800 Message-ID: <3C1F914B.D0D4192B@lucent.com> Date: Tue, 18 Dec 2001 11:56:11 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Zhi-Wei Lin CC: Ben Mack-Crane , Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi, We have been trying to work some consistency into this terminology over time. Working and Protection are terms that we are trying to use only between the ends of the protected domain. Normal traffic is the traffic that is carried over Working (sections, trails, whatever) in the absence of a failure or other switch cause. Extra traffic may be carried over Protection (sections, trails, ...) when they are not needed to carry Normal traffic. Active and Standby have normally been used with respect to 1+1 arrangements, although could make sense to use these terms in 1:n without extra traffic as well. An active (trail, section,...) is the one from which a normal traffic signal is currently selected, where a standby (trail, section) is one from which normal traffic is not currently selected. I am not entirely happy with use of the word "standby" to describe something that is currently carrying extra traffic. Regards, Steve Zhi-Wei Lin wrote: > > Hi, > > I think active/standby and extra-traffic/normal-traffic are also two > separate descriptors. Extra traffic may be carried on a standby > connection (but a standby connection does not necessarily have extra > traffic on it). > > How do we define normal traffic? Is this user traffic carried by working > path (when working is active), or also carried by recovery path (when > recovery is active)? > > And once you defined these, I think you still may need to specify > whether a connection is revertive or non-revertive. > > For example, take the case of 1+1. One operator may decide to use > non-revertive (because both paths are "equivalent") so avoid a switching > hit on the traffic (order of milliseconds?), while another operator may > decide to use revertive (because the recovery path is much longer/more > hops). Could these decisions be made per protected LSP basis? If yes, > then would tail-end need to know which mode it is operating/to use (the > intermediate nodes don't need to know this)? > > Zhi > > Ben Mack-Crane wrote: > > > Maarten, > > > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > > because it seemed a more neutral term given that we were including both protection > > switching and reroute recovery mechanisms. > > > > We did not address the state (active/standby). We use the terms "extra traffic" and > > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > > > It would be useful in moving forward in CCAMP if we could try to adopt terms > > that are consistent with those in current use elsewhere. > > > > Regards, > > Ben > > > > Maarten Vissers wrote: > > > >>There exist well defined protection terminology in ITU-T for the transport > >>plane. "Working" and "Protection" are being used and not primary/secondary. E.g. > >>a 1+1 architecture has one working connection, one protection connection and a > >>permanent bridge. > >> > >>Besides working/protection indication for the transport entity, there is > >>- "active" and "standby" to indicate if the signal is selected from the working > >>or protection transport entity; i.e. if selector selects from working, the > >>working is active and protection is standby, if the selector selects from > >>protection the working is standby and the protection is active. > >>- "normal" and "extra traffic" signal. The normal signal is protected. > >> > >>Regards, > >> > >>Maarten > >> > >>neil.2.harrison@bt.com wrote: > >> > >>>Jonathan....review the text below....I think the problem is 1:1. > >>> > >>>neil > >>> > >>> > >>>>-----Original Message----- > >>>>From: Jonathan Lang [mailto:jplang@calient.net] > >>>>Sent: 12 December 2001 17:46 > >>>>To: 'Ben Mack-Crane'; John Drake > >>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > >>>>Subject: RE: Moving right along ... generalized-signaling-06 > >>>> > >>>> > >>>>Ben, > >>>> Please see inline. > >>>> > >>>>Thanks, > >>>>Jonathan > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > >>>>>Sent: Wednesday, December 12, 2001 8:56 AM > >>>>>To: John Drake > >>>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > >>>>>Subject: Re: Moving right along ... generalized-signaling-06 > >>>>> > >>>>> > >>>>>See comment below. > >>>>> > >>>>>Regards, > >>>>>Ben > >>>>> > >>>>>John Drake wrote: > >>>>> > >>>>>>Snipped > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM > >>>>>>To: Lou Berger > >>>>>>Cc: Kireeti Kompella; ccamp@ops.ietf.org > >>>>>>Subject: Re: Moving right along ... generalized-signaling-06 > >>>>>> > >>>>>> > >>>>>>>>7) In Protection Information it states "The resources > >>>>>>>> > >>>>>allocated for a > >>>>> > >>>>>>>> secondary LSP MAY be used by other LSPs until the > >>>>>>>> > >>>>>primary LSP fails > >>>>> > >>>>>>>> over to the secondary LSP." This may not always be > >>>>>>>> > >>>>>the case. An > >>>>> > >>>>>>>> explicit flag indicating whether or not extra > >>>>>>>> > >>>>>traffic may use the > >>>>> > >>>>>>>> secondary path resources is needed. > >>>>>>>> > >>>>>>>??? This is the purpose of this bit. > >>>>>>> > >>>>>>This is not clear from the definition. The bit is defined > >>>>>> > >>>>>as indicating > >>>>> > >>>>>>the LSP is a secondary (or protecting) LSP and in 1+1 > >>>>>> > >>>>protection the > >>>> > >>>>>>secondary LSP may not be used for extra traffic. > >>>>>> > >>>>>>Perhaps the problem here is that protection features are > >>>>>> > >>>>>being defined > >>>>> > >>>>>>before the protection framework and requirements are > >>>>>> > >>>>done. Is this > >>>> > >>>>>>presupposing some particular outcome of the recovery work in CAMP? > >>>>>> > >>>>>>JD: I think the definition of the bit is fine. For both > >>>>>> > >>>>>1+1 and 1:1 > >>>>> > >>>>>>protection, there would be a pair of Primary LSPs between > >>>>>> > >>>>the source > >>>> > >>>>>>and destination, rather than a Primary and a Secondary. > >>>>>> > >>>>>This is an unusual use of terms. I have never encountered a case > >>>>>where both the working and recovery paths are call "primary." > >>>>> > >>>>>This is not consistent with either draft-mpls-recovery-framework > >>>>>or with draft-lang-ccamp-recovery. I think this is a sign that the > >>>>>protection work is immature and not ready for progressing to RFC. > >>>>> > >>>>> > >>>>For 1+1 path protection, both working/recovery paths are > >>>>carrying user data > >>>>traffic and it is an endpoint decision as to which path is > >>>>actually the > >>>>working/recovery path. At a transit node, both paths need to > >>>>be treated as > >>>>primary, as the resources are currently being used and > >>>>obviously can't be > >>>>used for Extra Traffic. > >>>> > >>>> > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 10:55:01 -0800 Message-ID: <3C1F8EEF.839DEE8A@lucent.com> Date: Tue, 18 Dec 2001 11:46:07 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com, bwijnen@lucent.com, sob@harvard.edu Subject: Re: GMPLS signaling documents updated per last calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular rate in both SONET and SDH. I exchanged an email with Deborah Brungard (T1X1.5 chair) on this one and I take the liberty of sharing her response: Deborah Brungard wrote: > The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip > with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it > would just be part of g707 too. So basically, there are no mappings or equipment functions for this rate, and as far as we know no network equipment or networks supporting it. Deborah suggests that if we were ever to define such mappings, that this would be proposed for addition to G.707 and hence be part of SDH. I think our agreement had been to use the SDH label for all signals that had the same multiplex structure in SONET and SDH. In Salt Lake City, we thought that this was everything except VT3. Given that VT3 seems not to be a "real" signal at this point and will likely be added to SDH if it ever becomes real, does our agreement then become that we use SDH labels for everything? Regards, Steve Kireeti Kompella wrote: > > Hi Deborah, > > > I previously made the > > comments to merge the (1) SDH and SONET values as one value > > There was a meeting among Steve Trowbridge, Maarten Vissers, > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on > several issues, among them this one. The upshot was that whenever > possible, the SDH label should be used, with the encoding type > set to SDH (i.e., G.707); however, there are signals that have > no SDH equivalent (if I remember right, VC-3 -- someone correct > me!), so we will keep SONET labels and encoding types around > for that case and for legacy equipment. > > The revised SONET/SDH document will contain the exact wording. > I will also be sending a reply to the ITU communication stating > the agreement we came to. > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 10:48:47 -0800 Message-ID: <3C1F8D0A.76A451DB@lucent.com> Date: Tue, 18 Dec 2001 11:38:02 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, The problem here is that this is not compatible with transport plane protection. Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation of the protection group is controlled by exchange of the K1, K2 bytes in the MSOH of the PROTECTION MS. If the control plane reuses the protection MS at for a different LSP at a time when the state of the protection group is "No Request" (assuming no extra traffic carried on the protection section in the transport plane), this disables the protection since the endpoints of the protection group are no longer able to exchange K1, K2 over the protection channel. Even though the payload is unused and irrelevant to the transport plane at this point, the exchange of overhead is essential to proper operation of the protection group. Regards, Steve John Drake wrote: > > Steven, > > The basic idea is that if a connection is of type 'secondary', then other > LSPs of type 'primary' between the same or different source/destination > pairs MAY use its resources in intermediate nodes, until that LSP is > converted into a 'primary' with a subsequent Path/Resv flow. At this point, > other LSPs that were using its resources may get pre-empted. Think of the > primary/secondary mechanism as a way to ensure temporal priority while > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > is carrying no data. > > So in the 1:1 case the protect LSP could be established either as a primary > or secondary LSP, while in the 1:N case the protect LSP would be established > as a secondary. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, December 13, 2001 12:15 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > It would seem from this standpoint, ANY transport plane protection > must use "primary" for all trails. You have already made this argument > for the 1+1 case to carry the permanently bridged copy of the payload. > > In 1:1 or 1:n, when protection is not being used to carry one/any of > the normal traffic signals, it may either carry a null signal (no bridge) > or transport plane extra traffic. Even if the transport plane has only > a null signal on protection, the control plane cannot itself place extra > traffic on any portion of the end-to-end protection channel as this is > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > The protection channel overhead is chosen to carry the APS since it is > necessary to exchange APS bytes to complete a switch when working channels > are failed. If the protection channel has failed and APS cannot be > exchanged, > normal traffic signals will not be selected from protection. > Regards, > Steve > > John Drake wrote: > > > > Maarten, > > > > That's fine, however it's beside the point. The semantics of > > Primary/Secondary refer to the control plane and whether the node > > establishing a given LSP is planning to use it at the time it's > established > > or at a later time. As I indicated in an earlier note, 1+1 transport > plane > > protection would be accomplished in the control plane by establishing two > > LSPs of type Primary. The control plane really doesn't care which LSP the > > transport plane is using as Working and which as Protect, although that > > information is available to the control plane at the LSP endpoints. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 AM > > To: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not > primary/secondary. > > E.g. > > a 1+1 architecture has one working connection, one protection connection > and > > a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the > > working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 10:40:30 -0800 Message-ID: <3C1F8C4D.7070404@lucent.com> Date: Tue, 18 Dec 2001 13:34:53 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Ben Mack-Crane CC: Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I think active/standby and extra-traffic/normal-traffic are also two separate descriptors. Extra traffic may be carried on a standby connection (but a standby connection does not necessarily have extra traffic on it). How do we define normal traffic? Is this user traffic carried by working path (when working is active), or also carried by recovery path (when recovery is active)? And once you defined these, I think you still may need to specify whether a connection is revertive or non-revertive. For example, take the case of 1+1. One operator may decide to use non-revertive (because both paths are "equivalent") so avoid a switching hit on the traffic (order of milliseconds?), while another operator may decide to use revertive (because the recovery path is much longer/more hops). Could these decisions be made per protected LSP basis? If yes, then would tail-end need to know which mode it is operating/to use (the intermediate nodes don't need to know this)? Zhi Ben Mack-Crane wrote: > Maarten, > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > because it seemed a more neutral term given that we were including both protection > switching and reroute recovery mechanisms. > > We did not address the state (active/standby). We use the terms "extra traffic" and > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > It would be useful in moving forward in CCAMP if we could try to adopt terms > that are consistent with those in current use elsewhere. > > Regards, > Ben > > Maarten Vissers wrote: > >>There exist well defined protection terminology in ITU-T for the transport >>plane. "Working" and "Protection" are being used and not primary/secondary. E.g. >>a 1+1 architecture has one working connection, one protection connection and a >>permanent bridge. >> >>Besides working/protection indication for the transport entity, there is >>- "active" and "standby" to indicate if the signal is selected from the working >>or protection transport entity; i.e. if selector selects from working, the >>working is active and protection is standby, if the selector selects from >>protection the working is standby and the protection is active. >>- "normal" and "extra traffic" signal. The normal signal is protected. >> >>Regards, >> >>Maarten >> >>neil.2.harrison@bt.com wrote: >> >>>Jonathan....review the text below....I think the problem is 1:1. >>> >>>neil >>> >>> >>>>-----Original Message----- >>>>From: Jonathan Lang [mailto:jplang@calient.net] >>>>Sent: 12 December 2001 17:46 >>>>To: 'Ben Mack-Crane'; John Drake >>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org >>>>Subject: RE: Moving right along ... generalized-signaling-06 >>>> >>>> >>>>Ben, >>>> Please see inline. >>>> >>>>Thanks, >>>>Jonathan >>>> >>>> >>>>>-----Original Message----- >>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>>>>Sent: Wednesday, December 12, 2001 8:56 AM >>>>>To: John Drake >>>>>Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org >>>>>Subject: Re: Moving right along ... generalized-signaling-06 >>>>> >>>>> >>>>>See comment below. >>>>> >>>>>Regards, >>>>>Ben >>>>> >>>>>John Drake wrote: >>>>> >>>>>>Snipped >>>>>> >>>>>>-----Original Message----- >>>>>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM >>>>>>To: Lou Berger >>>>>>Cc: Kireeti Kompella; ccamp@ops.ietf.org >>>>>>Subject: Re: Moving right along ... generalized-signaling-06 >>>>>> >>>>>> >>>>>>>>7) In Protection Information it states "The resources >>>>>>>> >>>>>allocated for a >>>>> >>>>>>>> secondary LSP MAY be used by other LSPs until the >>>>>>>> >>>>>primary LSP fails >>>>> >>>>>>>> over to the secondary LSP." This may not always be >>>>>>>> >>>>>the case. An >>>>> >>>>>>>> explicit flag indicating whether or not extra >>>>>>>> >>>>>traffic may use the >>>>> >>>>>>>> secondary path resources is needed. >>>>>>>> >>>>>>>??? This is the purpose of this bit. >>>>>>> >>>>>>This is not clear from the definition. The bit is defined >>>>>> >>>>>as indicating >>>>> >>>>>>the LSP is a secondary (or protecting) LSP and in 1+1 >>>>>> >>>>protection the >>>> >>>>>>secondary LSP may not be used for extra traffic. >>>>>> >>>>>>Perhaps the problem here is that protection features are >>>>>> >>>>>being defined >>>>> >>>>>>before the protection framework and requirements are >>>>>> >>>>done. Is this >>>> >>>>>>presupposing some particular outcome of the recovery work in CAMP? >>>>>> >>>>>>JD: I think the definition of the bit is fine. For both >>>>>> >>>>>1+1 and 1:1 >>>>> >>>>>>protection, there would be a pair of Primary LSPs between >>>>>> >>>>the source >>>> >>>>>>and destination, rather than a Primary and a Secondary. >>>>>> >>>>>This is an unusual use of terms. I have never encountered a case >>>>>where both the working and recovery paths are call "primary." >>>>> >>>>>This is not consistent with either draft-mpls-recovery-framework >>>>>or with draft-lang-ccamp-recovery. I think this is a sign that the >>>>>protection work is immature and not ready for progressing to RFC. >>>>> >>>>> >>>>For 1+1 path protection, both working/recovery paths are >>>>carrying user data >>>>traffic and it is an endpoint decision as to which path is >>>>actually the >>>>working/recovery path. At a transit node, both paths need to >>>>be treated as >>>>primary, as the resources are currently being used and >>>>obviously can't be >>>>used for Extra Traffic. >>>> >>>> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 09:53:58 -0800 Message-ID: From: John Drake To: 'Markus Jork' , Lou Berger Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-rsvp-te-05 Date: Tue, 18 Dec 2001 09:50:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Markus, The router would specify LSC in the generalized label request. The Router/OXC links are PSC at the router end and LSC at the OXC end. Thanks, John -----Original Message----- From: Markus Jork [mailto:mjork@avici.com] Sent: Monday, December 17, 2001 1:39 PM To: Lou Berger Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Lou, I think there is still some confusion in the draft regarding the switching type. Of course it could also be that the draft is perfectly clear and I'm confused... Quoting a response you gave to Manoj/Ben: > > > > > > >A Tunnel (FA) is a type > > > > of link, not a class of switching. This adds to the > > > > confusion I've noted about the need for and use of Switching > > > > Type. > > > >Switching Type continues to be ill-defined. I have heard that the real > >definition is different from that given in the current drafts. If the > >signaling information is not clearly defined and it's use described, we > >can hardly expect interoperability. > > I can't speak for others. My belief is that there is a very concrete > definition. I thought the text in the draft was clear as well, but let me > try again: > > > Switching Type: 8 bits > > Indicates the type of switching that should be performed > on a particular link. This field is needed for links that > advertise more than one type of switching capability. > This field contains one of the values advertised for the > corresponding link in the routing Switching Capability > field as defined in [GMPLS-RTG]. > > In other words, on links where one Switching Capability is advertised > (which will be all the time for most equipment) Switching Type is set to > the same value as advertised in routing. On links where multiple Switching > Capabilities are advertised, Switching Type is set to the value advertised > in Switching Capability that matches the type of switching to be performed. > > [I'll put the revised text in the next rev...] > Let's look at the example of two IP routers connected to a cloud of opaque OXCs: R1 ----- OXC1 ----- OXC2 ----- R2 LSC LSC PSC OXC1 and OXC2 switch the Sonet stream from an incoming interface to some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks at the incoming IP packets. The encoding on the links is OC192. Now I want to setup an LSP between R1 and R2. (This LSP is essentially a "lightpath" through the optical cloud and will be advertised as FA so that PSC LSPs can be tunneled through it later.) What is the switching type requested in the Generalized Label Request object? I would expect LSC. But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: A Generalized Label Request object is set by the ingress node, transparently passed by transit nodes, and used by the egress node. This would suggest the switching type needs to be PSC. But then the text in 2.1.1 says: Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication. So when the Path message requested PSC, it would be rejected by OXC1 and OXC2. When it requested LSC it would be rejected by R2. The transit nodes can't modify the switching type in the Path message because they don't have enough knowledge to pick the right one. How is this supposed to work? thanks for any clarification, Markus Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 09:26:51 -0800 Message-ID: <3C1F7B3F.CCCD4A1C@tellabs.com> Date: Tue, 18 Dec 2001 11:22:07 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Maarten Vissers CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) we chose "working path" and "recovery path." We used "recovery" instead of "protection" because it seemed a more neutral term given that we were including both protection switching and reroute recovery mechanisms. We did not address the state (active/standby). We use the terms "extra traffic" and "working traffic" (perhaps the latter could be changed to "normal traffic"). It would be useful in moving forward in CCAMP if we could try to adopt terms that are consistent with those in current use elsewhere. Regards, Ben Maarten Vissers wrote: > > There exist well defined protection terminology in ITU-T for the transport > plane. "Working" and "Protection" are being used and not primary/secondary. E.g. > a 1+1 architecture has one working connection, one protection connection and a > permanent bridge. > > Besides working/protection indication for the transport entity, there is > - "active" and "standby" to indicate if the signal is selected from the working > or protection transport entity; i.e. if selector selects from working, the > working is active and protection is standby, if the selector selects from > protection the working is standby and the protection is active. > - "normal" and "extra traffic" signal. The normal signal is protected. > > Regards, > > Maarten > > neil.2.harrison@bt.com wrote: > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > neil > > > > > -----Original Message----- > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > Sent: 12 December 2001 17:46 > > > To: 'Ben Mack-Crane'; John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > Ben, > > > Please see inline. > > > > > > Thanks, > > > Jonathan > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > To: John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > See comment below. > > > > > > > > Regards, > > > > Ben > > > > > > > > John Drake wrote: > > > > > > > > > > Snipped > > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > To: Lou Berger > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > allocated for a > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > primary LSP fails > > > > > > > over to the secondary LSP." This may not always be > > > > the case. An > > > > > > > explicit flag indicating whether or not extra > > > > traffic may use the > > > > > > > secondary path resources is needed. > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > as indicating > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > protection the > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > Perhaps the problem here is that protection features are > > > > being defined > > > > > before the protection framework and requirements are > > > done. Is this > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > 1+1 and 1:1 > > > > > protection, there would be a pair of Primary LSPs between > > > the source > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > where both the working and recovery paths are call "primary." > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > For 1+1 path protection, both working/recovery paths are > > > carrying user data > > > traffic and it is an endpoint decision as to which path is > > > actually the > > > working/recovery path. At a transit node, both paths need to > > > be treated as > > > primary, as the resources are currently being used and > > > obviously can't be > > > used for Extra Traffic. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 09:18:45 -0800 Date: Tue, 18 Dec 2001 09:12:28 -0800 (PST) From: Kireeti Kompella Message-Id: <200112181712.JAA27830@kummer.juniper.net> To: ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com Subject: RE: GMPLS signaling documents updated per last calls Cc: bwijnen@lucent.com, sob@harvard.edu Hi Deborah, > I previously made the > comments to merge the (1) SDH and SONET values as one value There was a meeting among Steve Trowbridge, Maarten Vissers, Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on several issues, among them this one. The upshot was that whenever possible, the SDH label should be used, with the encoding type set to SDH (i.e., G.707); however, there are signals that have no SDH equivalent (if I remember right, VC-3 -- someone correct me!), so we will keep SONET labels and encoding types around for that case and for legacy equipment. The revised SONET/SDH document will contain the exact wording. I will also be sending a reply to the ITU communication stating the agreement we came to. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 09:04:47 -0800 Message-ID: <3C1F75A3.17B99FF6@tellabs.com> Date: Tue, 18 Dec 2001 10:58:11 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: "'Stephen Trowbridge'" , Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, You describe a bit that indicates whether or not the path should be connected. Perhaps we could call such a bit the "reserve/connect" bit. Calling it Secondary is not in line with the normal use of that term, and is thus misleading. It is useful to have a bit which identifies whether the path is the working or recovery path (thus the name "Secondary") so I think we should keep that meaning for this bit. Regards, Ben John Drake wrote: > > Steven, > > The basic idea is that if a connection is of type 'secondary', then other > LSPs of type 'primary' between the same or different source/destination > pairs MAY use its resources in intermediate nodes, until that LSP is > converted into a 'primary' with a subsequent Path/Resv flow. At this point, > other LSPs that were using its resources may get pre-empted. Think of the > primary/secondary mechanism as a way to ensure temporal priority while > allowing network resources to be re-used; i.e., an LSP of type 'secondary' > is carrying no data. > > So in the 1:1 case the protect LSP could be established either as a primary > or secondary LSP, while in the 1:N case the protect LSP would be established > as a secondary. > > Thanks, > > John > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Thursday, December 13, 2001 12:15 PM > To: John Drake > Cc: Maarten Vissers; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > John, > It would seem from this standpoint, ANY transport plane protection > must use "primary" for all trails. You have already made this argument > for the 1+1 case to carry the permanently bridged copy of the payload. > > In 1:1 or 1:n, when protection is not being used to carry one/any of > the normal traffic signals, it may either carry a null signal (no bridge) > or transport plane extra traffic. Even if the transport plane has only > a null signal on protection, the control plane cannot itself place extra > traffic on any portion of the end-to-end protection channel as this is > where the APS protocol is carried to coordinate the 1:1 or 1:n protection. > The protection channel overhead is chosen to carry the APS since it is > necessary to exchange APS bytes to complete a switch when working channels > are failed. If the protection channel has failed and APS cannot be > exchanged, > normal traffic signals will not be selected from protection. > Regards, > Steve > > John Drake wrote: > > > > Maarten, > > > > That's fine, however it's beside the point. The semantics of > > Primary/Secondary refer to the control plane and whether the node > > establishing a given LSP is planning to use it at the time it's > established > > or at a later time. As I indicated in an earlier note, 1+1 transport > plane > > protection would be accomplished in the control plane by establishing two > > LSPs of type Primary. The control plane really doesn't care which LSP the > > transport plane is using as Working and which as Protect, although that > > information is available to the control plane at the LSP endpoints. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Thursday, December 13, 2001 12:15 AM > > To: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not > primary/secondary. > > E.g. > > a 1+1 architecture has one working connection, one protection connection > and > > a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the > > working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:51:58 -0800 Message-ID: <3C1F729F.CA243EE@tellabs.com> Date: Tue, 18 Dec 2001 10:45:19 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See in-line. Regards, Ben John Drake wrote: > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Wednesday, December 12, 2001 10:10 AM > To: Jonathan Lang > Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > Jonathan, > > I agree that both the working and recovery paths must be connected > and carrying traffic (except at the egress). It is a problem that > the term "primary" is being overloaded to indicate both "working" > and "connected in transit nodes". > > JD: The fact that you don't understand the semantics of the > Primary/Secondary > bit doesn't necessarily mean that they're incorrect The fact that the semantics are unclear, and in fact misleading, is a problem. > > If it is an endpoint decision as to which is the working and which > is the recovery path, this seems to add more complexity to the > operator's job in setting up protected paths. > > JD: Assertion What do operator's think about having provision the signaled path AND separately configure the protection in the endpoints? What if only a part of the path needs protection? > > It would seem quite > reasonable to signal which path is which. > > JD: And why would the intermediate nodes care? The same could be said for G-PID! > > Regards, > Ben > > Jonathan Lang wrote: > > > > Ben, > > Please see inline. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > To: John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > See comment below. > > > > > > Regards, > > > Ben > > > > > > John Drake wrote: > > > > > > > > Snipped > > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > To: Lou Berger > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > allocated for a > > > > > > secondary LSP MAY be used by other LSPs until the > > > primary LSP fails > > > > > > over to the secondary LSP." This may not always be > > > the case. An > > > > > > explicit flag indicating whether or not extra > > > traffic may use the > > > > > > secondary path resources is needed. > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > This is not clear from the definition. The bit is defined > > > as indicating > > > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > > > secondary LSP may not be used for extra traffic. > > > > > > > > Perhaps the problem here is that protection features are > > > being defined > > > > before the protection framework and requirements are done. Is this > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > JD: I think the definition of the bit is fine. For both > > > 1+1 and 1:1 > > > > protection, there would be a pair of Primary LSPs between the source > > > > and destination, rather than a Primary and a Secondary. > > > > > > This is an unusual use of terms. I have never encountered a case > > > where both the working and recovery paths are call "primary." > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > protection work is immature and not ready for progressing to RFC. > > > > > For 1+1 path protection, both working/recovery paths are carrying user > data > > traffic and it is an endpoint decision as to which path is actually the > > working/recovery path. At a transit node, both paths need to be treated > as > > primary, as the resources are currently being used and obviously can't be > > used for Extra Traffic. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:32:54 -0800 Message-ID: <3C1F6FEC.F14A3D82@cisco.com> Date: Tue, 18 Dec 2001 11:33:48 -0500 From: Srinivasa Datari MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: jplang@calient.net Subject: Question on LMP Link Summary Nack msg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, If a TE link correlation fails (while processing a Link Summary msg), the Link Summary Nack msg only provides an error code (bit value 0x04 - Bad Received Remote_Link_Id) to indicate this failure. To help determine which TE link failed, would it be useful to include the failed TE link object as part of the Link Summary Nack msg ? The new Link Summary Nack msg can be of the form: ::= [] [...] Thanks, Srini Datari. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:26:00 -0800 Message-ID: <3C1F6BF5.16151FE6@tellabs.com> Date: Tue, 18 Dec 2001 10:16:53 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Notify Message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following issue raised 10/29/01 has not been addressed: > > >7) The Notify message is intended to "enable expedited notification of > > > failures," but it relies on the IP layer which may be affected by the > > > failure that the Notify is reporting. This could defeat the goal > > > of rapid notification. Without some means of guaranteeing the Notify > > > doesn't have to wait for IP routing convergence to be delivered, > > > it isn't a satisfactory solution. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:19:42 -0800 Message-ID: <3C1F6B8F.54CC2ECF@tellabs.com> Date: Tue, 18 Dec 2001 10:15:12 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In a brief discussion at the IETF meeting I was told that Switching Type really is Multiplexing Type, that is, HOW the LSP is to be carried over a link (not what is switched or how it is switched). This raises a set of issues that have not yet been discussed. The first of these is: What problem is this solving? Regards, Ben Mack-Crane The following issue raised 10/29/01 has not been addressed: >Switching Type continues to be ill-defined. I have heard that the real >definition is different from that given in the current drafts. If the >signaling information is not clearly defined and it's use described, we >can hardly expect interoperability. I can't speak for others. My belief is that there is a very concrete definition. I thought the text in the draft was clear as well, but let me try again: Switching Type: 8 bits Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field contains one of the values advertised for the corresponding link in the routing Switching Capability field as defined in [GMPLS-RTG]. In other words, on links where one Switching Capability is advertised (which will be all the time for most equipment) Switching Type is set to the same value as advertised in routing. On links where multiple Switching Capabilities are advertised, Switching Type is set to the value advertised in Switching Capability that matches the type of switching to be performed. [I'll put the revised text in the next rev...] Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:09:55 -0800 Message-ID: <3C1F6918.4A866073@tellabs.com> Date: Tue, 18 Dec 2001 10:04:40 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Protection Information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following issue raised 10/29/01 has not been addressed: (There are other active threads on this.) > >7) In Protection Information it states "The resources allocated for a > > secondary LSP MAY be used by other LSPs until the primary LSP fails > > over to the secondary LSP." This may not always be the case. An > > explicit flag indicating whether or not extra traffic may use the > > secondary path resources is needed. > > ??? This is the purpose of this bit. This is not clear from the definition. The bit is defined as indicating the LSP is a secondary (or protecting) LSP and in 1+1 protection the secondary LSP may not be used for extra traffic. Perhaps the problem here is that protection features are being defined before the protection framework and requirements are done. Is this presupposing some particular outcome of the recovery work in CAMP? Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:06:22 -0800 Message-ID: <3C1F67D1.32D01F90@tellabs.com> Date: Tue, 18 Dec 2001 09:59:13 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Bandwidth Encoding Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following issue raised 10/29/01 has not been addressed: > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it > > is useful to define discrete values to identify the bandwidth of the > > LSP." For SONET/SDH this is unnecessary given the Signal Type is > > provided. For the other non-packet LSP types (Lambda and Fiber) > > it is not clear that all the values cited in the example are relevant > > (for example, a DS0 lambda would seem wasteful...). > > > This is confusing, and should be clarified. In fact, a description of > > exactly why this field is required is needed. > > We've gone over this text multiple times. Do you have any suggested wording. > I would gladly suggest wording if I understood the use for this. It has no use for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda or Fiber. However, several of the examples are not appropriate for this. Perhaps this should be moved to a technology specific document since it is not really general anyway. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:05:43 -0800 Message-ID: <3C1F6835.D112FABF@tellabs.com> Date: Tue, 18 Dec 2001 10:00:53 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Waveband Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following issue raised 10/29/01 has not been addressed: > >6) The definition of Start Label and End Label in waveband switching seems > > inconsistent with the behavior described in generalized-rsvp-te-05. > > I don't see this. Feel free to suggest wording. Does anyone else see an inconsistency here? I would be interested in hearing from someone who understands the waveband content. I am concerned that the waveband proposal is speculative and not ready to progress toward RFC status. Perhaps the waveband content should be removed and the sections marked FFS. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 08:00:14 -0800 Message-ID: <3C1F670C.C51923FC@tellabs.com> Date: Tue, 18 Dec 2001 09:55:56 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: GMPLS Issue - Ethernet LSP Enc Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following issue raised 10/29/01 has not been addressed. > >1) There seems to be no difference as far as label allocation > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > and Ethernet 802.3 (10). One Encoding type would seem to > > be sufficient. > > I agree, but some feel that this is needed to properly establish LSPs in > systems what would terminate each type differently. I don't recall seeing anything on the list about the reasoning about this. can someone provide a pointer to where this was described? Since LSP Encoding type is intended to describe the LSP for transit nodes and G-PID is intended to describe the LSP contents for the purpose of terminating it at the ends, information relevant only to termination should be conveyed in G-PID. Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" would make this clearer. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Dec 2001 07:15:46 -0800 Cc: Lou Berger , ccamp@ops.ietf.org Message-ID: <3C1F5CF5.FF785ADC@lucent.com> Date: Tue, 18 Dec 2001 16:12:53 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Markus Jork Original-CC: Lou Berger , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Content-Type: multipart/mixed; boundary="------------A86F327437182D66D2D265AD" This is a multi-part message in MIME format. --------------A86F327437182D66D2D265AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Markus, John, Lou, Manoj, I also still have a major issue to understand the switching type... or more precise I have the feeling it is too coarse and ill defined. Let me provide some more examples to evaluate: Frist Markus' network example... it will look like the following in reality R1 ------ OXC1 ------ OXC2 ------ R2 OC-N OC-N OC-N OC-N trail |<------------------------------>| STS-Nc trail |<-------------------------------->| IP Link |<---------------------------------->| I assume that OXC1/2 are all optical cross connects which pass through the complete OC-N signals. In order to route IP packets between R1 and R2, you need to set up an OC-N trail between R1 and R2. Once this is done, you need to set up a STS-Nc trail between R1 and R2. Once this is done you have an IP link with a bandwidth of 9 584 640 kbit/s established between R1 and R2. Now IP signals can flow between R1 and R2. Now make the example a bit more complex and let me add a SONET cross connect in the chain. R1 ------ OXC1 ------ OXC2 ------ DXC1 ------ R2 OC-N OC-N OC-N OC-N OC-N trail OC-N trail |<------------------------------>| |<------>| STS-Nc trail |<-------------------------------------------->| IP Link |<---------------------------------------------->| The physical interface in each case is an OC-N. The DXC1 is a SONET cross connect, which terminates the OC-N Section and Line layers and forwards the STS-Nc signal. What would the switching types be in this case when an LSP is requested between R1 and R2? Now assume that the transport network contains some OTN OXCs interconnected via 40G wavelengths. The Routers are having STM-16 physical interfaces with VC-4-16c path signal carrying IP traffic. The DXC1 is a SDH cross connect with an OTN OTM-0.3 (i.e. 40G) interface, which is carrying ODU1 (2G5) signals with STM-16 inside. R1 -------- OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2 STM-16 OTM-64.3 OTM-40.3 OTM-0.3 STM-16 OCh trail |<-------------------------->| ODU3 trail |<----------------------------------------->| ODU1 trail |<-------------------------------------------->| STM-16 trail STM-16 trail |<-------------------------------------------------------->||<-------->| VC-4-16c trail |<---------------------------------------------------------------------->| IP Link |<------------------------------------------------------------------------>| What would the switching types be in this case when an LSP is requested between R1 and R2? But a router may also connect via a GE interface. The ethernet frames are then forwarded in OXC1 via a virtual concatenated VC-4-Xv to R2 (which has a STM-16 interface supporting VC-4-Xv). As VC-4-Xv signals can only be carried in sTM-N signals, there is an STM-16 trail between OXC1 and DXC1. There is another STM-16 trail between DXC1 and R2. The OXCs are part of an OTN network, so the STM-16 that is created in the OXC1 is mapped into an ODU1 and this ODU1 is switched to an OTM-64.3 port. In this port the ODU1 signal is TDM multiplexed into an ODU3 and this ODU3 is put onto a wavelenght (via OTU3V and OCh). OXC2 is an OCh (all optical) switch, capable to forward the true wavelenght signal between the two OTM-64.3 and OTM-40.3 line ports. The OCh signal is terminated in the OTM-40.3 line port in OXC3 and the ODU3 is switched to the egress OTM-0.3 interface port. Arriving at DXC1, the ODu3 is terminated, the ODU1 is demultiplexed from the ODU3, the ODU1 is terminated and the STM-16 is extracted. Then the sTM-16 is terminated and the X VC-4 signals are switched to the egress STM-16 signal. At R2 the STM-16 signal is terminated, the X-VC-4 signals are connected to the VC-4-Xv port and terminated making the ethernet frames available. The ehternet frames are terminated and the IP packets are now accessible. R1 ------ OXC1 ---------- OXC2 ---------- OXC3 --------- DXC1 -------- R2 1 GE OTM-64.3 OTM-40.3 OTM-0.3 STM-16 OCh trail |<-------------------------->| ODU3 trail |<----------------------------------------->| ODU1 trail |<-------------------------------------------->| GE trail STM-16 trail STM-16 trail |<----->||<---------------------------------------------->||<-------->| VC-4-Xv (X=1..7) trail |<------------------------------------------------------------>| Ethernet MAC link |<---------------------------------------------------------------------->| IP Link |<------------------------------------------------------------------------>| Question is again the switching types you will see when requesting a LSP between R1 and R2. Regards, Maarten Markus Jork wrote: > Let's look at the example of two IP routers connected to a cloud of > opaque OXCs: > > R1 ----- OXC1 ----- OXC2 ----- R2 > LSC LSC PSC > > OXC1 and OXC2 switch the Sonet stream from an incoming interface to > some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 > are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks > at the incoming IP packets. The encoding on the links is OC192. > > Now I want to setup an LSP between R1 and R2. (This LSP is essentially > a "lightpath" through the optical cloud and will be advertised as FA > so that PSC LSPs can be tunneled through it later.) > What is the switching type requested in the Generalized Label Request > object? I would expect LSC. > But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: > > A Generalized Label Request object is set by the ingress node, > transparently passed by transit nodes, and used by the egress node. > > This would suggest the switching type needs to be PSC. > But then the text in 2.1.1 says: > > Nodes MUST verify that the type indicated in the Switching Type > parameter is supported on the corresponding incoming interface. If > the type cannot be supported, the node MUST generate a PathErr > message with a "Routing problem/Switching Type" indication. > > So when the Path message requested PSC, it would be rejected by OXC1 > and OXC2. When it requested LSC it would be rejected by R2. > The transit nodes can't modify the switching type in the Path message > because they don't have enough knowledge to pick the right one. > How is this supposed to work? > > thanks for any clarification, > Markus --------------A86F327437182D66D2D265AD Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------A86F327437182D66D2D265AD-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 19:14:10 -0800 Message-ID: From: John Drake To: 'Stephen Trowbridge' Cc: Maarten Vissers , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Mon, 17 Dec 2001 19:11:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Steven, The basic idea is that if a connection is of type 'secondary', then other LSPs of type 'primary' between the same or different source/destination pairs MAY use its resources in intermediate nodes, until that LSP is converted into a 'primary' with a subsequent Path/Resv flow. At this point, other LSPs that were using its resources may get pre-empted. Think of the primary/secondary mechanism as a way to ensure temporal priority while allowing network resources to be re-used; i.e., an LSP of type 'secondary' is carrying no data. So in the 1:1 case the protect LSP could be established either as a primary or secondary LSP, while in the 1:N case the protect LSP would be established as a secondary. Thanks, John -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Thursday, December 13, 2001 12:15 PM To: John Drake Cc: Maarten Vissers; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 John, It would seem from this standpoint, ANY transport plane protection must use "primary" for all trails. You have already made this argument for the 1+1 case to carry the permanently bridged copy of the payload. In 1:1 or 1:n, when protection is not being used to carry one/any of the normal traffic signals, it may either carry a null signal (no bridge) or transport plane extra traffic. Even if the transport plane has only a null signal on protection, the control plane cannot itself place extra traffic on any portion of the end-to-end protection channel as this is where the APS protocol is carried to coordinate the 1:1 or 1:n protection. The protection channel overhead is chosen to carry the APS since it is necessary to exchange APS bytes to complete a switch when working channels are failed. If the protection channel has failed and APS cannot be exchanged, normal traffic signals will not be selected from protection. Regards, Steve John Drake wrote: > > Maarten, > > That's fine, however it's beside the point. The semantics of > Primary/Secondary refer to the control plane and whether the node > establishing a given LSP is planning to use it at the time it's established > or at a later time. As I indicated in an earlier note, 1+1 transport plane > protection would be accomplished in the control plane by establishing two > LSPs of type Primary. The control plane really doesn't care which LSP the > transport plane is using as Working and which as Protect, although that > information is available to the control plane at the LSP endpoints. > > Thanks, > > John > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Thursday, December 13, 2001 12:15 AM > To: ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > There exist well defined protection terminology in ITU-T for the transport > plane. "Working" and "Protection" are being used and not primary/secondary. > E.g. > a 1+1 architecture has one working connection, one protection connection and > a > permanent bridge. > > Besides working/protection indication for the transport entity, there is > - "active" and "standby" to indicate if the signal is selected from the > working > or protection transport entity; i.e. if selector selects from working, the > working is active and protection is standby, if the selector selects from > protection the working is standby and the protection is active. > - "normal" and "extra traffic" signal. The normal signal is protected. > > Regards, > > Maarten > > neil.2.harrison@bt.com wrote: > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > neil > > > > > -----Original Message----- > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > Sent: 12 December 2001 17:46 > > > To: 'Ben Mack-Crane'; John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > Ben, > > > Please see inline. > > > > > > Thanks, > > > Jonathan > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > To: John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > See comment below. > > > > > > > > Regards, > > > > Ben > > > > > > > > John Drake wrote: > > > > > > > > > > Snipped > > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > To: Lou Berger > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > allocated for a > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > primary LSP fails > > > > > > > over to the secondary LSP." This may not always be > > > > the case. An > > > > > > > explicit flag indicating whether or not extra > > > > traffic may use the > > > > > > > secondary path resources is needed. > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > as indicating > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > protection the > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > Perhaps the problem here is that protection features are > > > > being defined > > > > > before the protection framework and requirements are > > > done. Is this > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > 1+1 and 1:1 > > > > > protection, there would be a pair of Primary LSPs between > > > the source > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > where both the working and recovery paths are call "primary." > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > For 1+1 path protection, both working/recovery paths are > > > carrying user data > > > traffic and it is an endpoint decision as to which path is > > > actually the > > > working/recovery path. At a transit node, both paths need to > > > be treated as > > > primary, as the resources are currently being used and > > > obviously can't be > > > used for Extra Traffic. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 15:04:09 -0800 From: Joe Dumont Reply-To: joe.dumont@verizon.net To: ccamp@ops.ietf.org Subject: Addition to Deletion Proc for GMPLS RSVP Date: Mon, 17 Dec 2001 17:03:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20011217230329.DKEY24740.mta003.verizon.net@mta003> Hello, Section 7.2.2 of generalized-rsvp-te-06 does not appear cover the case of an Egress initiated deletion where the ingress node does not support admin status. I suggest the following additional wording to be added to the end of section 7.2.2 to clarify this additional error procedure: "In the case of a non-supporting ingress node, a PathTear may not be returned when an egress node sends a Resv with D and R bits set. To support the case of non-supporting ingress node, the egress SHOULD only wait a configurable period of time for the PathTear message to be returned. Once the period of time has elapsed, the egress node sends a ResvTear message or a PathErr message with Path_state_removed flag set, and normal RSVP takes place. By default for this period SHOULD be 30 seconds." Regards, Joe Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 14:38:04 -0800 From: "manoj juneja" To: v.sharma@ieee.org, lberger@movaz.com Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Bcc: Subject: RE: Fwd: Comments on GMPLS signalling drafts Date: Mon, 17 Dec 2001 15:37:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Vishal, Thanks a lot for the clarifications. John Drake mentioned in one of his responses that a LSC FA-LSP can be advertised in routing with different switching type (i.e. TDM). It means an FA can be advertised using switching type that is different from the switching type of the LSP that created the FA. I don't think this is mentioned in any of the drafts. Please let me know if I m missing something. Following was my main concern : A LSP that is established with switching type say X (X=PSC/LSC/FSC/TDM) and advertised as a FA with different switching type say Y (X != Y) then what all the possible combinatios of X and Y ? Regards, manoj. >From: "Vishal Sharma" >Reply-To: >To: "manoj juneja" , >CC: , , > >Subject: RE: Fwd: Comments on GMPLS signalling drafts >Date: Mon, 17 Dec 2001 10:10:55 -0800 > >Manoj, > >I just got to my email after a hiatus, and saw your question on >tunnelling at the end of this email (I've deleted all the rest). >Since there seems to have been much debate on this, and you >brought it up yet again, I thought it appropriate to answer. > >Actually, I don't understand where the confusion is. I think John Drake >already answered this question, both in his reply directly to you, >and again, in his observations on Juergen's email (the one where >Juergen tried to explain his understanding of FA's etc.). > >The basic answer is that the lambda LSP will be advertised in routing, >and stored in the TED at A and D, as a TDM-capable FA LSP. >From that point forward, nodes A and D will exchange TDM labels for >any TDM LSP being setup over this FA LSP(those labels will of course >follow all the layering rules that Maarten and Juergen have been >talking about, and the label requests themselves will be tunnelled >directly from A to D; for example, over the SONET/SDH section or line >DCC). In fact, one could view this FA LSP as a "one-hop" >TDM link, with all the properties of a TDM link. > >More specifically, all TDM LSPs tunneled through the >FA LSP will *not* be allocated the same label (this is a physical >impossibility in a circuit switched network in any case). Rather, >they will each be allocated a label that denotes the time slots >on the FA LSP (now viewed as TDM capable) that each TDM LSP will >use. > >(BTW, you might also find a presentation >I gave at MPLSCon'01 in March this year on this very subject useful to >clarify some of your doubts (there are some pictures there that >are useful for visualizing these scenarios).) > >Finally, I saw in one of your earlier emails on this subject a request, >which seemed to boil down to asking that every possible scenario >be outlined in some document or the other. While, in general, I am >supportive of making things clear (and I've expressed that viewpoint >several times on this list and the MPLS list over the past couple years), >in this particular case, I think you might be asking for too much! >Doing that is practically impossible. > >Once the building blocks are specified (and I support that they be >specified as clearly as possible), the compositions of these blocks >is something that has to be done depending on the specific applications >that one intends to use these blocks for. > >-Vishal > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >Behalf Of manoj juneja >Sent: Friday, December 14, 2001 3:33 PM >To: lberger@movaz.com >Cc: Eric.Mannie@ebone.com; dimitri.papadimitriou@alcatel.be; >ccamp@ops.ietf.org >Subject: Re: Fwd: Comments on GMPLS signalling drafts > > >Hi Lou/Eric/Dimitri, > > Please see the following para from gmpls-architecture draft : > > > > >From: Lou Berger > >To: "manoj juneja" > >CC: ,, > > > >Subject: Re: Fwd: Comments on GMPLS signalling drafts > >Date: Fri, 14 Dec 2001 15:18:34 -0500 > > > >see comments inline. > > > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > >> >From: "manoj juneja" > >> >To: ccamp@ops.ietf.org > >> >Subject: Comments on GMPLS signalling drafts > >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 > >> > > >> >Hi All, > >> > > >> >1. SE-style supported by GMPLS or not ? > >> > > ><> > > >> >8. The LSP hierarchy concept is still not clear. Some days back I >posted > >> >one > >> >doubt related to tunneling of TDM LSP over Lambda LSP using the >concept > >>of > >> >forwarding adjacency and different people replied with different > >>thoughts. > >> >Does this mean this concept is not standardized in GMPLS ? > >> >My question was : > >> > > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > >> >established from A to D and if a new TDM LSP request comes to node A > >> >which is to be tunneled through the already established lambda FA-LSP > >> >then the node A sends the Path/label request message directly to node > >> >D. What label the node D will send back to node A in the RESV/label > >> >mapping message since the FA-LSP is just one label (lambda) ? Does it > >> >mean that all the LSPs which are tunneled through the lambda FA-LSP > >> >will be allocated the same label by node D to node A ? If this type of > >> >scenario can't exist in GMPLS then please let me know that too." > > > >I believe this topic is being covered in other threads. > > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 14:20:43 -0800 content-class: urn:content-classes:message Subject: RE: GMPLS signaling documents updated per last calls Date: Mon, 17 Dec 2001 17:20:10 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC6240FA717@OCCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: GMPLS signaling documents updated per last calls Thread-Index: AcGBwkEknRA37O2zEdWVVQCQJ2GH0wFhDfjQ From: "Brungard, Deborah A, ALCTA" To: "Lou Berger" , Cc: , On the mpls-generalized-signaling draft, can someone please summarize = the agreements regarding the LSP encoding types? I previously made the = comments to merge the (1) SDH and SONET values as one value (i.e. ITU-T = G.707)and (2) ANSI PDH and ETSI PDH values as one value (i.e. ITU-T = PDH)? The latest draft does not show any changes on the LSP encoding = types. Deborah Brungard AT&T -----Original Message----- From: Lou Berger [mailto:lberger@movaz.com] Sent: Monday, December 10, 2001 4:05 PM To: ccamp@ops.ietf.org Cc: bwijnen@lucent.com; sob@harvard.edu Subject: GMPLS signaling documents updated per last calls All, As was discussed in this morning's SUB-IP session, the GMPLS signaling=20 documents have been updated to reflect comments received during the=20 extended last call. If you believe an issue that you have previously=20 raised has not been addressed in the drafts, please send a message to = the=20 list. (We'll respond with either how the issue was addressed or if it = was=20 missed.) Here's a summary of changes: draft-ietf-mpls-generalized-signaling-07.txt see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version. o changes were primarily in the area of GPID values. (Juergen has a couple of additions that we'll incorporate in next rev.) draft-ietf-mpls-generalized-rsvp-te-06.txt see http://www.labn.net/docs/diff-rsvp-05-06.txt o Minor editorial changes and clarifications based on comments from list draft-ietf-mpls-generalized-cr-ldp-05.txt http://www.labn.net/docs/diff-ldp-04-05.txt o Brings cr-ldp functionally in line with rsvp-te o Revised Admin Status Usage (per comments and also removed potential = race=20 condition) o Clarified text related to interface bundling (To be consistent with=20 updated bundling draft.) o Added IANA Considerations o Minor editorial changes and clarifications Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 14:17:13 -0800 From: "manoj juneja" To: mjork@avici.com, lberger@movaz.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Moving right along ... generalized-rsvp-te-05 Date: Mon, 17 Dec 2001 15:15:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Markus, I think first u have to create an FA between R1-OXC1-OXC2 with switching type LSC. If u want to tunnel the packet traffic over this FA -LSC LSP then u need to send another LSP request (Path message) with switching type as PSC from R1 to OXC2. The path message will directly be sent by R1 to OXC-2 (as R1 and OXC-2 are the end-points of the FA). The OXC-2 will have to trigger new LSP from OXC-2 to R2 with switching type PSC. Lou, please correct me if I am wrong. Regards, manoj. >From: Markus Jork >To: Lou Berger >CC: ccamp@ops.ietf.org >Subject: Re: Moving right along ... generalized-rsvp-te-05 >Date: Mon, 17 Dec 2001 16:39:18 -0500 > >Lou, > >I think there is still some confusion in the draft regarding >the switching type. Of course it could also be that the draft >is perfectly clear and I'm confused... > >Quoting a response you gave to Manoj/Ben: > > > > > > > > > >A Tunnel (FA) is a type > > > > > of link, not a class of switching. This adds to the > > > > > confusion I've noted about the need for and use of Switching > > > > > Type. > > > > > >Switching Type continues to be ill-defined. I have heard that the real > > >definition is different from that given in the current drafts. If the > > >signaling information is not clearly defined and it's use described, we > > >can hardly expect interoperability. > > > > I can't speak for others. My belief is that there is a very concrete > > definition. I thought the text in the draft was clear as well, but let >me > > try again: > > > > > > Switching Type: 8 bits > > > > Indicates the type of switching that should be performed > > on a particular link. This field is needed for links that > > advertise more than one type of switching capability. > > This field contains one of the values advertised for the > > corresponding link in the routing Switching Capability > > field as defined in [GMPLS-RTG]. > > > > In other words, on links where one Switching Capability is advertised > > (which will be all the time for most equipment) Switching Type is set to > > the same value as advertised in routing. On links where multiple >Switching > > Capabilities are advertised, Switching Type is set to the value >advertised > > in Switching Capability that matches the type of switching to be >performed. > > > > [I'll put the revised text in the next rev...] > > > >Let's look at the example of two IP routers connected to a cloud of >opaque OXCs: > >R1 ----- OXC1 ----- OXC2 ----- R2 > LSC LSC PSC > >OXC1 and OXC2 switch the Sonet stream from an incoming interface to >some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 >are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks >at the incoming IP packets. The encoding on the links is OC192. > >Now I want to setup an LSP between R1 and R2. (This LSP is essentially >a "lightpath" through the optical cloud and will be advertised as FA >so that PSC LSPs can be tunneled through it later.) >What is the switching type requested in the Generalized Label Request >object? I would expect LSC. >But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: > > A Generalized Label Request object is set by the ingress node, > transparently passed by transit nodes, and used by the egress node. > >This would suggest the switching type needs to be PSC. >But then the text in 2.1.1 says: > > Nodes MUST verify that the type indicated in the Switching Type > parameter is supported on the corresponding incoming interface. If > the type cannot be supported, the node MUST generate a PathErr > message with a "Routing problem/Switching Type" indication. > >So when the Path message requested PSC, it would be rejected by OXC1 >and OXC2. When it requested LSC it would be rejected by R2. >The transit nodes can't modify the switching type in the Path message >because they don't have enough knowledge to pick the right one. >How is this supposed to work? > >thanks for any clarification, >Markus > > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 13:44:11 -0800 Message-Id: <200112172139.fBHLdJj05759@mailhost.avici.com> From: Markus Jork To: Lou Berger cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Dec 2001 16:39:18 -0500 Lou, I think there is still some confusion in the draft regarding the switching type. Of course it could also be that the draft is perfectly clear and I'm confused... Quoting a response you gave to Manoj/Ben: > > > > > > >A Tunnel (FA) is a type > > > > of link, not a class of switching. This adds to the > > > > confusion I've noted about the need for and use of Switching > > > > Type. > > > >Switching Type continues to be ill-defined. I have heard that the real > >definition is different from that given in the current drafts. If the > >signaling information is not clearly defined and it's use described, we > >can hardly expect interoperability. > > I can't speak for others. My belief is that there is a very concrete > definition. I thought the text in the draft was clear as well, but let me > try again: > > > Switching Type: 8 bits > > Indicates the type of switching that should be performed > on a particular link. This field is needed for links that > advertise more than one type of switching capability. > This field contains one of the values advertised for the > corresponding link in the routing Switching Capability > field as defined in [GMPLS-RTG]. > > In other words, on links where one Switching Capability is advertised > (which will be all the time for most equipment) Switching Type is set to > the same value as advertised in routing. On links where multiple Switching > Capabilities are advertised, Switching Type is set to the value advertised > in Switching Capability that matches the type of switching to be performed. > > [I'll put the revised text in the next rev...] > Let's look at the example of two IP routers connected to a cloud of opaque OXCs: R1 ----- OXC1 ----- OXC2 ----- R2 LSC LSC PSC OXC1 and OXC2 switch the Sonet stream from an incoming interface to some outgoing interface, that's why links R1-OXC1 and OXC1-OCX2 are advertised as LSC in the IGP. Link OXC2-R2 is PSC because R2 looks at the incoming IP packets. The encoding on the links is OC192. Now I want to setup an LSP between R1 and R2. (This LSP is essentially a "lightpath" through the optical cloud and will be advertised as FA so that PSC LSPs can be tunneled through it later.) What is the switching type requested in the Generalized Label Request object? I would expect LSC. But section 2.1 of draft-ietf-mpls-generalized-rsvp-te-06 says: A Generalized Label Request object is set by the ingress node, transparently passed by transit nodes, and used by the egress node. This would suggest the switching type needs to be PSC. But then the text in 2.1.1 says: Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication. So when the Path message requested PSC, it would be rejected by OXC1 and OXC2. When it requested LSC it would be rejected by R2. The transit nodes can't modify the switching type in the Path message because they don't have enough knowledge to pick the right one. How is this supposed to work? thanks for any clarification, Markus Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 10:22:54 -0800 Message-Id: <4.3.2.7.2.20011217131855.02514ac8@mo-ex1> Date: Mon, 17 Dec 2001 13:19:33 -0500 To: "Kullberg, Alan" From: Lou Berger Subject: RE: Fwd: Comments on GMPLS signalling drafts Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:57 PM 12/17/2001, Kullberg, Alan wrote: >Lou, > >See comments below. > >Alan > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@movaz.com] > > Sent: Friday, December 14, 2001 3:19 PM > > To: manoj juneja > > Cc: Eric.Mannie@ebone.com; dimitri.papadimitriou@alcatel.be; > > ccamp@ops.ietf.org > > Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > > > > see comments inline. > > > > At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > > > > > >From: "manoj juneja" > > > >To: ccamp@ops.ietf.org > > > >Subject: Comments on GMPLS signalling drafts > > > >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > > > >[snip, snip] > > > > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs > > defined. What > > > >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > > >bundling draft has removed these 2 TLVs. What about the > > GMPLS signalling > > > >drafts ? > > > > > > > > It's still in, see the drafts for explanations. > > From section 8.1 of draft-ietf-mpls-generalized-rsvp-te-06.txt, > > In all cases but bundling, see [MPLS-BUNDLE], the > upstream interface is implied by the downstream interface. For > bundling, the path sender explicitly identifies the component > interface used in each direction. > >The latest bundling draft (draft-ietf-mpls-bundle-01.txt) doesn't >support this statement as far as I can tell. The bundling draft >now specifies to use type 1, 2, or 3 in the IF_ID TLV, but never >type 4 or 5. This is in conflict with generalized-rsvp-te-06. >I don't think the bundle draft can be used as the reference here >or in generalized-signaling-07, section 9.1.1, since there is a >contradicion between the 2 drafts. The reference is to provide context on bundling, not operation. The reference will be dropped. Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 10:13:37 -0800 Reply-To: From: "Vishal Sharma" To: "manoj juneja" , Cc: , , Subject: RE: Fwd: Comments on GMPLS signalling drafts Date: Mon, 17 Dec 2001 10:10:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manoj, I just got to my email after a hiatus, and saw your question on tunnelling at the end of this email (I've deleted all the rest). Since there seems to have been much debate on this, and you brought it up yet again, I thought it appropriate to answer. Actually, I don't understand where the confusion is. I think John Drake already answered this question, both in his reply directly to you, and again, in his observations on Juergen's email (the one where Juergen tried to explain his understanding of FA's etc.). The basic answer is that the lambda LSP will be advertised in routing, and stored in the TED at A and D, as a TDM-capable FA LSP. >From that point forward, nodes A and D will exchange TDM labels for any TDM LSP being setup over this FA LSP(those labels will of course follow all the layering rules that Maarten and Juergen have been talking about, and the label requests themselves will be tunnelled directly from A to D; for example, over the SONET/SDH section or line DCC). In fact, one could view this FA LSP as a "one-hop" TDM link, with all the properties of a TDM link. More specifically, all TDM LSPs tunneled through the FA LSP will *not* be allocated the same label (this is a physical impossibility in a circuit switched network in any case). Rather, they will each be allocated a label that denotes the time slots on the FA LSP (now viewed as TDM capable) that each TDM LSP will use. (BTW, you might also find a presentation I gave at MPLSCon'01 in March this year on this very subject useful to clarify some of your doubts (there are some pictures there that are useful for visualizing these scenarios).) Finally, I saw in one of your earlier emails on this subject a request, which seemed to boil down to asking that every possible scenario be outlined in some document or the other. While, in general, I am supportive of making things clear (and I've expressed that viewpoint several times on this list and the MPLS list over the past couple years), in this particular case, I think you might be asking for too much! Doing that is practically impossible. Once the building blocks are specified (and I support that they be specified as clearly as possible), the compositions of these blocks is something that has to be done depending on the specific applications that one intends to use these blocks for. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of manoj juneja Sent: Friday, December 14, 2001 3:33 PM To: lberger@movaz.com Cc: Eric.Mannie@ebone.com; dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org Subject: Re: Fwd: Comments on GMPLS signalling drafts Hi Lou/Eric/Dimitri, Please see the following para from gmpls-architecture draft : >From: Lou Berger >To: "manoj juneja" >CC: ,, > >Subject: Re: Fwd: Comments on GMPLS signalling drafts >Date: Fri, 14 Dec 2001 15:18:34 -0500 > >see comments inline. > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > >> >From: "manoj juneja" >> >To: ccamp@ops.ietf.org >> >Subject: Comments on GMPLS signalling drafts >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 >> > >> >Hi All, >> > >> >1. SE-style supported by GMPLS or not ? >> > <> >> >8. The LSP hierarchy concept is still not clear. Some days back I posted >> >one >> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept >>of >> >forwarding adjacency and different people replied with different >>thoughts. >> >Does this mean this concept is not standardized in GMPLS ? >> >My question was : >> > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA >> >established from A to D and if a new TDM LSP request comes to node A >> >which is to be tunneled through the already established lambda FA-LSP >> >then the node A sends the Path/label request message directly to node >> >D. What label the node D will send back to node A in the RESV/label >> >mapping message since the FA-LSP is just one label (lambda) ? Does it >> >mean that all the LSPs which are tunneled through the lambda FA-LSP >> >will be allocated the same label by node D to node A ? If this type of >> >scenario can't exist in GMPLS then please let me know that too." > >I believe this topic is being covered in other threads. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 09:59:13 -0800 Message-ID: <87009604743AD411B1F600508BA0F9598AD9A7@XOVER.dedham.mindspeed.com> From: "Kullberg, Alan" To: ccamp@ops.ietf.org Subject: RE: Fwd: Comments on GMPLS signalling drafts Date: Mon, 17 Dec 2001 12:57:55 -0500 MIME-Version: 1.0 Content-Type: text/plain Lou, See comments below. Alan > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: Friday, December 14, 2001 3:19 PM > To: manoj juneja > Cc: Eric.Mannie@ebone.com; dimitri.papadimitriou@alcatel.be; > ccamp@ops.ietf.org > Subject: Re: Fwd: Comments on GMPLS signalling drafts > > > see comments inline. > > At 09:10 PM 12/13/2001, manoj juneja wrote: > > > > > >From: "manoj juneja" > > >To: ccamp@ops.ietf.org > > >Subject: Comments on GMPLS signalling drafts > > >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > [snip, snip] > > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs > defined. What > > >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > >bundling draft has removed these 2 TLVs. What about the > GMPLS signalling > > >drafts ? > > > > > It's still in, see the drafts for explanations. >From section 8.1 of draft-ietf-mpls-generalized-rsvp-te-06.txt, In all cases but bundling, see [MPLS-BUNDLE], the upstream interface is implied by the downstream interface. For bundling, the path sender explicitly identifies the component interface used in each direction. The latest bundling draft (draft-ietf-mpls-bundle-01.txt) doesn't support this statement as far as I can tell. The bundling draft now specifies to use type 1, 2, or 3 in the IF_ID TLV, but never type 4 or 5. This is in conflict with generalized-rsvp-te-06. I don't think the bundle draft can be used as the reference here or in generalized-signaling-07, section 9.1.1, since there is a contradicion between the 2 drafts. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 09:19:35 -0800 content-class: urn:content-classes:message Subject: RE: Intra-area Crankback Date: Mon, 17 Dec 2001 12:16:33 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170B24DB@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Intra-area Crankback Thread-Index: AcGDaosk4OC/1+9bEdWY1wCQJ3s6pwDsgPLg From: "Ash, Gerald R (Jerry), ALCTA" To: "Don Fedyk" Cc: "Ash, Gerald R (Jerry), ALCTA" , "Adrian Farrel" , "Atsushi Iwata" , "Norihito Fujita" , "Simon Marshall-Unitt" , "ccamp" Hi Don, don> The feedback draft is intended for this type of operation.=20 don> Feedback is best within the area crank back is best outside=20 don> the area. We discussed all of this with the original authors=20 don> many many times.=20 don> Crankback is a primitive from of feedback.=20 I recall perhaps one or two 'hallway discussions' along this line. = Personally I think that feedback and crankback do different things, one = is not a replacement for the other. Feedback feeds information to the = TED, crankback is a reroute-notify to the head-end or border LSR. One = can emulate a 'crankback' with a failure-notify, just as well as = interpreting a feedback TLV as a 'crankback'. It is not the same as = crankback nor a replacement for it. Both can provide needed functionality. Regards, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2001 01:30:50 -0800 Message-ID: <3C1DBA15.9F54099C@lucent.com> Date: Mon, 17 Dec 2001 10:25:41 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------A81E68D66DFC5BFCA0B54BC3" This is a multi-part message in MIME format. --------------A81E68D66DFC5BFCA0B54BC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I agree with John that the set up of the working and protection connections will be done by means of the set up of two normal connections with the constraint that those have to be diverse routed. The role these two diverse routed connections play has only relevance at the head and tail ends of the protected domain; not at any intermediate point along the connections. As I indicated in my presentation on Wednesday evening, connection set up has multiple phases: - connection bearer set up - connection monitoring set up - connection protection set up. The latter one refers to the set up of the head/tail end connection functions which include the bridges and selectors. Note that I ignore for this moment the Dual Node Interconnect (DNI) cases (see G.842) in which some intermediate nodes do have to know about protection. In section 3.2 of SG15 contribution D.301 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/301_ww2.pdf you find a high level overview of linear protection switching related management parameters: - Architecture Type (1+1, 1:n, ..) - Switching Type (uni-directional, bi-directional) - Operation Type (revertive, non-revertive) - Protection Type (trail, SNC/I, SNC/N, SNC/S) - Extra Traffic - SFPriority, SDPriority - Wait To Restore time - Hold Off time Note - the shared protection ring (MS Spring/BLSR and in future OCH SPRing and ODUk SPRing) (will) have their own set of parameters. When a call controller receives a request for a connection, it may decide that it must create a protected connection to compy with the QoS parameters associated with the call. The call controller then issues two connection requests to a connection controller, with the constraint to diverse route the two connections between the head end and tail end of the protected domain. At this point we have to differentiate between native connection requests and client connection requests. For the case there is a native connection request, the protection will be of the SubNetwork Connection (SNC) type. For the case there is a client connection request, the protection type may be of the SNC type, or may be of the trail protection type. Example 1: If a VC-4 call is to be supported by means of a protected VC-4 connection, then VC-4 SNC protection will have to be deployed. Example 2: If a STM-16 call is to be supported by means of a protected ODU1 connection then there is a choice to use either ODU1 trail protection or ODU1 SNC protection. Instead that the network call controller decides that a call is to be supported by a protected connection, the user may decide such and request for two diverse routed connections. The head/tail ends are then within the user domain. Example 3: If a user wants a protected STM-16 connection between e.g. two of its SDH equipment, it will set up a STM-16 MS trail protected port in its own equipment and request two diverse routed connections from the network. In addition to the above two cases, there can be a 3rd hybrid case; i.e. one bridge/seelctor pair is in the user domain and the other bridge/selector pair is in the network domain. When SNC protection is applicable, the fabrics will contain the protection switch processes. Two (case of 1+1, 1:1) regular connections between the first/last fabric in the protected domain are to be set up. Depending on the protection type, either no monitors have to be activated (SNC/I), or non intrusive monitors (SNC/N) have to be activated, or tandem connection monitoring functions have to be activated (SNC/S). When trail protection is applicable, the ports (not the fabrics) will contain the protection switch processes. Two (case of 1+1, 1:1) regular connections have to be set up between the working interface points of the protected ports and between the protection interface points of the protected ports. The ports include already the monitoring functionalities, so no specific action for monitoring selection is required in this case. The connection set up process must take care to provide the monitors in either case with the correct parameter values. Parameters are associated with the following monitoring processes: trace identifier, error detection, alarm reporting modes (TPmode, ARCmode), TCM level. With the connection and monitoring functions being set up, the protection processes at each endpoint can now be configured. I.e. the set of protection parameters listed at the begin of this email have to get values assigned. Note - As the connection protection set up hasn't been architected yet in ASON, it is undecided if the call controller or the connection controllers will be responsible for the head/tail end set up. For the case the connections have to pass multiple subnetworks or routing domains, the first and last subnetwork/routing domain may have a hybrid casen (including one portected domain end point), whereas any intermediate subnetwork/routing area has the case of two diverse routed connections (and no protected domain endpoints). Up to so far. Regards, Maarten PS. I hadn't seen "primary" before as an indication of connection set up. It seems unnecessary to add this adjective if it isn't used when setting up an unprotected connection. John Drake wrote: > > Maarten, > > That's fine, however it's beside the point. The semantics of > Primary/Secondary refer to the control plane and whether the node > establishing a given LSP is planning to use it at the time it's established > or at a later time. As I indicated in an earlier note, 1+1 transport plane > protection would be accomplished in the control plane by establishing two > LSPs of type Primary. The control plane really doesn't care which LSP the > transport plane is using as Working and which as Protect, although that > information is available to the control plane at the LSP endpoints. > > Thanks, > > John > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Thursday, December 13, 2001 12:15 AM > To: ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > There exist well defined protection terminology in ITU-T for the transport > plane. "Working" and "Protection" are being used and not primary/secondary. > E.g. > a 1+1 architecture has one working connection, one protection connection and > a > permanent bridge. > > Besides working/protection indication for the transport entity, there is > - "active" and "standby" to indicate if the signal is selected from the > working > or protection transport entity; i.e. if selector selects from working, the > working is active and protection is standby, if the selector selects from > protection the working is standby and the protection is active. > - "normal" and "extra traffic" signal. The normal signal is protected. > > Regards, > > Maarten > > neil.2.harrison@bt.com wrote: > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > neil > > > > > -----Original Message----- > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > Sent: 12 December 2001 17:46 > > > To: 'Ben Mack-Crane'; John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > Ben, > > > Please see inline. > > > > > > Thanks, > > > Jonathan > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > To: John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > See comment below. > > > > > > > > Regards, > > > > Ben > > > > > > > > John Drake wrote: > > > > > > > > > > Snipped > > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > To: Lou Berger > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > allocated for a > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > primary LSP fails > > > > > > > over to the secondary LSP." This may not always be > > > > the case. An > > > > > > > explicit flag indicating whether or not extra > > > > traffic may use the > > > > > > > secondary path resources is needed. > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > as indicating > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > protection the > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > Perhaps the problem here is that protection features are > > > > being defined > > > > > before the protection framework and requirements are > > > done. Is this > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > 1+1 and 1:1 > > > > > protection, there would be a pair of Primary LSPs between > > > the source > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > where both the working and recovery paths are call "primary." > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > For 1+1 path protection, both working/recovery paths are > > > carrying user data > > > traffic and it is an endpoint decision as to which path is > > > actually the > > > working/recovery path. At a transit node, both paths need to > > > be treated as > > > primary, as the resources are currently being used and > > > obviously can't be > > > used for Extra Traffic. > > > --------------A81E68D66DFC5BFCA0B54BC3 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------A81E68D66DFC5BFCA0B54BC3-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Dec 2001 11:45:38 -0800 Message-Id: <4.3.2.7.2.20011216141439.01b4b0d8@bucket.cisco.com> Date: Sun, 16 Dec 2001 14:18:47 -0500 To: "Adrian Farrel" From: Thomas Nadeau Subject: Re: MIBs for GMPLS Cc: "Joan Cucchiara" , , "Tim Hall" , "Edward Harrison" , "Cheenu Srinivasan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:51 PM 12/14/2001 -0500, Adrian Farrel wrote: > > > We considered several approaches to producing GMPLS MIBs and > presented these >in > > > London (if the slides are not still on the Web site I can mail them to >anyone > > > interested). > > > > Which web site? > >IETF. >I'll mail you under separate cover. > > > > The options were... > > > 1. Recycle the existing MIBs > > > 2. Add extensions to the existing MIBs as new tables and AUGMENTS > > > 3. Completely rewrite the MIBs > > > 4. Make version 2 MIBs > >[SNIP] > > So the decision was for #4 Make Version 2 of the MIBs. > > > > Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ? > > That is what is typically done. > >SNaFU. They are not called LSRv2 etc... because they support enhanced functionality for GMPLS that "classic" MPLS cannot handle. They are intended to represent a superset of functions -- classic MPLS being a superset. Our thinking was that calling them v2 would just confuse things. Perhaps we have done this anyway. > > Further, if these are supposed to eventuall replace documents in the > > MPLS working group, then isn't it appropriate to let that be known? > > I have seen no such postings to that working group. > >Replace may be too strong a word. Does the v1 MIB actually need to be >retired? > >You're correct that we haven't posted widely on the these MIBs yet. They >haven't existed long. > >I did send a note to the MPLS mailing list when we published the MIBs and >invited the discussion to be joined on the ccamp list. It is a good idea to >send a reminder - I will. > > > I do think this is probably a good way to go (although it was not > > clear from anything that I've read that that was the intent > > until you explained it here. Thanks for the explanation. > >Good, I'm glad you support the approach, > > > > > Also the Labels MIB is glumping everything into > > > > a single table. Was the use of separate tables (similar > > > > to what LDP did for ATM and FR specific objects) > > > > considered? > > > > > > Good choice of word, "glumping". I confess that I was never a fan of the > > > multiple table approach! > > > > > > >From an implementation point of view there is need be no impact > (although I >can > > > conceive of implementations where this is not the case :-). The > conformance > > > statement (of course, should make it clear that implementations can > support > > > whatever set of label-types they like. Note that an important > consideration >is > > > the type of labels reported from the network which may not match those >supported > > > locally. > > > > > > Hope this answers you. > > > > Not really. This is not an implementation issue, it is a MIB design > > issue. I think it is sloppy (another highly technical term like > > glumping ;) to have MIBs look like C union structures. Sorry to be > > so terse, but I would *hope* the IETF would raise the bar on MIB > > quality just a tad. You have no idea if the way the MIB is currently > > written would be less difficult to implement for most folks. > > In fact, I would argue just the opposite; based on my experience > > a poorly designed MIB is far more difficult to implement because > > it is difficult to understand and it becomes difficult to maintain and > > scale over time as deprecations/extentions are needed. > >OK. Probably bringing implementation into it is not going to help us much. I >have plenty of experience of MIB implementation and would not propose >anything I >considered hard to implement, but as you say that is not the issue. The idea was not to discuss implementations, but to use existing ones as a measure of how difficult it would be to support the new ones. Thus far, it does not seem like it is that difficult to support the new functions and the old ones on boxes that support both. >The issue is doing the correct MIB-like thing. > >You are suggesting a label table for each type of label. Presumably the >referencing object still contains a simple index, and the table to index is >deduced from the label type. We had thought of using this approach, but in the end it seemed like having one table for all labels (with a label type) was the simplest approach. >Note that we did not want to use rowPointer because we wanted to facilitate >non-use of the Label Table in 32 bit label systems by direct inclusion of the >label (as in the current MIBs). Yes. --Tom >We'll think about this a bit. > >Thanks, >Adrian >-- >Adrian Farrel >Movaz Networks Inc. >Tel: 703-847-1867 >afarrel@movaz.com ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Dec 2001 06:09:17 -0800 Message-Id: <4.3.2.7.2.20011216090030.01a3a918@bucket.cisco.com> Date: Sun, 16 Dec 2001 09:03:39 -0500 To: Joan Cucchiara From: Thomas Nadeau Subject: Re: MIBs for GMPLS Cc: Adrian Farrel , ccamp@ops.ietf.org, Tim Hall , Edward Harrison , Cheenu Srinivasan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Joan, >Why is there so much overlap between these >MIBs and the MIBs in MPLS? >It seems that the MPLS MIBs could be extended >for GMPLS specific info and thus avoid so much >overlap. Could you shed some light on this? The idea was to leverage as much of the "classic" MIBs as possible. We originally tried extending the "classic" MIBs, but it turned out to be quite a problem and made the MIBs resemble a pile of bailing wire and bubble gum, especially for those tables which were indexed by labels (LSR and TE hop tables, for example). >Also the Labels MIB is glumping everything into >a single table. Was the use of separate tables (similar >to what LDP did for ATM and FR specific objects) >considered? The motivation here was to be able to implement the GMPLS TE MIB without the GMPLS LSR MIB. The dependency from the TE MIB is really on the label table, so pulling this out seemed to make sense for those only wishing to implement the GMPLS TE MIB first. --Tom > Thanks, Joan > > > Adrian Farrel wrote: > > > > At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS > > that we have produced. > > > > Kireeti asked that we take the MIBs to the list to ensure that the big > > issues have been addressed, that everyone is comfortable with the > > approach and there really is a need for the MIBs. > > > > Requirements are handled by... > > > > - protocols within the IETF need MIBs, further > > draft-ietf-ccamp-gmpls-architecture-01.txt > > explicitly requires MIBs for GMPLS > > > > The biggest issue outstanding was whether the Labels MIB should be > > included within the LSR MIB. The authors currently feel that it > > should remain as a separate MIB > > > > - to allow people to implement only the TE MIB > > without putting complex conformance statements > > in the LSR MIB > > - to allow people to clearly not implement the > > Labels MIB at all. > > We would welcome input on this. > > > > > > Please take this opportunity to give us your input and help shape the > > MIBs. > > > > We hope to respin the drafts in a compilable form in the next few > > days. > > > > > > The MIBs are... > > > > > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00.txt > > > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib-00.txt > > > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00.txt > > > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-00.txt > > > > > > Regards, > > Adrian > > > > -- > > Adrian Farrel > > Movaz Networks Inc. > > Tel: 703-847-1867 > > afarrel@movaz.com ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 20:54:37 -0800 Message-ID: <00f101c18524$2c2a2180$681810ac@movaz.com> From: "Adrian Farrel" To: "Joan Cucchiara" Cc: , "Tim Hall" , "Thomas D. Nadeau" , "Edward Harrison" , "Cheenu Srinivasan" Subject: Re: MIBs for GMPLS Date: Fri, 14 Dec 2001 23:51:34 -0500 > > We considered several approaches to producing GMPLS MIBs and presented these in > > London (if the slides are not still on the Web site I can mail them to anyone > > interested). > > Which web site? IETF. I'll mail you under separate cover. > > The options were... > > 1. Recycle the existing MIBs > > 2. Add extensions to the existing MIBs as new tables and AUGMENTS > > 3. Completely rewrite the MIBs > > 4. Make version 2 MIBs [SNIP] > So the decision was for #4 Make Version 2 of the MIBs. > > Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ? > That is what is typically done. SNaFU. > Further, if these are supposed to eventuall replace documents in the > MPLS working group, then isn't it appropriate to let that be known? > I have seen no such postings to that working group. Replace may be too strong a word. Does the v1 MIB actually need to be retired? You're correct that we haven't posted widely on the these MIBs yet. They haven't existed long. I did send a note to the MPLS mailing list when we published the MIBs and invited the discussion to be joined on the ccamp list. It is a good idea to send a reminder - I will. > I do think this is probably a good way to go (although it was not > clear from anything that I've read that that was the intent > until you explained it here. Thanks for the explanation. Good, I'm glad you support the approach, > > > Also the Labels MIB is glumping everything into > > > a single table. Was the use of separate tables (similar > > > to what LDP did for ATM and FR specific objects) > > > considered? > > > > Good choice of word, "glumping". I confess that I was never a fan of the > > multiple table approach! > > > > >From an implementation point of view there is need be no impact (although I can > > conceive of implementations where this is not the case :-). The conformance > > statement (of course, should make it clear that implementations can support > > whatever set of label-types they like. Note that an important consideration is > > the type of labels reported from the network which may not match those supported > > locally. > > > > Hope this answers you. > > Not really. This is not an implementation issue, it is a MIB design > issue. I think it is sloppy (another highly technical term like > glumping ;) to have MIBs look like C union structures. Sorry to be > so terse, but I would *hope* the IETF would raise the bar on MIB > quality just a tad. You have no idea if the way the MIB is currently > written would be less difficult to implement for most folks. > In fact, I would argue just the opposite; based on my experience > a poorly designed MIB is far more difficult to implement because > it is difficult to understand and it becomes difficult to maintain and > scale over time as deprecations/extentions are needed. OK. Probably bringing implementation into it is not going to help us much. I have plenty of experience of MIB implementation and would not propose anything I considered hard to implement, but as you say that is not the issue. The issue is doing the correct MIB-like thing. You are suggesting a label table for each type of label. Presumably the referencing object still contains a simple index, and the table to index is deduced from the label type. Note that we did not want to use rowPointer because we wanted to facilitate non-use of the Label Table in 32 bit label systems by direct inclusion of the label (as in the current MIBs). We'll think about this a bit. Thanks, Adrian -- Adrian Farrel Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 15:36:03 -0800 From: "manoj juneja" To: lberger@movaz.com Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org Bcc: Subject: Re: Fwd: Comments on GMPLS signalling drafts Date: Fri, 14 Dec 2001 16:32:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Lou/Eric/Dimitri, Please see the following para from gmpls-architecture draft : "LSP modification consists in changing some LSP parameters, but normally without changing the route. It is supported using the same mechanism as re-routing. However, the semantic of LSP modification will differ from one technology to the other. For instance, further studies are required to understand the impact of dynamically changing some SDH/SONET circuit characteristics such as the bandwidth, the protection type, the transparency, the concatenation etc." If u say that SE style of reservation is supported then how are u going to share the bandwidth of SDH/SONET, Lambda or Fiber LSPs ? How can one assign diferent labels (labels are the physical resources on the link) to different senders that belong to the same RSVP session. Is it that the SE style of reservation only supported to modify the bandwidth of LSP ? Can I modify the bandwidth of LSC/FSC LSP ? If yes then how ? Do u people think that waveband section is compelte in the drafts ? Please see other comments inline. Regards, manoj. >From: Lou Berger >To: "manoj juneja" >CC: ,, > >Subject: Re: Fwd: Comments on GMPLS signalling drafts >Date: Fri, 14 Dec 2001 15:18:34 -0500 > >see comments inline. > >At 09:10 PM 12/13/2001, manoj juneja wrote: > > > >> >From: "manoj juneja" >> >To: ccamp@ops.ietf.org >> >Subject: Comments on GMPLS signalling drafts >> >Date: Tue, 11 Dec 2001 16:15:10 -0700 >> > >> >Hi All, >> > >> >1. SE-style supported by GMPLS or not ? >> > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > >>As labels are the resources on the link, one can't allocate different >> >label to different senders in the same RSVP session. >> > > >I don't think you fully understand SE. I suggest you read the base >documents. (2205 and RSVP-TE) > >> >> >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a >> >separate draft for TDM LSP bandwidth modification but what about the >> >bandwidth modification for other types of LSPs ? There is no mention of >> >these in any of the GMPLS drafts. >> > > >GMPLS doesn't modify this. See the appropriate base protocol docs. > >> >> >3. It should be mentioned clearly that waveband section is still not >> >complete in the drafts. >> > >> >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What >> >about the Component_If_Id_Downstream/Upstream TLV ? The revised >> >bundling draft has removed these 2 TLVs. What about the GMPLS signalling >> >drafts ? >> > > >It's still in, see the drafts for explanations. > [Manoj]: What I want to say is that Component_If_Id_Downstream and Upstream TLVs of IF_ID_RSVP_HOP object have been removed from the bundling draft. Do u still want to keep these TLVs in GMPLS drafts ? If yes then is there any reason for keeping these ? >> >5. STM-0 label representation using {SUKLM} should be mentioned in the >> >drafts (because it is a special case). >> > > >the sonet draft is the right place for this. I defer to Eric on this. > [Manoj]: Thanks for putting this info in the new version of the draft. >> >> >6. It should be mentioned that bandwidth encoding parameter is useful >> >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. >> > [Manoj]: I think u should include what all technologies will make use of this parameter. >> >7. There is an example scenario for contention resolution in case of bi- >> >directional LSPs. It should be mentioned that : >> > >> >"contention resolution is an optimization, not a correctness issue ... >> >and no procedure can provide optimal resolution in all cases. An >> >implementor >> >may do differently to provide better resolution." >> > >> >The above quotes are extracted from one of the mails from Fong Liaw. >> > >> >If this is the case then this should be mentioned in the drafts. >> > > >Read the Acknowledgments section of the draft. (I'm sure Fong will be >happy to see you protecting her interests!) > >> >> >8. The LSP hierarchy concept is still not clear. Some days back I posted >> >one >> >doubt related to tunneling of TDM LSP over Lambda LSP using the concept >>of >> >forwarding adjacency and different people replied with different >>thoughts. >> >Does this mean this concept is not standardized in GMPLS ? >> >My question was : >> > >> >"If there are 4 nodes say A, B, C and D. There is a Lambda FA >> >established from A to D and if a new TDM LSP request comes to node A >> >which is to be tunneled through the already established lambda FA-LSP >> >then the node A sends the Path/label request message directly to node >> >D. What label the node D will send back to node A in the RESV/label >> >mapping message since the FA-LSP is just one label (lambda) ? Does it >> >mean that all the LSPs which are tunneled through the lambda FA-LSP >> >will be allocated the same label by node D to node A ? If this type of >> >scenario can't exist in GMPLS then please let me know that too." > >I believe this topic is being covered in other threads. > >> > >> > >> >Regards, >> >manoj. >> > >> > >> > >> > >> >_________________________________________________________________ >> >Join the world s largest e-mail service with MSN Hotmail. >> >http://www.hotmail.com >> > >> > >> >>_________________________________________________________________ >>Get your FREE download of MSN Explorer at >>http://explorer.msn.com/intl.asp. > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 13:37:04 -0800 Message-ID: <20011214213321.23470.qmail@web14707.mail.yahoo.com> Date: Fri, 14 Dec 2001 13:33:21 -0800 (PST) From: Fong Liaw Subject: Re: Fwd: Comments on GMPLS signalling drafts To: Lou Berger , manoj juneja Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lou I am happy to see my interest protected, however I think manoj is asking to insert the "optimization vs. correctness" text into the draft. Right now, -07 text says a node with higher node id MUST send a PathErr etc. this does not allow for different behavior. I would suggest to change the text slightly as following: "To resolve contention, the node with the higher node ID will win the contention and it MUST issue a ^^^ resolve PathErr/NOTIFICATION message ^^^^^^^PathErr/Path/Notification with a "Routing problem/Label allocation failure" indication. " ^ for the LSP that loses in the resolution. We can also specify the default behavior is that "the LSP requested by a higher node id wins the resolution." Regards, -Fong > > > > > >7. There is an example scenario for contention > resolution in case of bi- > > >directional LSPs. It should be mentioned that : > > > > > >"contention resolution is an optimization, not a > correctness issue ... > > >and no procedure can provide optimal resolution > in all cases. An > > >implementor > > >may do differently to provide better resolution." > > > > > >The above quotes are extracted from one of the > mails from Fong Liaw. > > > > > >If this is the case then this should be mentioned > in the drafts. > > > > > Read the Acknowledgments section of the draft. (I'm > sure Fong will be > happy to see you protecting her interests!) > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 13:11:26 -0800 Message-ID: <3C1A6961.A07F75C2@crescentnetworks.com> Date: Fri, 14 Dec 2001 16:04:33 -0500 From: Joan Cucchiara Organization: Crescent Networks MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Tim Hall , "Thomas D. Nadeau" , Edward Harrison , Cheenu Srinivasan Subject: Re: MIBs for GMPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > > Hi Joan. > > > Why is there so much overlap between these > > MIBs and the MIBs in MPLS? > > > > It seems that the MPLS MIBs could be extended > > for GMPLS specific info and thus avoid so much > > overlap. Could you shed some light on this? > > Certainly. > We considered several approaches to producing GMPLS MIBs and presented these in > London (if the slides are not still on the Web site I can mail them to anyone > interested). Which web site? > > The options were... > 1. Recycle the existing MIBs > 2. Add extensions to the existing MIBs as new tables and AUGMENTS > 3. Completely rewrite the MIBs > 4. Make version 2 MIBs > > Now, the feeling (amongst the authors and the implementors that gave us > feedback) was that there were two prime objectives: > a. support 'classic' MPLS and GMPLS with the same set of MIBs > b. cause minimal disruption to people who have implemented the existing MIBs and > want to move forward to GMPLS. > > This ruled out option 3 (for which we were all hugely greatful!) > > Options 1 and 4 differ only in timing. When we looked at the timescales to > produce the GMPLS MIBs we realized that it was likely to take another few months > before the MIBs were close to being last-callable. On the other hand, the > existing MIBs are through WG last call and undergoing final markups for the > IESG. The demand for the existing MIBs to reach a stable form is immense and so > we decided to rule out option 1. > > This leaves option 2 or option 4. > > Although using augmentation seems attractive (it was my first attempt at doing > this work) when you push into the corners you find that it gets very messy. > This is not to say it isn't possible, but every table takes a hit. Other issues > were > - new values for existing fields > - the desirability of a change to indexing in the LSR MIB. > > It was decided that the solution we were most comfortable with was producing a > version 2 of the MIBs. This is sufficiently close to version 1 to be > - understandable by the same group of people > - easy to modify implementations to support version 2 (or both versions) > > We are, of course, open to persuasive discussion on this point > So the decision was for #4 Make Version 2 of the MIBs. Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ? That is what is typically done. Further, if these are supposed to eventuall replace documents in the MPLS working group, then isn't it appropriate to let that be known? I have seen no such postings to that working group. I do think this is probably a good way to go (although it was not clear from anything that I've read that that was the intent until you explained it here. Thanks for the explanation. > > Also the Labels MIB is glumping everything into > > a single table. Was the use of separate tables (similar > > to what LDP did for ATM and FR specific objects) > > considered? > > Good choice of word, "glumping". I confess that I was never a fan of the > multiple table approach! > > >From an implementation point of view there is need be no impact (although I can > conceive of implementations where this is not the case :-). The conformance > statement (of course, should make it clear that implementations can support > whatever set of label-types they like. Note that an important consideration is > the type of labels reported from the network which may not match those supported > locally. > > Hope this answers you. Not really. This is not an implementation issue, it is a MIB design issue. I think it is sloppy (another highly technical term like glumping ;) to have MIBs look like C union structures. Sorry to be so terse, but I would *hope* the IETF would raise the bar on MIB quality just a tad. You have no idea if the way the MIB is currently written would be less difficult to implement for most folks. In fact, I would argue just the opposite; based on my experience a poorly designed MIB is far more difficult to implement because it is difficult to understand and it becomes difficult to maintain and scale over time as deprecations/extentions are needed. thanks, Joan > > Regards, > Adrian > -- > Adrian Farrel > Movaz Networks Inc. > Tel: 703-847-1867 > afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 12:40:17 -0800 Message-ID: <3C1A6164.E89360@alcatel.be> Date: Fri, 14 Dec 2001 21:30:28 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Lou Berger CC: manoj juneja , Eric.Mannie@ebone.com, ccamp@ops.ietf.org Subject: Re: Fwd: Comments on GMPLS signalling drafts Content-Type: multipart/mixed; boundary="------------1B4A3768514DBCD2DA4CC857" This is a multi-part message in MIME format. --------------1B4A3768514DBCD2DA4CC857 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, > > >5. STM-0 label representation using {SUKLM} should be mentioned in the > > >drafts (because it is a special case). > > > > > the sonet draft is the right place for this. I defer to Eric on this. I refer Manoj to the latest versions of the Sonet/SDH I-Ds posted on the CCAMP mailing list on Thursday. Cheers, - dimitri. Lou Berger wrote: > > see comments inline. > > At 09:10 PM 12/13/2001, manoj juneja wrote: > > > >From: "manoj juneja" > > >To: ccamp@ops.ietf.org > > >Subject: Comments on GMPLS signalling drafts > > >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > > > >Hi All, > > > > > >1. SE-style supported by GMPLS or not ? > > > > > GMPLS doesn't modify this. See the appropriate base protocol docs. > > >As labels are the resources on the link, one can't allocate different > > >label to different senders in the same RSVP session. > > > > > I don't think you fully understand SE. I suggest you read the base > documents. (2205 and RSVP-TE) > > > > > >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > > >separate draft for TDM LSP bandwidth modification but what about the > > >bandwidth modification for other types of LSPs ? There is no mention of > > >these in any of the GMPLS drafts. > > > > > GMPLS doesn't modify this. See the appropriate base protocol docs. > > > > > >3. It should be mentioned clearly that waveband section is still not > > >complete in the drafts. > > > > > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What > > >about the Component_If_Id_Downstream/Upstream TLV ? The revised > > >bundling draft has removed these 2 TLVs. What about the GMPLS signalling > > >drafts ? > > > > > It's still in, see the drafts for explanations. > > > >5. STM-0 label representation using {SUKLM} should be mentioned in the > > >drafts (because it is a special case). > > > > > the sonet draft is the right place for this. I defer to Eric on this. > > > > > >6. It should be mentioned that bandwidth encoding parameter is useful > > >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > > > > >7. There is an example scenario for contention resolution in case of bi- > > >directional LSPs. It should be mentioned that : > > > > > >"contention resolution is an optimization, not a correctness issue ... > > >and no procedure can provide optimal resolution in all cases. An > > >implementor > > >may do differently to provide better resolution." > > > > > >The above quotes are extracted from one of the mails from Fong Liaw. > > > > > >If this is the case then this should be mentioned in the drafts. > > > > > Read the Acknowledgments section of the draft. (I'm sure Fong will be > happy to see you protecting her interests!) > > > > > >8. The LSP hierarchy concept is still not clear. Some days back I posted > > >one > > >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of > > >forwarding adjacency and different people replied with different thoughts. > > >Does this mean this concept is not standardized in GMPLS ? > > >My question was : > > > > > >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > > >established from A to D and if a new TDM LSP request comes to node A > > >which is to be tunneled through the already established lambda FA-LSP > > >then the node A sends the Path/label request message directly to node > > >D. What label the node D will send back to node A in the RESV/label > > >mapping message since the FA-LSP is just one label (lambda) ? Does it > > >mean that all the LSPs which are tunneled through the lambda FA-LSP > > >will be allocated the same label by node D to node A ? If this type of > > >scenario can't exist in GMPLS then please let me know that too." > > I believe this topic is being covered in other threads. > > > > > > > > > >Regards, > > >manoj. > > > > > > > > > > > > > > >_________________________________________________________________ > > >Join the world s largest e-mail service with MSN Hotmail. > > >http://www.hotmail.com > > > > > > > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp. --------------1B4A3768514DBCD2DA4CC857 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------1B4A3768514DBCD2DA4CC857-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 12:22:37 -0800 Message-Id: <4.3.2.7.2.20011214150549.02357f08@mo-ex1> Date: Fri, 14 Dec 2001 15:18:34 -0500 To: "manoj juneja" From: Lou Berger Subject: Re: Fwd: Comments on GMPLS signalling drafts Cc: ,, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed see comments inline. At 09:10 PM 12/13/2001, manoj juneja wrote: > >From: "manoj juneja" > >To: ccamp@ops.ietf.org > >Subject: Comments on GMPLS signalling drafts > >Date: Tue, 11 Dec 2001 16:15:10 -0700 > > > >Hi All, > > > >1. SE-style supported by GMPLS or not ? > > GMPLS doesn't modify this. See the appropriate base protocol docs. >As labels are the resources on the link, one can't allocate different > >label to different senders in the same RSVP session. > > I don't think you fully understand SE. I suggest you read the base documents. (2205 and RSVP-TE) > > >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a > >separate draft for TDM LSP bandwidth modification but what about the > >bandwidth modification for other types of LSPs ? There is no mention of > >these in any of the GMPLS drafts. > > GMPLS doesn't modify this. See the appropriate base protocol docs. > > >3. It should be mentioned clearly that waveband section is still not > >complete in the drafts. > > > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What > >about the Component_If_Id_Downstream/Upstream TLV ? The revised > >bundling draft has removed these 2 TLVs. What about the GMPLS signalling > >drafts ? > > It's still in, see the drafts for explanations. > >5. STM-0 label representation using {SUKLM} should be mentioned in the > >drafts (because it is a special case). > > the sonet draft is the right place for this. I defer to Eric on this. > > >6. It should be mentioned that bandwidth encoding parameter is useful > >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > > > >7. There is an example scenario for contention resolution in case of bi- > >directional LSPs. It should be mentioned that : > > > >"contention resolution is an optimization, not a correctness issue ... > >and no procedure can provide optimal resolution in all cases. An > >implementor > >may do differently to provide better resolution." > > > >The above quotes are extracted from one of the mails from Fong Liaw. > > > >If this is the case then this should be mentioned in the drafts. > > Read the Acknowledgments section of the draft. (I'm sure Fong will be happy to see you protecting her interests!) > > >8. The LSP hierarchy concept is still not clear. Some days back I posted > >one > >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of > >forwarding adjacency and different people replied with different thoughts. > >Does this mean this concept is not standardized in GMPLS ? > >My question was : > > > >"If there are 4 nodes say A, B, C and D. There is a Lambda FA > >established from A to D and if a new TDM LSP request comes to node A > >which is to be tunneled through the already established lambda FA-LSP > >then the node A sends the Path/label request message directly to node > >D. What label the node D will send back to node A in the RESV/label > >mapping message since the FA-LSP is just one label (lambda) ? Does it > >mean that all the LSPs which are tunneled through the lambda FA-LSP > >will be allocated the same label by node D to node A ? If this type of > >scenario can't exist in GMPLS then please let me know that too." I believe this topic is being covered in other threads. > > > > > >Regards, > >manoj. > > > > > > > > > >_________________________________________________________________ > >Join the world s largest e-mail service with MSN Hotmail. > >http://www.hotmail.com > > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 10:44:44 -0800 Message-ID: <008101c184ce$f48d60c0$681810ac@movaz.com> From: "Adrian Farrel" To: "Joan Cucchiara" Cc: , "Tim Hall" , "Thomas D. Nadeau" , "Edward Harrison" , "Cheenu Srinivasan" Subject: Re: MIBs for GMPLS Date: Fri, 14 Dec 2001 13:41:33 -0500 Hi Joan. > Why is there so much overlap between these > MIBs and the MIBs in MPLS? > > It seems that the MPLS MIBs could be extended > for GMPLS specific info and thus avoid so much > overlap. Could you shed some light on this? Certainly. We considered several approaches to producing GMPLS MIBs and presented these in London (if the slides are not still on the Web site I can mail them to anyone interested). The options were... 1. Recycle the existing MIBs 2. Add extensions to the existing MIBs as new tables and AUGMENTS 3. Completely rewrite the MIBs 4. Make version 2 MIBs Now, the feeling (amongst the authors and the implementors that gave us feedback) was that there were two prime objectives: a. support 'classic' MPLS and GMPLS with the same set of MIBs b. cause minimal disruption to people who have implemented the existing MIBs and want to move forward to GMPLS. This ruled out option 3 (for which we were all hugely greatful!) Options 1 and 4 differ only in timing. When we looked at the timescales to produce the GMPLS MIBs we realized that it was likely to take another few months before the MIBs were close to being last-callable. On the other hand, the existing MIBs are through WG last call and undergoing final markups for the IESG. The demand for the existing MIBs to reach a stable form is immense and so we decided to rule out option 1. This leaves option 2 or option 4. Although using augmentation seems attractive (it was my first attempt at doing this work) when you push into the corners you find that it gets very messy. This is not to say it isn't possible, but every table takes a hit. Other issues were - new values for existing fields - the desirability of a change to indexing in the LSR MIB. It was decided that the solution we were most comfortable with was producing a version 2 of the MIBs. This is sufficiently close to version 1 to be - understandable by the same group of people - easy to modify implementations to support version 2 (or both versions) We are, of course, open to persuasive discussion on this point > Also the Labels MIB is glumping everything into > a single table. Was the use of separate tables (similar > to what LDP did for ATM and FR specific objects) > considered? Good choice of word, "glumping". I confess that I was never a fan of the multiple table approach! >From an implementation point of view there is need be no impact (although I can conceive of implementations where this is not the case :-). The conformance statement (of course, should make it clear that implementations can support whatever set of label-types they like. Note that an important consideration is the type of labels reported from the network which may not match those supported locally. Hope this answers you. Regards, Adrian -- Adrian Farrel Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2001 07:04:31 -0800 Message-ID: <3C1A1463.3DB8DE2B@crescentnetworks.com> Date: Fri, 14 Dec 2001 10:01:55 -0500 From: Joan Cucchiara Organization: Crescent Networks MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Tim Hall , "Thomas D. Nadeau" , Edward Harrison , Cheenu Srinivasan Subject: Re: MIBs for GMPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Adrian, Why is there so much overlap between these MIBs and the MIBs in MPLS? It seems that the MPLS MIBs could be extended for GMPLS specific info and thus avoid so much overlap. Could you shed some light on this? Also the Labels MIB is glumping everything into a single table. Was the use of separate tables (similar to what LDP did for ATM and FR specific objects) considered? Thanks, Joan > Adrian Farrel wrote: > > At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS > that we have produced. > > Kireeti asked that we take the MIBs to the list to ensure that the big > issues have been addressed, that everyone is comfortable with the > approach and there really is a need for the MIBs. > > Requirements are handled by... > > - protocols within the IETF need MIBs, further > draft-ietf-ccamp-gmpls-architecture-01.txt > explicitly requires MIBs for GMPLS > > The biggest issue outstanding was whether the Labels MIB should be > included within the LSR MIB. The authors currently feel that it > should remain as a separate MIB > > - to allow people to implement only the TE MIB > without putting complex conformance statements > in the LSR MIB > - to allow people to clearly not implement the > Labels MIB at all. > We would welcome input on this. > > > Please take this opportunity to give us your input and help shape the > MIBs. > > We hope to respin the drafts in a compilable form in the next few > days. > > > The MIBs are... > > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00.txt > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib-00.txt > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00.txt > http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-00.txt > > > Regards, > Adrian > > -- > Adrian Farrel > Movaz Networks Inc. > Tel: 703-847-1867 > afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 18:13:08 -0800 From: "manoj juneja" To: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Bcc: Subject: Fwd: Comments on GMPLS signalling drafts Date: Thu, 13 Dec 2001 19:10:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: >From: "manoj juneja" >To: ccamp@ops.ietf.org >Subject: Comments on GMPLS signalling drafts >Date: Tue, 11 Dec 2001 16:15:10 -0700 > >Hi All, > >1. SE-style supported by GMPLS or not ? >As labels are the resources on the link, one can't allocate different >label to different senders in the same RSVP session. > >2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a >separate draft for TDM LSP bandwidth modification but what about the >bandwidth modification for other types of LSPs ? There is no mention of >these in any of the GMPLS drafts. > >3. It should be mentioned clearly that waveband section is still not >complete in the drafts. > >4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What >about the Component_If_Id_Downstream/Upstream TLV ? The revised >bundling draft has removed these 2 TLVs. What about the GMPLS signalling >drafts ? > >5. STM-0 label representation using {SUKLM} should be mentioned in the >drafts (because it is a special case). > >6. It should be mentioned that bandwidth encoding parameter is useful >for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. > >7. There is an example scenario for contention resolution in case of bi- >directional LSPs. It should be mentioned that : > >"contention resolution is an optimization, not a correctness issue ... >and no procedure can provide optimal resolution in all cases. An >implementor >may do differently to provide better resolution." > >The above quotes are extracted from one of the mails from Fong Liaw. > >If this is the case then this should be mentioned in the drafts. > >8. The LSP hierarchy concept is still not clear. Some days back I posted >one >doubt related to tunneling of TDM LSP over Lambda LSP using the concept of >forwarding adjacency and different people replied with different thoughts. >Does this mean this concept is not standardized in GMPLS ? >My question was : > >"If there are 4 nodes say A, B, C and D. There is a Lambda FA >established from A to D and if a new TDM LSP request comes to node A >which is to be tunneled through the already established lambda FA-LSP >then the node A sends the Path/label request message directly to node >D. What label the node D will send back to node A in the RESV/label >mapping message since the FA-LSP is just one label (lambda) ? Does it >mean that all the LSPs which are tunneled through the lambda FA-LSP >will be allocated the same label by node D to node A ? If this type of >scenario can't exist in GMPLS then please let me know that too." > > >Regards, >manoj. > > > > >_________________________________________________________________ >Join the world’s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 18:09:58 -0800 From: "manoj juneja" To: jingrq@sohu.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: ´ð¸´: Lambda LSP establishment Date: Thu, 13 Dec 2001 19:09:20 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Rick, What happens if the node or interface supports multiple switching/multiplexing capabilities ? >From: "rick king" >To: "manoj juneja" >CC: >Subject: ´ð¸´: Lambda LSP establishment >Date: Fri, 14 Dec 2001 09:54:51 +0800 > >I think the multiplexing capabilities of the FA is decided by the >multiplexing/switching capabilities >of the two LSRs connected by this FA. right? > >rick >---------------------------------------------------------- >·¢ËÍʱ¼ä: 2001Äê12ÔÂ14ÈÕ 2:45 >ÊÕ¼þÈË: Eric.Mannie@ebone.com; Juergen.Heiles@icn.siemens.de; >jdrake@calient.net; mvissers@lucent.com. >³­ËÍ: ccamp@ops.ietf.org >Ö÷Ìâ: RE: Lambda LSP establishment > > >Hi Eric, > I fully support ur idea of having an informational draft >explaining different scenarios of SDH/SONET LSP establishment. The >concept of hierarchy is clear in case of SDH/SONET. What about the LSC >or FSC interfaces ? >2-3 days back john responded to my question on lambda hierarchy that a >lambda LSP can be advertised as a FA with different switching type (say >TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am >interested in knowing the list of such scenarios in case of LSC or FSC >LSP advertised as a FA and its different combinations of switching >capabilities as these things are not expalined anywhere. >When a head or tail end of LSP advertises it as a FA then how the >multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of >the FA are decided ? > >Regards, >manoj. > > >From: "Mannie, Eric" > >To: 'Heiles Juergen ' , ''John Drake' ' > >, 'Maarten Vissers ' , 'manoj > >juneja ' > >CC: "'ccamp@ops.ietf.org '" > >Subject: RE: Lambda LSP establishment > >Date: Thu, 13 Dec 2001 18:56:31 +0100 > > > >Hi All, > > > >A few comments, > > > > >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer > >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, >OTS). > >A > >FA basically corresponds to a real trail in a circuit switched network. > > > >Eric: ...and this trail is setup dynamically using GMPLS. That's the > >interest. One can think of SDH/SONET FAs as shortcuts or express-routes. > > > > >One special thing about the SDH label is, that it includes a hierarchy >as > >it identifies the lower order VC in a higher order VC in a STM-N signal. > >Note that this is somehow in contradiction with a statement in the GMPLS > >signaling document which says > > > > >"A Generalized Label only carries a single level of label, i.e., it is > > non-hierarchical. When multiple levels of label (LSPs within LSPs) > > are required, each LSP must be established separately, see [MPLS- > > HIERARCHY]." > > > >No, hierarchy of labels is not hierarchy of layers. And even one should > >have > >a common definition of what means a "layer". This text says that we >cannot > >have multiple embedded labels, e.g. one label containting a label stack. > >This is a signaling stuff that doesn't imply anything on the transport > >plane. > > > >Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO > >in > >SDH. The label can be fully specified or partially specified, depending >on > >the context where the LSP is established. > > > >E.g. when an LSP is established over a FA, the highest part of the LSP > >label > >is not relevant. When the FA LSP is established the lowest part of the FA > >LSP label is not relevant. > > > >If a low order LSP is established without any higher order FA, the label >is > >fully specified. As you said the link is indeed the "ultimate FA" in that > >case. Except that from the routing point of view a link and an FA are two > >different things. There is a routing adjacency "over" a link but not over >a > >FA. > > > >The SDH/SONET label just includes what you need to include in each > >scenario. > > > >Moreover, the label MUST be interpreted according to the type of >interface > >for which it is used. It is possible to code two labels having the same > >value but a complete different meaning. Labels are context sensitive of > >course. > > > >For instance, an LSP over an STM-0 interface or over a FA will have the > >highest part set to zero, and could possibly have the same lowest part. >You > >cannot understand what means the label without knowning the detail of the > >interface. In that case, the interface is either an STM-0 interface or a > >VC-3 FA. And of course that FA and STM-0 interface are two different > >things, > >but from the LSP point of view, in both cases what it wants is a VC-3 in > >which it can be multiplexed. > > > >Hope this helps. > > > >I start to wonder if we should have an informational draft describing > >different scenarios of SDH/SONET LSP establishment. That could complement > >the SDH/SONET signaling drafts and the GMPLS architecture. That could >solve > >many terminology and modeling issues. > > > >Kind regards, > > > >Eric > > > >-----Original Message----- > >From: Heiles Juergen > >To: 'John Drake'; Maarten Vissers; manoj juneja > >Cc: ccamp@ops.ietf.org > >Sent: 12/13/01 11:15 AM > >Subject: RE: Lambda LSP establishment > > > >Let me express my understanding of FAs in MPLS/GMPLS, please correct me > >if I am wrong. I have also some questions related to the label > >generation and interactions between layer networks. > > > >The label in MPLS is local to the link between two adjacent MPLS > >switches, it indicates a LSP in this link. This link is therefore the > >ultimate FA. An already established LSP between two MPLS switches, which > >don't have to be adjacent, can be used to transport/tunnel other LSPs > >between this two nodes. This already established LSP generates a virtual > >adjacency between the two nodes, the FA. As several LSPs can use this FA > >it is also a kind of virtual multiplexing. > >If you compare it with a circuit switched network the FA is a server > >layer trail that provides transport (a link connection) for one or more > >client layer signals. > >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer > >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, > >OTS). A FA basically corresponds to a real trail in a circuit switched > >network. > >In GMPLS the label is also local to the link between the two devices > >that perform the switching. For example for SDH the VC-N is identified > >by the STM-N link/port and the SUKLM number according to > >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by > >the interface ID (I am not sure on this) and SUKLM is the SDH label that > >locates the VC within the STM-N. > >From just the SDH viewpoint the STM-N connection is the ultimate server > >trail/FA. However the STM-N signal could be transported over a Optical > >Channel or G.709 ODU. The OCh or ODU can already start in the equipment > >that performs the VC-N switching. So the STM-N signal is not the port, > >but the WDM signal is the port and the STM-N signal makes use of a OCh > >or ODU server layer trail. This server layer trail can be established > >via management or using GMPLS. > >Can someone explain how a label for a VC-4 is generated in this case > >(pre-established OCh or ODU trail via management or setup using GMPLS). > >This interaction between the different technologies/labels need in my > >view some further explanation. > > > >One special thing about the SDH label is, that it includes a hierarchy > >as it identifies the lower order VC in a higher order VC in a STM-N > >signal. Note that this is somehow in contradiction with a statement in > >the GMPLS signaling document which says > >"A Generalized Label only carries a single level of label, i.e., it is > > non-hierarchical. When multiple levels of label (LSPs within LSPs) > > are required, each LSP must be established separately, see [MPLS- > > HIERARCHY]." > >Following this statement each layer should have its own label > >independent of server layers. > >The combination of hierarchies in labels is based on technology (e.g. > >SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The > >SDH label for example fits to standard STM-N signals, but not to sub-STM > >signals. > >For the SDH the full SUKLM number is used if a e.g. VC-12 is located in > >relation to a STM-N interface. If it is located in relation to a VC-4 > >(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear > >in which case I use the first and in which case I use the second case as > >a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be > >established using management or GMPLS. However it should have no > >influence on the label. > >Some more information is needed in my view in this area. > > > > > >Juergen > > > > > > > -----Original Message----- > > > From: John Drake [mailto:jdrake@calient.net] > > > Sent: Wednesday, December 12, 2001 6:54 AM > > > To: Maarten Vissers; manoj juneja > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: Lambda LSP establishment > > > > > > > > > fortunately, this is just your opinion > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Tuesday, December 11, 2001 9:31 PM > > > To: manoj juneja > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Lambda LSP establishment > > > > > > > > > Manoj, > > > > > > Forget the FA stuff, it is not appropriate in circuit > > > networks. It only > > > applies > > > to MPLS. We should remove it when it is used in relation with PDH, > > > SDH/SONET, > > > OTN and pre-OTN. The text in sdh-sonet draft should state > > > that if there is a > > > LOVC link (IETF: link bundle/TE link) then the LOVC signals > > > use a label with > > > "00KLM". > > > > > > Regards, > > > > > > Maarten > > > > > > manoj juneja wrote: > > > > > > > > Hi Marteen, > > > > The concept of FA is mentioned for SDH/SONET in > > > gmpls-sdh > > > > -sonet draft. It says that if u have a HOVC trail as a FA > > > (advertized > > > > as a link) then u can allocate the lower level signals in > > > it by making > > > > the higher bits of label as 0s (i.e. S and U}. This is fine > > > for the same > > > > technology. What about the case where the TDM LSP has to be tunneled > > > through > > > > the Lambda LSP ? What will be the form of label (i.e. > > > {SUKLM} or lambda > > > > etc.) ? > > > > > > > > Regards, > > > > manoj. > > > > > > > > >From: Maarten Vissers > > > > >To: manoj juneja > > > > >CC: ccamp@ops.ietf.org > > > > >Subject: Re: Lambda LSP establishment > > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > > > > > >Manoj, > > > > > > > > > >You refer to one wavelength to be available between A-E without > > > wavelength > > > > >conversion capability. This suggests that you operate at > > > the OCh layer > > > > >network. > > > > >Then you specify the capacity of the 4 OCh link > > > connections (A-B, B-C, > > > C-D, > > > > >D-E) > > > > >to be "C". Say that C is about 10 Gbit/s. You then assume > > > that there is a > > > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > > > Gbit/s) between C > > > and > > > > >E. > > > > >The result is that the OCh link connections C-D and D-E > > > are transporting > > > > >the OCh > > > > >signal (of e.g. 2.5G). These OCh link connections are now > > > in service and > > > > >not > > > > >longer available to an other OCh connection request. I.e. > > > a request for > > > an > > > > >OCh > > > > >connection between A and E will be rejected. > > > > > > > > > >FAs are not applicable in the circuit layers. IF there is > > > a trail in > > > server > > > > >layer X, then there is a link in its client layer Y. X and > > > Y are thus > > > > >different > > > > >layer networks and signals. > > > > > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > > > be an OCh trail > > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > > > connection. > > > > > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > > > network. Such is > > > not > > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > > > > > >Regards, > > > > > > > > > >Maarten > > > > > > > > > >OCh link connections > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > Hi All, > > > > > > If I have 5 nodes A, B, C, D and E connected as > > > shown. Assume > > > > > > that only one wavelength is available on the path A to E (no > > > wavelength > > > > > > conversion capability is there on the complete path). > > > Let the capacity > > > > > > of the wavelength be C. Further assume a request arrives for > > > connection > > > > > > from node C to E for a line capacity of C/4. This > > > request will be > > > > > > successful as we have available wavelength. Now If > > > another request > > > > > > comes at node A to establish another connection from > > > node A to node E > > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > > > Should this request > > > > > > be successful as we have already allocated the wavelength ? > > > > > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > > > > > If the previous connection from C to E of capacity C/4 > > > had not been > > > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > > > > > Regards, > > > > > > manoj. > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at > > > > >http://explorer.msn.com/intl.asp > > > > ><< mvissers.vcf >> > > > > > > > > _________________________________________________________________ > > > > Send and receive Hotmail on your mobile device: > >http://mobile.msn.com > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 17:57:06 -0800 From: "rick king" To: "manoj juneja" Cc: Subject: =?gb2312?B?tPC4tDogTGFtYmRhIExTUCBlc3RhYmxpc2htZW50?= Date: Fri, 14 Dec 2001 09:54:51 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgbXVsdGlwbGV4aW5nIGNhcGFiaWxpdGllcyBvZiB0aGUgRkEgaXMgZGVjaWRl ZCAgYnkgdGhlIG11bHRpcGxleGluZy9zd2l0Y2hpbmcgY2FwYWJpbGl0aWVzDQpvZiB0aGUgdHdv IExTUnMgY29ubmVjdGVkIGJ5IHRoaXMgRkEuIHJpZ2h0Pw0KDQpyaWNrDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQq3osvNyrG85Dog MjAwMcTqMTLUwjE0yNUgMjo0NQ0KytW8/sjLOiBFcmljLk1hbm5pZUBlYm9uZS5jb207IEp1ZXJn ZW4uSGVpbGVzQGljbi5zaWVtZW5zLmRlOw0KamRyYWtlQGNhbGllbnQubmV0OyBtdmlzc2Vyc0Bs dWNlbnQuY29tLg0Ks63LzTogY2NhbXBAb3BzLmlldGYub3JnDQrW98ziOiBSRTogTGFtYmRhIExT UCBlc3RhYmxpc2htZW50DQoNCg0KSGkgRXJpYywNCiAgICAgICAgICBJIGZ1bGx5IHN1cHBvcnQg dXIgaWRlYSBvZiBoYXZpbmcgYW4gaW5mb3JtYXRpb25hbCBkcmFmdA0KZXhwbGFpbmluZyBkaWZm ZXJlbnQgc2NlbmFyaW9zIG9mIFNESC9TT05FVCBMU1AgZXN0YWJsaXNobWVudC4gVGhlDQpjb25j ZXB0IG9mIGhpZXJhcmNoeSBpcyBjbGVhciBpbiBjYXNlIG9mIFNESC9TT05FVC4gV2hhdCBhYm91 dCB0aGUgTFNDDQpvciBGU0MgaW50ZXJmYWNlcyA/DQoyLTMgZGF5cyBiYWNrIGpvaG4gcmVzcG9u ZGVkIHRvIG15IHF1ZXN0aW9uIG9uIGxhbWJkYSBoaWVyYXJjaHkgdGhhdCBhDQpsYW1iZGEgTFNQ IGNhbiBiZSBhZHZlcnRpc2VkIGFzIGEgRkEgd2l0aCBkaWZmZXJlbnQgc3dpdGNoaW5nIHR5cGUg KHNheQ0KVERNKSBhbmQgdGhlbiBhIFRETSBMU1AgY2FuIGJlIHR1bm5lbGVkIG92ZXIgYSBsYW1i ZGEgTFNQLiBJIGFtDQppbnRlcmVzdGVkIGluIGtub3dpbmcgdGhlIGxpc3Qgb2Ygc3VjaCBzY2Vu YXJpb3MgaW4gY2FzZSBvZiBMU0Mgb3IgRlNDDQpMU1AgYWR2ZXJ0aXNlZCBhcyBhIEZBIGFuZCBp dHMgZGlmZmVyZW50IGNvbWJpbmF0aW9ucyBvZiBzd2l0Y2hpbmcNCmNhcGFiaWxpdGllcyBhcyB0 aGVzZSB0aGluZ3MgYXJlIG5vdCBleHBhbGluZWQgYW55d2hlcmUuDQpXaGVuIGEgaGVhZCBvciB0 YWlsIGVuZCBvZiBMU1AgYWR2ZXJ0aXNlcyBpdCBhcyBhIEZBIHRoZW4gaG93IHRoZQ0KbXVsdGlw bGV4aW5nIGNhcGFiaWxpdGllcyAobGlrZSBjYW4gc3dpdGNoIFZDLTQgYnV0IG5vdCBWQy0zIGV0 Yy4pIG9mDQp0aGUgRkEgYXJlIGRlY2lkZWQgPw0KDQpSZWdhcmRzLA0KbWFub2ouDQoNCj5Gcm9t OiAiTWFubmllLCBFcmljIiA8RXJpYy5NYW5uaWVAZWJvbmUuY29tPg0KPlRvOiAnSGVpbGVzIEp1 ZXJnZW4gJyA8SnVlcmdlbi5IZWlsZXNAaWNuLnNpZW1lbnMuZGU+LCAnJ0pvaG4gRHJha2UnICcg IA0KPjxqZHJha2VAY2FsaWVudC5uZXQ+LCAnTWFhcnRlbiBWaXNzZXJzICcgPG12aXNzZXJzQGx1 Y2VudC5jb20+LCAnbWFub2ogDQo+anVuZWphICcgPG1hbm9qa3VtYXJqdW5lamFAaG90bWFpbC5j b20+DQo+Q0M6ICInY2NhbXBAb3BzLmlldGYub3JnICciIDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQo+ U3ViamVjdDogUkU6IExhbWJkYSBMU1AgZXN0YWJsaXNobWVudA0KPkRhdGU6IFRodSwgMTMgRGVj IDIwMDEgMTg6NTY6MzEgKzAxMDANCj4NCj5IaSBBbGwsDQo+DQo+QSBmZXcgY29tbWVudHMsDQo+ DQo+ID5JbiBNUExTIHRoZSBGQSBlc3RhYmxpc2hlcyAidmlydHVhbCIgbGF5ZXIgbmV0d29ya3Mu IEluIEdNUExTIHRoZSBsYXllcg0KPm5ldHdvcmtzIGFscmVhZHkgZXhpc3QgKFNESCBITy9MTy1W Q3MsIFJTLCBNUywgRy43MDkgT0RVcywgT0NoLCBPTVMsIE9UUykuIA0KPkENCj5GQSBiYXNpY2Fs bHkgY29ycmVzcG9uZHMgdG8gYSByZWFsIHRyYWlsIGluIGEgY2lyY3VpdCBzd2l0Y2hlZCBuZXR3 b3JrLg0KPg0KPkVyaWM6IC4uLmFuZCB0aGlzIHRyYWlsIGlzIHNldHVwIGR5bmFtaWNhbGx5IHVz aW5nIEdNUExTLiBUaGF0J3MgdGhlDQo+aW50ZXJlc3QuIE9uZSBjYW4gdGhpbmsgb2YgU0RIL1NP TkVUIEZBcyBhcyBzaG9ydGN1dHMgb3IgZXhwcmVzcy1yb3V0ZXMuDQo+DQo+ID5PbmUgc3BlY2lh bCB0aGluZyBhYm91dCB0aGUgU0RIIGxhYmVsIGlzLCB0aGF0IGl0IGluY2x1ZGVzIGEgaGllcmFy Y2h5IGFzDQo+aXQgaWRlbnRpZmllcyB0aGUgbG93ZXIgb3JkZXIgVkMgaW4gYSBoaWdoZXIgb3Jk ZXIgVkMgaW4gYSBTVE0tTiBzaWduYWwuDQo+Tm90ZSB0aGF0IHRoaXMgaXMgc29tZWhvdyBpbiBj b250cmFkaWN0aW9uIHdpdGggYSBzdGF0ZW1lbnQgaW4gdGhlIEdNUExTDQo+c2lnbmFsaW5nIGRv Y3VtZW50IHdoaWNoIHNheXMNCj4NCj4gPiJBIEdlbmVyYWxpemVkIExhYmVsIG9ubHkgY2Fycmll cyBhIHNpbmdsZSBsZXZlbCBvZiBsYWJlbCwgaS5lLiwgaXQgaXMNCj4gICAgbm9uLWhpZXJhcmNo aWNhbC4gIFdoZW4gbXVsdGlwbGUgbGV2ZWxzIG9mIGxhYmVsIChMU1BzIHdpdGhpbiBMU1BzKQ0K PiAgICBhcmUgcmVxdWlyZWQsIGVhY2ggTFNQIG11c3QgYmUgZXN0YWJsaXNoZWQgc2VwYXJhdGVs eSwgc2VlIFtNUExTLQ0KPiAgICBISUVSQVJDSFldLiINCj4NCj5ObywgaGllcmFyY2h5IG9mIGxh YmVscyBpcyBub3QgaGllcmFyY2h5IG9mIGxheWVycy4gQW5kIGV2ZW4gb25lIHNob3VsZCANCj5o YXZlDQo+YSBjb21tb24gZGVmaW5pdGlvbiBvZiB3aGF0IG1lYW5zIGEgImxheWVyIi4gVGhpcyB0 ZXh0IHNheXMgdGhhdCB3ZSBjYW5ub3QNCj5oYXZlIG11bHRpcGxlIGVtYmVkZGVkIGxhYmVscywg ZS5nLiBvbmUgbGFiZWwgY29udGFpbnRpbmcgYSBsYWJlbCBzdGFjay4NCj5UaGlzIGlzIGEgc2ln bmFsaW5nIHN0dWZmIHRoYXQgZG9lc24ndCBpbXBseSBhbnl0aGluZyBvbiB0aGUgdHJhbnNwb3J0 DQo+cGxhbmUuDQo+DQo+Tm93LCBhIGxhYmVsIGlkZW50aWZpZXMgT05FIExTUCBhdCBhbiBpbnRl cmZhY2UuIFRoaXMgTFNQIGNhbiBiZSBITyBvciBMTyANCj5pbg0KPlNESC4gVGhlIGxhYmVsIGNh biBiZSBmdWxseSBzcGVjaWZpZWQgb3IgcGFydGlhbGx5IHNwZWNpZmllZCwgZGVwZW5kaW5nIG9u DQo+dGhlIGNvbnRleHQgd2hlcmUgdGhlIExTUCBpcyBlc3RhYmxpc2hlZC4NCj4NCj5FLmcuIHdo ZW4gYW4gTFNQIGlzIGVzdGFibGlzaGVkIG92ZXIgYSBGQSwgdGhlIGhpZ2hlc3QgcGFydCBvZiB0 aGUgTFNQIA0KPmxhYmVsDQo+aXMgbm90IHJlbGV2YW50LiBXaGVuIHRoZSBGQSBMU1AgaXMgZXN0 YWJsaXNoZWQgdGhlIGxvd2VzdCBwYXJ0IG9mIHRoZSBGQQ0KPkxTUCBsYWJlbCBpcyBub3QgcmVs ZXZhbnQuDQo+DQo+SWYgYSBsb3cgb3JkZXIgTFNQIGlzIGVzdGFibGlzaGVkIHdpdGhvdXQgYW55 IGhpZ2hlciBvcmRlciBGQSwgdGhlIGxhYmVsIGlzDQo+ZnVsbHkgc3BlY2lmaWVkLiBBcyB5b3Ug c2FpZCB0aGUgbGluayBpcyBpbmRlZWQgdGhlICJ1bHRpbWF0ZSBGQSIgaW4gdGhhdA0KPmNhc2Uu IEV4Y2VwdCB0aGF0IGZyb20gdGhlIHJvdXRpbmcgcG9pbnQgb2YgdmlldyBhIGxpbmsgYW5kIGFu IEZBIGFyZSB0d28NCj5kaWZmZXJlbnQgdGhpbmdzLiBUaGVyZSBpcyBhIHJvdXRpbmcgYWRqYWNl bmN5ICJvdmVyIiBhIGxpbmsgYnV0IG5vdCBvdmVyIGENCj5GQS4NCj4NCj5UaGUgU0RIL1NPTkVU IGxhYmVsIGp1c3QgaW5jbHVkZXMgd2hhdCB5b3UgbmVlZCB0byBpbmNsdWRlIGluIGVhY2ggDQo+ c2NlbmFyaW8uDQo+DQo+TW9yZW92ZXIsIHRoZSBsYWJlbCBNVVNUIGJlIGludGVycHJldGVkIGFj Y29yZGluZyB0byB0aGUgdHlwZSBvZiBpbnRlcmZhY2UNCj5mb3Igd2hpY2ggaXQgaXMgdXNlZC4g SXQgaXMgcG9zc2libGUgdG8gY29kZSB0d28gbGFiZWxzIGhhdmluZyB0aGUgc2FtZQ0KPnZhbHVl IGJ1dCBhIGNvbXBsZXRlIGRpZmZlcmVudCBtZWFuaW5nLiBMYWJlbHMgYXJlIGNvbnRleHQgc2Vu c2l0aXZlIG9mDQo+Y291cnNlLg0KPg0KPkZvciBpbnN0YW5jZSwgYW4gTFNQIG92ZXIgYW4gU1RN LTAgaW50ZXJmYWNlIG9yIG92ZXIgYSBGQSB3aWxsIGhhdmUgdGhlDQo+aGlnaGVzdCBwYXJ0IHNl dCB0byB6ZXJvLCBhbmQgY291bGQgcG9zc2libHkgaGF2ZSB0aGUgc2FtZSBsb3dlc3QgcGFydC4g WW91DQo+Y2Fubm90IHVuZGVyc3RhbmQgd2hhdCBtZWFucyB0aGUgbGFiZWwgd2l0aG91dCBrbm93 bmluZyB0aGUgZGV0YWlsIG9mIHRoZQ0KPmludGVyZmFjZS4gSW4gdGhhdCBjYXNlLCB0aGUgaW50 ZXJmYWNlIGlzIGVpdGhlciBhbiBTVE0tMCBpbnRlcmZhY2Ugb3IgYQ0KPlZDLTMgRkEuIEFuZCBv ZiBjb3Vyc2UgdGhhdCBGQSBhbmQgU1RNLTAgaW50ZXJmYWNlIGFyZSB0d28gZGlmZmVyZW50IA0K PnRoaW5ncywNCj5idXQgZnJvbSB0aGUgTFNQIHBvaW50IG9mIHZpZXcsIGluIGJvdGggY2FzZXMg d2hhdCBpdCB3YW50cyBpcyBhIFZDLTMgaW4NCj53aGljaCBpdCBjYW4gYmUgbXVsdGlwbGV4ZWQu DQo+DQo+SG9wZSB0aGlzIGhlbHBzLg0KPg0KPkkgc3RhcnQgdG8gd29uZGVyIGlmIHdlIHNob3Vs ZCBoYXZlIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgZGVzY3JpYmluZw0KPmRpZmZlcmVudCBzY2Vu YXJpb3Mgb2YgU0RIL1NPTkVUIExTUCBlc3RhYmxpc2htZW50LiBUaGF0IGNvdWxkIGNvbXBsZW1l bnQNCj50aGUgU0RIL1NPTkVUIHNpZ25hbGluZyBkcmFmdHMgYW5kIHRoZSBHTVBMUyBhcmNoaXRl Y3R1cmUuIFRoYXQgY291bGQgc29sdmUNCj5tYW55IHRlcm1pbm9sb2d5IGFuZCBtb2RlbGluZyBp c3N1ZXMuDQo+DQo+S2luZCByZWdhcmRzLA0KPg0KPkVyaWMNCj4NCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IEhlaWxlcyBKdWVyZ2VuDQo+VG86ICdKb2huIERyYWtlJzsgTWFh cnRlbiBWaXNzZXJzOyBtYW5vaiBqdW5lamENCj5DYzogY2NhbXBAb3BzLmlldGYub3JnDQo+U2Vu dDogMTIvMTMvMDEgMTE6MTUgQU0NCj5TdWJqZWN0OiBSRTogTGFtYmRhIExTUCBlc3RhYmxpc2ht ZW50DQo+DQo+TGV0IG1lIGV4cHJlc3MgbXkgdW5kZXJzdGFuZGluZyBvZiBGQXMgaW4gTVBMUy9H TVBMUywgcGxlYXNlIGNvcnJlY3QgbWUNCj5pZiBJIGFtIHdyb25nLiBJIGhhdmUgYWxzbyBzb21l IHF1ZXN0aW9ucyByZWxhdGVkIHRvIHRoZSBsYWJlbA0KPmdlbmVyYXRpb24gYW5kIGludGVyYWN0 aW9ucyBiZXR3ZWVuIGxheWVyIG5ldHdvcmtzLg0KPg0KPlRoZSBsYWJlbCBpbiBNUExTIGlzIGxv Y2FsIHRvIHRoZSBsaW5rIGJldHdlZW4gdHdvIGFkamFjZW50IE1QTFMNCj5zd2l0Y2hlcywgaXQg aW5kaWNhdGVzIGEgTFNQIGluIHRoaXMgbGluay4gVGhpcyBsaW5rIGlzIHRoZXJlZm9yZSB0aGUN Cj51bHRpbWF0ZSBGQS4gQW4gYWxyZWFkeSBlc3RhYmxpc2hlZCBMU1AgYmV0d2VlbiB0d28gTVBM UyBzd2l0Y2hlcywgd2hpY2gNCj5kb24ndCBoYXZlIHRvIGJlIGFkamFjZW50LCBjYW4gYmUgdXNl ZCB0byB0cmFuc3BvcnQvdHVubmVsIG90aGVyIExTUHMNCj5iZXR3ZWVuIHRoaXMgdHdvIG5vZGVz LiBUaGlzIGFscmVhZHkgZXN0YWJsaXNoZWQgTFNQIGdlbmVyYXRlcyBhIHZpcnR1YWwNCj5hZGph Y2VuY3kgYmV0d2VlbiB0aGUgdHdvIG5vZGVzLCB0aGUgRkEuIEFzIHNldmVyYWwgTFNQcyBjYW4g dXNlIHRoaXMgRkENCj5pdCBpcyBhbHNvIGEga2luZCBvZiB2aXJ0dWFsIG11bHRpcGxleGluZy4N Cj5JZiB5b3UgY29tcGFyZSBpdCB3aXRoIGEgY2lyY3VpdCBzd2l0Y2hlZCBuZXR3b3JrIHRoZSBG QSBpcyBhIHNlcnZlcg0KPmxheWVyIHRyYWlsIHRoYXQgcHJvdmlkZXMgdHJhbnNwb3J0IChhIGxp bmsgY29ubmVjdGlvbikgZm9yIG9uZSBvciBtb3JlDQo+Y2xpZW50IGxheWVyIHNpZ25hbHMuDQo+ SW4gTVBMUyB0aGUgRkEgZXN0YWJsaXNoZXMgInZpcnR1YWwiIGxheWVyIG5ldHdvcmtzLiBJbiBH TVBMUyB0aGUgbGF5ZXINCj5uZXR3b3JrcyBhbHJlYWR5IGV4aXN0IChTREggSE8vTE8tVkNzLCBS UywgTVMsIEcuNzA5IE9EVXMsIE9DaCwgT01TLA0KPk9UUykuIEEgRkEgYmFzaWNhbGx5IGNvcnJl c3BvbmRzIHRvIGEgcmVhbCB0cmFpbCBpbiBhIGNpcmN1aXQgc3dpdGNoZWQNCj5uZXR3b3JrLg0K PkluIEdNUExTIHRoZSBsYWJlbCBpcyBhbHNvIGxvY2FsIHRvIHRoZSBsaW5rIGJldHdlZW4gdGhl IHR3byBkZXZpY2VzDQo+dGhhdCBwZXJmb3JtIHRoZSBzd2l0Y2hpbmcuIEZvciBleGFtcGxlIGZv ciBTREggdGhlIFZDLU4gaXMgaWRlbnRpZmllZA0KPmJ5IHRoZSBTVE0tTiBsaW5rL3BvcnQgYW5k IHRoZSBTVUtMTSBudW1iZXIgYWNjb3JkaW5nIHRvDQo+ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1z b25ldC1zZGgtMDIudHh0LiBUaGUgU1RNLU4gcG9ydCBpcyBpZGVudGlmaWVkIGJ5DQo+dGhlIGlu dGVyZmFjZSBJRCAoSSBhbSBub3Qgc3VyZSBvbiB0aGlzKSBhbmQgU1VLTE0gaXMgdGhlIFNESCBs YWJlbCB0aGF0DQo+bG9jYXRlcyB0aGUgVkMgd2l0aGluIHRoZSBTVE0tTi4NCj5Gcm9tIGp1c3Qg dGhlIFNESCB2aWV3cG9pbnQgdGhlIFNUTS1OIGNvbm5lY3Rpb24gaXMgdGhlIHVsdGltYXRlIHNl cnZlcg0KPnRyYWlsL0ZBLiBIb3dldmVyIHRoZSBTVE0tTiBzaWduYWwgY291bGQgYmUgdHJhbnNw b3J0ZWQgb3ZlciBhIE9wdGljYWwNCj5DaGFubmVsIG9yIEcuNzA5IE9EVS4gVGhlIE9DaCBvciBP RFUgY2FuIGFscmVhZHkgc3RhcnQgaW4gdGhlIGVxdWlwbWVudA0KPnRoYXQgcGVyZm9ybXMgdGhl IFZDLU4gc3dpdGNoaW5nLiBTbyB0aGUgU1RNLU4gc2lnbmFsIGlzIG5vdCB0aGUgcG9ydCwNCj5i dXQgdGhlIFdETSBzaWduYWwgaXMgdGhlIHBvcnQgYW5kIHRoZSBTVE0tTiBzaWduYWwgbWFrZXMg dXNlIG9mIGEgT0NoDQo+b3IgT0RVIHNlcnZlciBsYXllciB0cmFpbC4gVGhpcyBzZXJ2ZXIgbGF5 ZXIgdHJhaWwgY2FuIGJlIGVzdGFibGlzaGVkDQo+dmlhIG1hbmFnZW1lbnQgb3IgdXNpbmcgR01Q TFMuDQo+Q2FuIHNvbWVvbmUgZXhwbGFpbiBob3cgYSBsYWJlbCBmb3IgYSBWQy00IGlzIGdlbmVy YXRlZCBpbiB0aGlzIGNhc2UNCj4ocHJlLWVzdGFibGlzaGVkIE9DaCBvciBPRFUgdHJhaWwgdmlh IG1hbmFnZW1lbnQgb3Igc2V0dXAgdXNpbmcgR01QTFMpLg0KPlRoaXMgaW50ZXJhY3Rpb24gYmV0 d2VlbiB0aGUgZGlmZmVyZW50IHRlY2hub2xvZ2llcy9sYWJlbHMgbmVlZCBpbiBteQ0KPnZpZXcg c29tZSBmdXJ0aGVyIGV4cGxhbmF0aW9uLg0KPg0KPk9uZSBzcGVjaWFsIHRoaW5nIGFib3V0IHRo ZSBTREggbGFiZWwgaXMsIHRoYXQgaXQgaW5jbHVkZXMgYSBoaWVyYXJjaHkNCj5hcyBpdCBpZGVu dGlmaWVzIHRoZSBsb3dlciBvcmRlciBWQyBpbiBhIGhpZ2hlciBvcmRlciBWQyBpbiBhIFNUTS1O DQo+c2lnbmFsLiBOb3RlIHRoYXQgdGhpcyBpcyBzb21laG93IGluIGNvbnRyYWRpY3Rpb24gd2l0 aCBhIHN0YXRlbWVudCBpbg0KPnRoZSBHTVBMUyBzaWduYWxpbmcgZG9jdW1lbnQgd2hpY2ggc2F5 cw0KPiJBIEdlbmVyYWxpemVkIExhYmVsIG9ubHkgY2FycmllcyBhIHNpbmdsZSBsZXZlbCBvZiBs YWJlbCwgaS5lLiwgaXQgaXMNCj4gICAgbm9uLWhpZXJhcmNoaWNhbC4gIFdoZW4gbXVsdGlwbGUg bGV2ZWxzIG9mIGxhYmVsIChMU1BzIHdpdGhpbiBMU1BzKQ0KPiAgICBhcmUgcmVxdWlyZWQsIGVh Y2ggTFNQIG11c3QgYmUgZXN0YWJsaXNoZWQgc2VwYXJhdGVseSwgc2VlIFtNUExTLQ0KPiAgICBI SUVSQVJDSFldLiINCj5Gb2xsb3dpbmcgdGhpcyBzdGF0ZW1lbnQgZWFjaCBsYXllciBzaG91bGQg aGF2ZSBpdHMgb3duIGxhYmVsDQo+aW5kZXBlbmRlbnQgb2Ygc2VydmVyIGxheWVycy4NCj5UaGUg Y29tYmluYXRpb24gb2YgaGllcmFyY2hpZXMgaW4gbGFiZWxzIGlzIGJhc2VkIG9uIHRlY2hub2xv Z3kgKGUuZy4NCj5TREgsIFNvbmV0LCBHLjcwOSBPRFUpIGJ1dCBoYXMgaW4gbXkgdmlldyBubyBy ZWFsIHRlY2huaWNhbCByZWFzb24uIFRoZQ0KPlNESCBsYWJlbCBmb3IgZXhhbXBsZSBmaXRzIHRv IHN0YW5kYXJkIFNUTS1OIHNpZ25hbHMsIGJ1dCBub3QgdG8gc3ViLVNUTQ0KPnNpZ25hbHMuDQo+ Rm9yIHRoZSBTREggdGhlIGZ1bGwgU1VLTE0gbnVtYmVyIGlzIHVzZWQgaWYgYSBlLmcuIFZDLTEy IGlzIGxvY2F0ZWQgaW4NCj5yZWxhdGlvbiB0byBhIFNUTS1OIGludGVyZmFjZS4gSWYgaXQgaXMg bG9jYXRlZCBpbiByZWxhdGlvbiB0byBhIFZDLTQNCj4odGhlIFZDLTQgaXMgaW4gdGhpcyBjYXNl IGEgRkEpIFNVSyBhcmUgc2V0IHRvIDAuIEZvciBtZSBpdCBpcyBub3QgY2xlYXINCj5pbiB3aGlj aCBjYXNlIEkgdXNlIHRoZSBmaXJzdCBhbmQgaW4gd2hpY2ggY2FzZSBJIHVzZSB0aGUgc2Vjb25k IGNhc2UgYXMNCj5hIFZDLTQgdHJhaWwgaXMgYWx3YXlzIG5lZWRlZCBmb3IgYSBWQy0xMiBjb25u ZWN0aW9uLiBUaGlzIFZDLTQgY291bGQgYmUNCj5lc3RhYmxpc2hlZCB1c2luZyBtYW5hZ2VtZW50 IG9yIEdNUExTLiBIb3dldmVyIGl0IHNob3VsZCBoYXZlIG5vDQo+aW5mbHVlbmNlIG9uIHRoZSBs YWJlbC4NCj5Tb21lIG1vcmUgaW5mb3JtYXRpb24gaXMgbmVlZGVkIGluIG15IHZpZXcgaW4gdGhp cyBhcmVhLg0KPg0KPg0KPkp1ZXJnZW4NCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IEpvaG4gRHJha2UgW21haWx0bzpqZHJha2VAY2FsaWVudC5uZXRdDQo+ ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxMiwgMjAwMSA2OjU0IEFNDQo+ID4gVG86IE1h YXJ0ZW4gVmlzc2VyczsgbWFub2oganVuZWphDQo+ID4gQ2M6IGNjYW1wQG9wcy5pZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJFOiBMYW1iZGEgTFNQIGVzdGFibGlzaG1lbnQNCj4gPg0KPiA+DQo+ID4g Zm9ydHVuYXRlbHksIHRoaXMgaXMganVzdCB5b3VyIG9waW5pb24NCj4gPg0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTWFhcnRlbiBWaXNzZXJzIFttYWlsdG86bXZp c3NlcnNAbHVjZW50LmNvbV0NCj4gPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxMSwgMjAwMSA5 OjMxIFBNDQo+ID4gVG86IG1hbm9qIGp1bmVqYQ0KPiA+IENjOiBjY2FtcEBvcHMuaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogTGFtYmRhIExTUCBlc3RhYmxpc2htZW50DQo+ID4NCj4gPg0KPiA+ IE1hbm9qLA0KPiA+DQo+ID4gRm9yZ2V0IHRoZSBGQSBzdHVmZiwgaXQgaXMgbm90IGFwcHJvcHJp YXRlIGluIGNpcmN1aXQNCj4gPiBuZXR3b3Jrcy4gSXQgb25seQ0KPiA+IGFwcGxpZXMNCj4gPiB0 byBNUExTLiBXZSBzaG91bGQgcmVtb3ZlIGl0IHdoZW4gaXQgaXMgdXNlZCBpbiByZWxhdGlvbiB3 aXRoIFBESCwNCj4gPiBTREgvU09ORVQsDQo+ID4gT1ROIGFuZCBwcmUtT1ROLiBUaGUgdGV4dCBp biBzZGgtc29uZXQgZHJhZnQgc2hvdWxkIHN0YXRlDQo+ID4gdGhhdCBpZiB0aGVyZSBpcyBhDQo+ ID4gTE9WQyBsaW5rIChJRVRGOiBsaW5rIGJ1bmRsZS9URSBsaW5rKSB0aGVuIHRoZSBMT1ZDIHNp Z25hbHMNCj4gPiB1c2UgYSBsYWJlbCB3aXRoDQo+ID4gIjAwS0xNIi4NCj4gPg0KPiA+IFJlZ2Fy ZHMsDQo+ID4NCj4gPiBNYWFydGVuDQo+ID4NCj4gPiBtYW5vaiBqdW5lamEgd3JvdGU6DQo+ID4g Pg0KPiA+ID4gSGkgTWFydGVlbiwNCj4gPiA+ICAgICAgICAgICAgIFRoZSBjb25jZXB0IG9mIEZB IGlzIG1lbnRpb25lZCBmb3IgU0RIL1NPTkVUIGluDQo+ID4gZ21wbHMtc2RoDQo+ID4gPiAtc29u ZXQgZHJhZnQuIEl0IHNheXMgdGhhdCBpZiB1IGhhdmUgYSBIT1ZDIHRyYWlsIGFzIGEgRkENCj4g PiAoYWR2ZXJ0aXplZA0KPiA+ID4gYXMgYSBsaW5rKSB0aGVuIHUgY2FuIGFsbG9jYXRlIHRoZSBs b3dlciBsZXZlbCBzaWduYWxzIGluDQo+ID4gaXQgYnkgbWFraW5nDQo+ID4gPiB0aGUgaGlnaGVy IGJpdHMgb2YgbGFiZWwgYXMgMHMgKGkuZS4gUyBhbmQgVX0uIFRoaXMgaXMgZmluZQ0KPiA+IGZv ciB0aGUgc2FtZQ0KPiA+ID4gdGVjaG5vbG9neS4gV2hhdCBhYm91dCB0aGUgY2FzZSB3aGVyZSB0 aGUgVERNIExTUCBoYXMgdG8gYmUgdHVubmVsZWQNCj4gPiB0aHJvdWdoDQo+ID4gPiB0aGUgTGFt YmRhIExTUCA/IFdoYXQgd2lsbCBiZSB0aGUgZm9ybSBvZiBsYWJlbCAoaS5lLg0KPiA+IHtTVUtM TX0gb3IgbGFtYmRhDQo+ID4gPiBldGMuKSA/DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+ IG1hbm9qLg0KPiA+ID4NCj4gPiA+ID5Gcm9tOiBNYWFydGVuIFZpc3NlcnMgPG12aXNzZXJzQGx1 Y2VudC5jb20+DQo+ID4gPiA+VG86IG1hbm9qIGp1bmVqYSA8bWFub2prdW1hcmp1bmVqYUBob3Rt YWlsLmNvbT4NCj4gPiA+ID5DQzogY2NhbXBAb3BzLmlldGYub3JnDQo+ID4gPiA+U3ViamVjdDog UmU6IExhbWJkYSBMU1AgZXN0YWJsaXNobWVudA0KPiA+ID4gPkRhdGU6IFR1ZSwgMTEgRGVjIDIw MDEgMTU6NTY6NDEgKzAxMDANCj4gPiA+ID4NCj4gPiA+ID5NYW5vaiwNCj4gPiA+ID4NCj4gPiA+ ID5Zb3UgcmVmZXIgdG8gb25lIHdhdmVsZW5ndGggdG8gYmUgYXZhaWxhYmxlIGJldHdlZW4gQS1F IHdpdGhvdXQNCj4gPiB3YXZlbGVuZ3RoDQo+ID4gPiA+Y29udmVyc2lvbiBjYXBhYmlsaXR5LiBU aGlzIHN1Z2dlc3RzIHRoYXQgeW91IG9wZXJhdGUgYXQNCj4gPiB0aGUgT0NoIGxheWVyDQo+ID4g PiA+bmV0d29yay4NCj4gPiA+ID5UaGVuIHlvdSBzcGVjaWZ5IHRoZSBjYXBhY2l0eSBvZiB0aGUg NCBPQ2ggbGluaw0KPiA+IGNvbm5lY3Rpb25zIChBLUIsIEItQywNCj4gPiBDLUQsDQo+ID4gPiA+ RC1FKQ0KPiA+ID4gPnRvIGJlICJDIi4gU2F5IHRoYXQgQyBpcyBhYm91dCAxMCBHYml0L3MuIFlv dSB0aGVuIGFzc3VtZQ0KPiA+IHRoYXQgdGhlcmUgaXMgYQ0KPiA+ID4gPnJlcXVlc3QgZm9yIGFu IE9DaCBzaWduYWwgd2l0aCBjYXBhY2l0eSBDLzQgKGUuZy4gMi41DQo+ID4gR2JpdC9zKSBiZXR3 ZWVuIEMNCj4gPiBhbmQNCj4gPiA+ID5FLg0KPiA+ID4gPlRoZSByZXN1bHQgaXMgdGhhdCB0aGUg T0NoIGxpbmsgY29ubmVjdGlvbnMgQy1EIGFuZCBELUUNCj4gPiBhcmUgdHJhbnNwb3J0aW5nDQo+ ID4gPiA+dGhlIE9DaA0KPiA+ID4gPnNpZ25hbCAob2YgZS5nLiAyLjVHKS4gVGhlc2UgT0NoIGxp bmsgY29ubmVjdGlvbnMgYXJlIG5vdw0KPiA+IGluIHNlcnZpY2UgYW5kDQo+ID4gPiA+bm90DQo+ ID4gPiA+bG9uZ2VyIGF2YWlsYWJsZSB0byBhbiBvdGhlciBPQ2ggY29ubmVjdGlvbiByZXF1ZXN0 LiBJLmUuDQo+ID4gYSByZXF1ZXN0IGZvcg0KPiA+IGFuDQo+ID4gPiA+T0NoDQo+ID4gPiA+Y29u bmVjdGlvbiBiZXR3ZWVuIEEgYW5kIEUgd2lsbCBiZSByZWplY3RlZC4NCj4gPiA+ID4NCj4gPiA+ ID5GQXMgYXJlIG5vdCBhcHBsaWNhYmxlIGluIHRoZSBjaXJjdWl0IGxheWVycy4gSUYgdGhlcmUg aXMNCj4gPiBhIHRyYWlsIGluDQo+ID4gc2VydmVyDQo+ID4gPiA+bGF5ZXIgWCwgdGhlbiB0aGVy ZSBpcyBhIGxpbmsgaW4gaXRzIGNsaWVudCBsYXllciBZLiBYIGFuZA0KPiA+IFkgYXJlIHRodXMN Cj4gPiA+ID5kaWZmZXJlbnQNCj4gPiA+ID5sYXllciBuZXR3b3JrcyBhbmQgc2lnbmFscy4NCj4g PiA+ID4NCj4gPiA+ID5JZiBDLUUgaXMgYSAiRkEiLCB0aGVuIGluIGFuIE9UTiB0aGUgQy1FIGNv bm5lY3Rpb24gd291bGQNCj4gPiBiZSBhbiBPQ2ggdHJhaWwNCj4gPiA+ID5zdXBwb3J0aW5nIGFu IE9EVWsgKGs9MSBpZiBPQ2ggaXMgMkc1KSBsaW5rIHdpdGggYSBzaW5nbGUgbGluaw0KPiA+IGNv bm5lY3Rpb24uDQo+ID4gPiA+DQo+ID4gPiA+Tm90ZSBhIEZBIGluIE1QTFMgY3JlYXRlcyBlc3Nl bnRpYWxseSBhIE1QTFMgc3VibGF5ZXINCj4gPiBuZXR3b3JrLiBTdWNoIGlzDQo+ID4gbm90DQo+ ID4gPiA+cG9zc2libGUgaW4gdGhlIFNESC9TT05FVCwgT1ROLCBQREggb3IgQVRNIHRlY2hub2xv Z2llcy4NCj4gPiA+ID4NCj4gPiA+ID5SZWdhcmRzLA0KPiA+ID4gPg0KPiA+ID4gPk1hYXJ0ZW4N Cj4gPiA+ID4NCj4gPiA+ID5PQ2ggbGluayBjb25uZWN0aW9ucw0KPiA+ID4gPg0KPiA+ID4gPm1h bm9qIGp1bmVqYSB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIEFsbCwNCj4gPiA+ID4g PiAgICAgICAgIElmIEkgaGF2ZSA1IG5vZGVzIEEsIEIsIEMsIEQgYW5kIEUgY29ubmVjdGVkIGFz DQo+ID4gc2hvd24uIEFzc3VtZQ0KPiA+ID4gPiA+IHRoYXQgb25seSBvbmUgd2F2ZWxlbmd0aCBp cyBhdmFpbGFibGUgb24gdGhlIHBhdGggQSB0byBFIChubw0KPiA+IHdhdmVsZW5ndGgNCj4gPiA+ ID4gPiBjb252ZXJzaW9uIGNhcGFiaWxpdHkgaXMgdGhlcmUgb24gdGhlIGNvbXBsZXRlIHBhdGgp Lg0KPiA+IExldCB0aGUgY2FwYWNpdHkNCj4gPiA+ID4gPiBvZiB0aGUgd2F2ZWxlbmd0aCBiZSBD LiBGdXJ0aGVyIGFzc3VtZSBhIHJlcXVlc3QgYXJyaXZlcyBmb3INCj4gPiBjb25uZWN0aW9uDQo+ ID4gPiA+ID4gZnJvbSBub2RlIEMgdG8gRSBmb3IgYSBsaW5lIGNhcGFjaXR5IG9mIEMvNC4gVGhp cw0KPiA+IHJlcXVlc3Qgd2lsbCBiZQ0KPiA+ID4gPiA+IHN1Y2Nlc3NmdWwgYXMgd2UgaGF2ZSBh dmFpbGFibGUgd2F2ZWxlbmd0aC4gTm93IElmDQo+ID4gYW5vdGhlciByZXF1ZXN0DQo+ID4gPiA+ ID4gY29tZXMgYXQgbm9kZSBBIHRvIGVzdGFibGlzaCBhbm90aGVyIGNvbm5lY3Rpb24gZnJvbQ0K PiA+IG5vZGUgQSB0byBub2RlIEUNCj4gPiA+ID4gPiB2aWEgbm9kZXMge0EsQixDLEQsRX0gZm9y IGEgbGluZSBjYXBhY2l0eSBvZiBDLzQuDQo+ID4gU2hvdWxkIHRoaXMgcmVxdWVzdA0KPiA+ID4g PiA+IGJlIHN1Y2Nlc3NmdWwgYXMgd2UgaGF2ZSBhbHJlYWR5IGFsbG9jYXRlZCB0aGUgd2F2ZWxl bmd0aCA/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJZiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbiBm cm9tIEMgdG8gRSBvZiBjYXBhY2l0eSBDLzQgaGFkIGJlZW4NCj4gPiA+ID4gPiBhZHZlcnRpc2Vk IGFzIGEgRkEsIGluIHRoYXQgY2FzZSB3aWxsIHRoZSBJSW5kIHJlcXVlc3Qgc3VjY2VlZCA/DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBJZiB0aGUgcHJldmlvdXMgY29ubmVjdGlvbiBmcm9tIEMgdG8g RSBvZiBjYXBhY2l0eSBDLzQNCj4gPiBoYWQgbm90IGJlZW4NCj4gPiA+ID4gPiBhZHZlcnRpc2Vk IGFzIEZBIHRoZW4gd2hhdCB3aWxsIGJlIHRoZSBmYXRlIG9mIElJbmQgY29ubmVjdGlvbiA/DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiAgICAgICAgQSA8LS0+IEIgPC0tLT4gQyA8LS0tLT4gRCA8LS0t PiA8LS0tLT4gRQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4gPiBtYW5v ai4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBHZXQgeW91 ciBGUkVFIGRvd25sb2FkIG9mIE1TTiBFeHBsb3JlciBhdA0KPiA+ID4gPmh0dHA6Ly9leHBsb3Jl ci5tc24uY29tL2ludGwuYXNwDQo+ID4gPiA+PDwgbXZpc3NlcnMudmNmID4+DQo+ID4gPg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IFNlbmQgYW5kIHJlY2VpdmUgSG90bWFpbCBvbiB5b3VyIG1vYmls ZSBkZXZpY2U6DQo+aHR0cDovL21vYmlsZS5tc24uY29tDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNlbmQgYW5k IHJlY2VpdmUgSG90bWFpbCBvbiB5b3VyIG1vYmlsZSBkZXZpY2U6IGh0dHA6Ly9tb2JpbGUubXNu LmNvbQ0KDQoNCg== Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 16:03:24 -0800 Message-ID: From: "Mannie, Eric" To: "'ccamp@ops.ietf.org '" Cc: "'dimitri.papadimitriou@alcatel.be '" Subject: Revised GMPLS SONET/SDH drafts Date: Fri, 14 Dec 2001 00:59:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18432.3B958350" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C18432.3B958350 Content-Type: text/plain Dear All, Please find attached the two GMPLS SDH/SONET drafts revised according to the comments received during the last period of comments, and during the Salt Lake City meeting: - draft-ietf-ccamp-gmpls-sonet-sdh-03.txt - draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt Please, send your comments to the mailing list AND to us. Kind regards, Eric and Dimitri ------_=_NextPart_000_01C18432.3B958350 Content-Type: application/octet-stream; name="draft-ietf-ccamp-gmpls-sonet-sdh-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-sonet-sdh-03.txt" CCAMP Working Group Eric Mannie (Ebone) - Editor=20 Internet Draft =20 Expiration Date: June 2002 Stefan Ansorge (Alcatel)=20 Peter Ashwood-Smith (Nortel)=20 Ayan Banerjee (Calient)=20 Lou Berger (Movaz)=20 Greg Bernstein (Ciena)=20 Angela Chiu (Celion)=20 John Drake (Calient)=20 Yanhe Fan (Axiowave)=20 Michele Fontana (Alcatel)=20 Gert Grammel (Alcatel)=20 Juergen Heiles(Siemens)=20 Suresh Katukam (Cisco)=20 Kireeti Kompella (Juniper)=20 Jonathan P. Lang (Calient)=20 Fong Liaw (Zaffire)=20 Zhi-Wei Lin (Lucent)=20 Ben Mack-Crane (Tellabs)=20 Dimitri Papadimitriou (Alcatel)=20 Dimitrios Pendarakis (Tellium)=20 Mike Raftelis (White Rock)=20 Bala Rajagopalan (Tellium)=20 Yakov Rekhter (Juniper)=20 Debanjan Saha (Tellium)=20 Vishal Sharma (Metanoia)=20 George Swallow (Cisco)=20 Z. Bo Tang (Tellium)=20 Eve Varma (Lucent)=20 Maarten Vissers (Lucent)=20 Yangguang Xu (Lucent)=20 =20 December 2001=20 =20 =20 GMPLS Extensions for SONET and SDH Control=20 =20 =20 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force (IETF),=20 its areas, and its working groups. Note that other groups may=20 also distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress."=20 =20 =20 E. Mannie Editor 1=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 To view the current status of any Internet-Draft, please check the=20 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow=20 Directory, see http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document is a companion to the Generalized MPLS signaling=20 documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines=20 the SONET/SDH technology specific information needed when using=20 GMPLS signaling.=20 =20 =20 1. Introduction=20 =20 Generalized MPLS (GMPLS) extends MPLS from supporting packet=20 (Packet Switching Capable - PSC) interfaces and switching to=20 include support of four new classes of interfaces and switching:=20 Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM),=20 Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A=20 functional description of the extensions to MPLS signaling needed=20 to support the new classes of interfaces and switching is provided=20 in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats=20 and mechanisms needed to support all five classes of interfaces,=20 and CR-LDP extensions can be found in [GMPLS-LDP]. This document=20 presents details that are specific to SONET/SDH. Per [GMPLS-SIG],=20 SONET/SDH specific parameters are carried in the signaling=20 protocol in traffic parameter specific objects.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"=20 in this document are to be interpreted as described in [RFC2119].=20 =20 =20 2. SDH and SONET Traffic Parameters=20 =20 This section defines the GMPLS traffic parameters for SONET/SDH.=20 The protocol specific formats, for the SDH/SONET-specific RSVP-TE=20 objects and CR-LDP TLVs are described in sections 2.2 and 2.3=20 respectively.=20 =20 These traffic parameters specify indeed a base set of capabilities=20 for SONET (ANSI T1.105) and SDH (ITU-T G.707) such as=20 concatenation and transparency. Some extra non-standard=20 capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents=20 could further enhance this set of capabilities in the future. For=20 instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0=20 (ITU-T G.708) interfaces could be defined.=20 =20 The traffic parameters defined hereafter MUST be used when=20 SONET/SDH is specified in the LSP Encoding Type field of a=20 Generalized Label Request [GMPLS-SIG].=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 2=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 A SONET signal which has an identical SDH signal SHOULD be=20 requested using the same traffic parameters as for the equivalent=20 SDH signal, and will consequently use the SDH label.=20 =20 =20 2.1. SONET/SDH Traffic Parameters=20 =20 The traffic parameters for SONET/SDH is organized as follows:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Signal Type | RCC | NCC |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | NVC | Multiplier (MT) |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Transparency (T) |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Annex 1 defines examples of SONET and SDH signal coding.=20 =20 Signal Type (ST): 8 bits=20 =20 This field indicates the type of Elementary Signal that=20 comprises the requested LSP. Several transforms can be applied=20 successively on the Elementary Signal to build the Final Signal=20 being actually requested for the LSP.=20 =20 Each transform is optional and must be ignored if zero, except=20 MT that cannot be zero and is ignored if equal to one.=20 =20 Transforms must be applied strictly in the following order:=20 =20 - First, contiguous concatenation (by using the RCC and NCC=20 fields) can be optionally applied on the Elementary Signal,=20 resulting in a contiguously concatenated signal.=20 - Second, virtual concatenation (by using the NVC field) can=20 be optionally applied either directly on the Elementary=20 Signal, or on the contiguously concatenated signal obtained=20 from the previous phase (see [GMPLS-SONET-SDH-EXT]).=20 - Third, some transparency can be optionally specified when=20 requesting a frame as signal rather than an SPE or VC based=20 signal (by using the Transparency field).=20 - Fourth, a multiplication (by using the Multiplier field) can be = optionally applied either directly on the Elementary Signal, or = on the contiguously concatenated signal obtained from the first = phase, or on the virtually concatenated signal obtained from=20 the second phase, or on these signals combined with some=20 transparency.=20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 3=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Permitted Signal Type values for SONET/SDH are:=20 =20 Value Type=20 ----- -----------------=20 1 VT1.5 SPE / VC-11=20 2 VT2 SPE / VC-12=20 3 VT3 SPE=20 4 VT6 SPE / VC-2=20 5 STS-1 SPE / VC-3=20 6 STS-3c SPE / VC-4=20 7 STS-1 / STM-0 (only when requesting transparency)=20 8 STS-3 / STM-1 (only when requesting transparency)=20 9 STS-12 / STM-4 (only when requesting transparency)=20 10 STS-48 / STM-16 (only when requesting transparency)=20 11 STS-192 / STM-64 (only when requesting transparency)=20 12 STS-768 / STM-256 (only when requesting transparency)=20 =20 A dedicated signal type is assigned to a SONET STS-3c SPE instead=20 of coding it as a contiguous concatenation of three STS-1 SPEs.=20 This is done in order to provide easy interworking between SONET=20 and SDH signaling.=20 =20 Appendix 1 adds one more signal type (optional). Refer to [GMPLS- SDH-SONET-EXT] for an extended set of signal type values beyond=20 the signal types as defined in T1.105/G.707. =20 =20 Requested Contiguous Concatenation (RCC): 8 bits=20 =20 This field is used to request and sometimes negotiate (see=20 [GMPLS-SDH-SONET-EXT]) the optional SONET/SDH contiguous=20 concatenation of the Elementary Signal.=20 =20 This field is a vector of flags. Each flag indicates the=20 support of a particular type of contiguous concatenation.=20 Several flags can be set at the same time to indicate a choice. =20 =20 These flags allow an upstream node to indicate to a downstream=20 node the different types of contiguous concatenation that it=20 supports. However, the downstream node decides which one to use=20 according to its own rules.=20 =20 A downstream node receiving simultaneously more than one flag=20 chooses a particular type of contiguous concatenation, if any=20 supported, and based on criteria that are out of this document=20 scope. A downstream node that doesn=92t support any of the=20 concatenation types indicated by the field must refuse the LSP=20 request. In particular, it must refuse the LSP request if it=20 doesn=92t support contiguous concatenation at all.=20 =20 The upstream node knows which type of contiguous concatenation=20 the downstream node chosen by looking at the position indicated=20 by the first label and the number of label(s) as returned by=20 the downstream node.=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 4=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 The entire field is set to zero to indicate that no contiguous=20 concatenation is requested at all (default value). A non-zero=20 field indicates that some contiguous concatenation is=20 requested.=20 =20 The following flag is defined:=20 =20 Flag 1 (bit 1): Standard contiguous concatenation.=20 =20 Flag 1 indicates that only the standard SONET/SDH contiguous=20 concatenation as defined in T1.105/G.707 is supported. Note=20 that bit 1 is the low order bit. Other flags are reserved for=20 extensions, if not used they must be set to zero when sent, and=20 should be ignored when received.=20 =20 See note 1 hereafter in the section on the NCC about the SONET=20 contiguous concatenation of STS-1 SPEs when the number of=20 components is a multiple of three.=20 =20 Refer to [GMPLS-SONET-SDH-EXT] for an extended set of contiguous=20 concatenation types beyond the contiguous concatenation types as=20 defined in T1.105/G.707.=20 =20 Number of Contiguous Components (NCC): 16 bits=20 =20 This field indicates the number of identical SONET/SDH SPEs/VCs=20 that are requested to be concatenated, as specified in the RCC=20 field.=20 =20 Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the=20 elementary signal to use must always be an STS-3c SPE signal=20 type and the value of NCC must always be equal to X. This=20 allows also facilitating the interworking between SONET and=20 SDH. In particular, it means that the contiguous concatenation=20 of three STS-1 SPEs cannot not be requested because according=20 to this specification, this type of signal must be coded using=20 the STS-3c SPE signal type.=20 =20 Note 2: when requesting a transparent STM-N/STS-N signal=20 limited to a single contiguously concatenated VC-4-Nc/STS-Nc- SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and=20 NCC set to 1.=20 =20 This field is irrelevant if no contiguous concatenation is=20 requested (RCC =3D 0), in that case it must be set to zero when=20 send, and should be ignored when received. A RCC value=20 different from 0 must imply a number of components greater than=20 1. The NCC value must be consistent with the type of contiguous=20 concatenation being requested in the RCC field.=20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 5=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Number of Virtual Components (NVC): 16 bits=20 =20 This field indicates the number of signals that are requested=20 to be virtually concatenated. These signals are all of the same=20 type by definition. They are Elementary Signal SPEs/VCs for=20 which signal types are defined in this document, i.e. VT1.5=20 SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11,=20 VC-12, VC-2, VC-3 or VC-4.=20 =20 This field is set to 0 (default value) to indicate that no=20 virtual concatenation is requested.=20 =20 Refer to [GMPLS-SONET-SDH-EXT] for an extended set of signals that = can be virtually concatenated beyond the virtual concatenation as=20 defined in T1.105/G.707.=20 =20 Multiplier (MT): 16 bits=20 =20 This field indicates the number of identical signals that are=20 requested for the LSP, i.e. that form the Final Signal. These=20 signals can be either identical Elementary Signals, or=20 identical contiguously concatenated signals, or identical=20 virtually concatenated signals. Note that all these signals=20 belongs thus to the same LSP.=20 =20 The distinction between the components of multiple virtually=20 concatenated signals is done via the order of the labels that=20 are specified in the signaling. The first set of labels must=20 describe the first component (set of individual signals=20 belonging to the first virtual concatenated signal), the second=20 set must describe the second component (set of individual=20 signals belonging to the second virtual concatenated signal)=20 and so on.=20 =20 This field is set to one (default value) to indicate that=20 exactly one instance of a signal is being requested. Zero is an=20 invalid value.=20 =20 Transparency (T): 32 bits=20 =20 This field is a vector of flags that indicates the type of=20 transparency being requested. Several flags can be combined to=20 provide different types of transparency. Not all combinations=20 are necessarily valid. The default value for this field is=20 zero, i.e. no transparency requested.=20 =20 Transparency, as defined from the point of view of this=20 signaling specification, is only applicable to the fields in=20 the SONET/SDH frame overheads. In the SONET case, these are the=20 fields in the Section Overhead (SOH), and the Line Overhead=20 (LOH). In the SDH case, these are the fields in the Regenerator=20 Section Overhead (RSOH), the Multiplex Section overhead (MSOH),=20 and the pointer fields between the two. With SONET, the pointer=20 fields are part of the LOH.=20 =20 E. Mannie Editor Internet-Draft June 2002 6=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 =20 Note as well that transparency is only applicable when using=20 the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM- 64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS- 768. At least one transparency type must be specified when=20 requesting such a signal type.=20 =20 Transparency indicates precisely which fields in these=20 overheads must be delivered unmodified at the other end of the=20 LSP. An ingress LSR requesting transparency will pass these=20 overhead fields that must be delivered to the egress LSR=20 without any change. From the ingress and egress LSRs point of=20 views, these fields must be seen as unmodified.=20 =20 Transparency is not applied at the interfaces with the=20 initiating and terminating LSRs, but is only applied between=20 intermediate LSRs. =20 =20 The transparency field is used to request an LSP that supports=20 the requested transparency type; it may also be used to setup=20 the transparency process to be applied in each intermediate=20 LSR.=20 =20 The different transparency flags are the following:=20 =20 Flag 1 (bit 1): Section/Regenerator Section layer.=20 Flag 2 (bit 2): Line/Multiplex Section layer.=20 =20 Where bit 1 is the low order bit. Others flags are reserved,=20 they should be set to zero when sent, and should be ignored=20 when received. A flag is set to one to indicate that the=20 corresponding transparency is requested.=20 =20 Section/Regenerator Section layer transparency means that the=20 entire frames must be delivered unmodified. This implies that=20 pointers cannot be adjusted. When using Section/Regenerator=20 Section layer transparency all other flags must be ignored.=20 =20 Line/Multiplex Section layer transparency means that the=20 LOH/MSOH must be delivered unmodified. This implies that=20 pointers cannot be adjusted. =20 =20 Refer to [GMPLS-SONET-SDH-EXT] for an extended set of transparency = types beyond the transparency types as defined in T1.105/G.707.=20 =20 =20 2.2. RSVP-TE Details=20 =20 For RSVP-TE, the SONET/SDH traffic parameters are carried in the=20 SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is=20 used both for SENDER_TSPEC object and FLOWSPEC objects. The=20 contents of the objects is defined above in Section 2.1. The=20 objects have the following class and type:=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 7=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 For SONET ANSI T1.105 and SDH ITU-T G.707:=20 =20 SONET/SDH SENDER_TSPEC object: Class =3D 12, C-Type =3D 4 (TBA)=20 SONET/SDH FLOWSPEC object: Class =3D 9, C-Type =3D 4 (TBA)=20 =20 There is no Adspec associated with the SONET/SDH SENDER_TSPEC.=20 Either the Adspec is omitted or an int-serv Adspec with the=20 Default General Characterization Parameters and Guaranteed Service=20 fragment is used, see [RFC2210].=20 =20 For a particular sender in a session the contents of the FLOWSPEC=20 object received in a Resv message SHOULD be identical to the=20 contents of the SENDER_TSPEC object received in the corresponding=20 Path message. If the objects do not match, a ResvErr message with=20 a "Traffic Control Error/Bad Flowspec value" error SHOULD be=20 generated.=20 =20 =20 2.3. CR-LDP Details=20 =20 For CR-LDP, the SONET/SDH traffic parameters are carried in the=20 SONET/SDH Traffic Parameters TLV. The contents of the TLV is=20 defined above in Section 2.1. The header of the TLV has the=20 following format:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |U|F| Type | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA.=20 =20 =20 3. SDH and SONET Labels=20 =20 SDH and SONET each define a multiplexing structure, with the SONET=20 multiplex structure being a subset of the SDH multiplex structure.=20 These two structures are trees whose roots are respectively an=20 STM-N or an STS-N; and whose leaves are the signals that can be=20 transported via the time-slots and switched between time-slots,=20 i.e. a VC-x, a VT-x SPE or an STS SPE. An SDH/SONET label will=20 identify the exact position of a particular signal in a=20 multiplexing structure. SDH and SONET labels are carried in the=20 Generalized Label per [GMPLS-RSVP] and [GMPLS-LDP].=20 =20 These multiplexing structures will be used as naming trees to=20 create unique multiplex entry names or labels. Since the SONET=20 multiplexing structure may be seen as a subset of the SDH=20 multiplexing structure, the same format of label is used for SDH=20 and SONET. As explained in [GMPLS-SIG], a label does not identify=20 the "class" to which the label belongs. This is implicitly=20 determined by the link on which the label is used.=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 8=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 In case of signal concatenation or multiplication, a list of=20 labels can appear in the Label field of a Generalized Label.=20 =20 In case of contiguous concatenation, only one label appears in the=20 Label field. This label is the lowest signal of the contiguously=20 concatenated signal. By lowest signal we mean the one having the=20 lowest label when compared as integer values, i.e. the first=20 component signal of the concatenated signal encountered when=20 descending the tree.=20 =20 In case of virtual concatenation, the explicit ordered list of all=20 labels in the concatenation is given. Each label indicates a=20 component of the virtually concatenated signal. The order of the=20 labels must reflect the order of the payloads to concatenate (not=20 the physical order of time-slots). The above representation limits=20 virtual concatenation to remain within a single (component) link;=20 it imposes as such a restriction compared to the G.707/T1.105=20 recommendations.=20 =20 In case of multiplication (i.e. using the multiplier transform),=20 the explicit ordered list of all labels that take part in the=20 Final Signal is given. In case of multiplication of virtually=20 concatenated signals, the first set of labels indicates the first=20 virtually concatenated signal, the second set of labels indicates=20 the second virtually concatenated signal, and so on. The above=20 representation limits multiplication to remain within a single=20 (component) link.=20 =20 The format of the label for SDH and/or SONET TDM-LSR link is:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | S | U | K | L | M |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 For SDH, this is an extension of the numbering scheme defined in=20 G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U=20 and K fields are not significant and must be set to zero. Only the=20 S, L and M fields are significant for SONET and have a similar=20 semantic as for SDH.=20 =20 Each letter indicates a possible branch number starting at the=20 parent node in the multiplex structure. Branches are considered as=20 numbered in increasing order, starting from the top of the=20 multiplexing structure. The numbering starts at 1, zero is used to=20 indicate a non-significant or ignored field.=20 =20 When a field is not significant or ignored in a particular context=20 it MUST be set to zero when transmitted, and MUST be ignored when=20 received.=20 =20 When hierarchical SDH/SONET LSPs are used, an LSP with a given=20 bandwidth can be used to tunnel lower order LSPs. The higher=20 =20 E. Mannie Editor Internet-Draft June 2002 9=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 order SDH/SONET LSP behaves as a virtual link with a given=20 bandwidth (e.g. VC-3), it may also be used as a Forwarding=20 Adjacency. A lower order SDH/SONET LSP can be established through=20 that higher order LSP. Since a label is local to a (virtual) link,=20 the highest part of that label is non-significant and is set to=20 zero.=20 =20 For instance, a VC-3 LSP can be advertised as a forwarding=20 adjacency. In that case the labels allocated between the two ends=20 of that LSP (i.e. for that "link") will have S, U and K set to=20 zero, i.e., non-significant, while L and M will be used to=20 indicate the signal allocated in that VC-3.=20 =20 The possible values of S, U, K, L and M are defined as it follows:=20 =20 1. S is only significant for SDH STM-N (N>0) and SONET. It must=20 be ignored for STM-0. S is the index of a particular AUG-1/STS- 1. S=3D1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N = multiplex. For example, S=3D1 indicates the first AUG-1/STS-1, and = S=3DN indicates the last AUG-1/STS-1 of this multiplex.=20 =20 2. U is only significant for SDH STM-N (N>0) and must be ignored=20 for STM-0 and SONET. It indicates a specific VC inside a given=20 AUG-1. U=3D1 indicates a single VC-4, while U=3D2->4 indicates a=20 specific VC-3 inside the given AUG-1.=20 =20 3. K is only significant for SDH VC-4 and must be ignored in all=20 other cases. It indicates a specific branch of a VC-4. K=3D1=20 indicates that the VC-4 is not further subdivided and contains a=20 C-4. K=3D2->4 indicates a specific TUG-3 inside the VC-4. K is not = significant when the AUG-1 is divided into AU-3s.=20 =20 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.=20 It is not significant for an unstructured VC-4 (L=3D0). L=3D1=20 indicates that the TUG-3/VC-3/STS-1 SPE is not further=20 subdivided and contains a VC-3/C-3 in SDH or the equivalent in=20 SONET. L=3D2->8 indicates a specific TUG-2/VT Group inside the=20 corresponding higher order signal.=20 =20 5. M indicates a specific branch of a TUG-2/VT Group. It is not=20 significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE.=20 M=3D1 indicates that the TUG-2/VT Group is not further subdivided=20 and contains a VC-2/VT-6 SPE. M=3D2->3 indicates a specific VT-3=20 inside the corresponding VT Group, these values MUST NOT be used=20 for SDH since there is no equivalent of VT-3 with SDH. M=3D4->6=20 indicates a specific VC-12/VT-2 SPE inside the corresponding=20 TUG-2/VT Group. M=3D7->10 indicates a specific VC-11/VT-1.5 SPE=20 inside the corresponding TUG-2/VT Group. Note that M=3D0 denotes=20 an unstructured VC-4, VC-3 or STS-1 SPE.=20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 10=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 The M encoding is summarized in the following table:=20 =20 M SDH SONET=20 ----------------------------------------------------------=20 0 unstructured VC-4/VC-3 unstructured STS-1 SPE=20 1 VC-2 VT-6=20 2 - 1st VT-3=20 3 - 2nd VT-3=20 4 1st VC-12 1st VT-2=20 5 2nd VC-12 2nd VT-2=20 6 3rd VC-12 3rd VT-2=20 7 1st VC-11 1st VT-1.5=20 8 2nd VC-11 2nd VT-1.5=20 9 3rd VC-11 3rd VT-1.5=20 10 4th VC-11 4th VT-1.5=20 =20 Examples of labels:=20 =20 Example 1: S>0, U=3D1, K=3D1, L=3D0, M=3D0=20 Denotes the unstructured VC-4 of the Sth AUG-1.=20 =20 Example 2: S>0, U=3D1, K>1, L=3D1, M=3D0=20 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.=20 =20 Example 3: S>0, U=3D0, K=3D0, L=3D0, M=3D0=20 Denotes the unstructured SPE of the Sth STS-1.=20 =20 Example 4: S>0, U=3D0, K=3D0, L>1, M=3D1=20 Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1.=20 =20 Example 5: S>0, U=3D0, K=3D0, L>1, M=3D9=20 Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1.=20 =20 In case of contiguous concatenation, the label that is used is the=20 lowest label of the contiguously concatenated signal as explained=20 before. The higher part of the label indicates where the signal=20 starts and the lowest part is not significant. For instance, when=20 requesting an STS-48c the label is S>0, U=3D0, K=3D0, L=3D0, M=3D0.=20 =20 In case of STM-0, the values of S, U and K must be equal to zero=20 according to the field coding rules. For instance, when requesting=20 an unstructured VC-3 in an STM-0 the label is S=3D0, U=3D0, K=3D0, = L=3D1,=20 M=3D0.=20 =20 In case of STS-3c SPE, the value of S is the index of the first=20 STS-1 of the STS-3c SPE in the SONET multiplex where SPEs are=20 numbered from 1 to N (before any interleaving).=20 =20 When a transparent concatenated STM-N/STS-3*N (N=3D1, 4, 16, 64,=20 256) is requested, the label is coded as for the case of=20 contiguous concatenation and with S=3D1. I.e. S=3D1, U=3D0, K=3D0, = L=3D0,=20 M=3D0.=20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 11=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 4. Acknowledgments=20 =20 Valuable comments and input were received from many people.=20 =20 =20 5. Security Considerations=20 =20 This draft introduces no new security considerations to either=20 [GMPLS-RSVP] or [GMPLS-LDP].=20 =20 =20 6. References=20 =20 [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -=20 Signaling Functional Description", Internet Draft,=20 draft-ietf-mpls-generalized-signaling-07.txt,=20 November 2001.=20 =20 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -=20 CR-LDP Extensions", Internet Draft,=20 draft-ietf-mpls-generalized-cr-ldp-05.txt,=20 November 2001.=20 =20 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS=20 Signaling - RSVP-TE Extensions", Internet Draft,=20 draft-ietf-mpls-generalized-rsvp-te-06.txt,=20 November 2001.=20 =20 [GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to=20 control non-standard SONET and SDH features",=20 Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-=20 extensions-01.txt, December 2001.=20 =20 [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet=20 Draft, draft-ietf-ccamp-gmpls-architecture-01.txt,=20 November 2001.=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels," RFC 2119.=20 =20 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated=20 Services," RFC 2210, September 1997.=20 =20 =20 7. Authors Addresses=20 =20 Stefan Ansorge=20 Alcatel=20 Lorenzstrasse 10=20 70435 Stuttgart=20 Germany=20 Phone: +49 7 11 821 337 44=20 Email: Stefan.ansorge@alcatel.de=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 12=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Peter Ashwood-Smith=20 Nortel Networks Corp.=20 P.O. Box 3511 Station C,=20 Ottawa, ON K1Y 4H7=20 Canada=20 Phone: +1 613 763 4534=20 Email: petera@nortelnetworks.com=20 =20 Ayan Banerjee=20 Calient Networks=20 5853 Rue Ferrari=20 San Jose, CA 95138=20 Phone: +1 408 972-3645=20 Email: abanerjee@calient.net=20 =20 Lou Berger=20 Movaz Networks, Inc.=20 7926 Jones Branch Drive=20 Suite 615=20 McLean VA, 22102=20 Phone: +1 703 847-1801=20 Email: lberger@movaz.com=20 =20 Greg Bernstein=20 Ciena Corporation=20 10480 Ridgeview Court=20 Cupertino, CA 94014=20 Phone: +1 408 366 4713=20 Email: greg@ciena.com=20 =20 Angela Chiu=20 Celion Networks=20 One Sheila Drive, Suite 2=20 Tinton Falls, NJ 07724-2658=20 Phone: +1 732 747 9987=20 Email: angela.chiu@celion.com=20 =20 John Drake=20 Calient Networks=20 5853 Rue Ferrari=20 San Jose, CA 95138=20 Phone: +1 408 972 3720=20 Email: jdrake@calient.net=20 =20 Yanhe Fan=20 Axiowave Networks, Inc.=20 100 Nickerson Road=20 Marlborough, MA 01752=20 Phone: +1 508 460 6969 Ext. 627=20 Email: yfan@axiowave.com=20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 13=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Michele Fontana=20 Alcatel=20 Via Trento 30,=20 I-20059 Vimercate, Italy=20 Phone: +39 039 686-7053=20 Email: michele.fontana@netit.alcatel.it=20 =20 Gert Grammel=20 Alcatel=20 Via Trento 30,=20 I-20059 Vimercate, Italy=20 Phone: +39 039 686-7060=20 Email: gert.grammel@netit.alcatel.it=20 =20 Juergen Heiles=20 Siemens AG=20 Hofmannstr. 51=20 D-81379 Munich, Germany=20 Phone: +49 89 7 22 - 4 86 64=20 Email: Juergen.Heiles@icn.siemens.de=20 =20 Suresh Katukam=20 Cisco Systems=20 1450 N. McDowell Blvd,=20 Petaluma, CA 94954-6515 USA=20 e-mail: skatukam@cisco.com=20 =20 Kireeti Kompella=20 Juniper Networks, Inc.=20 1194 N. Mathilda Ave.=20 Sunnyvale, CA 94089=20 Email: kireeti@juniper.net=20 =20 Jonathan P. Lang=20 Calient Networks=20 25 Castilian=20 Goleta, CA 93117=20 Email: jplang@calient.net=20 =20 Zhi-Wei Lin=20 101 Crawfords Corner Rd=20 Holmdel, NJ 07733-3030=20 Phone: +1 732 949 5141=20 Email: zwlin@lucent.com=20 =20 Ben Mack-Crane=20 Tellabs=20 Email: Ben.Mack-Crane@tellabs.com=20 =20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 14=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Eric Mannie=20 EBONE=20 Terhulpsesteenweg 6A=20 1560 Hoeilaart - Belgium=20 Phone: +32 2 658 56 52=20 Mobile: +32 496 58 56 52=20 Fax: +32 2 658 51 18=20 Email: eric.mannie@ebone.com=20 =20 Dimitri Papadimitriou=20 Alcatel=20 Francis Wellesplein 1,=20 B-2018 Antwerpen, Belgium=20 Phone: +32 3 240-8491=20 Email: Dimitri.Papadimitriou@alcatel.be=20 =20 Mike Raftelis=20 White Rock Networks=20 18111 Preston Road Suite 900=20 Dallas, TX 75252=20 Phone: +1 (972)588-3728=20 Fax: +1 (972)588-3701=20 Email: Mraftelis@WhiteRockNetworks.com=20 =20 Bala Rajagopalan=20 Tellium, Inc.=20 2 Crescent Place=20 P.O. Box 901=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4237=20 Fax: +1 732 923 9804=20 Email: braja@tellium.com=20 =20 Yakov Rekhter=20 Juniper Networks, Inc.=20 Email: yakov@juniper.net=20 =20 Debanjan Saha=20 Tellium Optical Systems=20 2 Crescent Place=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4264=20 Fax: +1 732 923 9804=20 Email: dsaha@tellium.com=20 =20 Vishal Sharma=20 Metanoia, Inc.=20 335 Elan Village Lane=20 San Jose, CA 95134=20 Phone: +1 408 943 1794=20 Email: vsharma87@yahoo.com=20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 15=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 George Swallow=20 Cisco Systems, Inc.=20 250 Apollo Drive=20 Chelmsford, MA 01824=20 Voice: +1 978 244 8143=20 Email: swallow@cisco.com=20 =20 Z. Bo Tang=20 Tellium, Inc.=20 2 Crescent Place=20 P.O. Box 901=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4231=20 Fax: +1 732 923 9804=20 Email: btang@tellium.com=20 =20 Eve Varma=20 101 Crawfords Corner Rd=20 Holmdel, NJ 07733-3030=20 Phone: +1 732 949 8559=20 Email: evarma@lucent.com=20 =20 Maarten Vissers=20 Botterstraat 45=20 Postbus 18=20 1270 AA Huizen, Netherlands=20 Email: mvissers@lucent.com=20 =20 Yangguang Xu=20 21-2A41, 1600 Osgood Street=20 North Andover, MA 01845=20 Email: xuyg@lucent.com=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 16=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Appendix 1 - Signal Type Values Extension For VC-3=20 =20 This appendix defines the following optional additional Signal=20 Type value for the Signal Type field of section 2.1:=20 =20 Value Type=20 ----- ---------------------=20 20 "VC-3 via AU-3 at the end"=20 =20 According to the G.707 standard a VC-3 in the TU-3/TUG-3/VC-4/AU-4=20 branch of the SDH multiplex cannot be structured in TUG-2s,=20 however a VC-3 in the AU-3 branch can be. In addition, a VC-3=20 could be switched between the two branches if required.=20 =20 A VC-3 circuit could be terminated on an ingress interface of an=20 LSR (e.g. forming a VC-3 forwarding adjacency). This LSR could=20 then want to demultiplex this VC-3 and switch internal low order=20 LSPs. For implementation reasons, this could be only possible if=20 the LSR receives the VC-3 in the AU-3 branch. E.g. for an LSR not=20 able to switch internally from a TU-3 branch to an AU-3 branch on=20 its incoming interface before demultiplexing and then switching=20 the content with its switch fabric.=20 =20 In that case it is useful to indicate that the VC-3 LSP must be=20 terminated at the end in the AU-3 branch instead of the TU-3=20 branch.=20 =20 This is achieved by using the "VC-3 via AU-3 at the end" signal=20 type. This information can be used, for instance, by the=20 penultimate LSR to switch an incoming VC-3 received in any branch=20 to the TU-3 branch on the outgoing interface to the destination=20 LSR.=20 =20 The "VC-3 via AU-3 at the end" signal type does not imply that the=20 VC-3 must be switched via the AU-3 branch at some other places in=20 the network. The VC-3 signal type just indicates that a VC-3 in=20 any branch is suitable.=20 =20 E. Mannie Editor Internet-Draft June 2002 17=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 Annex 1 - Examples=20 =20 This annex defines examples of SONET and SDH signal coding. Their=20 objective is to help the reader to understand how works the traffic=20 parameter coding and not to give examples of typical SONET or SDH=20 signals.=20 =20 As stated above, signal types are Elementary Signals to which=20 successive concatenation, multiplication and transparency=20 transforms can be applied.=20 =20 1. A VC-4 signal is formed by the application of RCC with value 0,=20 NCC with value 0, NVC with value 0, MT with value 1 and T with=20 value 0 to a VC-4 Elementary Signal.=20 =20 2. A VC-4-7v signal is formed by the application of RCC with value=20 0, NCC with value 0, NVC with value 7 (virtual concatenation of 7=20 components), MT with value 1 and T with value 0 to a VC-4=20 Elementary Signal.=20 =20 3. A VC-4-16c signal is formed by the application of RCC with flag=20 1 (standard contiguous concatenation), NCC with value 16, NVC with=20 value 0, MT with value 1 and T with value 0 to a VC-4 Elementary=20 Signal.=20 =20 4. An STM-16 signal with Multiplex Section layer transparency is=20 formed by the application of RCC with value 0, NCC with value 0,=20 NVC with value 0, MT with value 1 and T with flag 2 to an STM-16=20 Elementary Signal.=20 =20 5. An STM-4c signal (i.e. VC-4-4C with the transport overhead)=20 with Multiplex Section layer transparency is formed by the=20 application of RCC with flag 1, NCC with value 1, NVC with value=20 0, MT with value 1 and T with flag 2 applied to an STM-4=20 Elementary Signal.=20 =20 6. An STM-256c signal with Multiplex Section layer transparency is=20 formed by the application of RCC with flag 1, NCC with value 1,=20 NVC with value 0, MT with value 1 and T with flag 2 applied to an=20 STM-256 Elementary Signal.=20 =20 7. An STS-1 SPE signal is formed by the application of RCC with=20 value 0, NCC with value 0, NVC with value 0, MT with value 1 and T=20 with value 0 to an STS-1 SPE Elementary Signal.=20 =20 8. An STS-3c SPE signal is formed by the application of RCC with=20 value 0 (no contiguous concatenation), NCC with value 0, NVC with=20 value 0, MT with value 1 and T with value 0 to an STS-3c SPE=20 Elementary Signal.=20 =20 9. An STS-48c SPE signal is formed by the application of RCC with=20 flag 1 (standard contiguous concatenation), NCC with value 16, NVC=20 with value 0, MT with value 1 and T with value 0 to an STS-3c SPE=20 Elementary Signal.=20 =20 E. Mannie Editor Internet-Draft June 2002 18=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001=20 =20 10. An STS-1-3v SPE signal is formed by the application of RCC=20 with value 0, NVC with value 3 (virtual concatenation of 3=20 components), MT with value 1 and T with value 0 to an STS-1 SPE=20 Elementary Signal.=20 =20 11. An STS-3c-9v SPE signal is formed by the application of RCC=20 with value 0, NCC with value 0, NVC with value 9 (virtual=20 concatenation of 9 STS-3c), MT with value 1 and T with value 0 to=20 an STS-3c SPE Elementary Signal.=20 =20 12. An STS-12 signal with Section layer (full) transparency is=20 formed by the application of RCC with value 0, NVC with value 0,=20 MT with value 1 and T with flag 1 to an STS-12 Elementary Signal.=20 =20 13. 3 x STS-768c SPE signal is formed by the application of RCC=20 with flag 1, NCC with value 256, NVC with value 0, MT with value=20 3, and T with value 0 to an STS-3c SPE Elementary Signal.=20 =20 14. 5 x VC-4-13v composed signal is formed by the application of=20 RCC with value 0, NVC with value 13, MT with value 5 and T with=20 value 0 to a VC-4 Elementary Signal.=20 =20 E. Mannie Editor Internet-Draft June 2002 19=20 =0C ------_=_NextPart_000_01C18432.3B958350 Content-Type: application/octet-stream; name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt" CCAMP Working Group Eric Mannie (Ebone) - Editor=20 Internet Draft =20 Expiration Date: June 2002 Stefan Ansorge (Alcatel)=20 Peter Ashwood-Smith (Nortel)=20 Ayan Banerjee (Calient)=20 Lou Berger (Movaz)=20 Greg Bernstein (Ciena)=20 Angela Chiu (Celion)=20 John Drake (Calient)=20 Yanhe Fan (Axiowave)=20 Michele Fontana (Alcatel)=20 Gert Grammel (Alcatel)=20 Juergen Heiles(Siemens)=20 Suresh Katukam (Cisco)=20 Kireeti Kompella (Juniper)=20 Jonathan P. Lang (Calient)=20 Fong Liaw (Zaffire)=20 Zhi-Wei Lin (Lucent)=20 Ben Mack-Crane (Tellabs)=20 Dimitri Papadimitriou (Alcatel)=20 Dimitrios Pendarakis (Tellium)=20 Mike Raftelis (White Rock)=20 Bala Rajagopalan (Tellium)=20 Yakov Rekhter (Juniper)=20 Debanjan Saha (Tellium)=20 Vishal Sharma (Metanoia)=20 George Swallow (Cisco)=20 Z. Bo Tang (Tellium)=20 Eve Varma (Lucent)=20 Maarten Vissers (Lucent)=20 Yangguang Xu (Lucent)=20 =20 December 2001=20 =20 =20 GMPLS Extensions to Control Non-Standard SONET and SDH Features=20 =20 =20 draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are=20 working documents of the Internet Engineering Task Force (IETF),=20 its areas, and its working groups. Note that other groups may=20 also distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress."=20 =20 E. Mannie Editor 1=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 =20 To view the current status of any Internet-Draft, please check the=20 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow=20 Directory, see http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document is a companion to the GMPLS signaling extensions to=20 control SONET and SDH document [GMPLS-SONET-SDH] that defines the=20 SONET/SDH technology specific information needed when using GMPLS=20 signaling.=20 =20 This informational document defines GMPLS signaling extensions to=20 control four optional non-standard (i.e. proprietary) SONET and=20 SDH features: group signals, arbitrary concatenation, virtual=20 concatenation of contiguously concatenated signals and per byte=20 transparency.=20 =20 =20 1. Introduction=20 =20 Generalized MPLS (GMPLS) [GMPLS-ARCH] extends MPLS from supporting=20 packet (Packet Switching Capable - PSC) interfaces and switching=20 to include support of four new classes of interfaces and=20 switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex=20 (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC).=20 =20 A functional description of the extensions to MPLS signaling=20 needed to support the new classes of interfaces and switching is=20 provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific=20 formats and mechanisms needed to support all five classes of=20 interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. =20 =20 [GMPLS-SONET-SDH] presents details that are specific to SONET/SDH.=20 Per [GMPLS-SIG], SONET/SDH specific parameters are carried in the=20 signaling protocol in traffic parameter specific objects.=20 =20 This informational document defines GMPLS signaling extensions to=20 control four optional non-standard (i.e. proprietary) SONET/SDH=20 features: group signals (section 2), arbitrary concatenation=20 (section 3), virtual concatenation of contiguously concatenated=20 signals (section 4), and per byte transparency (section 5).=20 Section 6 gives examples of SONET/SDH traffic parameters (also=20 referred to as signal coding) when requesting a SONET/SDH LSP.=20 =20 Such features are already implemented or under development by a=20 significant number of manufacturers. For instance, arbitrary=20 concatenation is already implemented in many legacy SONET and SDH=20 equipment that don't support any byte-oriented protocol based=20 control plane.=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 2=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 This document doesn't specify how to implement these features in=20 the transmission plane but how to control their usage with a GMPLS=20 control plane.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"=20 in this document are to be interpreted as described in [RFC2119].=20 =20 =20 2. Signal Type Values Extension For Group Signals=20 =20 This section defines the following optional additional Signal Type=20 values for the Signal Type field of section 2.1 of [GMPLS-SONET- SDH]:=20 =20 Value Type=20 ----- ---------------------=20 13 VTG / TUG-2=20 14 TUG-3=20 15 STSG-3 / AUG-1=20 16 STSG-12 / AUG-4=20 17 STSG-48 / AUG-16=20 18 STSG-192 / AUG-64=20 19 STSG-768 / AUG-256=20 =20 Administrative Unit Group-Ns (AUG-Ns) and STS Groups-3*Ns (STSG-Ms),=20 are logical objects defined as a collection of AU-3s/STS-1 SPEs, AU- 4s/STS-3c SPEs and/or AU-4-Xcs/STS-3*Xc SPEs (X =3D 4,16,64,256).=20 =20 When used as a signal type this means that all the VC-3s/STS-1_SPEs,=20 VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc SPEs in the AU-3s/STS-1 SPEs,=20 AU-4s/STS-3c SPEs or AU-4-Xcs/STS-3*Xc SPEs that comprise the AUG- N/STSG-3*N are switched together as one unique signal.=20 =20 In addition the structure of the VC-3s/STS-1_SPEs, VC-4s/STS-3c_SPEs=20 and VC-4-Xcs/STS-3*Xc_SPEs in the AUG-N/STSG-3*N are preserved and=20 are allowed to change over the life of an AUG-N/STSG-3*N.=20 =20 It is this flexibility in the relationships between the component VCs = or SPEs that differentiates this signal from a set of VC-3s/STS- 1_SPEs, VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc_SPEs. Whether the AUG- N/STSG-3*N is structured with AU-3s/STS-1 SPEs, AU-4s/STS-3c SPEs=20 and/or AU-4-Xcs/STS-3*Xc SPEs does not need to be specified and is=20 allowed to change over time. The same reasoning applies to TUG-2/VTG=20 and TUG-3 signal types.=20 =20 For example an STSG-48 could at one time consist of four STS-12c=20 signals and at another point in time of three STS-12c signals and=20 four STS-3c signals. =20 =20 Note that the use of VTG, TUG-X, AUG-N and STSG-M as circuit types is = not described in ANSI and ITU-T standards. These signal types are=20 conceptual objects that intend to designate a group of physical=20 objects in the data plane.=20 =20 E. Mannie Editor Internet-Draft June 2002 3=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 =20 =20 3. Contiguous Concatenation Extension=20 =20 This section defines the following optional extension flag for the=20 Requested Contiguous Concatenation (RCC) field defined in section=20 2.1 of [GMPLS-SONET-SDH]:=20 =20 Flag 2 (bit 2): Arbitrary contiguous concatenation.=20 =20 This flag allows an upstream node to signal to a downstream node=20 that it supports arbitrary contiguous concatenation. This type of=20 concatenation is not defined by ANSI or ITU-T.=20 =20 Arbitrary contiguous concatenation allows the contiguous=20 concatenation of any number X of VC-4/STS-1 SPE/STS-3c SPE with X=20 less or equal N, resulting in a VC-4-Xa/STS-1-Xa SPE/STS-3c-Xa SPE=20 signal. In addition, it allows the arbitrary contiguous=20 concatenated signal to start at any location (AU-4/STS-1 timeslot)=20 in the STM-N/STS-N signal.=20 =20 This flag can be setup together with Flag 1 (Standard Contiguous=20 Concatenation) to give a choice to the downstream node. The=20 resulting type of contiguous concatenation can be different at=20 each hop according to the result of the negotiation.=20 =20 A label is assigned following the same rule as for the Standard=20 Contiguous Concatenation (see [GMPLS-SONET-SDH]).=20 =20 =20 4. Virtual Concatenation Extension=20 =20 This section defines the following optional extension for the=20 signals that can be virtually concatenated.=20 =20 In addition to the elementary signal types, which can be virtual=20 concatenated as described in section 2.1 of [GMPLS-SONET-SDH],=20 identical contiguously concatenated signals may be virtually=20 concatenated. In this last case, it allows for instance to request=20 the virtual concatenation of several VC-4-4c/STS-12c SPEs (i.e.=20 per [GMPLS-SONET-SDH] (STS-3c)-4c SPE), or more generally any VC- 4-Xc/STS-3c-Xc SPEs to obtain a VC-4-Xc-Yv/STS-3c-Xc-Yv.=20 =20 The virtual concatenation can also be applied to arbitrary=20 contiguously concatenated signals to form VC-4-Xa-Yv/STS-1-Xa-Yv=20 SPE/STS-3c-Xa-Yv SPE. Note that STS-3c-Xa-Yv SPE signal is=20 described only for completeness of the mechanism defined in this=20 document.=20 =20 The standard definition for virtual concatenation allows each=20 virtual concatenation components to travel over diverse paths.=20 Within GMPLS, virtual concatenation components must travel over=20 the same (component) link if they are part of the same LSP. This=20 is due to the way that labels are bound to a (component) link.=20 =20 E. Mannie Editor Internet-Draft June 2002 4=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 Note however, that the routing of components on different paths is=20 indeed equivalent to establishing different LSPs, each one having=20 its own route. Several LSPs can be initiated and terminated=20 between the same nodes and their corresponding components can then=20 be associated together (i.e. virtually concatenated).=20 =20 In case of virtual concatenation of a contiguously concatenated=20 signal, the same rule as described in section 3 of [GMPLS-SONET- SD] for virtual concatenation applies, except that a component of=20 the virtually concatenated signal is now a contiguously=20 concatenated signal. The first label indicates the first=20 contiguously concatenated signal; the second label indicates the=20 second contiguously concatenated signal, and so on.=20 =20 =20 5. Transparency Extension=20 =20 This section defines the following optional extension for the=20 Transparency field defined in section 2.1 of [GMPLS-SONET-SDH].=20 =20 This "extended" transparency (simply referred here as=20 transparency) can be requested for a particular SOH/RSOH or=20 MSOH/LOH field in the STM-N/STS-N signal.=20 =20 Transparency is not applied at the interfaces of the initiating=20 and terminating LSRs, but is only applied between intermediate=20 LSRs. Moreover, the transparency extensions can be implemented=20 effectively in very different ways, e.g. by forwarding the=20 corresponding overhead bytes unmodified, or by tunneling the=20 bytes. =20 =20 This document specifies neither how transparency is achieved; nor=20 the behavior of the signal at the egress of the transparent=20 network during fault conditions at the ingress of the transparent=20 network or within the transparent network; nor network deployment=20 scenarios. The signaling is independent of these considerations.=20 =20 When the signaling is used between intermediate nodes it is up to=20 a data plane profile or specification to indicate how transparency=20 is effectively achieved in the data plane. When the signaling is=20 used at the interfaces with the initiating and terminating LSRs it=20 is up to the data plane specification to guarantee compliant=20 behavior to G.707/T1.105 under fault free and fault conditions.=20 =20 Note that B1 in the SOH/RSOH is computed over the complete=20 previous frame, if one bit changes, B1 must be re-computed. Note=20 that B2 in the LOH/MSOH is also computed over the complete=20 previous frame, except the SOH/RSOH.=20 =20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 5=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 The different transparency extension flags are the following:=20 =20 Flag 3 (bit 3) : J0.=20 Flag 4 (bit 4) : SOH/RSOH DCC (D1-D3).=20 Flag 5 (bit 5) : LOH/MSOH DCC (D4-D12).=20 Flag 6 (bit 6) : LOH/MSOH Extended DCC (D13-D156).=20 Flag 7 (bit 7) : K1/K2.=20 Flag 8 (bit 8) : E1.=20 Flag 9 (bit 9) : F1.=20 Flag 10 (bit 10): E2.=20 Flag 11 (bit 11): B1.=20 Flag 12 (bit 12): B2.=20 Flag 13 (bit 13): M0.=20 Flag 14 (bit 14): M1.=20 =20 Line/Multiplex Section layer transparency (refer to section 2.1 of=20 [GMPLS-SONET-SDH]) can be combined only with any of the following=20 transparency types: J0, SOH/RSOH DCC (D1-D3), E1, F1; and all=20 other transparency flags must be ignored.=20 =20 Note that the extended LOH/MSOH DCC (D13-D156) is only applicable=20 to (defined for) STS-768/STM-256.=20 =20 If B1 transparency is requested, this means transparency for the bit = error supervision functionality provided by the B1. The B1 contains=20 the BIP8 calculated over the previous RS/Section frame of the STM- N/STS-N signal at the RS/Section termination source. At the=20 RS/Section termination sink the B1 BIP is compared with the local=20 BIP also calculated over the previous RS/Section frame of the STM- N/STS-N. Any difference between the two BIP values is an indication=20 for a bit error that occurred between the termination source and=20 sink. In case of B1 transparency this functionality shall be=20 preserved. This means that a B1 bit error detection as described=20 above performed after the transparent transport (at a RS/Section=20 termination sink) indicates exactly the bit errors that occur=20 between the B1 insertion point (RS/Section termination source) and=20 this point. Any intended changes to the previous RS/Section frame=20 content due to the implementation of the transparency feature (e.g.=20 modifications of the RS/Section overhead, modifications of the=20 payload due to pointer justifications) have to be reflected in the=20 B1 BIP value, it has to be adjusted accordingly.=20 =20 If B2 transparency is requested, this means transparency for the bit = error supervision functionality provided by the B2. The B2 contains=20 the BIP24*N/BIP8*N calculated over the previous MS/Line frame of the = STM-N/STS-N signal at the MS/Line termination source. At the MS/Line = termination sink the B2 BIP is compared with the local BIP also=20 calculated over the previous MS/Line frame of the STM-N/STS-N. Any=20 difference between the two BIP values is an indication for a bit=20 error that occurred between the termination source and sink. In case = of B2 transparency this functionality shall be preserved. This means = that a B2 bit error detection as described above performed after the = transparent transport (at a MS/Line termination sink) indicates=20 exactly the bit errors that occur between the B2 insertion point=20 =20 E. Mannie Editor Internet-Draft June 2002 6=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 (MS/Line termination source) and this point. Any intended changes to = the previous MS/Line frame content due to the implementation of the=20 transparency feature (e.g. modifications of the MS/Line overhead,=20 modifications of the payload due to pointer justifications) have to=20 be reflected in the B2 BIP value, it has to be adjusted accordingly. = =20 =20 M1 and M1/M0 transparency are only meaningful when the B2=20 transparency is requested.=20 =20 =20 6. Examples=20 =20 This section defines examples of SONET and SDH signal coding. Their=20 objective is to help the reader to understand how works the traffic=20 parameter coding and not to give examples of typical SONET or SDH=20 signals.=20 =20 As stated in [GMPLS_SONET_SDH], signal types are Elementary=20 Signals to which successive concatenation, multiplication and=20 transparency transforms can be applied.=20 =20 1. An STM-64 signal with RSOH and MSOH DCCs transparency is formed=20 by the application of RCC with value 0, NCC with value 0, NVC with=20 value 0, MT with value 1 and T with flag 4 and 5 to an STM-64=20 Elementary Signal.=20 =20 2. An STS-192 signal with K1/K2 and LOH DCC transparency is formed=20 by the application of RCC with value 0, NVC with value 0, MT with=20 value 1 and T with flags 5 and 7 to an STS-192 Elementary Signal.=20 =20 3. An STS-48c signal with LOH DCC and E2 transparency is formed by=20 the application of RCC with flag 1, NCC with value 1, NVC with=20 value 0, MT with value 1 and T with flag 5 and 10 to an STS-48=20 Elementary Signal.=20 =20 4. An STS-768c signal with K1/K2 and LOH DCC transparency is=20 formed by the application of RCC with flag 1, NCC with value 1,=20 NVC with value 0, MT with value 1 and T with flag 5 and 7 to an=20 STS-768 Elementary Signal.=20 =20 5. 4 x STS-12 signals with K1/K2 and LOH DCC transparency is=20 formed by the application of RCC with value 0, NVC with value 0,=20 MT with value 4 and T with flags 5 and 7 to an STS-12 Elementary=20 Signal.=20 =20 6. A VC-4-3a signal is formed by the application of RCC with flag=20 2 (arbitrary contiguous concatenation), NCC with value 3, NVC with=20 value 0, MT with value 1 and T with value 0 to a VC-4 Elementary=20 Signal.=20 =20 7. An STS-1-34a SPE signal is formed by the application of RCC=20 with flag 2 (arbitrary contiguous concatenation), NCC with value=20 34, NVC with value 0, MT with value 1 and T with value 0 to an=20 STS-1 SPE Elementary Signal.=20 =20 E. Mannie Editor Internet-Draft June 2002 7=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 =20 8. 2 x STS-1-4a-5v SPE signal is formed by the application of RCC=20 with flag 2 (for arbitrary contiguous concatenation), NCC with=20 value 4, NVC with value 5, MT with value 2 and T with value 0 to=20 an STS-1 SPE Elementary Signal.=20 =20 =20 7. Acknowledgments=20 =20 Valuable comments and input were received from many people.=20 =20 =20 8. Security Considerations=20 =20 This draft introduces no new security considerations to [GMPLS- SONET-SDH].=20 =20 =20 9. References=20 =20 [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -=20 Signaling Functional Description", Internet Draft,=20 draft-ietf-mpls-generalized-signaling-07.txt,=20 November 2001.=20 =20 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -=20 CR-LDP Extensions", Internet Draft,=20 draft-ietf-mpls-generalized-cr-ldp-05.txt,=20 November 2001.=20 =20 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS=20 Signaling - RSVP-TE Extensions", Internet Draft,=20 draft-ietf-mpls-generalized-rsvp-te-06.txt,=20 November 2001.=20 =20 [GMPLS-SONET-SDH] E. Mannie Editor, "GMPLS extensions for SONET=20 and SDH control", Internet Draft,=20 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt, December=20 2001.=20 =20 [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet=20 Draft, draft-ietf-ccamp-gmpls-architecture-01.txt,=20 November 2001.=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels," RFC 2119.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 8=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 10. Authors Addresses=20 =20 Stefan Ansorge=20 Alcatel=20 Lorenzstrasse 10=20 70435 Stuttgart=20 Germany=20 Phone: +49 7 11 821 337 44=20 Email: Stefan.ansorge@alcatel.de=20 =20 Peter Ashwood-Smith=20 Nortel Networks Corp.=20 P.O. Box 3511 Station C,=20 Ottawa, ON K1Y 4H7=20 Canada=20 Phone: +1 613 763 4534=20 Email: petera@nortelnetworks.com=20 =20 Ayan Banerjee=20 Calient Networks=20 5853 Rue Ferrari=20 San Jose, CA 95138=20 Phone: +1 408 972-3645=20 Email: abanerjee@calient.net=20 =20 Lou Berger=20 Movaz Networks, Inc.=20 7926 Jones Branch Drive=20 Suite 615=20 McLean VA, 22102=20 Phone: +1 703 847-1801=20 Email: lberger@movaz.com=20 =20 Greg Bernstein=20 Ciena Corporation=20 10480 Ridgeview Court=20 Cupertino, CA 94014=20 Phone: +1 408 366 4713=20 Email: greg@ciena.com=20 =20 Angela Chiu=20 Celion Networks=20 One Sheila Drive, Suite 2=20 Tinton Falls, NJ 07724-2658=20 Phone: +1 732 747 9987=20 Email: angela.chiu@celion.com=20 =20 John Drake=20 Calient Networks=20 5853 Rue Ferrari=20 San Jose, CA 95138=20 Phone: +1 408 972 3720=20 Email: jdrake@calient.net=20 =20 =20 E. Mannie Editor Internet-Draft June 2002 9=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 Yanhe Fan=20 Axiowave Networks, Inc.=20 100 Nickerson Road=20 Marlborough, MA 01752=20 Phone: +1 508 460 6969 Ext. 627=20 Email: yfan@axiowave.com=20 =20 Michele Fontana=20 Alcatel=20 Via Trento 30,=20 I-20059 Vimercate, Italy=20 Phone: +39 039 686-7053=20 Email: michele.fontana@netit.alcatel.it=20 =20 Gert Grammel=20 Alcatel=20 Via Trento 30,=20 I-20059 Vimercate, Italy=20 Phone: +39 039 686-7060=20 Email: gert.grammel@netit.alcatel.it=20 =20 Juergen Heiles=20 Siemens AG=20 Hofmannstr. 51=20 D-81379 Munich, Germany=20 Phone: +49 89 7 22 - 4 86 64=20 Email: Juergen.Heiles@icn.siemens.de=20 =20 Suresh Katukam=20 Cisco Systems=20 1450 N. McDowell Blvd,=20 Petaluma, CA 94954-6515 USA=20 e-mail: skatukam@cisco.com=20 =20 Kireeti Kompella=20 Juniper Networks, Inc.=20 1194 N. Mathilda Ave.=20 Sunnyvale, CA 94089=20 Email: kireeti@juniper.net=20 =20 Jonathan P. Lang=20 Calient Networks=20 25 Castilian=20 Goleta, CA 93117=20 Email: jplang@calient.net=20 =20 Zhi-Wei Lin=20 101 Crawfords Corner Rd=20 Holmdel, NJ 07733-3030=20 Phone: +1 732 949 5141=20 Email: zwlin@lucent.com=20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 10=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 Ben Mack-Crane=20 Tellabs=20 Email: Ben.Mack-Crane@tellabs.com=20 =20 Eric Mannie=20 EBONE=20 Terhulpsesteenweg 6A=20 1560 Hoeilaart - Belgium=20 Phone: +32 2 658 56 52=20 Mobile: +32 496 58 56 52=20 Fax: +32 2 658 51 18=20 Email: eric.mannie@ebone.com=20 =20 Dimitri Papadimitriou=20 Alcatel=20 Francis Wellesplein 1,=20 B-2018 Antwerpen, Belgium=20 Phone: +32 3 240-8491=20 Email: Dimitri.Papadimitriou@alcatel.be=20 =20 Mike Raftelis=20 White Rock Networks=20 18111 Preston Road Suite 900=20 Dallas, TX 75252=20 Phone: +1 (972)588-3728=20 Fax: +1 (972)588-3701=20 Email: Mraftelis@WhiteRockNetworks.com=20 =20 Bala Rajagopalan=20 Tellium, Inc.=20 2 Crescent Place=20 P.O. Box 901=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4237=20 Fax: +1 732 923 9804=20 Email: braja@tellium.com=20 =20 Yakov Rekhter=20 Juniper Networks, Inc.=20 Email: yakov@juniper.net=20 =20 Debanjan Saha=20 Tellium Optical Systems=20 2 Crescent Place=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4264=20 Fax: +1 732 923 9804=20 Email: dsaha@tellium.com=20 =20 =20 =20 =20 =20 =20 =20 E. Mannie Editor Internet-Draft June 2002 11=20 =0C draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01.txt December, 2001=20 Vishal Sharma=20 Metanoia, Inc.=20 335 Elan Village Lane=20 San Jose, CA 95134=20 Phone: +1 408 943 1794=20 Email: vsharma87@yahoo.com=20 =20 George Swallow=20 Cisco Systems, Inc.=20 250 Apollo Drive=20 Chelmsford, MA 01824=20 Voice: +1 978 244 8143=20 Email: swallow@cisco.com=20 =20 Z. Bo Tang=20 Tellium, Inc.=20 2 Crescent Place=20 P.O. Box 901=20 Oceanport, NJ 07757-0901=20 Phone: +1 732 923 4231=20 Fax: +1 732 923 9804=20 Email: btang@tellium.com=20 =20 Eve Varma=20 101 Crawfords Corner Rd=20 Holmdel, NJ 07733-3030=20 Phone: +1 732 949 8559=20 Email: evarma@lucent.com=20 =20 Maarten Vissers=20 Botterstraat 45=20 Postbus 18=20 1270 AA Huizen, Netherlands=20 Email: mvissers@lucent.com=20 =20 Yangguang Xu=20 21-2A41, 1600 Osgood Street=20 North Andover, MA 01845=20 Email: xuyg@lucent.com=20 =20 E. Mannie Editor Internet-Draft June 2002 12=20 =0C ------_=_NextPart_000_01C18432.3B958350-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 12:26:35 -0800 Message-ID: <3C190C54.DE136B00@lucent.com> Date: Thu, 13 Dec 2001 13:15:16 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: Maarten Vissers , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, It would seem from this standpoint, ANY transport plane protection must use "primary" for all trails. You have already made this argument for the 1+1 case to carry the permanently bridged copy of the payload. In 1:1 or 1:n, when protection is not being used to carry one/any of the normal traffic signals, it may either carry a null signal (no bridge) or transport plane extra traffic. Even if the transport plane has only a null signal on protection, the control plane cannot itself place extra traffic on any portion of the end-to-end protection channel as this is where the APS protocol is carried to coordinate the 1:1 or 1:n protection. The protection channel overhead is chosen to carry the APS since it is necessary to exchange APS bytes to complete a switch when working channels are failed. If the protection channel has failed and APS cannot be exchanged, normal traffic signals will not be selected from protection. Regards, Steve John Drake wrote: > > Maarten, > > That's fine, however it's beside the point. The semantics of > Primary/Secondary refer to the control plane and whether the node > establishing a given LSP is planning to use it at the time it's established > or at a later time. As I indicated in an earlier note, 1+1 transport plane > protection would be accomplished in the control plane by establishing two > LSPs of type Primary. The control plane really doesn't care which LSP the > transport plane is using as Working and which as Protect, although that > information is available to the control plane at the LSP endpoints. > > Thanks, > > John > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Thursday, December 13, 2001 12:15 AM > To: ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > There exist well defined protection terminology in ITU-T for the transport > plane. "Working" and "Protection" are being used and not primary/secondary. > E.g. > a 1+1 architecture has one working connection, one protection connection and > a > permanent bridge. > > Besides working/protection indication for the transport entity, there is > - "active" and "standby" to indicate if the signal is selected from the > working > or protection transport entity; i.e. if selector selects from working, the > working is active and protection is standby, if the selector selects from > protection the working is standby and the protection is active. > - "normal" and "extra traffic" signal. The normal signal is protected. > > Regards, > > Maarten > > neil.2.harrison@bt.com wrote: > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > neil > > > > > -----Original Message----- > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > Sent: 12 December 2001 17:46 > > > To: 'Ben Mack-Crane'; John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > Ben, > > > Please see inline. > > > > > > Thanks, > > > Jonathan > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > To: John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > See comment below. > > > > > > > > Regards, > > > > Ben > > > > > > > > John Drake wrote: > > > > > > > > > > Snipped > > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > To: Lou Berger > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > allocated for a > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > primary LSP fails > > > > > > > over to the secondary LSP." This may not always be > > > > the case. An > > > > > > > explicit flag indicating whether or not extra > > > > traffic may use the > > > > > > > secondary path resources is needed. > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > as indicating > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > protection the > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > Perhaps the problem here is that protection features are > > > > being defined > > > > > before the protection framework and requirements are > > > done. Is this > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > 1+1 and 1:1 > > > > > protection, there would be a pair of Primary LSPs between > > > the source > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > where both the working and recovery paths are call "primary." > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > For 1+1 path protection, both working/recovery paths are > > > carrying user data > > > traffic and it is an endpoint decision as to which path is > > > actually the > > > working/recovery path. At a transit node, both paths need to > > > be treated as > > > primary, as the resources are currently being used and > > > obviously can't be > > > used for Extra Traffic. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 11:33:10 -0800 Message-ID: From: John Drake To: manoj juneja , Eric.Mannie@ebone.com, Juergen.Heiles@icn.siemens.de, mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Date: Thu, 13 Dec 2001 11:24:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric, I spoke with Maarten about such an I-D some time ago, and we both thought it would be a great idea. Thanks, John -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Thursday, December 13, 2001 10:45 AM To: Eric.Mannie@ebone.com; Juergen.Heiles@icn.siemens.de; John Drake; mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Hi Eric, I fully support ur idea of having an informational draft explaining different scenarios of SDH/SONET LSP establishment. The concept of hierarchy is clear in case of SDH/SONET. What about the LSC or FSC interfaces ? 2-3 days back john responded to my question on lambda hierarchy that a lambda LSP can be advertised as a FA with different switching type (say TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am interested in knowing the list of such scenarios in case of LSC or FSC LSP advertised as a FA and its different combinations of switching capabilities as these things are not expalined anywhere. When a head or tail end of LSP advertises it as a FA then how the multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of the FA are decided ? Regards, manoj. >From: "Mannie, Eric" >To: 'Heiles Juergen ' , ''John Drake' ' >, 'Maarten Vissers ' , 'manoj >juneja ' >CC: "'ccamp@ops.ietf.org '" >Subject: RE: Lambda LSP establishment >Date: Thu, 13 Dec 2001 18:56:31 +0100 > >Hi All, > >A few comments, > > >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). >A >FA basically corresponds to a real trail in a circuit switched network. > >Eric: ...and this trail is setup dynamically using GMPLS. That's the >interest. One can think of SDH/SONET FAs as shortcuts or express-routes. > > >One special thing about the SDH label is, that it includes a hierarchy as >it identifies the lower order VC in a higher order VC in a STM-N signal. >Note that this is somehow in contradiction with a statement in the GMPLS >signaling document which says > > >"A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > >No, hierarchy of labels is not hierarchy of layers. And even one should >have >a common definition of what means a "layer". This text says that we cannot >have multiple embedded labels, e.g. one label containting a label stack. >This is a signaling stuff that doesn't imply anything on the transport >plane. > >Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO >in >SDH. The label can be fully specified or partially specified, depending on >the context where the LSP is established. > >E.g. when an LSP is established over a FA, the highest part of the LSP >label >is not relevant. When the FA LSP is established the lowest part of the FA >LSP label is not relevant. > >If a low order LSP is established without any higher order FA, the label is >fully specified. As you said the link is indeed the "ultimate FA" in that >case. Except that from the routing point of view a link and an FA are two >different things. There is a routing adjacency "over" a link but not over a >FA. > >The SDH/SONET label just includes what you need to include in each >scenario. > >Moreover, the label MUST be interpreted according to the type of interface >for which it is used. It is possible to code two labels having the same >value but a complete different meaning. Labels are context sensitive of >course. > >For instance, an LSP over an STM-0 interface or over a FA will have the >highest part set to zero, and could possibly have the same lowest part. You >cannot understand what means the label without knowning the detail of the >interface. In that case, the interface is either an STM-0 interface or a >VC-3 FA. And of course that FA and STM-0 interface are two different >things, >but from the LSP point of view, in both cases what it wants is a VC-3 in >which it can be multiplexed. > >Hope this helps. > >I start to wonder if we should have an informational draft describing >different scenarios of SDH/SONET LSP establishment. That could complement >the SDH/SONET signaling drafts and the GMPLS architecture. That could solve >many terminology and modeling issues. > >Kind regards, > >Eric > >-----Original Message----- >From: Heiles Juergen >To: 'John Drake'; Maarten Vissers; manoj juneja >Cc: ccamp@ops.ietf.org >Sent: 12/13/01 11:15 AM >Subject: RE: Lambda LSP establishment > >Let me express my understanding of FAs in MPLS/GMPLS, please correct me >if I am wrong. I have also some questions related to the label >generation and interactions between layer networks. > >The label in MPLS is local to the link between two adjacent MPLS >switches, it indicates a LSP in this link. This link is therefore the >ultimate FA. An already established LSP between two MPLS switches, which >don't have to be adjacent, can be used to transport/tunnel other LSPs >between this two nodes. This already established LSP generates a virtual >adjacency between the two nodes, the FA. As several LSPs can use this FA >it is also a kind of virtual multiplexing. >If you compare it with a circuit switched network the FA is a server >layer trail that provides transport (a link connection) for one or more >client layer signals. >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, >OTS). A FA basically corresponds to a real trail in a circuit switched >network. >In GMPLS the label is also local to the link between the two devices >that perform the switching. For example for SDH the VC-N is identified >by the STM-N link/port and the SUKLM number according to >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by >the interface ID (I am not sure on this) and SUKLM is the SDH label that >locates the VC within the STM-N. >From just the SDH viewpoint the STM-N connection is the ultimate server >trail/FA. However the STM-N signal could be transported over a Optical >Channel or G.709 ODU. The OCh or ODU can already start in the equipment >that performs the VC-N switching. So the STM-N signal is not the port, >but the WDM signal is the port and the STM-N signal makes use of a OCh >or ODU server layer trail. This server layer trail can be established >via management or using GMPLS. >Can someone explain how a label for a VC-4 is generated in this case >(pre-established OCh or ODU trail via management or setup using GMPLS). >This interaction between the different technologies/labels need in my >view some further explanation. > >One special thing about the SDH label is, that it includes a hierarchy >as it identifies the lower order VC in a higher order VC in a STM-N >signal. Note that this is somehow in contradiction with a statement in >the GMPLS signaling document which says >"A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." >Following this statement each layer should have its own label >independent of server layers. >The combination of hierarchies in labels is based on technology (e.g. >SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The >SDH label for example fits to standard STM-N signals, but not to sub-STM >signals. >For the SDH the full SUKLM number is used if a e.g. VC-12 is located in >relation to a STM-N interface. If it is located in relation to a VC-4 >(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear >in which case I use the first and in which case I use the second case as >a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be >established using management or GMPLS. However it should have no >influence on the label. >Some more information is needed in my view in this area. > > >Juergen > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Wednesday, December 12, 2001 6:54 AM > > To: Maarten Vissers; manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: RE: Lambda LSP establishment > > > > > > fortunately, this is just your opinion > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Tuesday, December 11, 2001 9:31 PM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: Lambda LSP establishment > > > > > > Manoj, > > > > Forget the FA stuff, it is not appropriate in circuit > > networks. It only > > applies > > to MPLS. We should remove it when it is used in relation with PDH, > > SDH/SONET, > > OTN and pre-OTN. The text in sdh-sonet draft should state > > that if there is a > > LOVC link (IETF: link bundle/TE link) then the LOVC signals > > use a label with > > "00KLM". > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > The concept of FA is mentioned for SDH/SONET in > > gmpls-sdh > > > -sonet draft. It says that if u have a HOVC trail as a FA > > (advertized > > > as a link) then u can allocate the lower level signals in > > it by making > > > the higher bits of label as 0s (i.e. S and U}. This is fine > > for the same > > > technology. What about the case where the TDM LSP has to be tunneled > > through > > > the Lambda LSP ? What will be the form of label (i.e. > > {SUKLM} or lambda > > > etc.) ? > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Lambda LSP establishment > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > > > >Manoj, > > > > > > > >You refer to one wavelength to be available between A-E without > > wavelength > > > >conversion capability. This suggests that you operate at > > the OCh layer > > > >network. > > > >Then you specify the capacity of the 4 OCh link > > connections (A-B, B-C, > > C-D, > > > >D-E) > > > >to be "C". Say that C is about 10 Gbit/s. You then assume > > that there is a > > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > > Gbit/s) between C > > and > > > >E. > > > >The result is that the OCh link connections C-D and D-E > > are transporting > > > >the OCh > > > >signal (of e.g. 2.5G). These OCh link connections are now > > in service and > > > >not > > > >longer available to an other OCh connection request. I.e. > > a request for > > an > > > >OCh > > > >connection between A and E will be rejected. > > > > > > > >FAs are not applicable in the circuit layers. IF there is > > a trail in > > server > > > >layer X, then there is a link in its client layer Y. X and > > Y are thus > > > >different > > > >layer networks and signals. > > > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > > be an OCh trail > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > > connection. > > > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > > network. Such is > > not > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >OCh link connections > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I have 5 nodes A, B, C, D and E connected as > > shown. Assume > > > > > that only one wavelength is available on the path A to E (no > > wavelength > > > > > conversion capability is there on the complete path). > > Let the capacity > > > > > of the wavelength be C. Further assume a request arrives for > > connection > > > > > from node C to E for a line capacity of C/4. This > > request will be > > > > > successful as we have available wavelength. Now If > > another request > > > > > comes at node A to establish another connection from > > node A to node E > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > > Should this request > > > > > be successful as we have already allocated the wavelength ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 > > had not been > > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 11:29:57 -0800 Message-ID: From: John Drake To: Heiles Juergen , Maarten Vissers , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Date: Thu, 13 Dec 2001 11:24:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Thursday, December 13, 2001 2:16 AM To: John Drake; Maarten Vissers; manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Let me express my understanding of FAs in MPLS/GMPLS, please correct me if I am wrong. I have also some questions related to the label generation and interactions between layer networks. The label in MPLS is local to the link between two adjacent MPLS switches, it indicates a LSP in this link. This link is therefore the ultimate FA. An already established LSP between two MPLS switches, which don't have to be adjacent, can be used to transport/tunnel other LSPs between this two nodes. This already established LSP generates a virtual adjacency between the two nodes, the FA. As several LSPs can use this FA it is also a kind of virtual multiplexing. JD: What people don't seem to realize is that LSP hierarchy and FAs were developed for GMPLS and not for MPLS. In the case of a non-PSC FA, the virtual multiplexing that you mention is real. If you compare it with a circuit switched network the FA is a server layer trail that provides transport (a link connection) for one or more client layer signals. In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A FA basically corresponds to a real trail in a circuit switched network. JD: However, that 'real trail' may be established dynamically as an FA and its path may include two or more MPLS nodes. To expand on my example of the other day, one might establish an FA LSP of type TDM and capacity OC-192 across a lambda core and advertise it as being able to multiplex four OC-48s. Up to four OC 48 FA LSPs could then be established using this FA LSP as a link. Each of these four OC 48s could then be advertised as FA LSPs and so on. In GMPLS the label is also local to the link between the two devices that perform the switching. For example for SDH the VC-N is identified by the STM-N link/port and the SUKLM number according to draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by the interface ID (I am not sure on this) and SUKLM is the SDH label that locates the VC within the STM-N. >From just the SDH viewpoint the STM-N connection is the ultimate server trail/FA. However the STM-N signal could be transported over a Optical Channel or G.709 ODU. The OCh or ODU can already start in the equipment that performs the VC-N switching. So the STM-N signal is not the port, but the WDM signal is the port and the STM-N signal makes use of a OCh or ODU server layer trail. This server layer trail can be established via management or using GMPLS. Can someone explain how a label for a VC-4 is generated in this case (pre-established OCh or ODU trail via management or setup using GMPLS). This interaction between the different technologies/labels need in my view some further explanation. JD: The details of the SONET/SDH hierarchy are, as I've noted previously, beyond me. However, the general model is that the head and tail ends of an FA LSP communicate directly to allocate a label for a given LSP from the address space of the FA LSP. If that FA LSP is of type TDM, then the label will be a SONET/SDH label. One special thing about the SDH label is, that it includes a hierarchy as it identifies the lower order VC in a higher order VC in a STM-N signal. Note that this is somehow in contradiction with a statement in the GMPLS signaling document which says "A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS- HIERARCHY]." Following this statement each layer should have its own label independent of server layers. The combination of hierarchies in labels is based on technology (e.g. SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The SDH label for example fits to standard STM-N signals, but not to sub-STM signals. For the SDH the full SUKLM number is used if a e.g. VC-12 is located in relation to a STM-N interface. If it is located in relation to a VC-4 (the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear in which case I use the first and in which case I use the second case as a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be established using management or GMPLS. However it should have no influence on the label. Some more information is needed in my view in this area. JD: You're probably right. Juergen > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, December 12, 2001 6:54 AM > To: Maarten Vissers; manoj juneja > Cc: ccamp@ops.ietf.org > Subject: RE: Lambda LSP establishment > > > fortunately, this is just your opinion > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, December 11, 2001 9:31 PM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Lambda LSP establishment > > > Manoj, > > Forget the FA stuff, it is not appropriate in circuit > networks. It only > applies > to MPLS. We should remove it when it is used in relation with PDH, > SDH/SONET, > OTN and pre-OTN. The text in sdh-sonet draft should state > that if there is a > LOVC link (IETF: link bundle/TE link) then the LOVC signals > use a label with > "00KLM". > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in > gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA > (advertized > > as a link) then u can allocate the lower level signals in > it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine > for the same > > technology. What about the case where the TDM LSP has to be tunneled > through > > the Lambda LSP ? What will be the form of label (i.e. > {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without > wavelength > > >conversion capability. This suggests that you operate at > the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link > connections (A-B, B-C, > C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume > that there is a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > Gbit/s) between C > and > > >E. > > >The result is that the OCh link connections C-D and D-E > are transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now > in service and > > >not > > >longer available to an other OCh connection request. I.e. > a request for > an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is > a trail in > server > > >layer X, then there is a link in its client layer Y. X and > Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > be an OCh trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > network. Such is > not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as > shown. Assume > > > > that only one wavelength is available on the path A to E (no > wavelength > > > > conversion capability is there on the complete path). > Let the capacity > > > > of the wavelength be C. Further assume a request arrives for > connection > > > > from node C to E for a line capacity of C/4. This > request will be > > > > successful as we have available wavelength. Now If > another request > > > > comes at node A to establish another connection from > node A to node E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > Should this request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 > had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 10:49:09 -0800 From: "manoj juneja" To: Eric.Mannie@ebone.com, Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Lambda LSP establishment Date: Thu, 13 Dec 2001 11:45:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric, I fully support ur idea of having an informational draft explaining different scenarios of SDH/SONET LSP establishment. The concept of hierarchy is clear in case of SDH/SONET. What about the LSC or FSC interfaces ? 2-3 days back john responded to my question on lambda hierarchy that a lambda LSP can be advertised as a FA with different switching type (say TDM) and then a TDM LSP can be tunneled over a lambda LSP. I am interested in knowing the list of such scenarios in case of LSC or FSC LSP advertised as a FA and its different combinations of switching capabilities as these things are not expalined anywhere. When a head or tail end of LSP advertises it as a FA then how the multiplexing capabilities (like can switch VC-4 but not VC-3 etc.) of the FA are decided ? Regards, manoj. >From: "Mannie, Eric" >To: 'Heiles Juergen ' , ''John Drake' ' >, 'Maarten Vissers ' , 'manoj >juneja ' >CC: "'ccamp@ops.ietf.org '" >Subject: RE: Lambda LSP establishment >Date: Thu, 13 Dec 2001 18:56:31 +0100 > >Hi All, > >A few comments, > > >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). >A >FA basically corresponds to a real trail in a circuit switched network. > >Eric: ...and this trail is setup dynamically using GMPLS. That's the >interest. One can think of SDH/SONET FAs as shortcuts or express-routes. > > >One special thing about the SDH label is, that it includes a hierarchy as >it identifies the lower order VC in a higher order VC in a STM-N signal. >Note that this is somehow in contradiction with a statement in the GMPLS >signaling document which says > > >"A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." > >No, hierarchy of labels is not hierarchy of layers. And even one should >have >a common definition of what means a "layer". This text says that we cannot >have multiple embedded labels, e.g. one label containting a label stack. >This is a signaling stuff that doesn't imply anything on the transport >plane. > >Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO >in >SDH. The label can be fully specified or partially specified, depending on >the context where the LSP is established. > >E.g. when an LSP is established over a FA, the highest part of the LSP >label >is not relevant. When the FA LSP is established the lowest part of the FA >LSP label is not relevant. > >If a low order LSP is established without any higher order FA, the label is >fully specified. As you said the link is indeed the "ultimate FA" in that >case. Except that from the routing point of view a link and an FA are two >different things. There is a routing adjacency "over" a link but not over a >FA. > >The SDH/SONET label just includes what you need to include in each >scenario. > >Moreover, the label MUST be interpreted according to the type of interface >for which it is used. It is possible to code two labels having the same >value but a complete different meaning. Labels are context sensitive of >course. > >For instance, an LSP over an STM-0 interface or over a FA will have the >highest part set to zero, and could possibly have the same lowest part. You >cannot understand what means the label without knowning the detail of the >interface. In that case, the interface is either an STM-0 interface or a >VC-3 FA. And of course that FA and STM-0 interface are two different >things, >but from the LSP point of view, in both cases what it wants is a VC-3 in >which it can be multiplexed. > >Hope this helps. > >I start to wonder if we should have an informational draft describing >different scenarios of SDH/SONET LSP establishment. That could complement >the SDH/SONET signaling drafts and the GMPLS architecture. That could solve >many terminology and modeling issues. > >Kind regards, > >Eric > >-----Original Message----- >From: Heiles Juergen >To: 'John Drake'; Maarten Vissers; manoj juneja >Cc: ccamp@ops.ietf.org >Sent: 12/13/01 11:15 AM >Subject: RE: Lambda LSP establishment > >Let me express my understanding of FAs in MPLS/GMPLS, please correct me >if I am wrong. I have also some questions related to the label >generation and interactions between layer networks. > >The label in MPLS is local to the link between two adjacent MPLS >switches, it indicates a LSP in this link. This link is therefore the >ultimate FA. An already established LSP between two MPLS switches, which >don't have to be adjacent, can be used to transport/tunnel other LSPs >between this two nodes. This already established LSP generates a virtual >adjacency between the two nodes, the FA. As several LSPs can use this FA >it is also a kind of virtual multiplexing. >If you compare it with a circuit switched network the FA is a server >layer trail that provides transport (a link connection) for one or more >client layer signals. >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer >networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, >OTS). A FA basically corresponds to a real trail in a circuit switched >network. >In GMPLS the label is also local to the link between the two devices >that perform the switching. For example for SDH the VC-N is identified >by the STM-N link/port and the SUKLM number according to >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by >the interface ID (I am not sure on this) and SUKLM is the SDH label that >locates the VC within the STM-N. >From just the SDH viewpoint the STM-N connection is the ultimate server >trail/FA. However the STM-N signal could be transported over a Optical >Channel or G.709 ODU. The OCh or ODU can already start in the equipment >that performs the VC-N switching. So the STM-N signal is not the port, >but the WDM signal is the port and the STM-N signal makes use of a OCh >or ODU server layer trail. This server layer trail can be established >via management or using GMPLS. >Can someone explain how a label for a VC-4 is generated in this case >(pre-established OCh or ODU trail via management or setup using GMPLS). >This interaction between the different technologies/labels need in my >view some further explanation. > >One special thing about the SDH label is, that it includes a hierarchy >as it identifies the lower order VC in a higher order VC in a STM-N >signal. Note that this is somehow in contradiction with a statement in >the GMPLS signaling document which says >"A Generalized Label only carries a single level of label, i.e., it is > non-hierarchical. When multiple levels of label (LSPs within LSPs) > are required, each LSP must be established separately, see [MPLS- > HIERARCHY]." >Following this statement each layer should have its own label >independent of server layers. >The combination of hierarchies in labels is based on technology (e.g. >SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The >SDH label for example fits to standard STM-N signals, but not to sub-STM >signals. >For the SDH the full SUKLM number is used if a e.g. VC-12 is located in >relation to a STM-N interface. If it is located in relation to a VC-4 >(the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear >in which case I use the first and in which case I use the second case as >a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be >established using management or GMPLS. However it should have no >influence on the label. >Some more information is needed in my view in this area. > > >Juergen > > > > -----Original Message----- > > From: John Drake [mailto:jdrake@calient.net] > > Sent: Wednesday, December 12, 2001 6:54 AM > > To: Maarten Vissers; manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: RE: Lambda LSP establishment > > > > > > fortunately, this is just your opinion > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Tuesday, December 11, 2001 9:31 PM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: Lambda LSP establishment > > > > > > Manoj, > > > > Forget the FA stuff, it is not appropriate in circuit > > networks. It only > > applies > > to MPLS. We should remove it when it is used in relation with PDH, > > SDH/SONET, > > OTN and pre-OTN. The text in sdh-sonet draft should state > > that if there is a > > LOVC link (IETF: link bundle/TE link) then the LOVC signals > > use a label with > > "00KLM". > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > The concept of FA is mentioned for SDH/SONET in > > gmpls-sdh > > > -sonet draft. It says that if u have a HOVC trail as a FA > > (advertized > > > as a link) then u can allocate the lower level signals in > > it by making > > > the higher bits of label as 0s (i.e. S and U}. This is fine > > for the same > > > technology. What about the case where the TDM LSP has to be tunneled > > through > > > the Lambda LSP ? What will be the form of label (i.e. > > {SUKLM} or lambda > > > etc.) ? > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Lambda LSP establishment > > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > > > >Manoj, > > > > > > > >You refer to one wavelength to be available between A-E without > > wavelength > > > >conversion capability. This suggests that you operate at > > the OCh layer > > > >network. > > > >Then you specify the capacity of the 4 OCh link > > connections (A-B, B-C, > > C-D, > > > >D-E) > > > >to be "C". Say that C is about 10 Gbit/s. You then assume > > that there is a > > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > > Gbit/s) between C > > and > > > >E. > > > >The result is that the OCh link connections C-D and D-E > > are transporting > > > >the OCh > > > >signal (of e.g. 2.5G). These OCh link connections are now > > in service and > > > >not > > > >longer available to an other OCh connection request. I.e. > > a request for > > an > > > >OCh > > > >connection between A and E will be rejected. > > > > > > > >FAs are not applicable in the circuit layers. IF there is > > a trail in > > server > > > >layer X, then there is a link in its client layer Y. X and > > Y are thus > > > >different > > > >layer networks and signals. > > > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > > be an OCh trail > > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > > connection. > > > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > > network. Such is > > not > > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >OCh link connections > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I have 5 nodes A, B, C, D and E connected as > > shown. Assume > > > > > that only one wavelength is available on the path A to E (no > > wavelength > > > > > conversion capability is there on the complete path). > > Let the capacity > > > > > of the wavelength be C. Further assume a request arrives for > > connection > > > > > from node C to E for a line capacity of C/4. This > > request will be > > > > > successful as we have available wavelength. Now If > > another request > > > > > comes at node A to establish another connection from > > node A to node E > > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > > Should this request > > > > > be successful as we have already allocated the wavelength ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > > > If the previous connection from C to E of capacity C/4 > > had not been > > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Send and receive Hotmail on your mobile device: >http://mobile.msn.com _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 10:00:32 -0800 Message-ID: From: "Mannie, Eric" To: 'Heiles Juergen ' , ''John Drake' ' , 'Maarten Vissers ' , 'manoj juneja ' Cc: "'ccamp@ops.ietf.org '" Subject: RE: Lambda LSP establishment Date: Thu, 13 Dec 2001 18:56:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi All, A few comments, >In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A FA basically corresponds to a real trail in a circuit switched network. Eric: ...and this trail is setup dynamically using GMPLS. That's the interest. One can think of SDH/SONET FAs as shortcuts or express-routes. >One special thing about the SDH label is, that it includes a hierarchy as it identifies the lower order VC in a higher order VC in a STM-N signal. Note that this is somehow in contradiction with a statement in the GMPLS signaling document which says >"A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS- HIERARCHY]." No, hierarchy of labels is not hierarchy of layers. And even one should have a common definition of what means a "layer". This text says that we cannot have multiple embedded labels, e.g. one label containting a label stack. This is a signaling stuff that doesn't imply anything on the transport plane. Now, a label identifies ONE LSP at an interface. This LSP can be HO or LO in SDH. The label can be fully specified or partially specified, depending on the context where the LSP is established. E.g. when an LSP is established over a FA, the highest part of the LSP label is not relevant. When the FA LSP is established the lowest part of the FA LSP label is not relevant. If a low order LSP is established without any higher order FA, the label is fully specified. As you said the link is indeed the "ultimate FA" in that case. Except that from the routing point of view a link and an FA are two different things. There is a routing adjacency "over" a link but not over a FA. The SDH/SONET label just includes what you need to include in each scenario. Moreover, the label MUST be interpreted according to the type of interface for which it is used. It is possible to code two labels having the same value but a complete different meaning. Labels are context sensitive of course. For instance, an LSP over an STM-0 interface or over a FA will have the highest part set to zero, and could possibly have the same lowest part. You cannot understand what means the label without knowning the detail of the interface. In that case, the interface is either an STM-0 interface or a VC-3 FA. And of course that FA and STM-0 interface are two different things, but from the LSP point of view, in both cases what it wants is a VC-3 in which it can be multiplexed. Hope this helps. I start to wonder if we should have an informational draft describing different scenarios of SDH/SONET LSP establishment. That could complement the SDH/SONET signaling drafts and the GMPLS architecture. That could solve many terminology and modeling issues. Kind regards, Eric -----Original Message----- From: Heiles Juergen To: 'John Drake'; Maarten Vissers; manoj juneja Cc: ccamp@ops.ietf.org Sent: 12/13/01 11:15 AM Subject: RE: Lambda LSP establishment Let me express my understanding of FAs in MPLS/GMPLS, please correct me if I am wrong. I have also some questions related to the label generation and interactions between layer networks. The label in MPLS is local to the link between two adjacent MPLS switches, it indicates a LSP in this link. This link is therefore the ultimate FA. An already established LSP between two MPLS switches, which don't have to be adjacent, can be used to transport/tunnel other LSPs between this two nodes. This already established LSP generates a virtual adjacency between the two nodes, the FA. As several LSPs can use this FA it is also a kind of virtual multiplexing. If you compare it with a circuit switched network the FA is a server layer trail that provides transport (a link connection) for one or more client layer signals. In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A FA basically corresponds to a real trail in a circuit switched network. In GMPLS the label is also local to the link between the two devices that perform the switching. For example for SDH the VC-N is identified by the STM-N link/port and the SUKLM number according to draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by the interface ID (I am not sure on this) and SUKLM is the SDH label that locates the VC within the STM-N. >From just the SDH viewpoint the STM-N connection is the ultimate server trail/FA. However the STM-N signal could be transported over a Optical Channel or G.709 ODU. The OCh or ODU can already start in the equipment that performs the VC-N switching. So the STM-N signal is not the port, but the WDM signal is the port and the STM-N signal makes use of a OCh or ODU server layer trail. This server layer trail can be established via management or using GMPLS. Can someone explain how a label for a VC-4 is generated in this case (pre-established OCh or ODU trail via management or setup using GMPLS). This interaction between the different technologies/labels need in my view some further explanation. One special thing about the SDH label is, that it includes a hierarchy as it identifies the lower order VC in a higher order VC in a STM-N signal. Note that this is somehow in contradiction with a statement in the GMPLS signaling document which says "A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS- HIERARCHY]." Following this statement each layer should have its own label independent of server layers. The combination of hierarchies in labels is based on technology (e.g. SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The SDH label for example fits to standard STM-N signals, but not to sub-STM signals. For the SDH the full SUKLM number is used if a e.g. VC-12 is located in relation to a STM-N interface. If it is located in relation to a VC-4 (the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear in which case I use the first and in which case I use the second case as a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be established using management or GMPLS. However it should have no influence on the label. Some more information is needed in my view in this area. Juergen > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, December 12, 2001 6:54 AM > To: Maarten Vissers; manoj juneja > Cc: ccamp@ops.ietf.org > Subject: RE: Lambda LSP establishment > > > fortunately, this is just your opinion > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, December 11, 2001 9:31 PM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Lambda LSP establishment > > > Manoj, > > Forget the FA stuff, it is not appropriate in circuit > networks. It only > applies > to MPLS. We should remove it when it is used in relation with PDH, > SDH/SONET, > OTN and pre-OTN. The text in sdh-sonet draft should state > that if there is a > LOVC link (IETF: link bundle/TE link) then the LOVC signals > use a label with > "00KLM". > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in > gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA > (advertized > > as a link) then u can allocate the lower level signals in > it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine > for the same > > technology. What about the case where the TDM LSP has to be tunneled > through > > the Lambda LSP ? What will be the form of label (i.e. > {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without > wavelength > > >conversion capability. This suggests that you operate at > the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link > connections (A-B, B-C, > C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume > that there is a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > Gbit/s) between C > and > > >E. > > >The result is that the OCh link connections C-D and D-E > are transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now > in service and > > >not > > >longer available to an other OCh connection request. I.e. > a request for > an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is > a trail in > server > > >layer X, then there is a link in its client layer Y. X and > Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > be an OCh trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > network. Such is > not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as > shown. Assume > > > > that only one wavelength is available on the path A to E (no > wavelength > > > > conversion capability is there on the complete path). > Let the capacity > > > > of the wavelength be C. Further assume a request arrives for > connection > > > > from node C to E for a line capacity of C/4. This > request will be > > > > successful as we have available wavelength. Now If > another request > > > > comes at node A to establish another connection from > node A to node E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > Should this request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 > had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 08:12:47 -0800 Message-ID: From: John Drake To: Maarten Vissers , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Thu, 13 Dec 2001 08:08:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Maarten, That's fine, however it's beside the point. The semantics of Primary/Secondary refer to the control plane and whether the node establishing a given LSP is planning to use it at the time it's established or at a later time. As I indicated in an earlier note, 1+1 transport plane protection would be accomplished in the control plane by establishing two LSPs of type Primary. The control plane really doesn't care which LSP the transport plane is using as Working and which as Protect, although that information is available to the control plane at the LSP endpoints. Thanks, John -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Thursday, December 13, 2001 12:15 AM To: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 There exist well defined protection terminology in ITU-T for the transport plane. "Working" and "Protection" are being used and not primary/secondary. E.g. a 1+1 architecture has one working connection, one protection connection and a permanent bridge. Besides working/protection indication for the transport entity, there is - "active" and "standby" to indicate if the signal is selected from the working or protection transport entity; i.e. if selector selects from working, the working is active and protection is standby, if the selector selects from protection the working is standby and the protection is active. - "normal" and "extra traffic" signal. The normal signal is protected. Regards, Maarten neil.2.harrison@bt.com wrote: > > Jonathan....review the text below....I think the problem is 1:1. > > neil > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: 12 December 2001 17:46 > > To: 'Ben Mack-Crane'; John Drake > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > Ben, > > Please see inline. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > To: John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > See comment below. > > > > > > Regards, > > > Ben > > > > > > John Drake wrote: > > > > > > > > Snipped > > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > To: Lou Berger > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > allocated for a > > > > > > secondary LSP MAY be used by other LSPs until the > > > primary LSP fails > > > > > > over to the secondary LSP." This may not always be > > > the case. An > > > > > > explicit flag indicating whether or not extra > > > traffic may use the > > > > > > secondary path resources is needed. > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > This is not clear from the definition. The bit is defined > > > as indicating > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > protection the > > > > secondary LSP may not be used for extra traffic. > > > > > > > > Perhaps the problem here is that protection features are > > > being defined > > > > before the protection framework and requirements are > > done. Is this > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > JD: I think the definition of the bit is fine. For both > > > 1+1 and 1:1 > > > > protection, there would be a pair of Primary LSPs between > > the source > > > > and destination, rather than a Primary and a Secondary. > > > > > > This is an unusual use of terms. I have never encountered a case > > > where both the working and recovery paths are call "primary." > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > protection work is immature and not ready for progressing to RFC. > > > > > For 1+1 path protection, both working/recovery paths are > > carrying user data > > traffic and it is an endpoint decision as to which path is > > actually the > > working/recovery path. At a transit node, both paths need to > > be treated as > > primary, as the resources are currently being used and > > obviously can't be > > used for Extra Traffic. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 02:17:46 -0800 Message-ID: From: Heiles Juergen To: "'John Drake'" , Maarten Vissers , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Date: Thu, 13 Dec 2001 11:15:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Let me express my understanding of FAs in MPLS/GMPLS, please correct me if I am wrong. I have also some questions related to the label generation and interactions between layer networks. The label in MPLS is local to the link between two adjacent MPLS switches, it indicates a LSP in this link. This link is therefore the ultimate FA. An already established LSP between two MPLS switches, which don't have to be adjacent, can be used to transport/tunnel other LSPs between this two nodes. This already established LSP generates a virtual adjacency between the two nodes, the FA. As several LSPs can use this FA it is also a kind of virtual multiplexing. If you compare it with a circuit switched network the FA is a server layer trail that provides transport (a link connection) for one or more client layer signals. In MPLS the FA establishes "virtual" layer networks. In GMPLS the layer networks already exist (SDH HO/LO-VCs, RS, MS, G.709 ODUs, OCh, OMS, OTS). A FA basically corresponds to a real trail in a circuit switched network. In GMPLS the label is also local to the link between the two devices that perform the switching. For example for SDH the VC-N is identified by the STM-N link/port and the SUKLM number according to draft-ietf-ccamp-gmpls-sonet-sdh-02.txt. The STM-N port is identified by the interface ID (I am not sure on this) and SUKLM is the SDH label that locates the VC within the STM-N. >From just the SDH viewpoint the STM-N connection is the ultimate server trail/FA. However the STM-N signal could be transported over a Optical Channel or G.709 ODU. The OCh or ODU can already start in the equipment that performs the VC-N switching. So the STM-N signal is not the port, but the WDM signal is the port and the STM-N signal makes use of a OCh or ODU server layer trail. This server layer trail can be established via management or using GMPLS. Can someone explain how a label for a VC-4 is generated in this case (pre-established OCh or ODU trail via management or setup using GMPLS). This interaction between the different technologies/labels need in my view some further explanation. One special thing about the SDH label is, that it includes a hierarchy as it identifies the lower order VC in a higher order VC in a STM-N signal. Note that this is somehow in contradiction with a statement in the GMPLS signaling document which says "A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS- HIERARCHY]." Following this statement each layer should have its own label independent of server layers. The combination of hierarchies in labels is based on technology (e.g. SDH, Sonet, G.709 ODU) but has in my view no real technical reason. The SDH label for example fits to standard STM-N signals, but not to sub-STM signals. For the SDH the full SUKLM number is used if a e.g. VC-12 is located in relation to a STM-N interface. If it is located in relation to a VC-4 (the VC-4 is in this case a FA) SUK are set to 0. For me it is not clear in which case I use the first and in which case I use the second case as a VC-4 trail is always needed for a VC-12 connection. This VC-4 could be established using management or GMPLS. However it should have no influence on the label. Some more information is needed in my view in this area. Juergen > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: Wednesday, December 12, 2001 6:54 AM > To: Maarten Vissers; manoj juneja > Cc: ccamp@ops.ietf.org > Subject: RE: Lambda LSP establishment > > > fortunately, this is just your opinion > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, December 11, 2001 9:31 PM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Lambda LSP establishment > > > Manoj, > > Forget the FA stuff, it is not appropriate in circuit > networks. It only > applies > to MPLS. We should remove it when it is used in relation with PDH, > SDH/SONET, > OTN and pre-OTN. The text in sdh-sonet draft should state > that if there is a > LOVC link (IETF: link bundle/TE link) then the LOVC signals > use a label with > "00KLM". > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in > gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA > (advertized > > as a link) then u can allocate the lower level signals in > it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine > for the same > > technology. What about the case where the TDM LSP has to be tunneled > through > > the Lambda LSP ? What will be the form of label (i.e. > {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without > wavelength > > >conversion capability. This suggests that you operate at > the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link > connections (A-B, B-C, > C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume > that there is a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 > Gbit/s) between C > and > > >E. > > >The result is that the OCh link connections C-D and D-E > are transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now > in service and > > >not > > >longer available to an other OCh connection request. I.e. > a request for > an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is > a trail in > server > > >layer X, then there is a link in its client layer Y. X and > Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would > be an OCh trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer > network. Such is > not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as > shown. Assume > > > > that only one wavelength is available on the path A to E (no > wavelength > > > > conversion capability is there on the complete path). > Let the capacity > > > > of the wavelength be C. Further assume a request arrives for > connection > > > > from node C to E for a line capacity of C/4. This > request will be > > > > successful as we have available wavelength. Now If > another request > > > > comes at node A to establish another connection from > node A to node E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. > Should this request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 > had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Dec 2001 00:16:50 -0800 Message-ID: <3C18638F.75591024@lucent.com> Date: Thu, 13 Dec 2001 09:15:11 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------64509841E5E3E9A093182912" This is a multi-part message in MIME format. --------------64509841E5E3E9A093182912 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There exist well defined protection terminology in ITU-T for the transport plane. "Working" and "Protection" are being used and not primary/secondary. E.g. a 1+1 architecture has one working connection, one protection connection and a permanent bridge. Besides working/protection indication for the transport entity, there is - "active" and "standby" to indicate if the signal is selected from the working or protection transport entity; i.e. if selector selects from working, the working is active and protection is standby, if the selector selects from protection the working is standby and the protection is active. - "normal" and "extra traffic" signal. The normal signal is protected. Regards, Maarten neil.2.harrison@bt.com wrote: > > Jonathan....review the text below....I think the problem is 1:1. > > neil > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: 12 December 2001 17:46 > > To: 'Ben Mack-Crane'; John Drake > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > Ben, > > Please see inline. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > To: John Drake > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > See comment below. > > > > > > Regards, > > > Ben > > > > > > John Drake wrote: > > > > > > > > Snipped > > > > > > > > -----Original Message----- > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > To: Lou Berger > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > allocated for a > > > > > > secondary LSP MAY be used by other LSPs until the > > > primary LSP fails > > > > > > over to the secondary LSP." This may not always be > > > the case. An > > > > > > explicit flag indicating whether or not extra > > > traffic may use the > > > > > > secondary path resources is needed. > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > This is not clear from the definition. The bit is defined > > > as indicating > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > protection the > > > > secondary LSP may not be used for extra traffic. > > > > > > > > Perhaps the problem here is that protection features are > > > being defined > > > > before the protection framework and requirements are > > done. Is this > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > JD: I think the definition of the bit is fine. For both > > > 1+1 and 1:1 > > > > protection, there would be a pair of Primary LSPs between > > the source > > > > and destination, rather than a Primary and a Secondary. > > > > > > This is an unusual use of terms. I have never encountered a case > > > where both the working and recovery paths are call "primary." > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > protection work is immature and not ready for progressing to RFC. > > > > > For 1+1 path protection, both working/recovery paths are > > carrying user data > > traffic and it is an endpoint decision as to which path is > > actually the > > working/recovery path. At a transit node, both paths need to > > be treated as > > primary, as the resources are currently being used and > > obviously can't be > > used for Extra Traffic. > > --------------64509841E5E3E9A093182912 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------64509841E5E3E9A093182912-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 17:28:54 -0800 Message-ID: From: "Karmakar, Soumen" To: "'Robin Qiu'" , ccamp@ops.ietf.org Subject: RE: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages Date: Wed, 12 Dec 2001 17:25:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi Robin, Between the pair of UNI C and UNI N there can be multiple control channels where they can be used simultaneously or in primary/backup modes. That really doesn't matter as long as the "signalling channel" which is a bunch of all IPCCs between these two nodes are up. Hence the node Ids are used in ip header. Since in optical links there may not be one to one association of signalling and data channels the RSVP_HOP object was modified to carry the extra information of data channels (by adding the TLVs) . See RFC 2205 for use of the RSVP_HOP object . Depending on the IPCC being numbered/unnumbered the IPv4_IF_ID_RSVP_HOP object is used to identify the IPCC ; i.e combination of hop address (node address) and interface id used for unnumbered, in numbered use the IP address (of ipcc) and lih is not used. Soumen > -----Original Message----- > From: Robin Qiu [mailto:robin_qiu@hotmail.com] > Sent: Wednesday, December 12, 2001 9:18 AM > To: ccamp@ops.ietf.org > Subject: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages > > > Hi, > > Can anyone help on this? > > In UNI125.7, 12.4.2, it says that the IP header for UNI RSVP messages > must be set to the NodeId of the UNI peer. In section 9.3, it > also says > that for ServiceDiscovery LMP messages, the destination IP address is > set to the NodeId of the recipient. > > Question: how do you force to use a specific IPCC you selected, > assuming that the selected IPCC has a different address? > > Thanks. > > Robin Qiu > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 12:49:22 -0800 Message-Id: <4.3.2.7.2.20011212153211.01fdb7c0@mo-ex1> Date: Wed, 12 Dec 2001 15:46:19 -0500 To: "Zhi-Wei Lin" From: Lou Berger Subject: Re: Moving right along ... generalized-signaling-06 Cc: "Ben Mack-Crane" , "John Drake" ,"Berger, Lou" , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Zhi, Ben, Most (if not all) of the flags in this object have been there from day one of the GMPLS draft. They have been presented, discussed, and agreed to in multiple WG sessions. The WG also decided (maybe in summer'00?) to defer other, more detailed/complex protection until we completed these drafts. Time to move on... Lou At 12:36 PM 12/12/2001, Zhi-Wei Lin wrote: >Hi Ben, > >Yes I agree. Maybe given the status of protection and complexities that >it would introduce, can we treat it as a separate "function" of GMPLS >and pull it out of the current document and into a new document that >deals exclusively with protection? > >It would be a (relatively) simple task: > >(1) Remove section 7 of gmpls-sig doc >(2) Remove section 6 of gmpls-rsvpte doc >(3) Remove section 6 of gmpls-crldp doc > >and put these sections under a new document called gmpls-recovery (or >gmpls-protection) and then start work on this separately. > >Zhi > >Ben Mack-Crane wrote: > > > Zhi, > > > > A while ago there was a draft proposing a fairly comprehensive > > signaling solution for protection. At the time, there was not > > as much support for working on protection as there is now. > > > > There are several attributes that could be signaled in setting up > > a protection mechanism, including > > > > - whether the path is a working or recovery path > > - what notification mechanism is used to trigger the protection mechanism > > - hold-off time > > - wait-to-restore time, and > > - revertive operation > > > > This was an early draft, so there may be other attributes needed, or some > > simplification might be possible. In any case, the working group must > > decide how to progress the protection work. I don't think it is a good > > idea to take an ill-defined (and perhaps incomplete) solution to RFC. > > > > Regards, > > Ben > > > > Zhi-Wei Lin wrote: > > > >>Hi, > >> > >>To further the discussion, would it be possible to add a new flag for > >>purpose of identifying whether or not a connection (secondary > >>connection) can support extra traffic. A 1:1 connection should be able > >>to support extra traffic (if secondary is not used) while a 1+1 would > >>not support extra traffic. > >> > >>Also, we may want to add a flag for whether or not a protection is > >>revertive. > >> > >>Also, current "link flags" is assumed to provide link protection. Maybe > >>we can add a new flag for either "link" or "path" protection. > >> > >>So the total is three new flags using 3 bits, out of the current 25 > >>reserved bits. > >> > >>What do you think? > >>Zhi > >> > >>John Drake wrote: > >> > >> > >>>Snipped > >>> > >>>-----Original Message----- > >>>From: Ben Mack-Crane > [mailto:Ben.Mack-Crane@tellabs.com] > >>>Sent: Tuesday, December 11, 2001 6:38 AM > >>>To: Lou Berger > >>>Cc: Kireeti Kompella; ccamp@ops.ietf.org > >>>Subject: Re: Moving right along ... generalized-signaling-06 > >>> > >>> > >>> > >>> > >>>>>7) In Protection Information it states "The resources allocated for a > >>>>> secondary LSP MAY be used by other LSPs until the primary LSP fails > >>>>> over to the secondary LSP." This may not always be the case. An > >>>>> explicit flag indicating whether or not extra traffic may use the > >>>>> secondary path resources is needed. > >>>>> > >>>>> > >>>>??? This is the purpose of this bit. > >>>> > >>>> > >>>This is not clear from the definition. The bit is defined as indicating > >>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the > >>>secondary LSP may not be used for extra traffic. > >>> > >>>Perhaps the problem here is that protection features are being defined > >>>before the protection framework and requirements are done. Is this > >>>presupposing some particular outcome of the recovery work in CAMP? > >>> > >>>JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > >>>protection, there would be a pair of Primary LSPs between the source > >>>and destination, rather than a Primary and a Secondary. > >>> > >>> > >>> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 12:44:13 -0800 From: "Raju Venkatraman" To: ccamp@ops.ietf.org Bcc: Subject: Reception of RSVP packets at intermediate node Date: Wed, 12 Dec 2001 20:40:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Sorry for posting this question on this mailing list but I'd appreciate any help to my question. Is there a socket option to intercept and receive RSVP protocol messages at intermediate node on Sun Solaris [reception of packets not destined to this intermediate node]? The pacekts with router alert option are just not being intercepted at intermediate node. At intermediate node, when such packet is received an ICMP packet is being sent towards upstream node with cause "Bad Protocol (46), Destination Unreachable". Any help would be greatly appreciated. Regards. Raju _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 12:36:27 -0800 Message-Id: <4.3.2.7.2.20011212151017.01c38990@mo-ex1> Date: Wed, 12 Dec 2001 15:30:45 -0500 To: "Ben Mack-Crane" From: Lou Berger Subject: Re: Moving right along ... generalized-rsvp-te-05 Cc: "Berger, Lou" , "Kireeti Kompella" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ben, see below for topics not covered in other threads. Lou At 09:37 AM 12/11/2001, Ben Mack-Crane wrote: >See comments below. > >Regards, >Ben > >Lou Berger wrote: > > > > At 03:08 PM 10/29/2001, Ben Mack-Crane wrote: > > > > >After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt > > >I have the following comments and questions: > > > > > >1) In the procedures regarding the Generalized Label Request > > > object, the statement is made that "The node may either > > > directly support the LSP or it may use a tunnel (FA), > > > i.e., another class of switching." > > > > please see the routing drafts. > >Will these tell me that an FA is a type of switching? I still think >that's not accurate. [covered in other threads] > > > > >A Tunnel (FA) is a type > > > of link, not a class of switching. This adds to the > > > confusion I've noted about the need for and use of Switching > > > Type. > >Switching Type continues to be ill-defined. I have heard that the real >definition is different from that given in the current drafts. If the >signaling information is not clearly defined and it's use described, we >can hardly expect interoperability. I can't speak for others. My belief is that there is a very concrete definition. I thought the text in the draft was clear as well, but let me try again: Switching Type: 8 bits Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field contains one of the values advertised for the corresponding link in the routing Switching Capability field as defined in [GMPLS-RTG]. In other words, on links where one Switching Capability is advertised (which will be all the time for most equipment) Switching Type is set to the same value as advertised in routing. On links where multiple Switching Capabilities are advertised, Switching Type is set to the value advertised in Switching Capability that matches the type of switching to be performed. [I'll put the revised text in the next rev...] > > > > >2) Bandwidth Encoding use of the Intserv Tspec object seems > > > quite unusual since this use is not consistent with existing > > > uses of this object, and new uses could easily use a new > > > C-Type. > > > > I think either approach work. This topic was discussed by the authors at > > least 12-18 months. The current approach was decided then. > >It was discussed and rejected for TDM. >At least we should clarify the >applicability for this use of the Intserv Tspec. There was text to this affect in one version. We removed it based on a comment that as the drafts are not technology specific, the comment was inappropriate. As we clearly can't please everyone all the time, the current text will stand. > > > > >3) In the procedures for Generalized Label it states "If the label is > > > unacceptable then the recipient MUST generate a ResvErr message with > > > a "Routing problem/MPLS label allocation failure" indication." > > > I think "Unacceptable Label Value" would be more appropriate. > > > > okay. > > > > >4) In the Waveband Switching section it says "For compatibility reasons, > > > a new RSVP C-Type (3) is assigned." What is the compatability > > > problem this is solving? > > > > simply to distinguish types. I remove the text to avoid such confusion in > > the future. > > > > >5) In the Label Set object, why is the Label Type field 14 bits if > > > only the low order 8 bits are used? > > > > for CR-LDP compatibility. > > > > >6) Some new error strings are defined, "Label Set" and "Unsupported Link > > > Protection," but no values or placeholders are included. Where are > new > > > error values to be documented? > > > > As part of IANA assignment. > >Is this to be added to the IANA Considerations section or is it a new >document? The document will be updated when values are assigned in the appropriate places. Most are marked by TBA. > > > > >7) The Notify message is intended to "enable expedited notification of > > > failures," but it relies on the IP layer which may be affected by the > > > failure that the Notify is reporting. This could defeat the goal > > > of rapid notification. Without some means of guaranteeing the Notify > > > doesn't have to wait for IP routing convergence to be delivered, > > > it isn't a satisfactory solution. > > > > >Well? Does anyone else have thoughts on this? > > > >8) The description of the C-Type field in the Label ERO subobject > suggests > > > that this subobject contains a Label Object. Is this the case, or > does > > > the Label ERO subobject simple contain label values, and the C-Type > > > matches the C-Type that would be used if the same label values were > > > included in a Label object? > > > > per the draft: > > > > Label: Variable > > > > This field identifies the label to be used. The format of this > > field is identical to the one used by the Label field in > > Generalized Label, see Section 3.2.1. > > > > >9) In deleting an LSP from the egress, the R bit is set in the Admin > Status > > > object. The ingress responds with a PathTear message. Does this > PathTear > > > contain the Admin Status object or should the R bit be cleared? > > > > It's not in the BNF, so no it's not included. > > > >So perhaps we should change > > 1. The egress node indicates its desire for deletion by inserting > an Admin Status Object in a Resv message and setting the Reflect (R) > and Delete (D) bits. > >to > > 1. The egress node indicates its desire for deletion by inserting > an Admin Status Object in a Resv message and setting the > Delete (D) bit. no. This precludes unique identification of the originator of the D bit. Lou. > > >10)The Notify message may contain a new setting of the Admin Status. > > > Under what conditions would an intermediate or egress node change > > > Admin Status? > > > > It may be used at any time that a PathErr or ResvErr is generated. > > > > > What happens if the Notify receiver is not the ingress? > > > > same action as would be taken if/when the corresponding message is > received. > > > > >11)In Interface Identification it says "Data channels are specified from > > >the view point > > > of the sender of the Path message." Is this true even for Resv > messages > > > or should it read "Data channels are specified from the viewpoint > > > of the sender of the message."? > > > > current text is correct. > > > > >12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be > > > suppressed during this waiting period." I assume this is refreshes > > > toward the failed neighbor, not to all neighbors for that LSP. True? > > > > yes. > > > > thanks for the comments, > > lou > > > > >Regards, > > >Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 11:07:39 -0800 Message-ID: From: John Drake To: Ben Mack-Crane , Jonathan Lang Cc: Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Wed, 12 Dec 2001 11:01:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] Sent: Wednesday, December 12, 2001 10:10 AM To: Jonathan Lang Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Jonathan, I agree that both the working and recovery paths must be connected and carrying traffic (except at the egress). It is a problem that the term "primary" is being overloaded to indicate both "working" and "connected in transit nodes". JD: The fact that you don't understand the semantics of the Primary/Secondary bit doesn't necessarily mean that they're incorrect If it is an endpoint decision as to which is the working and which is the recovery path, this seems to add more complexity to the operator's job in setting up protected paths. JD: Assertion It would seem quite reasonable to signal which path is which. JD: And why would the intermediate nodes care? Regards, Ben Jonathan Lang wrote: > > Ben, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Wednesday, December 12, 2001 8:56 AM > > To: John Drake > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > See comment below. > > > > Regards, > > Ben > > > > John Drake wrote: > > > > > > Snipped > > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > To: Lou Berger > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > allocated for a > > > > > secondary LSP MAY be used by other LSPs until the > > primary LSP fails > > > > > over to the secondary LSP." This may not always be > > the case. An > > > > > explicit flag indicating whether or not extra > > traffic may use the > > > > > secondary path resources is needed. > > > > > > > > ??? This is the purpose of this bit. > > > > > > This is not clear from the definition. The bit is defined > > as indicating > > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > > secondary LSP may not be used for extra traffic. > > > > > > Perhaps the problem here is that protection features are > > being defined > > > before the protection framework and requirements are done. Is this > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > JD: I think the definition of the bit is fine. For both > > 1+1 and 1:1 > > > protection, there would be a pair of Primary LSPs between the source > > > and destination, rather than a Primary and a Secondary. > > > > This is an unusual use of terms. I have never encountered a case > > where both the working and recovery paths are call "primary." > > > > This is not consistent with either draft-mpls-recovery-framework > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > protection work is immature and not ready for progressing to RFC. > > > For 1+1 path protection, both working/recovery paths are carrying user data > traffic and it is an endpoint decision as to which path is actually the > working/recovery path. At a transit node, both paths need to be treated as > primary, as the resources are currently being used and obviously can't be > used for Extra Traffic. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:46:14 -0800 Message-ID: From: neil.2.harrison@bt.com To: jplang@calient.net, Ben.Mack-Crane@tellabs.com, jdrake@calient.net Cc: lberger@movaz.com, kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Wed, 12 Dec 2001 18:39:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan....review the text below....I think the problem is 1:1. neil > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: 12 December 2001 17:46 > To: 'Ben Mack-Crane'; John Drake > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > Subject: RE: Moving right along ... generalized-signaling-06 > > > Ben, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Wednesday, December 12, 2001 8:56 AM > > To: John Drake > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > See comment below. > > > > Regards, > > Ben > > > > John Drake wrote: > > > > > > Snipped > > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > To: Lou Berger > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > allocated for a > > > > > secondary LSP MAY be used by other LSPs until the > > primary LSP fails > > > > > over to the secondary LSP." This may not always be > > the case. An > > > > > explicit flag indicating whether or not extra > > traffic may use the > > > > > secondary path resources is needed. > > > > > > > > ??? This is the purpose of this bit. > > > > > > This is not clear from the definition. The bit is defined > > as indicating > > > the LSP is a secondary (or protecting) LSP and in 1+1 > protection the > > > secondary LSP may not be used for extra traffic. > > > > > > Perhaps the problem here is that protection features are > > being defined > > > before the protection framework and requirements are > done. Is this > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > JD: I think the definition of the bit is fine. For both > > 1+1 and 1:1 > > > protection, there would be a pair of Primary LSPs between > the source > > > and destination, rather than a Primary and a Secondary. > > > > This is an unusual use of terms. I have never encountered a case > > where both the working and recovery paths are call "primary." > > > > This is not consistent with either draft-mpls-recovery-framework > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > protection work is immature and not ready for progressing to RFC. > > > For 1+1 path protection, both working/recovery paths are > carrying user data > traffic and it is an endpoint decision as to which path is > actually the > working/recovery path. At a transit node, both paths need to > be treated as > primary, as the resources are currently being used and > obviously can't be > used for Extra Traffic. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:31:48 -0800 Message-ID: <3C179D68.91ABA75@tellabs.com> Date: Wed, 12 Dec 2001 12:09:44 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Jonathan Lang CC: John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan, I agree that both the working and recovery paths must be connected and carrying traffic (except at the egress). It is a problem that the term "primary" is being overloaded to indicate both "working" and "connected in transit nodes". If it is an endpoint decision as to which is the working and which is the recovery path, this seems to add more complexity to the operator's job in setting up protected paths. It would seem quite reasonable to signal which path is which. Regards, Ben Jonathan Lang wrote: > > Ben, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Wednesday, December 12, 2001 8:56 AM > > To: John Drake > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > See comment below. > > > > Regards, > > Ben > > > > John Drake wrote: > > > > > > Snipped > > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > To: Lou Berger > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > allocated for a > > > > > secondary LSP MAY be used by other LSPs until the > > primary LSP fails > > > > > over to the secondary LSP." This may not always be > > the case. An > > > > > explicit flag indicating whether or not extra > > traffic may use the > > > > > secondary path resources is needed. > > > > > > > > ??? This is the purpose of this bit. > > > > > > This is not clear from the definition. The bit is defined > > as indicating > > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > > secondary LSP may not be used for extra traffic. > > > > > > Perhaps the problem here is that protection features are > > being defined > > > before the protection framework and requirements are done. Is this > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > JD: I think the definition of the bit is fine. For both > > 1+1 and 1:1 > > > protection, there would be a pair of Primary LSPs between the source > > > and destination, rather than a Primary and a Secondary. > > > > This is an unusual use of terms. I have never encountered a case > > where both the working and recovery paths are call "primary." > > > > This is not consistent with either draft-mpls-recovery-framework > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > protection work is immature and not ready for progressing to RFC. > > > For 1+1 path protection, both working/recovery paths are carrying user data > traffic and it is an endpoint decision as to which path is actually the > working/recovery path. At a transit node, both paths need to be treated as > primary, as the resources are currently being used and obviously can't be > used for Extra Traffic. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:25:52 -0800 From: "Bill Breck" To: "Zhi-Wei Lin" , "Ben Mack-Crane" Cc: "John Drake" , "Lou Berger" , "Kireeti Kompella" , Subject: RE: Moving right along ... generalized-signaling-06 Date: Wed, 12 Dec 2001 11:23:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would also strongly support this modularization approach. We design our GMPLS software in this manner - would be great if the drafts also matched that architecture. -Bill Breck GMPLS Architect DeriveIt -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Zhi-Wei Lin Sent: Wednesday, December 12, 2001 9:36 AM To: Ben Mack-Crane Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Hi Ben, Yes I agree. Maybe given the status of protection and complexities that it would introduce, can we treat it as a separate "function" of GMPLS and pull it out of the current document and into a new document that deals exclusively with protection? It would be a (relatively) simple task: (1) Remove section 7 of gmpls-sig doc (2) Remove section 6 of gmpls-rsvpte doc (3) Remove section 6 of gmpls-crldp doc and put these sections under a new document called gmpls-recovery (or gmpls-protection) and then start work on this separately. Zhi Ben Mack-Crane wrote: > Zhi, > > A while ago there was a draft proposing a fairly comprehensive > signaling solution for protection. At the time, there was not > as much support for working on protection as there is now. > > There are several attributes that could be signaled in setting up > a protection mechanism, including > > - whether the path is a working or recovery path > - what notification mechanism is used to trigger the protection mechanism > - hold-off time > - wait-to-restore time, and > - revertive operation > > This was an early draft, so there may be other attributes needed, or some > simplification might be possible. In any case, the working group must > decide how to progress the protection work. I don't think it is a good > idea to take an ill-defined (and perhaps incomplete) solution to RFC. > > Regards, > Ben > > Zhi-Wei Lin wrote: > >>Hi, >> >>To further the discussion, would it be possible to add a new flag for >>purpose of identifying whether or not a connection (secondary >>connection) can support extra traffic. A 1:1 connection should be able >>to support extra traffic (if secondary is not used) while a 1+1 would >>not support extra traffic. >> >>Also, we may want to add a flag for whether or not a protection is >>revertive. >> >>Also, current "link flags" is assumed to provide link protection. Maybe >>we can add a new flag for either "link" or "path" protection. >> >>So the total is three new flags using 3 bits, out of the current 25 >>reserved bits. >> >>What do you think? >>Zhi >> >>John Drake wrote: >> >> >>>Snipped >>> >>>-----Original Message----- >>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>>Sent: Tuesday, December 11, 2001 6:38 AM >>>To: Lou Berger >>>Cc: Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... generalized-signaling-06 >>> >>> >>> >>> >>>>>7) In Protection Information it states "The resources allocated for a >>>>> secondary LSP MAY be used by other LSPs until the primary LSP fails >>>>> over to the secondary LSP." This may not always be the case. An >>>>> explicit flag indicating whether or not extra traffic may use the >>>>> secondary path resources is needed. >>>>> >>>>> >>>>??? This is the purpose of this bit. >>>> >>>> >>>This is not clear from the definition. The bit is defined as indicating >>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the >>>secondary LSP may not be used for extra traffic. >>> >>>Perhaps the problem here is that protection features are being defined >>>before the protection framework and requirements are done. Is this >>>presupposing some particular outcome of the recovery work in CAMP? >>> >>>JD: I think the definition of the bit is fine. For both 1+1 and 1:1 >>>protection, there would be a pair of Primary LSPs between the source >>>and destination, rather than a Primary and a Secondary. >>> >>> >>> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:25:43 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers ' , 'John Drake ' Cc: "'ccamp@ops.ietf.org '" Subject: RE: Lambda LSP establishment Date: Wed, 12 Dec 2001 19:07:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, A FA is mainly a routing concept (you advertise an LSP as a link in the same routing protocol used for the routing of that LSP). The FA concept makes sense for transport networks in many cases, not in other cases. FAs are useful for SONET/SDH, but it doesn't mean that all possible kinds of SDH/SONET LSPs can be advertised as FA. There is not an issue at all, this is just normal operation. A FA is a control plane feature, you cannot expect the IETF to change its terminology for IP routing and signaling, that would not make sense and doesn't present any interest. >The same applies to the switching types TDM, LSC. These do not align with the transport plane's layer network structure. They should be replaced by the proper layer network types. I expect that it will take a few months before this is resolved :-). One should not forget that a lot of people that developed GMPLS work for companies making transport plane products. They manufacture WDM systems, photonic cross-connect, TDM ADMs, TDM cross-connects, etc. They are well established and respected in the transport world. GMPLS was NOT developed by a bunch of IP guys completely ignorant of transmission systems. GMPLS was mainly developed by Sushi cookers (i.e. transport plane experts) that came to the IETF because they thought that it was the right place to develop an IP based control plane for a transport plane. The GMPLS work is mainly about OSPF, ISIS, RSVP-TE, CR-LDP, MPLS, IP addressing, etc. The right place to do extensions on these subjects is the IETF where the control plane experts are. This is the reason why transport plane experts went to the IETF two years ago and started to work on GMPLS. GMPLS is a great example of Sushi guys working with IP guys. It was very successful considering that in the same time frame no other standardization body was able to achieve any other control plane. There is certainly something magic of having IP protocols used in multiple contexts. I would appreciate if people could give the right consideration to the large community of transport plane experts working at the IETF (this message is a general one, not particularly intended to you). As a conclusion, I think that the transport plane experts that developed GMPLS are not dummies and know very well what they are doing. I appreciate your collaboration and the one of Stephen, but I don't consider that your are the only two people having transport and transmission experience in this arena. Kind regards, Eric -----Original Message----- From: Maarten Vissers To: John Drake Cc: ccamp@ops.ietf.org Sent: 12/12/01 3:23 PM Subject: Re: Lambda LSP establishment John, As always it takes some time to recognise the need for changes; I appreciate that. If it is the intention that GMPLS is used to control the transport plane consisting of PDH, SDH/SONET, pre-OTN and OTN then it would be logical that it is based on the transport plane's definitions and terminology. The concept of the MPLS FA isn't applicable for the mentioned technologies. Trying to stick to it in GMPLS is causing confusion and most likely will cause problems in the future. Let's prevent that latter to happen, by replacing the FA by the proper transport plane concepts. The same applies to the switching types TDM, LSC. These do not align with the transport plane's layer network structure. They should be replaced by the proper layer network types. I expect that it will take a few months before this is resolved :-). Regards, Maarten John Drake wrote: > > fortunately, this is just your opinion and some others... > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, December 11, 2001 9:31 PM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Lambda LSP establishment > > Manoj, > > Forget the FA stuff, it is not appropriate in circuit networks. It only > applies > to MPLS. We should remove it when it is used in relation with PDH, > SDH/SONET, > OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a > LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with > "00KLM". > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > > as a link) then u can allocate the lower level signals in it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > > technology. What about the case where the TDM LSP has to be tunneled > through > > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without > wavelength > > >conversion capability. This suggests that you operate at the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, > C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C > and > > >E. > > >The result is that the OCh link connections C-D and D-E are transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now in service and > > >not > > >longer available to an other OCh connection request. I.e. a request for > an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is a trail in > server > > >layer X, then there is a link in its client layer Y. X and Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is > not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > > > that only one wavelength is available on the path A to E (no > wavelength > > > > conversion capability is there on the complete path). Let the capacity > > > > of the wavelength be C. Further assume a request arrives for > connection > > > > from node C to E for a line capacity of C/4. This request will be > > > > successful as we have available wavelength. Now If another request > > > > comes at node A to establish another connection from node A to node E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com <> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:21:55 -0800 Cc: Zhi-Wei Lin , John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Message-ID: <3C179BB1.F4B59F4C@lucent.com> Date: Wed, 12 Dec 2001 19:02:25 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Ben Mack-Crane Original-CC: Zhi-Wei Lin , John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: multipart/mixed; boundary="------------47398F9CE3E792A421662D64" This is a multi-part message in MIME format. --------------47398F9CE3E792A421662D64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben, In ITU-T Q.9/15 work is ongoing to develop a generic protection switching overview document (G.gps). The first draft is available via the Q.9/15 web page: http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.doc http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.pdf This first draft version contains the linear protection switching generic aspects. To be added is the ring protection generic aspects (MS SPring and new OCh SPring and ODUk SPring). Regards, Maarten Ben Mack-Crane wrote: > > Zhi, > > A while ago there was a draft proposing a fairly comprehensive > signaling solution for protection. At the time, there was not > as much support for working on protection as there is now. > > There are several attributes that could be signaled in setting up > a protection mechanism, including > > - whether the path is a working or recovery path > - what notification mechanism is used to trigger the protection mechanism > - hold-off time > - wait-to-restore time, and > - revertive operation > > This was an early draft, so there may be other attributes needed, or some > simplification might be possible. In any case, the working group must > decide how to progress the protection work. I don't think it is a good > idea to take an ill-defined (and perhaps incomplete) solution to RFC. > > Regards, > Ben > > Zhi-Wei Lin wrote: > > > > Hi, > > > > To further the discussion, would it be possible to add a new flag for > > purpose of identifying whether or not a connection (secondary > > connection) can support extra traffic. A 1:1 connection should be able > > to support extra traffic (if secondary is not used) while a 1+1 would > > not support extra traffic. > > > > Also, we may want to add a flag for whether or not a protection is > > revertive. > > > > Also, current "link flags" is assumed to provide link protection. Maybe > > we can add a new flag for either "link" or "path" protection. > > > > So the total is three new flags using 3 bits, out of the current 25 > > reserved bits. > > > > What do you think? > > Zhi > > > > John Drake wrote: > > > > > Snipped > > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > To: Lou Berger > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > >>>7) In Protection Information it states "The resources allocated for a > > >>> secondary LSP MAY be used by other LSPs until the primary LSP fails > > >>> over to the secondary LSP." This may not always be the case. An > > >>> explicit flag indicating whether or not extra traffic may use the > > >>> secondary path resources is needed. > > >>> > > >>??? This is the purpose of this bit. > > >> > > > > > > This is not clear from the definition. The bit is defined as indicating > > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > > secondary LSP may not be used for extra traffic. > > > > > > Perhaps the problem here is that protection features are being defined > > > before the protection framework and requirements are done. Is this > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > > > protection, there would be a pair of Primary LSPs between the source > > > and destination, rather than a Primary and a Secondary. > > > > > > --------------47398F9CE3E792A421662D64 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------47398F9CE3E792A421662D64-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:21:46 -0800 Message-ID: From: Jonathan Lang To: 'Ben Mack-Crane' , Zhi-Wei Lin Cc: John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Wed, 12 Dec 2001 09:56:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ben, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Wednesday, December 12, 2001 9:12 AM > To: Zhi-Wei Lin > Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > > Zhi, > > A while ago there was a draft proposing a fairly comprehensive > signaling solution for protection. At the time, there was not > as much support for working on protection as there is now. I take issue with the above sentences as follows: sentence 1 - "comprehensive" should be replaced with "complex" sentence 2 - there was not much support for the specific proposal. There has always been support for working on protection & restoration. > > There are several attributes that could be signaled in setting up > a protection mechanism, including There are hundreds of attributes that *could* be signaled for setting up a protection mechanism. However, it's not clear that all of them are actually needed. > > - whether the path is a working or recovery path > - what notification mechanism is used to trigger the > protection mechanism > - hold-off time > - wait-to-restore time, and > - revertive operation > > This was an early draft, so there may be other attributes > needed, or some > simplification might be possible. In any case, the working group must > decide how to progress the protection work. I don't think it > is a good > idea to take an ill-defined (and perhaps incomplete) solution to RFC. > > Regards, > Ben > > Zhi-Wei Lin wrote: > > > > Hi, > > > > To further the discussion, would it be possible to add a > new flag for > > purpose of identifying whether or not a connection (secondary > > connection) can support extra traffic. A 1:1 connection > should be able > > to support extra traffic (if secondary is not used) while a > 1+1 would > > not support extra traffic. > > > > Also, we may want to add a flag for whether or not a protection is > > revertive. > > > > Also, current "link flags" is assumed to provide link > protection. Maybe > > we can add a new flag for either "link" or "path" protection. > > > > So the total is three new flags using 3 bits, out of the current 25 > > reserved bits. > > > > What do you think? > > Zhi > > > > John Drake wrote: > > > > > Snipped > > > > > > -----Original Message----- > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > To: Lou Berger > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > >>>7) In Protection Information it states "The resources > allocated for a > > >>> secondary LSP MAY be used by other LSPs until the > primary LSP fails > > >>> over to the secondary LSP." This may not always be > the case. An > > >>> explicit flag indicating whether or not extra traffic > may use the > > >>> secondary path resources is needed. > > >>> > > >>??? This is the purpose of this bit. > > >> > > > > > > This is not clear from the definition. The bit is > defined as indicating > > > the LSP is a secondary (or protecting) LSP and in 1+1 > protection the > > > secondary LSP may not be used for extra traffic. > > > > > > Perhaps the problem here is that protection features are > being defined > > > before the protection framework and requirements are > done. Is this > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > JD: I think the definition of the bit is fine. For both > 1+1 and 1:1 > > > protection, there would be a pair of Primary LSPs between > the source > > > and destination, rather than a Primary and a Secondary. > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:12:49 -0800 Message-ID: <20011212165852.20697.qmail@web20201.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Dec 2001 08:58:52 -0800 (PST) From: Dimitri Papadimitriou Subject: Re: Lambda LSP establishment To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Maarten, You have respond to John that the FA concept is unapplicable to SDH/Sonet, OTN, etc. layered transmission network technologies. Well to this assertion demonstrating that you didn't fully understand the draft-ietf-mpls- lsp-hierarchy-03.txt and that you didn't see the response that Mike Sexton (one of the fathers of the G.805 model) gave to you mid-October in order to explain you that the FA and regions concept are in perfect alignment with G.805. Unfortunately and as always it takes some time for some people to understand concepts that don't come from their own. Thanks, - dimitri. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:09:41 -0800 Message-ID: From: Jonathan Lang To: 'Ben Mack-Crane' , John Drake Cc: Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Wed, 12 Dec 2001 09:45:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ben, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Wednesday, December 12, 2001 8:56 AM > To: John Drake > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > > See comment below. > > Regards, > Ben > > John Drake wrote: > > > > Snipped > > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Tuesday, December 11, 2001 6:38 AM > > To: Lou Berger > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > >7) In Protection Information it states "The resources > allocated for a > > > > secondary LSP MAY be used by other LSPs until the > primary LSP fails > > > > over to the secondary LSP." This may not always be > the case. An > > > > explicit flag indicating whether or not extra > traffic may use the > > > > secondary path resources is needed. > > > > > > ??? This is the purpose of this bit. > > > > This is not clear from the definition. The bit is defined > as indicating > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > secondary LSP may not be used for extra traffic. > > > > Perhaps the problem here is that protection features are > being defined > > before the protection framework and requirements are done. Is this > > presupposing some particular outcome of the recovery work in CAMP? > > > > JD: I think the definition of the bit is fine. For both > 1+1 and 1:1 > > protection, there would be a pair of Primary LSPs between the source > > and destination, rather than a Primary and a Secondary. > > This is an unusual use of terms. I have never encountered a case > where both the working and recovery paths are call "primary." > > This is not consistent with either draft-mpls-recovery-framework > or with draft-lang-ccamp-recovery. I think this is a sign that the > protection work is immature and not ready for progressing to RFC. > For 1+1 path protection, both working/recovery paths are carrying user data traffic and it is an endpoint decision as to which path is actually the working/recovery path. At a transit node, both paths need to be treated as primary, as the resources are currently being used and obviously can't be used for Extra Traffic. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 10:00:03 -0800 Message-ID: <3C17962C.5A5DA340@tellabs.com> Date: Wed, 12 Dec 2001 11:38:53 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: Zhi-Wei Lin , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What does it mean for something to be "a policy decision?" I take this to mean that it must be configured via a management interface. Anything signaling can do can also be done via management. The goal is to signal all the necessary information so that an LSP can be setup to provide the desired service in an interoperable way. Leaving some aspects to "policy" simply means that there is no guarantee that these aspects will be interoperable (or even easy to configure in a uniform way). Regards, Ben John Drake wrote: > > As I understand it, discussion is closed. But to answer your questions: > > 1) No, it's a policy decision at the intermediate node. > > 2) No, revertive behavior is a policy decision at the LSP endpoints > > 3) No, path protection is a policy decision at the LSP endpoints > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Tuesday, December 11, 2001 8:37 AM > To: John Drake > Cc: Ben Mack-Crane; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > Hi, > > To further the discussion, would it be possible to add a new flag for > purpose of identifying whether or not a connection (secondary > connection) can support extra traffic. A 1:1 connection should be able > to support extra traffic (if secondary is not used) while a 1+1 would > not support extra traffic. > > Also, we may want to add a flag for whether or not a protection is > revertive. > > Also, current "link flags" is assumed to provide link protection. Maybe > we can add a new flag for either "link" or "path" protection. > > So the total is three new flags using 3 bits, out of the current 25 > reserved bits. > > What do you think? > Zhi > > John Drake wrote: > > > Snipped > > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Tuesday, December 11, 2001 6:38 AM > > To: Lou Berger > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > >>>7) In Protection Information it states "The resources allocated for a > >>> secondary LSP MAY be used by other LSPs until the primary LSP fails > >>> over to the secondary LSP." This may not always be the case. An > >>> explicit flag indicating whether or not extra traffic may use the > >>> secondary path resources is needed. > >>> > >>??? This is the purpose of this bit. > >> > > > > This is not clear from the definition. The bit is defined as indicating > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > secondary LSP may not be used for extra traffic. > > > > Perhaps the problem here is that protection features are being defined > > before the protection framework and requirements are done. Is this > > presupposing some particular outcome of the recovery work in CAMP? > > > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > > protection, there would be a pair of Primary LSPs between the source > > and destination, rather than a Primary and a Secondary. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:54:57 -0800 Message-ID: <3C179594.3030703@lucent.com> Date: Wed, 12 Dec 2001 12:36:20 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Ben Mack-Crane CC: John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ben, Yes I agree. Maybe given the status of protection and complexities that it would introduce, can we treat it as a separate "function" of GMPLS and pull it out of the current document and into a new document that deals exclusively with protection? It would be a (relatively) simple task: (1) Remove section 7 of gmpls-sig doc (2) Remove section 6 of gmpls-rsvpte doc (3) Remove section 6 of gmpls-crldp doc and put these sections under a new document called gmpls-recovery (or gmpls-protection) and then start work on this separately. Zhi Ben Mack-Crane wrote: > Zhi, > > A while ago there was a draft proposing a fairly comprehensive > signaling solution for protection. At the time, there was not > as much support for working on protection as there is now. > > There are several attributes that could be signaled in setting up > a protection mechanism, including > > - whether the path is a working or recovery path > - what notification mechanism is used to trigger the protection mechanism > - hold-off time > - wait-to-restore time, and > - revertive operation > > This was an early draft, so there may be other attributes needed, or some > simplification might be possible. In any case, the working group must > decide how to progress the protection work. I don't think it is a good > idea to take an ill-defined (and perhaps incomplete) solution to RFC. > > Regards, > Ben > > Zhi-Wei Lin wrote: > >>Hi, >> >>To further the discussion, would it be possible to add a new flag for >>purpose of identifying whether or not a connection (secondary >>connection) can support extra traffic. A 1:1 connection should be able >>to support extra traffic (if secondary is not used) while a 1+1 would >>not support extra traffic. >> >>Also, we may want to add a flag for whether or not a protection is >>revertive. >> >>Also, current "link flags" is assumed to provide link protection. Maybe >>we can add a new flag for either "link" or "path" protection. >> >>So the total is three new flags using 3 bits, out of the current 25 >>reserved bits. >> >>What do you think? >>Zhi >> >>John Drake wrote: >> >> >>>Snipped >>> >>>-----Original Message----- >>>From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] >>>Sent: Tuesday, December 11, 2001 6:38 AM >>>To: Lou Berger >>>Cc: Kireeti Kompella; ccamp@ops.ietf.org >>>Subject: Re: Moving right along ... generalized-signaling-06 >>> >>> >>> >>> >>>>>7) In Protection Information it states "The resources allocated for a >>>>> secondary LSP MAY be used by other LSPs until the primary LSP fails >>>>> over to the secondary LSP." This may not always be the case. An >>>>> explicit flag indicating whether or not extra traffic may use the >>>>> secondary path resources is needed. >>>>> >>>>> >>>>??? This is the purpose of this bit. >>>> >>>> >>>This is not clear from the definition. The bit is defined as indicating >>>the LSP is a secondary (or protecting) LSP and in 1+1 protection the >>>secondary LSP may not be used for extra traffic. >>> >>>Perhaps the problem here is that protection features are being defined >>>before the protection framework and requirements are done. Is this >>>presupposing some particular outcome of the recovery work in CAMP? >>> >>>JD: I think the definition of the bit is fine. For both 1+1 and 1:1 >>>protection, there would be a pair of Primary LSPs between the source >>>and destination, rather than a Primary and a Secondary. >>> >>> >>> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:42:33 -0800 Message-ID: <3C179351.84C0936C@tellabs.com> Date: Wed, 12 Dec 2001 11:26:41 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: CCAMP Subject: Comment on Recovery Effort Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, This is a comment that I was unable to make in the WG meeting yesterday due to time constraints: The CCAMP recovery work includes contributions that are aimed at developing a common terminology for the recovery work. A good amount of effort has already gone into a similar effort in MPLS to produce the draft-ietf-mpls-recovery-framework document, which I think is progressing toward informational RFC. It would be a very good idea if CCAMP would build on this work rather than starting over and defining new terms for the same concepts covered in that document. There are certainly some concepts that apply only to statistical networks; however, many of the concepts, terms and definitions, either apply directly to other technologies (e.g., TDM, optical) or could be relatively easily adjusted to do so. There is also an existing body of work covering recovery mechanisms (particularly protection switching) in the ITU standards (as pointed out by Maarten). The terminology is probably not completely consistent between the ITU and IETF, and perhaps this can be remedied somewhat as well. In any case, starting a new effort to define common terminology is not a good idea. We should build on what is already there. Regards, Ben Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:19:20 -0800 From: "Robin Qiu" To: ccamp@ops.ietf.org Bcc: Subject: NodeId as destinationIpAddress in (UNI) RSVP and LMP messages Date: Wed, 12 Dec 2001 12:17:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can anyone help on this? In UNI125.7, 12.4.2, it says that the IP header for UNI RSVP messages must be set to the NodeId of the UNI peer. In section 9.3, it also says that for ServiceDiscovery LMP messages, the destination IP address is set to the NodeId of the recipient. Question: how do you force to use a specific IPCC you selected, assuming that the selected IPCC has a different address? Thanks. Robin Qiu _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:19:11 -0800 Message-ID: <00b001c18330$ea79bc40$f8c9830c@movaz.com> From: "Adrian Farrel" To: Cc: "Tim Hall" , "Thomas D. Nadeau" , "Edward Harrison" , "Adrian Farrel" , "Cheenu Srinivasan" Subject: MIBs for GMPLS Date: Wed, 12 Dec 2001 12:17:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C18307.0088F570" This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C18307.0088F570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the CCAMP meeting in SLC Tom introduced the set of MIBs for GMPLS = that we have produced. Kireeti asked that we take the MIBs to the list to ensure that the big = issues have been addressed, that everyone is comfortable with the = approach and there really is a need for the MIBs. Requirements are handled by... - protocols within the IETF need MIBs, further=20 draft-ietf-ccamp-gmpls-architecture-01.txt explicitly requires MIBs for GMPLS=20 The biggest issue outstanding was whether the Labels MIB should be = included within the LSR MIB. The authors currently feel that it should = remain as a separate MIB - to allow people to implement only the TE MIB without putting complex conformance statements in the LSR MIB - to allow people to clearly not implement the Labels MIB at all. We would welcome input on this. Please take this opportunity to give us your input and help shape the = MIBs. We hope to respin the drafts in a compilable form in the next few days. The MIBs are... http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00= .txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib= -00.txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00= .txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-0= 0.txt Regards, Adrian -- Adrian Farrel Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com ------=_NextPart_000_00AD_01C18307.0088F570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At the CCAMP meeting in SLC Tom = introduced the=20 set of MIBs for GMPLS that we have produced.
 
Kireeti asked that we take the MIBs = to the list=20 to ensure that the big issues have been addressed, that everyone is = comfortable=20 with the approach and there really is a need for the MIBs.
 
Requirements are handled = by...
 
- protocols within the IETF need = MIBs, further=20
 =20 draft-ietf-ccamp-gmpls-architecture-01.txt
  explicitly requires MIBs for=20 GMPLS 
 
The biggest issue outstanding was = whether the=20 Labels MIB should be included within the LSR MIB.  The authors = currently=20 feel that it should remain as a separate MIB
 
- to allow people to implement only = the TE=20 MIB
  without putting complex = conformance=20 statements
  in the LSR MIB
- to allow people to clearly not = implement=20 the
  Labels MIB at = all.
We would welcome input on = this.
 
 
Please take this opportunity to give = us your=20 input and help shape the MIBs.
 
We hope to respin the drafts in a = compilable form=20 in the next few days.
 
 
The MIBs are...
 
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-tc-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccam= p-gmpls-label-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-te-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-= gmpls-lsr-mib-00.txt
 
 
Regards,
Adrian
 
--
Adrian Farrel
Movaz Networks = Inc.
Tel: 703-847-1867
afarrel@movaz.com
------=_NextPart_000_00AD_01C18307.0088F570-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:16:42 -0800 Message-ID: <3C178FC5.A9898110@tellabs.com> Date: Wed, 12 Dec 2001 11:11:34 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Zhi-Wei Lin CC: John Drake , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi, A while ago there was a draft proposing a fairly comprehensive signaling solution for protection. At the time, there was not as much support for working on protection as there is now. There are several attributes that could be signaled in setting up a protection mechanism, including - whether the path is a working or recovery path - what notification mechanism is used to trigger the protection mechanism - hold-off time - wait-to-restore time, and - revertive operation This was an early draft, so there may be other attributes needed, or some simplification might be possible. In any case, the working group must decide how to progress the protection work. I don't think it is a good idea to take an ill-defined (and perhaps incomplete) solution to RFC. Regards, Ben Zhi-Wei Lin wrote: > > Hi, > > To further the discussion, would it be possible to add a new flag for > purpose of identifying whether or not a connection (secondary > connection) can support extra traffic. A 1:1 connection should be able > to support extra traffic (if secondary is not used) while a 1+1 would > not support extra traffic. > > Also, we may want to add a flag for whether or not a protection is > revertive. > > Also, current "link flags" is assumed to provide link protection. Maybe > we can add a new flag for either "link" or "path" protection. > > So the total is three new flags using 3 bits, out of the current 25 > reserved bits. > > What do you think? > Zhi > > John Drake wrote: > > > Snipped > > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Tuesday, December 11, 2001 6:38 AM > > To: Lou Berger > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > >>>7) In Protection Information it states "The resources allocated for a > >>> secondary LSP MAY be used by other LSPs until the primary LSP fails > >>> over to the secondary LSP." This may not always be the case. An > >>> explicit flag indicating whether or not extra traffic may use the > >>> secondary path resources is needed. > >>> > >>??? This is the purpose of this bit. > >> > > > > This is not clear from the definition. The bit is defined as indicating > > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > > secondary LSP may not be used for extra traffic. > > > > Perhaps the problem here is that protection features are being defined > > before the protection framework and requirements are done. Is this > > presupposing some particular outcome of the recovery work in CAMP? > > > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > > protection, there would be a pair of Primary LSPs between the source > > and destination, rather than a Primary and a Secondary. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:10:13 -0800 Message-ID: <00a201c1832f$a2a330f0$f8c9830c@movaz.com> From: "Adrian Farrel" To: "Don Fedyk" , "ccamp" Cc: "Ash, Gerald R \(Jerry\)" , "Atsushi Iwata" , "Norihito Fujita" , "Simon Marshall-Unitt" Subject: Re: Intra-area Crankback Date: Wed, 12 Dec 2001 12:08:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C18305.B7423850" This is a multi-part message in MIME format. ------=_NextPart_000_009F_01C18305.B7423850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Intra-area CrankbackThanks Don. I've been on the authors list for 18 months and no-one has mentioned = this to me. I will re-read your draft and highlight the differences. Regards, Adrian ----- Original Message -----=20 From: Don Fedyk=20 To: Adrian Farrel ; ccamp=20 Cc: Ash, Gerald R (Jerry) ; Atsushi Iwata ; Norihito Fujita ; Simon = Marshall-Unitt=20 Sent: Wednesday, December 12, 2001 11:54 AM Subject: RE: Intra-area Crankback Adrian=20 The feedback draft is intended for this type of operation.=20 Feedback is best within the area crank back is best outside=20 the area. We discussed all of this with the original authors=20 many many times.=20 Crankback is a primitive from of feedback.=20 Don=20 > -----Original Message-----=20 > From: Adrian Farrel [mailto:afarrel@movaz.com]=20 > Sent: Wednesday, December 12, 2001 11:21 AM=20 > To: ccamp=20 > Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito=20 > Fujita; Simon Marshall-Unitt=20 > Subject: Intra-area Crankback=20 >=20 >=20 > At the CCAMP meeting in Salt Lake City I presented=20 > draft-iwata-mpls-crankback-02.txt=20 >=20 > This has previously been cast as a solution to multi-area=20 > problems, but of=20 > course it is equally useful within an area for collecting=20 > additional error=20 > information and passing it back to repair/re-route points in=20 > the network.=20 >=20 > In fact, the requirements for crankback are more immediate in=20 > the intra-area=20 > case and we would like you to consider the draft in that=20 > context. That the=20 > draft also solves inter-area problems should be seen as an=20 > additional benefit=20 > that can be utilized in the future if and when multi-area=20 > MPLS takes off.=20 >=20 > In summary, the draft allows an ingress to control crankback=20 > by requesting=20 > detailed feedback from the node that detects the failure, and=20 > by selecting the=20 > action that can be taken within the network when failure is=20 > detected/reported.=20 > This additional information supplements the details reported=20 > back (e.g. on=20 > PathErr and GMPLS Notify) and allows recalculation of a path=20 > that avoids the=20 > problem.=20 >=20 > We would welcome your comments and feedback on the need for=20 > crankback both=20 > within and between areas, and on the protocol extensions=20 > proposed in the draft.=20 >=20 > Thanks,=20 > Adrian=20 > --=20 > Adrian Farrel=20 > Movaz Networks Inc.=20 > Tel: 703-847-1867=20 > afarrel@movaz.com=20 >=20 >=20 >=20 >=20 ------=_NextPart_000_009F_01C18305.B7423850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Intra-area Crankback
Thanks Don.
 
I've been on the authors list for 18 = months and=20 no-one has mentioned this to me.
I will re-read your draft and = highlight the=20 differences.
 
Regards,
Adrian
----- Original Message -----
From:=20 Don Fedyk
To: Adrian Farrel ; ccamp
Cc: Ash, Gerald R (Jerry) ; Atsushi=20 Iwata ; Norihito Fujita ; Simon=20 Marshall-Unitt
Sent: Wednesday, December 12, = 2001 11:54=20 AM
Subject: RE: Intra-area = Crankback

Adrian

The feedback draft is intended for this type of=20 operation.
Feedback is best within the area = crank back=20 is best outside
the area. We discussed all = of this=20 with the original authors
many many = times.

Crankback is a primitive from of feedback. =

Don

> -----Original Message-----
>=20 From: Adrian Farrel [mailto:afarrel@movaz.com] =
> Sent: Wednesday, December 12, 2001 11:21 AM =
> To: ccamp
> Cc: Adrian = Farrel; Ash,=20 Gerald R (Jerry); Atsushi Iwata; Norihito
> Fujita;=20 Simon Marshall-Unitt
> Subject: = Intra-area=20 Crankback
>
>=20
> At the CCAMP meeting in Salt Lake City = I=20 presented
>=20 draft-iwata-mpls-crankback-02.txt
>=20
> This has previously been cast as a = solution to=20 multi-area
> problems, but of =
> course it is equally useful within an area for = collecting=20
> additional error
>=20 information and passing it back to repair/re-route points in =
> the network.
> =
> In fact, the requirements for crankback are more = immediate in=20
> the intra-area
> case=20 and we would like you to consider the draft in that
> context.  That the
> = draft also=20 solves inter-area problems should be seen as an
>=20 additional benefit
> that can be utilized = in the=20 future if and when multi-area
> MPLS = takes=20 off.
>
> In = summary, the=20 draft allows an ingress to control crankback
> by=20 requesting
> detailed feedback from the = node that=20 detects the failure, and
> by selecting = the=20
> action that can be taken within the network = when failure=20 is
> detected/reported.
> This additional information supplements the details = reported=20
> back (e.g. on
>=20 PathErr and GMPLS Notify) and allows recalculation of a path =
> that avoids the
> = problem.=20
>
> We would = welcome your=20 comments and feedback on the need for
> = crankback=20 both
> within and between areas, and on = the=20 protocol extensions
> proposed in the = draft.=20
>
> Thanks, =
> Adrian
> -- =
> Adrian Farrel
> Movaz = Networks=20 Inc.
> Tel: 703-847-1867
> afarrel@movaz.com
> =
>
>
>=20

------=_NextPart_000_009F_01C18305.B7423850-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 09:01:04 -0800 Message-ID: <3C178C1F.5296A773@tellabs.com> Date: Wed, 12 Dec 2001 10:55:59 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See comment below. Regards, Ben John Drake wrote: > > Snipped > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Tuesday, December 11, 2001 6:38 AM > To: Lou Berger > Cc: Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > >7) In Protection Information it states "The resources allocated for a > > > secondary LSP MAY be used by other LSPs until the primary LSP fails > > > over to the secondary LSP." This may not always be the case. An > > > explicit flag indicating whether or not extra traffic may use the > > > secondary path resources is needed. > > > > ??? This is the purpose of this bit. > > This is not clear from the definition. The bit is defined as indicating > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > secondary LSP may not be used for extra traffic. > > Perhaps the problem here is that protection features are being defined > before the protection framework and requirements are done. Is this > presupposing some particular outcome of the recovery work in CAMP? > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > protection, there would be a pair of Primary LSPs between the source > and destination, rather than a Primary and a Secondary. This is an unusual use of terms. I have never encountered a case where both the working and recovery paths are call "primary." This is not consistent with either draft-mpls-recovery-framework or with draft-lang-ccamp-recovery. I think this is a sign that the protection work is immature and not ready for progressing to RFC. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 08:56:51 -0800 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6C38CE9@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Adrian Farrel , ccamp Cc: "Ash, Gerald R (Jerry)" , Atsushi Iwata , Norihito Fujita , Simon Marshall-Unitt Subject: RE: Intra-area Crankback Date: Wed, 12 Dec 2001 11:54:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1832D.9EFF1A10" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1832D.9EFF1A10 Content-Type: text/plain; charset="iso-8859-1" Adrian The feedback draft is intended for this type of operation. Feedback is best within the area crank back is best outside the area. We discussed all of this with the original authors many many times. Crankback is a primitive from of feedback. Don > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: Wednesday, December 12, 2001 11:21 AM > To: ccamp > Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito > Fujita; Simon Marshall-Unitt > Subject: Intra-area Crankback > > > At the CCAMP meeting in Salt Lake City I presented > draft-iwata-mpls-crankback-02.txt > > This has previously been cast as a solution to multi-area > problems, but of > course it is equally useful within an area for collecting > additional error > information and passing it back to repair/re-route points in > the network. > > In fact, the requirements for crankback are more immediate in > the intra-area > case and we would like you to consider the draft in that > context. That the > draft also solves inter-area problems should be seen as an > additional benefit > that can be utilized in the future if and when multi-area > MPLS takes off. > > In summary, the draft allows an ingress to control crankback > by requesting > detailed feedback from the node that detects the failure, and > by selecting the > action that can be taken within the network when failure is > detected/reported. > This additional information supplements the details reported > back (e.g. on > PathErr and GMPLS Notify) and allows recalculation of a path > that avoids the > problem. > > We would welcome your comments and feedback on the need for > crankback both > within and between areas, and on the protocol extensions > proposed in the draft. > > Thanks, > Adrian > -- > Adrian Farrel > Movaz Networks Inc. > Tel: 703-847-1867 > afarrel@movaz.com > > > > ------_=_NextPart_001_01C1832D.9EFF1A10 Content-Type: text/html; charset="iso-8859-1" RE: Intra-area Crankback

Adrian

The feedback draft is intended for this type of operation.
Feedback is best within the area crank back is best outside
the area. We discussed all of this with the original authors
many many times.

Crankback is a primitive from of feedback.

Don

> -----Original Message-----
> From: Adrian Farrel [mailto:afarrel@movaz.com]
> Sent: Wednesday, December 12, 2001 11:21 AM
> To: ccamp
> Cc: Adrian Farrel; Ash, Gerald R (Jerry); Atsushi Iwata; Norihito
> Fujita; Simon Marshall-Unitt
> Subject: Intra-area Crankback
>
>
> At the CCAMP meeting in Salt Lake City I presented
> draft-iwata-mpls-crankback-02.txt
>
> This has previously been cast as a solution to multi-area
> problems, but of
> course it is equally useful within an area for collecting
> additional error
> information and passing it back to repair/re-route points in
> the network.
>
> In fact, the requirements for crankback are more immediate in
> the intra-area
> case and we would like you to consider the draft in that
> context.  That the
> draft also solves inter-area problems should be seen as an
> additional benefit
> that can be utilized in the future if and when multi-area
> MPLS takes off.
>
> In summary, the draft allows an ingress to control crankback
> by requesting
> detailed feedback from the node that detects the failure, and
> by selecting the
> action that can be taken within the network when failure is
> detected/reported.
> This additional information supplements the details reported
> back (e.g. on
> PathErr and GMPLS Notify) and allows recalculation of a path
> that avoids the
> problem.
>
> We would welcome your comments and feedback on the need for
> crankback both
> within and between areas, and on the protocol extensions
> proposed in the draft.
>
> Thanks,
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> afarrel@movaz.com
>
>
>
>

------_=_NextPart_001_01C1832D.9EFF1A10-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 08:21:50 -0800 Message-ID: <002401c18328$f17917a0$f8c9830c@movaz.com> From: "Adrian Farrel" To: Cc: "Adrian Farrel" , "Ash, Gerald R \(Jerry\)" , "Atsushi Iwata" , "Norihito Fujita" , "Simon Marshall-Unitt" Subject: Intra-area Crankback Date: Wed, 12 Dec 2001 11:20:40 -0500 At the CCAMP meeting in Salt Lake City I presented draft-iwata-mpls-crankback-02.txt This has previously been cast as a solution to multi-area problems, but of course it is equally useful within an area for collecting additional error information and passing it back to repair/re-route points in the network. In fact, the requirements for crankback are more immediate in the intra-area case and we would like you to consider the draft in that context. That the draft also solves inter-area problems should be seen as an additional benefit that can be utilized in the future if and when multi-area MPLS takes off. In summary, the draft allows an ingress to control crankback by requesting detailed feedback from the node that detects the failure, and by selecting the action that can be taken within the network when failure is detected/reported. This additional information supplements the details reported back (e.g. on PathErr and GMPLS Notify) and allows recalculation of a path that avoids the problem. We would welcome your comments and feedback on the need for crankback both within and between areas, and on the protocol extensions proposed in the draft. Thanks, Adrian -- Adrian Farrel Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 07:15:27 -0800 Message-ID: From: John Drake To: manoj juneja , mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Date: Wed, 12 Dec 2001 07:13:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" A FA would be created over a path consisting of links of switching type lambda, and that FA would then be announced in the link state database with a switching type of TDM. That FA LSP (and bear in mind that other than the Path (?) TLV) there's nothing in the link state database that identifies a link as being a forwarding adjacency) could then be used for the routing of other LSPs, either of switching type TDM according to the SONET/SDH hierarchy rules or of switching type PSC. When the node at the head end of the LSP receives a PATH for such an LSP, it tunnels the PATH to the tail end of the LSP, which then progresses it according to the ERO. The RESV returned by the tail end of the FA LSP to the head end of the FA LSP would contain a SONET or SDH label. -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Tuesday, December 11, 2001 10:50 PM To: John Drake; mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Hi John, Can u please then explain how to tunnel a TDM LSP over Lambda LSP ? I am only interested in what type of labels the tail end of the lambda FA-LSP will send to the head end of lambda LSP for tunneling the TDM LSP. These things are not clear from the drafts as u can see lot of confusions are there regarding these on the mailing list. After carefully reading the drafts, we are still not able to make out what the draft wants to say. I think these things are only clear to the people who either attend the IETF meeting or the authors themselves. One should write the drafts in such a way that these should be helpful to the readers and should not create chaos on the mailing lists. Regards, manoj. >From: John Drake >To: Maarten Vissers , manoj juneja > >CC: ccamp@ops.ietf.org >Subject: RE: Lambda LSP establishment >Date: Tue, 11 Dec 2001 21:53:38 -0800 > >fortunately, this is just your opinion > >-----Original Message----- >From: Maarten Vissers [mailto:mvissers@lucent.com] >Sent: Tuesday, December 11, 2001 9:31 PM >To: manoj juneja >Cc: ccamp@ops.ietf.org >Subject: Re: Lambda LSP establishment > > >Manoj, > >Forget the FA stuff, it is not appropriate in circuit networks. It only >applies >to MPLS. We should remove it when it is used in relation with PDH, >SDH/SONET, >OTN and pre-OTN. The text in sdh-sonet draft should state that if there is >a >LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label >with >"00KLM". > >Regards, > >Maarten > >manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > > as a link) then u can allocate the lower level signals in it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > > technology. What about the case where the TDM LSP has to be tunneled >through > > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without >wavelength > > >conversion capability. This suggests that you operate at the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, >C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is >a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C >and > > >E. > > >The result is that the OCh link connections C-D and D-E are >transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now in service >and > > >not > > >longer available to an other OCh connection request. I.e. a request for >an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is a trail in >server > > >layer X, then there is a link in its client layer Y. X and Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh >trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link >connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is >not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as shown. >Assume > > > > that only one wavelength is available on the path A to E (no >wavelength > > > > conversion capability is there on the complete path). Let the >capacity > > > > of the wavelength be C. Further assume a request arrives for >connection > > > > from node C to E for a line capacity of C/4. This request will be > > > > successful as we have available wavelength. Now If another request > > > > comes at node A to establish another connection from node A to node >E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this >request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2001 06:25:37 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C176847.EEA96443@lucent.com> Date: Wed, 12 Dec 2001 15:23:03 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake Original-CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP establishment Content-Type: multipart/mixed; boundary="------------8B13DB055BAFB764C817E304" This is a multi-part message in MIME format. --------------8B13DB055BAFB764C817E304 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, As always it takes some time to recognise the need for changes; I appreciate that. If it is the intention that GMPLS is used to control the transport plane consisting of PDH, SDH/SONET, pre-OTN and OTN then it would be logical that it is based on the transport plane's definitions and terminology. The concept of the MPLS FA isn't applicable for the mentioned technologies. Trying to stick to it in GMPLS is causing confusion and most likely will cause problems in the future. Let's prevent that latter to happen, by replacing the FA by the proper transport plane concepts. The same applies to the switching types TDM, LSC. These do not align with the transport plane's layer network structure. They should be replaced by the proper layer network types. I expect that it will take a few months before this is resolved :-). Regards, Maarten John Drake wrote: > > fortunately, this is just your opinion and some others... > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, December 11, 2001 9:31 PM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Lambda LSP establishment > > Manoj, > > Forget the FA stuff, it is not appropriate in circuit networks. It only > applies > to MPLS. We should remove it when it is used in relation with PDH, > SDH/SONET, > OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a > LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with > "00KLM". > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > > as a link) then u can allocate the lower level signals in it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > > technology. What about the case where the TDM LSP has to be tunneled > through > > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without > wavelength > > >conversion capability. This suggests that you operate at the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, > C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C > and > > >E. > > >The result is that the OCh link connections C-D and D-E are transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now in service and > > >not > > >longer available to an other OCh connection request. I.e. a request for > an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is a trail in > server > > >layer X, then there is a link in its client layer Y. X and Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link > connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is > not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > > > that only one wavelength is available on the path A to E (no > wavelength > > > > conversion capability is there on the complete path). Let the capacity > > > > of the wavelength be C. Further assume a request arrives for > connection > > > > from node C to E for a line capacity of C/4. This request will be > > > > successful as we have available wavelength. Now If another request > > > > comes at node A to establish another connection from node A to node E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com --------------8B13DB055BAFB764C817E304 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------8B13DB055BAFB764C817E304-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 22:51:49 -0800 From: "manoj juneja" To: jdrake@calient.net, mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Lambda LSP establishment Date: Tue, 11 Dec 2001 23:50:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi John, Can u please then explain how to tunnel a TDM LSP over Lambda LSP ? I am only interested in what type of labels the tail end of the lambda FA-LSP will send to the head end of lambda LSP for tunneling the TDM LSP. These things are not clear from the drafts as u can see lot of confusions are there regarding these on the mailing list. After carefully reading the drafts, we are still not able to make out what the draft wants to say. I think these things are only clear to the people who either attend the IETF meeting or the authors themselves. One should write the drafts in such a way that these should be helpful to the readers and should not create chaos on the mailing lists. Regards, manoj. >From: John Drake >To: Maarten Vissers , manoj juneja > >CC: ccamp@ops.ietf.org >Subject: RE: Lambda LSP establishment >Date: Tue, 11 Dec 2001 21:53:38 -0800 > >fortunately, this is just your opinion > >-----Original Message----- >From: Maarten Vissers [mailto:mvissers@lucent.com] >Sent: Tuesday, December 11, 2001 9:31 PM >To: manoj juneja >Cc: ccamp@ops.ietf.org >Subject: Re: Lambda LSP establishment > > >Manoj, > >Forget the FA stuff, it is not appropriate in circuit networks. It only >applies >to MPLS. We should remove it when it is used in relation with PDH, >SDH/SONET, >OTN and pre-OTN. The text in sdh-sonet draft should state that if there is >a >LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label >with >"00KLM". > >Regards, > >Maarten > >manoj juneja wrote: > > > > Hi Marteen, > > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > > as a link) then u can allocate the lower level signals in it by making > > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > > technology. What about the case where the TDM LSP has to be tunneled >through > > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > > etc.) ? > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Lambda LSP establishment > > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > > > >Manoj, > > > > > >You refer to one wavelength to be available between A-E without >wavelength > > >conversion capability. This suggests that you operate at the OCh layer > > >network. > > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, >C-D, > > >D-E) > > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is >a > > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C >and > > >E. > > >The result is that the OCh link connections C-D and D-E are >transporting > > >the OCh > > >signal (of e.g. 2.5G). These OCh link connections are now in service >and > > >not > > >longer available to an other OCh connection request. I.e. a request for >an > > >OCh > > >connection between A and E will be rejected. > > > > > >FAs are not applicable in the circuit layers. IF there is a trail in >server > > >layer X, then there is a link in its client layer Y. X and Y are thus > > >different > > >layer networks and signals. > > > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh >trail > > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link >connection. > > > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is >not > > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > > > >Regards, > > > > > >Maarten > > > > > >OCh link connections > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I have 5 nodes A, B, C, D and E connected as shown. >Assume > > > > that only one wavelength is available on the path A to E (no >wavelength > > > > conversion capability is there on the complete path). Let the >capacity > > > > of the wavelength be C. Further assume a request arrives for >connection > > > > from node C to E for a line capacity of C/4. This request will be > > > > successful as we have available wavelength. Now If another request > > > > comes at node A to establish another connection from node A to node >E > > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this >request > > > > be successful as we have already allocated the wavelength ? > > > > > > > > If the previous connection from C to E of capacity C/4 had been > > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > > > Regards, > > > > manoj. > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 21:54:48 -0800 Message-ID: From: John Drake To: Maarten Vissers , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Lambda LSP establishment Date: Tue, 11 Dec 2001 21:53:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" fortunately, this is just your opinion -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Tuesday, December 11, 2001 9:31 PM To: manoj juneja Cc: ccamp@ops.ietf.org Subject: Re: Lambda LSP establishment Manoj, Forget the FA stuff, it is not appropriate in circuit networks. It only applies to MPLS. We should remove it when it is used in relation with PDH, SDH/SONET, OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with "00KLM". Regards, Maarten manoj juneja wrote: > > Hi Marteen, > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > as a link) then u can allocate the lower level signals in it by making > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > technology. What about the case where the TDM LSP has to be tunneled through > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > etc.) ? > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Lambda LSP establishment > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > >Manoj, > > > >You refer to one wavelength to be available between A-E without wavelength > >conversion capability. This suggests that you operate at the OCh layer > >network. > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, > >D-E) > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and > >E. > >The result is that the OCh link connections C-D and D-E are transporting > >the OCh > >signal (of e.g. 2.5G). These OCh link connections are now in service and > >not > >longer available to an other OCh connection request. I.e. a request for an > >OCh > >connection between A and E will be rejected. > > > >FAs are not applicable in the circuit layers. IF there is a trail in server > >layer X, then there is a link in its client layer Y. X and Y are thus > >different > >layer networks and signals. > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection. > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > >Regards, > > > >Maarten > > > >OCh link connections > > > >manoj juneja wrote: > > > > > > Hi All, > > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > > that only one wavelength is available on the path A to E (no wavelength > > > conversion capability is there on the complete path). Let the capacity > > > of the wavelength be C. Further assume a request arrives for connection > > > from node C to E for a line capacity of C/4. This request will be > > > successful as we have available wavelength. Now If another request > > > comes at node A to establish another connection from node A to node E > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > > be successful as we have already allocated the wavelength ? > > > > > > If the previous connection from C to E of capacity C/4 had been > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 21:33:27 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C16EB91.E1A704FE@lucent.com> Date: Wed, 12 Dec 2001 06:30:57 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP establishment Content-Type: multipart/mixed; boundary="------------D9B734CF61B3E7B0AEA9DF7E" This is a multi-part message in MIME format. --------------D9B734CF61B3E7B0AEA9DF7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, Forget the FA stuff, it is not appropriate in circuit networks. It only applies to MPLS. We should remove it when it is used in relation with PDH, SDH/SONET, OTN and pre-OTN. The text in sdh-sonet draft should state that if there is a LOVC link (IETF: link bundle/TE link) then the LOVC signals use a label with "00KLM". Regards, Maarten manoj juneja wrote: > > Hi Marteen, > The concept of FA is mentioned for SDH/SONET in gmpls-sdh > -sonet draft. It says that if u have a HOVC trail as a FA (advertized > as a link) then u can allocate the lower level signals in it by making > the higher bits of label as 0s (i.e. S and U}. This is fine for the same > technology. What about the case where the TDM LSP has to be tunneled through > the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda > etc.) ? > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Lambda LSP establishment > >Date: Tue, 11 Dec 2001 15:56:41 +0100 > > > >Manoj, > > > >You refer to one wavelength to be available between A-E without wavelength > >conversion capability. This suggests that you operate at the OCh layer > >network. > >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, > >D-E) > >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a > >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and > >E. > >The result is that the OCh link connections C-D and D-E are transporting > >the OCh > >signal (of e.g. 2.5G). These OCh link connections are now in service and > >not > >longer available to an other OCh connection request. I.e. a request for an > >OCh > >connection between A and E will be rejected. > > > >FAs are not applicable in the circuit layers. IF there is a trail in server > >layer X, then there is a link in its client layer Y. X and Y are thus > >different > >layer networks and signals. > > > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail > >supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection. > > > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not > >possible in the SDH/SONET, OTN, PDH or ATM technologies. > > > >Regards, > > > >Maarten > > > >OCh link connections > > > >manoj juneja wrote: > > > > > > Hi All, > > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > > that only one wavelength is available on the path A to E (no wavelength > > > conversion capability is there on the complete path). Let the capacity > > > of the wavelength be C. Further assume a request arrives for connection > > > from node C to E for a line capacity of C/4. This request will be > > > successful as we have available wavelength. Now If another request > > > comes at node A to establish another connection from node A to node E > > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > > be successful as we have already allocated the wavelength ? > > > > > > If the previous connection from C to E of capacity C/4 had been > > > advertised as a FA, in that case will the IInd request succeed ? > > > > > > If the previous connection from C to E of capacity C/4 had not been > > > advertised as FA then what will be the fate of IInd connection ? > > > > > > A <--> B <---> C <----> D <---> <----> E > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com --------------D9B734CF61B3E7B0AEA9DF7E Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------D9B734CF61B3E7B0AEA9DF7E-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 16:41:31 -0800 Message-ID: <3C16A4CB.F2A685C8@lucent.com> Date: Tue, 11 Dec 2001 17:28:59 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'David S. Miller '" , "''Dimitri Papadimitriou' '" , "'Steve West '" , "''Maarten Vissers' '" , "'ccamp '" , "'q11/15 '" , "'t1x1.5 '" Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Not really. This is a different "flavor" of protection where the paths are NOT individually or collectively protected. It is assumed that for a service where you would be increasing or decreasing the available bandwidth, you are generally dealing with a packet oriented service where the bandwidth provide affects the degree of congestion but not basic connectivity. As a result, LCAS provides a way to remove failed components from the path, even in the middle to operate (temporarily) with reduced bandwidth. So if you had a VC-4-10v and one of the VC-4s fails, you can operate by temporarily reducing the bandwidth to VC-4-9v until service is restored on the other VC. When the VCs are routed independently, this provides a very good "lightweight" protection and the ability to take advantage of ALL of the bandwidth in the absence of failures. Regards, Steve "Mannie, Eric" wrote: > > Hi all, > > >LBM also does not accomodate removal of non-contiguous components: > e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need > to back down to 2 and then build up ... > > Not totally correct, if they are multiple LSPs used for the circuit, you can > remove/add VCs at the end of each LSP separately. However, since each LSP is > protected independently, if "any VC fails" inside, the whole LSP is > protected (so in that case the problem is a not relevant). If you want to > have completely separate VCs, you can have one LSP for each VC. Each LSP/VC > is then provisioned end-to-end, protected (if required) and can be routed > independently. The capability is the same as in LCAS in that case. > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge > To: David S. Miller > Cc: Mannie, Eric; 'Dimitri Papadimitriou'; Steve West; 'Maarten Vissers'; > ccamp; q11/15; t1x1.5 > Sent: 12/11/01 1:52 AM > Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > David, > Virtual Concatenation, with or without LCAS accomodates differential > delay for different parts of the payload. > > LCAS provides hitless add/remove. Also it provides for removal of > failed components, even when this results in non-contiguous > component numbering. > > LBM does not give you hitless add and remove from the payload. > LBM also does not accomodate removal of non-contiguous components: > e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need > to back down to 2 and then build up ... > Steve > > "David S. Miller" wrote: > > > > Am I missing something? > > > > I thought that LCAS gains 2 things: > > 1) Hitless and and remove of payload (dynamic bandwidth allocation) > > but more importantly > > 2) Differential Delay through the network for differents parts of the > > payload (i.e. diverse routing of network traffic). > > > > How does GMPLS w/ LBM address the second issue? > > > > David Miller > > Vitesse Semiconductor > > > > "Mannie, Eric" wrote: > > > > > > Hello Steve, > > > > > > Just to complement the answer of Dimitri, > > > > > > > You believe that the packet loss rate and robustness of LMB is > > > > similar to LCAS ? > > > > > > LCAS waits for the end of control packet which is multi-framed to > decide > > > when the payload is significant (the "transition"). LBM uses for > instance > > > the C2 byte for the HOVC, since this byte appears directly in the > POH and is > > > not part of a control packet, that should go faster, right ? I.e. > less > > > glitch than with LCAS ? > > > > > > But having a field in the transport plane to indicate a transition > (whatever > > > is the field ) is not the most important issue. Even if you have > that field, > > > you need some time to provision the additional VCs/SPEs in the > network. This > > > is not done by LCAS, and any control plane or management plane will > imply > > > some time for that operation, and the glitch will really come from > that > > > process, not from the way that you detect a transition in the > transport > > > plane. > > > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, > whereas LCAS > > > > could potentially be used with GMPLS or with other control plane > or > > > > management plane mechanisms ? > > > > > > When a distributed control plane is used (e.g. GMPLS or PNNI), using > LCAS > > > implies issues on this control plane. LCAS is a stand-alone solution > that > > > bypass the control plane to change the resource reservation in both > end > > > systems. A control plane maintains states in end systems (e.g. at > the UNI) > > > and in intermediate systems ! So, bandwidth modifications must be > reflected > > > in the control plane otherwise it will become inconsistent. > > > > > > Now, the control plane is natively designed to deal with these > resource > > > reservations including in the source and the destination (with the > UNI). > > > Moreover, GMPLS is natively designed to deal with bandwidth > modification (in > > > the packet world this was one of the major requirements). > Originally, we > > > just wanted to describe how to generalize these bandwidth > modification > > > principles to SDH/SONET and how to interwork with LCAS. > > > > > > Then, we saw that a large part of LCAS was overlapping with GMPLS, > i.e. all > > > the protocol part. The rest was the issue about when to decide that > a VC/SPE > > > contains real user data or not (the transition). > > > > > > Since LCAS added a control message, naturally it used a field in > that > > > control message to indicate that transition. But with GMPLS we > didn't need > > > any new control message, se we looked at what was available *in the > > > transport plane* to detect the fact that a VC/SPE contains now real > user > > > data (i.e the transition). We found natural to use the so-called > SDH/SONET > > > "signal label" (e.g. the C2 byte) (note for the readers: nothing to > do with > > > the GMPLS label :-). So we added these aspects to the draft. This is > the > > > part that we expected to validate with the ITU-T/T1X1 folks, but > flames came > > > first... > > > > > > What we are certainly going to do, is to add in the draft a section > about > > > how GMPLS should work when LCAS is used at the same time. However, > we think > > > that using GMPLS and LCAS at the same time will be more complex than > simply > > > using GMPLS and will not bring something additional. So the natural > > > observation came, "why should we use LCAS with GMPLS and build > something > > > more complex when there is almost no issue to solve when simply > using GMPLS > > > alone". Using GMPLS and LCAS at the same time to modify the > bandwidth > > > implies that we will have two signaling flows between the source and > the > > > destination running in parallel and overlapping. GMPLS will also > speak with > > > the source and the destination to do the same as LCAS, and with a > > > distributed control plane you need GMPLS anyway (or PNNI or etc). > > > > > > We also added a section to explain how several GMPLS LSPs (i.e. > circuits) > > > can be combined together to form a larger virtually concatenated > circuit. > > > This allows to deal with the non co-routing of VCs/SPEs with GMPLS. > > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Sunday, November 18, 2001 3:44 PM > > > To: Steve West > > > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; > > > q11/15; t1x1.5 > > > Subject: Re: [T1X1.5] Re: LCAS and > > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Hi Steve, > > > > > > Thanks for your comments, see in-line... > > > > > > Steve West wrote: > > > > > > > > Dimitri: > > > > > > > > Please confirm my understanding of your proposal: > > > > > > > > 1. Your proposal supports hitless link capacity adjustment. > (Capacity > > > > changes that occurs during transmission of a packet will not > corrupt that > > > > packet.) You believe that the packet loss rate and robustness of > LMB is > > > > similar to LCAS ? > > > > > > It is mentioned in the proposal that the source waits for a > > > confirmation from the destination (i.e. Resv Message). THEN > > > the source "equip" the VC/SPE and sends. After the destination > > > sees in the POH that the VC is "equipped" (transition). > > > > > > So instead of using the transitions proposed in LCAS (based > > > on the H4 CTRL words) we use the ones already available. > > > > > > Since we are the beginning, we were very cautious but we expect to > > > reach more than reasonable robustness and reliability. > > > > > > > 2. LMB requires hardware coordination between the SONET payload > mapper > > > and > > > > the SONET POH processor (C2 octet insertion/extraction logic) ? > > > > > > At the transport plane level C2 is the field that LBM uses for the > > > transition in the HOVC POH. > > > > > > > 3. The hardware based synchronization performance requirements > are > > > similar > > > > to those required by LCAS. Except that LCAS coordinates the > critical > > > > transitions using H4 instead of C2 ? And that Virtual > Concatenation > > > systems > > > > require to coordinate their payload mappers with bits 1-4 of the > H4 byte > > > to > > > > determine the sequence number anyway ? > > > > > > See above, yes and yes (since we re-use existing VC mechanisms) > > > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, > whereas LCAS > > > > could potentially be used with GMPLS or with other control plane > or > > > > management plane mechanisms ? > > > > > > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact > > > (from what i understand in your question) see it more from transport > > > to control plane impact taking the assumption that you expect some > > > hardware improvement. Let's first determine if this can be achieved > > > and then discuss the implementation issues that can arise from this > > > proposal. In a sense, GMPLS-LBM is a self-consistent solution. > > > > > > Regards, > > > - dimitri. > > > > > > > Thanks, > > > > > > > > Steve > > > > > > > > -----Original Message----- > > > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > > > Sent: Friday, November 16, 2001 4:09 PM > > > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > > > > Cc: ccamp; q11/15; t1x1.5 > > > > Subject: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > > > Hi folks, > > > > > > > > What happens... when we start the technical discussion > > > > all guys taking part to the previous one now are gone ? > > > > > > > > We would like to start a technical discussion.. rather > > > > difficult if we stay alone... or everybody agree on > > > > proposal made in the previous e-mail ? (this in order > > > > to refine the mechanism detailed in the GMPLS LBM I-D.) > > > > > > > > Any technical feedback is highly appreciated. > > > > > > > > Cheers, > > > > - dimitri. > > > > > > > > "Mannie, Eric" wrote: > > > > > > > > > > Hello Stephen > > > > > > > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > > > > > > No, please see explanations below. > > > > > > > > > > > If you use LBM and change the mappings at the two ends without > some > > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > > (I think this is simple enough). > > > > > > > > > > No, please see below (C2 or V5 transition). > > > > > > > > > > >The compare/contrast discussion of LBM and LCAS is appropriate > not > > > > > >because LCAS is "sacred", but because you are comparing apples > to > > > > > >oranges. Statements in this document such as "One drawback of > LCAS is > > > .." > > > > > >are unnecessary and inappropriate in this context, since LBM > does > > > > > >NOT solve the problem LCAS was designed to solve. Perhaps if > you > > > > > >were solving the SAME problem better, this would be OK, but > this > > > > > >is not the case. > > > > > > > > > > No, please see below. > > > > > > > > > > Simple example: > > > > > > > > > > 1) you first signal an additional VC/SPE to the destination (via > a > > > Path). > > > > > 2) the destination knows exactly which VC/SPE is added (via the > label). > > > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > > > > so the VC/SPE is not yet added to concatenated signal. > > > > > 4) then, you wait at the source for a confirmation from the > destination > > > > > (i.e. Resv). > > > > > 5) the source "equip" the VC/SPE and sends. > > > > > 6) the destination sees in the POH that the VC is "equipped" > > > (transition). > > > > > > > > > > The difference between LCAS and LBM is that LCAS uses an > additional > > > > explicit > > > > > indication in the overhead to say "this is the payload" to use. > LBM > > > > doesn't > > > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET > overhead > > > >:-) > > > > > > > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > > > > transitions > > > > > to a significant payload. LBM proposes to do the same simply by > looking > > > at > > > > > the C2 (for HOVC) transition - regular SDH/SONET field that will > change > > > > > anyway and that is used to indicate the type of payload. > > > > > > > > > > To be more precise about LCAS (I copy from the LCAS > specification, > > > section > > > > > 6.3.1): "The first container frame to contain payload data for > the new > > > > > member shall be the container frame immediately following the > container > > > > > frame that contained the last bit(s) (i.e. the CRC) of the > control > > > packet > > > > > with NORM/EOS message for that member" (the LCAS control > packet). > > > > > > > > > > So, LCAS waits for the last bit of the appropriate LCAS control > packet > > > in > > > > > the POH with the appropriate transition of its CTRL field. LBM > waits > > > > simply > > > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in > the POH > > > > > (don't change SDH/SONET). > > > > > > > > > > By the way, this is version 0 of the draft and it was just > posted. > > > > > > > > > > Suggestions, technical comments and improvements are welcome. > > > > > > > > > > I would appreciate if people could first read and speak before > shooting > > > > > directly :-) > > > > > > > > > > Kind regards, > > > > > > > > > > Eric > > > > > > > > > > -----Original Message----- > > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > > Sent: Friday, November 16, 2001 7:49 PM > > > > > To: Mannie, Eric > > > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri > Papadimitriou > > > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > > > > > Eric, > > > > > The point of my earlier email (items again below, this time with > > > > > numbers) was not to prompt the comment "#3 is out of scope, > therefore > > > > > it is a choice between #1 and #2" (my parsing of recent > statements). > > > > > > > > > > The issue (and I think the reason for Maarten's strong reaction) > is > > > this: > > > > > GMPLS-LBM and LCAS are NOT different solutions to the same > problem. > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > (I hope this is not too subtle for non-native English speakers). > > > > > > > > > > LCAS is a method to hitlessly change the mappings at the two > > > > > ends of a virtually concatenated trail to increase or decrease > the > > > > > bandwidth. It does not say anything about how components to be > > > > > added or removed from the virtually concatenated "bundle" are > > > > > set up or taken down. > > > > > > > > > > LBM talks about how to set up or take down those added or > removed > > > > > components, but not about the details of changing the mapping > (other > > > > > than that it is done after the new components are successfully > > > > > established. > > > > > > > > > > If you use LBM and change the mappings at the two ends without > some > > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > > (I think this is simple enough). > > > > > > > > > > The compare/contrast discussion of LBM and LCAS is appropriate > not > > > > > because LCAS is "sacred", but because you are comparing apples > to > > > > > oranges. Statements in this document such as "One drawback of > LCAS is > > > .." > > > > > are unnecessary and inappropriate in this context, since LBM > does > > > > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > > > > were solving the SAME problem better, this would be OK, but this > > > > > is not the case. > > > > > > > > > > Time to try to be constructive: > > > > > - I think most of the current discussion of LCAS should be > removed from > > > > > this document. It is irrelevant since LCAS solves a different > problem > > > than > > > > > LBM. To say that one is "better" than the other would only be > meaningful > > > > > if they were solving the same problem (can you really say that > LBM > > > solves > > > > > problem A better than LCAS solves problem B?). > > > > > - LCAS can be a good informative reference as a way to hitlessly > modify > > > > > the size of a virtually concatenated trail. > > > > > - Clarify in the scope that the current draft describes the use > of LBM > > > > > without LCAS, which results in a traffic glitch when bandwidth > is > > > > modified. > > > > > Indicate that the use of LCAS to hitlessly negotiate the changes > to > > > > > the size of virtually concatenated pipes after LBM sets up new > > > > component(s) > > > > > or before LBM takes down old component(s) is a topic for further > study > > > > > and perhaps to be addressed in a future version of the draft. > > > > > > > > > > Regards, > > > > > Steve > > > > > > > > > > Steve Trowbridge wrote: > > > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a > glitch to > > > > > > the traffic. > > > > > > > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care > whether the > > > > > > control plane knows that the different LSPs are part of the > same > > > > > > circuit. > > > > > > > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would > seem to > > > > > > be the preferred method for many applications. > > > > > > > > > > "Mannie, Eric" wrote: > > > > > > > > > > > > Hello Maarten, > > > > > > > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows > a lack > > > of > > > > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > > > > > > > Sorry, do you mean that it is forbidden to speak about your > LCAS > > > > document > > > > > > and to compare GMPLS and LCAS functionalities ? > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 16:35:24 -0800 Message-ID: From: "Mannie, Eric" To: 'manoj juneja ' , "'mvissers@lucent.com '" Cc: "'ccamp@ops.ietf.org '" Subject: RE: Lambda LSP establishment Date: Wed, 12 Dec 2001 01:26:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Manoj, The SDH/SONET draft has nothing to do with lambdas. The SDH/SONET label is for SDH/SONET only and doesn't need to care how the TDM is transported. The lambda LSP is at another layer. The labels between the layers are completely independent and allocated according to the rules of each respective layer. Kind regards, Eric -----Original Message----- From: manoj juneja To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Sent: 12/12/01 12:27 AM Subject: Re: Lambda LSP establishment Hi Marteen, The concept of FA is mentioned for SDH/SONET in gmpls-sdh -sonet draft. It says that if u have a HOVC trail as a FA (advertized as a link) then u can allocate the lower level signals in it by making the higher bits of label as 0s (i.e. S and U}. This is fine for the same technology. What about the case where the TDM LSP has to be tunneled through the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda etc.) ? Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Lambda LSP establishment >Date: Tue, 11 Dec 2001 15:56:41 +0100 > >Manoj, > >You refer to one wavelength to be available between A-E without wavelength >conversion capability. This suggests that you operate at the OCh layer >network. >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, >D-E) >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and >E. >The result is that the OCh link connections C-D and D-E are transporting >the OCh >signal (of e.g. 2.5G). These OCh link connections are now in service and >not >longer available to an other OCh connection request. I.e. a request for an >OCh >connection between A and E will be rejected. > >FAs are not applicable in the circuit layers. IF there is a trail in server >layer X, then there is a link in its client layer Y. X and Y are thus >different >layer networks and signals. > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail >supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection. > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not >possible in the SDH/SONET, OTN, PDH or ATM technologies. > >Regards, > >Maarten > >OCh link connections > >manoj juneja wrote: > > > > Hi All, > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > that only one wavelength is available on the path A to E (no wavelength > > conversion capability is there on the complete path). Let the capacity > > of the wavelength be C. Further assume a request arrives for connection > > from node C to E for a line capacity of C/4. This request will be > > successful as we have available wavelength. Now If another request > > comes at node A to establish another connection from node A to node E > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > be successful as we have already allocated the wavelength ? > > > > If the previous connection from C to E of capacity C/4 had been > > advertised as a FA, in that case will the IInd request succeed ? > > > > If the previous connection from C to E of capacity C/4 had not been > > advertised as FA then what will be the fate of IInd connection ? > > > > A <--> B <---> C <----> D <---> <----> E > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 16:25:16 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge ' , "'David S. Miller '" Cc: ''Dimitri Papadimitriou' ' , 'Steve West ' , ''Maarten Vissers' ' , 'ccamp ' , 'q11/15 ' , "'t1x1.5 '" Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Wed, 12 Dec 2001 01:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, >LBM also does not accomodate removal of non-contiguous components: e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need to back down to 2 and then build up ... Not totally correct, if they are multiple LSPs used for the circuit, you can remove/add VCs at the end of each LSP separately. However, since each LSP is protected independently, if "any VC fails" inside, the whole LSP is protected (so in that case the problem is a not relevant). If you want to have completely separate VCs, you can have one LSP for each VC. Each LSP/VC is then provisioned end-to-end, protected (if required) and can be routed independently. The capability is the same as in LCAS in that case. Kind regards, Eric -----Original Message----- From: Stephen Trowbridge To: David S. Miller Cc: Mannie, Eric; 'Dimitri Papadimitriou'; Steve West; 'Maarten Vissers'; ccamp; q11/15; t1x1.5 Sent: 12/11/01 1:52 AM Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt David, Virtual Concatenation, with or without LCAS accomodates differential delay for different parts of the payload. LCAS provides hitless add/remove. Also it provides for removal of failed components, even when this results in non-contiguous component numbering. LBM does not give you hitless add and remove from the payload. LBM also does not accomodate removal of non-contiguous components: e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need to back down to 2 and then build up ... Steve "David S. Miller" wrote: > > Am I missing something? > > I thought that LCAS gains 2 things: > 1) Hitless and and remove of payload (dynamic bandwidth allocation) > but more importantly > 2) Differential Delay through the network for differents parts of the > payload (i.e. diverse routing of network traffic). > > How does GMPLS w/ LBM address the second issue? > > David Miller > Vitesse Semiconductor > > "Mannie, Eric" wrote: > > > > Hello Steve, > > > > Just to complement the answer of Dimitri, > > > > > You believe that the packet loss rate and robustness of LMB is > > > similar to LCAS ? > > > > LCAS waits for the end of control packet which is multi-framed to decide > > when the payload is significant (the "transition"). LBM uses for instance > > the C2 byte for the HOVC, since this byte appears directly in the POH and is > > not part of a control packet, that should go faster, right ? I.e. less > > glitch than with LCAS ? > > > > But having a field in the transport plane to indicate a transition (whatever > > is the field ) is not the most important issue. Even if you have that field, > > you need some time to provision the additional VCs/SPEs in the network. This > > is not done by LCAS, and any control plane or management plane will imply > > some time for that operation, and the glitch will really come from that > > process, not from the way that you detect a transition in the transport > > plane. > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > > could potentially be used with GMPLS or with other control plane or > > > management plane mechanisms ? > > > > When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS > > implies issues on this control plane. LCAS is a stand-alone solution that > > bypass the control plane to change the resource reservation in both end > > systems. A control plane maintains states in end systems (e.g. at the UNI) > > and in intermediate systems ! So, bandwidth modifications must be reflected > > in the control plane otherwise it will become inconsistent. > > > > Now, the control plane is natively designed to deal with these resource > > reservations including in the source and the destination (with the UNI). > > Moreover, GMPLS is natively designed to deal with bandwidth modification (in > > the packet world this was one of the major requirements). Originally, we > > just wanted to describe how to generalize these bandwidth modification > > principles to SDH/SONET and how to interwork with LCAS. > > > > Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all > > the protocol part. The rest was the issue about when to decide that a VC/SPE > > contains real user data or not (the transition). > > > > Since LCAS added a control message, naturally it used a field in that > > control message to indicate that transition. But with GMPLS we didn't need > > any new control message, se we looked at what was available *in the > > transport plane* to detect the fact that a VC/SPE contains now real user > > data (i.e the transition). We found natural to use the so-called SDH/SONET > > "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with > > the GMPLS label :-). So we added these aspects to the draft. This is the > > part that we expected to validate with the ITU-T/T1X1 folks, but flames came > > first... > > > > What we are certainly going to do, is to add in the draft a section about > > how GMPLS should work when LCAS is used at the same time. However, we think > > that using GMPLS and LCAS at the same time will be more complex than simply > > using GMPLS and will not bring something additional. So the natural > > observation came, "why should we use LCAS with GMPLS and build something > > more complex when there is almost no issue to solve when simply using GMPLS > > alone". Using GMPLS and LCAS at the same time to modify the bandwidth > > implies that we will have two signaling flows between the source and the > > destination running in parallel and overlapping. GMPLS will also speak with > > the source and the destination to do the same as LCAS, and with a > > distributed control plane you need GMPLS anyway (or PNNI or etc). > > > > We also added a section to explain how several GMPLS LSPs (i.e. circuits) > > can be combined together to form a larger virtually concatenated circuit. > > This allows to deal with the non co-routing of VCs/SPEs with GMPLS. > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Sunday, November 18, 2001 3:44 PM > > To: Steve West > > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; > > q11/15; t1x1.5 > > Subject: Re: [T1X1.5] Re: LCAS and > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Hi Steve, > > > > Thanks for your comments, see in-line... > > > > Steve West wrote: > > > > > > Dimitri: > > > > > > Please confirm my understanding of your proposal: > > > > > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > > > changes that occurs during transmission of a packet will not corrupt that > > > packet.) You believe that the packet loss rate and robustness of LMB is > > > similar to LCAS ? > > > > It is mentioned in the proposal that the source waits for a > > confirmation from the destination (i.e. Resv Message). THEN > > the source "equip" the VC/SPE and sends. After the destination > > sees in the POH that the VC is "equipped" (transition). > > > > So instead of using the transitions proposed in LCAS (based > > on the H4 CTRL words) we use the ones already available. > > > > Since we are the beginning, we were very cautious but we expect to > > reach more than reasonable robustness and reliability. > > > > > 2. LMB requires hardware coordination between the SONET payload mapper > > and > > > the SONET POH processor (C2 octet insertion/extraction logic) ? > > > > At the transport plane level C2 is the field that LBM uses for the > > transition in the HOVC POH. > > > > > 3. The hardware based synchronization performance requirements are > > similar > > > to those required by LCAS. Except that LCAS coordinates the critical > > > transitions using H4 instead of C2 ? And that Virtual Concatenation > > systems > > > require to coordinate their payload mappers with bits 1-4 of the H4 byte > > to > > > determine the sequence number anyway ? > > > > See above, yes and yes (since we re-use existing VC mechanisms) > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > > could potentially be used with GMPLS or with other control plane or > > > management plane mechanisms ? > > > > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact > > (from what i understand in your question) see it more from transport > > to control plane impact taking the assumption that you expect some > > hardware improvement. Let's first determine if this can be achieved > > and then discuss the implementation issues that can arise from this > > proposal. In a sense, GMPLS-LBM is a self-consistent solution. > > > > Regards, > > - dimitri. > > > > > Thanks, > > > > > > Steve > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Friday, November 16, 2001 4:09 PM > > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > > > Cc: ccamp; q11/15; t1x1.5 > > > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Hi folks, > > > > > > What happens... when we start the technical discussion > > > all guys taking part to the previous one now are gone ? > > > > > > We would like to start a technical discussion.. rather > > > difficult if we stay alone... or everybody agree on > > > proposal made in the previous e-mail ? (this in order > > > to refine the mechanism detailed in the GMPLS LBM I-D.) > > > > > > Any technical feedback is highly appreciated. > > > > > > Cheers, > > > - dimitri. > > > > > > "Mannie, Eric" wrote: > > > > > > > > Hello Stephen > > > > > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > > > > No, please see explanations below. > > > > > > > > > If you use LBM and change the mappings at the two ends without some > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > (I think this is simple enough). > > > > > > > > No, please see below (C2 or V5 transition). > > > > > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > > > >because LCAS is "sacred", but because you are comparing apples to > > > > >oranges. Statements in this document such as "One drawback of LCAS is > > .." > > > > >are unnecessary and inappropriate in this context, since LBM does > > > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > > > >were solving the SAME problem better, this would be OK, but this > > > > >is not the case. > > > > > > > > No, please see below. > > > > > > > > Simple example: > > > > > > > > 1) you first signal an additional VC/SPE to the destination (via a > > Path). > > > > 2) the destination knows exactly which VC/SPE is added (via the label). > > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > > > so the VC/SPE is not yet added to concatenated signal. > > > > 4) then, you wait at the source for a confirmation from the destination > > > > (i.e. Resv). > > > > 5) the source "equip" the VC/SPE and sends. > > > > 6) the destination sees in the POH that the VC is "equipped" > > (transition). > > > > > > > > The difference between LCAS and LBM is that LCAS uses an additional > > > explicit > > > > indication in the overhead to say "this is the payload" to use. LBM > > > doesn't > > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > > >:-) > > > > > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > > > transitions > > > > to a significant payload. LBM proposes to do the same simply by looking > > at > > > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > > > anyway and that is used to indicate the type of payload. > > > > > > > > To be more precise about LCAS (I copy from the LCAS specification, > > section > > > > 6.3.1): "The first container frame to contain payload data for the new > > > > member shall be the container frame immediately following the container > > > > frame that contained the last bit(s) (i.e. the CRC) of the control > > packet > > > > with NORM/EOS message for that member" (the LCAS control packet). > > > > > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet > > in > > > > the POH with the appropriate transition of its CTRL field. LBM waits > > > simply > > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > > > (don't change SDH/SONET). > > > > > > > > By the way, this is version 0 of the draft and it was just posted. > > > > > > > > Suggestions, technical comments and improvements are welcome. > > > > > > > > I would appreciate if people could first read and speak before shooting > > > > directly :-) > > > > > > > > Kind regards, > > > > > > > > Eric > > > > > > > > -----Original Message----- > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > Sent: Friday, November 16, 2001 7:49 PM > > > > To: Mannie, Eric > > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > > > Eric, > > > > The point of my earlier email (items again below, this time with > > > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > > > > > The issue (and I think the reason for Maarten's strong reaction) is > > this: > > > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > (I hope this is not too subtle for non-native English speakers). > > > > > > > > LCAS is a method to hitlessly change the mappings at the two > > > > ends of a virtually concatenated trail to increase or decrease the > > > > bandwidth. It does not say anything about how components to be > > > > added or removed from the virtually concatenated "bundle" are > > > > set up or taken down. > > > > > > > > LBM talks about how to set up or take down those added or removed > > > > components, but not about the details of changing the mapping (other > > > > than that it is done after the new components are successfully > > > > established. > > > > > > > > If you use LBM and change the mappings at the two ends without some > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > (I think this is simple enough). > > > > > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > > > because LCAS is "sacred", but because you are comparing apples to > > > > oranges. Statements in this document such as "One drawback of LCAS is > > .." > > > > are unnecessary and inappropriate in this context, since LBM does > > > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > > > were solving the SAME problem better, this would be OK, but this > > > > is not the case. > > > > > > > > Time to try to be constructive: > > > > - I think most of the current discussion of LCAS should be removed from > > > > this document. It is irrelevant since LCAS solves a different problem > > than > > > > LBM. To say that one is "better" than the other would only be meaningful > > > > if they were solving the same problem (can you really say that LBM > > solves > > > > problem A better than LCAS solves problem B?). > > > > - LCAS can be a good informative reference as a way to hitlessly modify > > > > the size of a virtually concatenated trail. > > > > - Clarify in the scope that the current draft describes the use of LBM > > > > without LCAS, which results in a traffic glitch when bandwidth is > > > modified. > > > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > > > the size of virtually concatenated pipes after LBM sets up new > > > component(s) > > > > or before LBM takes down old component(s) is a topic for further study > > > > and perhaps to be addressed in a future version of the draft. > > > > > > > > Regards, > > > > Steve > > > > > > > > Steve Trowbridge wrote: > > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > > > the traffic. > > > > > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > > > control plane knows that the different LSPs are part of the same > > > > > circuit. > > > > > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > > > be the preferred method for many applications. > > > > > > > > "Mannie, Eric" wrote: > > > > > > > > > > Hello Maarten, > > > > > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack > > of > > > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > > > document > > > > > and to compare GMPLS and LCAS functionalities ? > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 15:28:27 -0800 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Lambda LSP establishment Date: Tue, 11 Dec 2001 16:27:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, The concept of FA is mentioned for SDH/SONET in gmpls-sdh -sonet draft. It says that if u have a HOVC trail as a FA (advertized as a link) then u can allocate the lower level signals in it by making the higher bits of label as 0s (i.e. S and U}. This is fine for the same technology. What about the case where the TDM LSP has to be tunneled through the Lambda LSP ? What will be the form of label (i.e. {SUKLM} or lambda etc.) ? Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Lambda LSP establishment >Date: Tue, 11 Dec 2001 15:56:41 +0100 > >Manoj, > >You refer to one wavelength to be available between A-E without wavelength >conversion capability. This suggests that you operate at the OCh layer >network. >Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, >D-E) >to be "C". Say that C is about 10 Gbit/s. You then assume that there is a >request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and >E. >The result is that the OCh link connections C-D and D-E are transporting >the OCh >signal (of e.g. 2.5G). These OCh link connections are now in service and >not >longer available to an other OCh connection request. I.e. a request for an >OCh >connection between A and E will be rejected. > >FAs are not applicable in the circuit layers. IF there is a trail in server >layer X, then there is a link in its client layer Y. X and Y are thus >different >layer networks and signals. > >If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail >supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection. > >Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not >possible in the SDH/SONET, OTN, PDH or ATM technologies. > >Regards, > >Maarten > >OCh link connections > >manoj juneja wrote: > > > > Hi All, > > If I have 5 nodes A, B, C, D and E connected as shown. Assume > > that only one wavelength is available on the path A to E (no wavelength > > conversion capability is there on the complete path). Let the capacity > > of the wavelength be C. Further assume a request arrives for connection > > from node C to E for a line capacity of C/4. This request will be > > successful as we have available wavelength. Now If another request > > comes at node A to establish another connection from node A to node E > > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > > be successful as we have already allocated the wavelength ? > > > > If the previous connection from C to E of capacity C/4 had been > > advertised as a FA, in that case will the IInd request succeed ? > > > > If the previous connection from C to E of capacity C/4 had not been > > advertised as FA then what will be the fate of IInd connection ? > > > > A <--> B <---> C <----> D <---> <----> E > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 15:18:31 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Comments on GMPLS signalling drafts Date: Tue, 11 Dec 2001 16:15:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, 1. SE-style supported by GMPLS or not ? As labels are the resources on the link, one can't allocate different label to different senders in the same RSVP session. 2. Bandwidth modification for TDM, LSC and FSC LSPs. There is a separate draft for TDM LSP bandwidth modification but what about the bandwidth modification for other types of LSPs ? There is no mention of these in any of the GMPLS drafts. 3. It should be mentioned clearly that waveband section is still not complete in the drafts. 4. For IF_ID_RSVP_HOP object, there are couple of TLVs defined. What about the Component_If_Id_Downstream/Upstream TLV ? The revised bundling draft has removed these 2 TLVs. What about the GMPLS signalling drafts ? 5. STM-0 label representation using {SUKLM} should be mentioned in the drafts (because it is a special case). 6. It should be mentioned that bandwidth encoding parameter is useful for what all type of LSPs i.e. TDM, LSC, FSC, PSC etc. 7. There is an example scenario for contention resolution in case of bi- directional LSPs. It should be mentioned that : "contention resolution is an optimization, not a correctness issue ... and no procedure can provide optimal resolution in all cases. An implementor may do differently to provide better resolution." The above quotes are extracted from one of the mails from Fong Liaw. If this is the case then this should be mentioned in the drafts. 8. The LSP hierarchy concept is still not clear. Some days back I posted one doubt related to tunneling of TDM LSP over Lambda LSP using the concept of forwarding adjacency and different people replied with different thoughts. Does this mean this concept is not standardized in GMPLS ? My question was : "If there are 4 nodes say A, B, C and D. There is a Lambda FA established from A to D and if a new TDM LSP request comes to node A which is to be tunneled through the already established lambda FA-LSP then the node A sends the Path/label request message directly to node D. What label the node D will send back to node A in the RESV/label mapping message since the FA-LSP is just one label (lambda) ? Does it mean that all the LSPs which are tunneled through the lambda FA-LSP will be allocated the same label by node D to node A ? If this type of scenario can't exist in GMPLS then please let me know that too." Regards, manoj. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 12:13:02 -0800 Message-ID: From: John Drake To: Zhi-Wei Lin Cc: Ben Mack-Crane , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Tue, 11 Dec 2001 12:09:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" As I understand it, discussion is closed. But to answer your questions: 1) No, it's a policy decision at the intermediate node. 2) No, revertive behavior is a policy decision at the LSP endpoints 3) No, path protection is a policy decision at the LSP endpoints -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Tuesday, December 11, 2001 8:37 AM To: John Drake Cc: Ben Mack-Crane; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Hi, To further the discussion, would it be possible to add a new flag for purpose of identifying whether or not a connection (secondary connection) can support extra traffic. A 1:1 connection should be able to support extra traffic (if secondary is not used) while a 1+1 would not support extra traffic. Also, we may want to add a flag for whether or not a protection is revertive. Also, current "link flags" is assumed to provide link protection. Maybe we can add a new flag for either "link" or "path" protection. So the total is three new flags using 3 bits, out of the current 25 reserved bits. What do you think? Zhi John Drake wrote: > Snipped > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Tuesday, December 11, 2001 6:38 AM > To: Lou Berger > Cc: Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > > >>>7) In Protection Information it states "The resources allocated for a >>> secondary LSP MAY be used by other LSPs until the primary LSP fails >>> over to the secondary LSP." This may not always be the case. An >>> explicit flag indicating whether or not extra traffic may use the >>> secondary path resources is needed. >>> >>??? This is the purpose of this bit. >> > > This is not clear from the definition. The bit is defined as indicating > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > secondary LSP may not be used for extra traffic. > > Perhaps the problem here is that protection features are being defined > before the protection framework and requirements are done. Is this > presupposing some particular outcome of the recovery work in CAMP? > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > protection, there would be a pair of Primary LSPs between the source > and destination, rather than a Primary and a Secondary. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 11:36:40 -0800 Message-ID: From: neil.2.harrison@bt.com To: Ben.Mack-Crane@tellabs.com, lberger@movaz.com Cc: kireeti@juniper.net, ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-rsvp-te-05 Date: Tue, 11 Dec 2001 19:31:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Ben......you asked a specific question 11 December 2001 14:38 > > >7) The Notify message is intended to "enable expedited > notification of > > > failures," but it relies on the IP layer which may be > affected by the > > > failure that the Notify is reporting. This could > defeat the goal > > > of rapid notification. Without some means of > guaranteeing the Notify > > > doesn't have to wait for IP routing convergence to be > delivered, > > > it isn't a satisfactory solution. > > > > > Well? Does anyone else have thoughts on this? NH=> Yes, but these are not 'thoughts', this is what is required and indeed provided on all transport networks defined by the ITU: There must be a user-plane Forward Defect Indication (FDI) provided. The key reason this is required is to suppress downstream alarms......and this includes *all* client layer network trails supported above the trail source of the orginal defect. Which therefore implies it must have a server->client FDI mapping specified at the relevant adaptation points, and note that this requirements recurses through all the layer networks affected. This requirement becomes increasingly important for international (and larger than 1 management domain) trail spans....which, noting the previous comments, may not be directly obvious to the source layer of failure, ie in different country/operator/customer domains. This is a well-known transport network requirement that simply has to be provided, and I thought everyone knew this? Note - it will not be satisfactory to assume that this function can be provided via the control-plane (using any of the protocols supported) or indeed via the (user-plane) OAM of any other layer network. The reasons why are obvious (I hope). regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 09:25:54 -0800 Message-ID: <3C16404E.5F3650E3@lucent.com> Date: Tue, 11 Dec 2001 10:20:15 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: URLs from this morning's ITU-T Presentation in CCAMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, The following are the key URLs from my slides this morning: IESG area for incoming liaisons from other organizations: http://www.ietf.org/IESG/liaison.html ITU-T ftp area for information sharing with other Standards Development Organizations. Note: This is where to download the documents referenced in the communication statements from ITU-T. ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html ITU-T Study Group 15 Home Page: http://www.itu.int/ITU-T/studygroups/com15/index.html For free download of the "Optical Transport Network and Technology Standardization/Work Plan", follow the following link from the ITU-T Study Group 15 home page: Optical Transport Networks & Technologies Project description Regards, Steve Trowbridge Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 08:36:53 -0800 Message-ID: <3C163610.7090401@lucent.com> Date: Tue, 11 Dec 2001 11:36:32 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: John Drake CC: Ben Mack-Crane , Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, To further the discussion, would it be possible to add a new flag for purpose of identifying whether or not a connection (secondary connection) can support extra traffic. A 1:1 connection should be able to support extra traffic (if secondary is not used) while a 1+1 would not support extra traffic. Also, we may want to add a flag for whether or not a protection is revertive. Also, current "link flags" is assumed to provide link protection. Maybe we can add a new flag for either "link" or "path" protection. So the total is three new flags using 3 bits, out of the current 25 reserved bits. What do you think? Zhi John Drake wrote: > Snipped > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Tuesday, December 11, 2001 6:38 AM > To: Lou Berger > Cc: Kireeti Kompella; ccamp@ops.ietf.org > Subject: Re: Moving right along ... generalized-signaling-06 > > > >>>7) In Protection Information it states "The resources allocated for a >>> secondary LSP MAY be used by other LSPs until the primary LSP fails >>> over to the secondary LSP." This may not always be the case. An >>> explicit flag indicating whether or not extra traffic may use the >>> secondary path resources is needed. >>> >>??? This is the purpose of this bit. >> > > This is not clear from the definition. The bit is defined as indicating > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > secondary LSP may not be used for extra traffic. > > Perhaps the problem here is that protection features are being defined > before the protection framework and requirements are done. Is this > presupposing some particular outcome of the recovery work in CAMP? > > JD: I think the definition of the bit is fine. For both 1+1 and 1:1 > protection, there would be a pair of Primary LSPs between the source > and destination, rather than a Primary and a Secondary. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 08:15:58 -0800 Message-ID: <3C163131.E6FBA1AB@alcatel.fr> Date: Tue, 11 Dec 2001 17:15:45 +0100 From: Richard Douville Organization: Alcatel R&I - URP MIME-Version: 1.0 To: Ben Mack-Crane CC: Lou Berger , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On the specific section on the waveband switching, we also agree that further work is required to achieve a consistent definition of waveband switching in GMPLS. In http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt and http://www.ietf.org/internet-drafts/draft-dotaro-ipo-multi-granularity-01.txt , we try to address some of the issues concerning waveband switching, notably by the introduction of a waveband switch capable interface (WBSC). We also try to remain as compliant as possible with the current proposition (GMPLS-SIG) for the proposed enhancements. However, we encourage that waveband switching issues be restudied before putting it back on the standard track. It is clear that an in-depth analysis of the constraints and requirements for waveband switching could leed to best suited proposals. What are the next step : take it off GMPLS-SIG for further work (ad hoc design team?), other ideas ? Regards, Richard Douville et al. Ben Mack-Crane wrote: > > See comments below. > > Regards, > Ben > > Lou Berger wrote: > > > > At 01:09 PM 10/29/2001, Ben Mack-Crane wrote: > > > > >After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have > > >a few comments and questions: > > > > > >1) There seems to be no difference as far as label allocation > > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > > and Ethernet 802.3 (10). One Encoding type would seem to > > > be sufficient. > > > > I agree, but some feel that this is needed to properly establish LSPs in > > systems what would terminate each type differently. > > I don't recall seeing anything on the list about the reasoning about this. > can someone provide a pointer to where this was described? > > Since LSP Encoding type is intended to describe the LSP for transit nodes > and G-PID is intended to describe the LSP contents for the purpose of > terminating it at the ends, information relevant only to termination > should be conveyed in G-PID. > > Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" > would make this clearer. > > > > > >2) G-PID types (19), (20), and (21) are repeats of (16), (17), > > > and (18). > > > > see latest draft... > > Thanks for fixing this. The new (19) should probably be "VC-11 in TU-12." > > > > > > Since the Siganl Type will indicate whether the > > > LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant. > > > > the fields serve different purposes. > > > > >3) G-PID type (37) Lambda seems insufficient (too vague) to > > > support interoperability. Is there any practical use for this > > > value? > > > > yes, it's needed when doing fiber/port switching. > > > > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it > > > is useful to define discrete values to identify the bandwidth of the > > > LSP." For SONET/SDH this is unnecessary given the Signal Type is > > > provided. For the other non-packet LSP types (Lambda and Fiber) > > > it is not clear that all the values cited in the example are relevant > > > (for example, a DS0 lambda would seem wasteful...). > > > > > This is confusing, and should be clarified. In fact, a description of > > > exactly why this field is required is needed. > > > > We've gone over this text multiple times. Do you have any suggested wording. > > > > I would gladly suggest wording if I understood the use for this. It has no use > for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda > or Fiber. However, several of the examples are not appropriate for this. > Perhaps this should be moved to a technology specific document since it is > not really general anyway. > > > >5) The Waveband ID "is selected by the sender and reused in all > > > subsequent related messages." This seems more the sort of thing that > > > should be negotiated by LMP rather than during connection setup. > > > > The ID has significance within signaling context of the sender. (like > > message id). I don't think using another layer of complexity for provate > > information makes sense. > > > > >6) The definition of Start Label and End Label in waveband switching seems > > > inconsistent with the behavior described in generalized-rsvp-te-05. > > > > I don't see this. Feel free to suggest wording. > > Does anyone else see an inconsistency here? I would be interested in hearing > from someone who understands the waveband content. > > I am concerned that the waveband proposal is speculative and not ready to > progress toward RFC status. Perhaps the waveband content should be removed > and the sections marked FFS. > > > > > > > > >7) In Protection Information it states "The resources allocated for a > > > secondary LSP MAY be used by other LSPs until the primary LSP fails > > > over to the secondary LSP." This may not always be the case. An > > > explicit flag indicating whether or not extra traffic may use the > > > secondary path resources is needed. > > > > ??? This is the purpose of this bit. > > This is not clear from the definition. The bit is defined as indicating > the LSP is a secondary (or protecting) LSP and in 1+1 protection the > secondary LSP may not be used for extra traffic. > > Perhaps the problem here is that protection features are being defined > before the protection framework and requirements are done. Is this > presupposing some particular outcome of the recovery work in CAMP? > > > > > >8) The Administrative Status Information includes a bit indicating > > > "Administratively down," but there is no reference to a definition > > > of this state. Is this intended to mirror the MIB variable? If so, > > > a reference is needed. If not, more definition is needed to ensure > > > the local behaviors driven by this bit are in some way consistent. > > > Whether this state defintion is consistent with current transport > > > network operations should also be considered. > > > > Per the document: > > The actions taken by a node based on a state local decision. > > > > >9) In Interface Identification, the IP Address for types 3,4, and 5 is > > > described as possibly "an IP address associated with the router ID." > > > Is this intended to mean the Router ID or any IP address owned by > > > the node? It seems the Router ID is the simplest solution, but the > > > wording is not clear. > > > > Text has been reworded in 07. It's any IP address configured on a node. > > > > >10)In describing the Interface ID the statement "The special value > > > 0xFFFFFFFF can be used to indicate the same label is to be valid > > > across all component links." What is the "label" referred to in > > > this case? > > > > I'll reword in the post IETF last call rev of the document. > > > > Lou > > > > >Regards, > > >Ben Mack-Crane -- Richard Douville Richard.Douville@alcatel.fr Alcatel Research & Innovation Photonic Networks Unit, URP Route de Nozay Tel: 33-1-69.63.44.31 F-91460 Marcoussis, France. Fax: 33-1-69.63.18.65 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 07:39:23 -0800 Message-ID: From: John Drake To: Ben Mack-Crane , Lou Berger Cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: Moving right along ... generalized-signaling-06 Date: Tue, 11 Dec 2001 07:35:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Snipped -----Original Message----- From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] Sent: Tuesday, December 11, 2001 6:38 AM To: Lou Berger Cc: Kireeti Kompella; ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 > > > > >7) In Protection Information it states "The resources allocated for a > > secondary LSP MAY be used by other LSPs until the primary LSP fails > > over to the secondary LSP." This may not always be the case. An > > explicit flag indicating whether or not extra traffic may use the > > secondary path resources is needed. > > ??? This is the purpose of this bit. This is not clear from the definition. The bit is defined as indicating the LSP is a secondary (or protecting) LSP and in 1+1 protection the secondary LSP may not be used for extra traffic. Perhaps the problem here is that protection features are being defined before the protection framework and requirements are done. Is this presupposing some particular outcome of the recovery work in CAMP? JD: I think the definition of the bit is fine. For both 1+1 and 1:1 protection, there would be a pair of Primary LSPs between the source and destination, rather than a Primary and a Secondary. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 07:01:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: "Sven Van den Bosch" To: ccamp@ops.ietf.org Subject: ccamp agenda Date: Tue, 11 Dec 2001 15:52:54 +0100 Hi, I regret to see that the time constraints for the ccamp agenda were so tight that we could not fit all proposals for multi-area TE. Surely, if a design team is formed, we can take all proposals into account during the discussion. Sven. _________________________________________________________________ Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 06:57:20 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C161EA9.63558BD6@lucent.com> Date: Tue, 11 Dec 2001 15:56:41 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP establishment Content-Type: multipart/mixed; boundary="------------0D7C41BC8C4651C4FE99D78F" This is a multi-part message in MIME format. --------------0D7C41BC8C4651C4FE99D78F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, You refer to one wavelength to be available between A-E without wavelength conversion capability. This suggests that you operate at the OCh layer network. Then you specify the capacity of the 4 OCh link connections (A-B, B-C, C-D, D-E) to be "C". Say that C is about 10 Gbit/s. You then assume that there is a request for an OCh signal with capacity C/4 (e.g. 2.5 Gbit/s) between C and E. The result is that the OCh link connections C-D and D-E are transporting the OCh signal (of e.g. 2.5G). These OCh link connections are now in service and not longer available to an other OCh connection request. I.e. a request for an OCh connection between A and E will be rejected. FAs are not applicable in the circuit layers. IF there is a trail in server layer X, then there is a link in its client layer Y. X and Y are thus different layer networks and signals. If C-E is a "FA", then in an OTN the C-E connection would be an OCh trail supporting an ODUk (k=1 if OCh is 2G5) link with a single link connection. Note a FA in MPLS creates essentially a MPLS sublayer network. Such is not possible in the SDH/SONET, OTN, PDH or ATM technologies. Regards, Maarten OCh link connections manoj juneja wrote: > > Hi All, > If I have 5 nodes A, B, C, D and E connected as shown. Assume > that only one wavelength is available on the path A to E (no wavelength > conversion capability is there on the complete path). Let the capacity > of the wavelength be C. Further assume a request arrives for connection > from node C to E for a line capacity of C/4. This request will be > successful as we have available wavelength. Now If another request > comes at node A to establish another connection from node A to node E > via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request > be successful as we have already allocated the wavelength ? > > If the previous connection from C to E of capacity C/4 had been > advertised as a FA, in that case will the IInd request succeed ? > > If the previous connection from C to E of capacity C/4 had not been > advertised as FA then what will be the fate of IInd connection ? > > A <--> B <---> C <----> D <---> <----> E > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------0D7C41BC8C4651C4FE99D78F Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------0D7C41BC8C4651C4FE99D78F-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 06:44:07 -0800 Message-ID: <3C161A3F.3A597ACF@tellabs.com> Date: Tue, 11 Dec 2001 08:37:51 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Lou Berger CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-rsvp-te-05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See comments below. Regards, Ben Lou Berger wrote: > > At 03:08 PM 10/29/2001, Ben Mack-Crane wrote: > > >After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt > >I have the following comments and questions: > > > >1) In the procedures regarding the Generalized Label Request > > object, the statement is made that "The node may either > > directly support the LSP or it may use a tunnel (FA), > > i.e., another class of switching." > > please see the routing drafts. Will these tell me that an FA is a type of switching? I still think that's not accurate. > > >A Tunnel (FA) is a type > > of link, not a class of switching. This adds to the > > confusion I've noted about the need for and use of Switching > > Type. Switching Type continues to be ill-defined. I have heard that the real definition is different from that given in the current drafts. If the signaling information is not clearly defined and it's use described, we can hardly expect interoperability. > > >2) Bandwidth Encoding use of the Intserv Tspec object seems > > quite unusual since this use is not consistent with existing > > uses of this object, and new uses could easily use a new > > C-Type. > > I think either approach work. This topic was discussed by the authors at > least 12-18 months. The current approach was decided then. It was discussed and rejected for TDM. At least we should clarify the applicability for this use of the Intserv Tspec. > > >3) In the procedures for Generalized Label it states "If the label is > > unacceptable then the recipient MUST generate a ResvErr message with > > a "Routing problem/MPLS label allocation failure" indication." > > I think "Unacceptable Label Value" would be more appropriate. > > okay. > > >4) In the Waveband Switching section it says "For compatibility reasons, > > a new RSVP C-Type (3) is assigned." What is the compatability > > problem this is solving? > > simply to distinguish types. I remove the text to avoid such confusion in > the future. > > >5) In the Label Set object, why is the Label Type field 14 bits if > > only the low order 8 bits are used? > > for CR-LDP compatibility. > > >6) Some new error strings are defined, "Label Set" and "Unsupported Link > > Protection," but no values or placeholders are included. Where are new > > error values to be documented? > > As part of IANA assignment. Is this to be added to the IANA Considerations section or is it a new document? > > >7) The Notify message is intended to "enable expedited notification of > > failures," but it relies on the IP layer which may be affected by the > > failure that the Notify is reporting. This could defeat the goal > > of rapid notification. Without some means of guaranteeing the Notify > > doesn't have to wait for IP routing convergence to be delivered, > > it isn't a satisfactory solution. > > Well? Does anyone else have thoughts on this? > >8) The description of the C-Type field in the Label ERO subobject suggests > > that this subobject contains a Label Object. Is this the case, or does > > the Label ERO subobject simple contain label values, and the C-Type > > matches the C-Type that would be used if the same label values were > > included in a Label object? > > per the draft: > > Label: Variable > > This field identifies the label to be used. The format of this > field is identical to the one used by the Label field in > Generalized Label, see Section 3.2.1. > > >9) In deleting an LSP from the egress, the R bit is set in the Admin Status > > object. The ingress responds with a PathTear message. Does this PathTear > > contain the Admin Status object or should the R bit be cleared? > > It's not in the BNF, so no it's not included. > So perhaps we should change 1. The egress node indicates its desire for deletion by inserting an Admin Status Object in a Resv message and setting the Reflect (R) and Delete (D) bits. to 1. The egress node indicates its desire for deletion by inserting an Admin Status Object in a Resv message and setting the Delete (D) bit. > >10)The Notify message may contain a new setting of the Admin Status. > > Under what conditions would an intermediate or egress node change > > Admin Status? > > It may be used at any time that a PathErr or ResvErr is generated. > > > What happens if the Notify receiver is not the ingress? > > same action as would be taken if/when the corresponding message is received. > > >11)In Interface Identification it says "Data channels are specified from > >the view point > > of the sender of the Path message." Is this true even for Resv messages > > or should it read "Data channels are specified from the viewpoint > > of the sender of the message."? > > current text is correct. > > >12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be > > suppressed during this waiting period." I assume this is refreshes > > toward the failed neighbor, not to all neighbors for that LSP. True? > > yes. > > thanks for the comments, > lou > > >Regards, > >Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 06:43:58 -0800 Message-ID: <3C161A33.365D84A2@tellabs.com> Date: Tue, 11 Dec 2001 08:37:39 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Lou Berger CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... generalized-signaling-06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See comments below. Regards, Ben Lou Berger wrote: > > At 01:09 PM 10/29/2001, Ben Mack-Crane wrote: > > >After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have > >a few comments and questions: > > > >1) There seems to be no difference as far as label allocation > > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > > and Ethernet 802.3 (10). One Encoding type would seem to > > be sufficient. > > I agree, but some feel that this is needed to properly establish LSPs in > systems what would terminate each type differently. I don't recall seeing anything on the list about the reasoning about this. can someone provide a pointer to where this was described? Since LSP Encoding type is intended to describe the LSP for transit nodes and G-PID is intended to describe the LSP contents for the purpose of terminating it at the ends, information relevant only to termination should be conveyed in G-PID. Perhaps changing the name of this LSP Encoding Type to "Ethernet Phy" would make this clearer. > > >2) G-PID types (19), (20), and (21) are repeats of (16), (17), > > and (18). > > see latest draft... Thanks for fixing this. The new (19) should probably be "VC-11 in TU-12." > > > Since the Siganl Type will indicate whether the > > LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant. > > the fields serve different purposes. > > >3) G-PID type (37) Lambda seems insufficient (too vague) to > > support interoperability. Is there any practical use for this > > value? > > yes, it's needed when doing fiber/port switching. > > >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it > > is useful to define discrete values to identify the bandwidth of the > > LSP." For SONET/SDH this is unnecessary given the Signal Type is > > provided. For the other non-packet LSP types (Lambda and Fiber) > > it is not clear that all the values cited in the example are relevant > > (for example, a DS0 lambda would seem wasteful...). > > > This is confusing, and should be clarified. In fact, a description of > > exactly why this field is required is needed. > > We've gone over this text multiple times. Do you have any suggested wording. > I would gladly suggest wording if I understood the use for this. It has no use for Packet, PDH, SDH/SONET, or "Digital Wrapper," so I assume it is for Lambda or Fiber. However, several of the examples are not appropriate for this. Perhaps this should be moved to a technology specific document since it is not really general anyway. > >5) The Waveband ID "is selected by the sender and reused in all > > subsequent related messages." This seems more the sort of thing that > > should be negotiated by LMP rather than during connection setup. > > The ID has significance within signaling context of the sender. (like > message id). I don't think using another layer of complexity for provate > information makes sense. > > >6) The definition of Start Label and End Label in waveband switching seems > > inconsistent with the behavior described in generalized-rsvp-te-05. > > I don't see this. Feel free to suggest wording. Does anyone else see an inconsistency here? I would be interested in hearing from someone who understands the waveband content. I am concerned that the waveband proposal is speculative and not ready to progress toward RFC status. Perhaps the waveband content should be removed and the sections marked FFS. > > > > >7) In Protection Information it states "The resources allocated for a > > secondary LSP MAY be used by other LSPs until the primary LSP fails > > over to the secondary LSP." This may not always be the case. An > > explicit flag indicating whether or not extra traffic may use the > > secondary path resources is needed. > > ??? This is the purpose of this bit. This is not clear from the definition. The bit is defined as indicating the LSP is a secondary (or protecting) LSP and in 1+1 protection the secondary LSP may not be used for extra traffic. Perhaps the problem here is that protection features are being defined before the protection framework and requirements are done. Is this presupposing some particular outcome of the recovery work in CAMP? > > >8) The Administrative Status Information includes a bit indicating > > "Administratively down," but there is no reference to a definition > > of this state. Is this intended to mirror the MIB variable? If so, > > a reference is needed. If not, more definition is needed to ensure > > the local behaviors driven by this bit are in some way consistent. > > Whether this state defintion is consistent with current transport > > network operations should also be considered. > > Per the document: > The actions taken by a node based on a state local decision. > > >9) In Interface Identification, the IP Address for types 3,4, and 5 is > > described as possibly "an IP address associated with the router ID." > > Is this intended to mean the Router ID or any IP address owned by > > the node? It seems the Router ID is the simplest solution, but the > > wording is not clear. > > Text has been reworded in 07. It's any IP address configured on a node. > > >10)In describing the Interface ID the statement "The special value > > 0xFFFFFFFF can be used to indicate the same label is to be valid > > across all component links." What is the "label" referred to in > > this case? > > I'll reword in the post IETF last call rev of the document. > > Lou > > >Regards, > >Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 06:40:47 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C161A37.D19C4D2C@lucent.com> Date: Tue, 11 Dec 2001 15:37:43 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Jonathan Lang Original-CC: ccamp@ops.ietf.org Subject: Re: Fwd: LSC Interface Doubt ... Content-Type: multipart/mixed; boundary="------------59EEFFCF4A7B4144BC9961AB" This is a multi-part message in MIME format. --------------59EEFFCF4A7B4144BC9961AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan, Jonathan Lang wrote: > > Maarten, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Friday, December 07, 2001 1:30 AM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: Fwd: LSC Interface Doubt ... > > > > > > Manoj, > > > > Are you aware that a PXC can be operated as an ODUk switch or > > a STM/OC-N switch in addition to an OCh switch? > > > > The PXC is a name for an optical fabric equipment. As fabrics are typical > more > > transparent than the connected line/trib ports, those latter determine the > > switching type. E.g. a PXC connected to optical line systems including > > transponders will not operate at wavelenght level. > A clarification here is needed. I agree that a PXC with integrated > transponders can be TDM capable. However, if the OLS is a separate piece of > equipment (most likely not speaking GMPLS), then from a GMPLS perspective, > the PXC is doing wavelength switching. Granted the wavelengths actually > being switched may all be the same wavelength (e.g., 1310), but they are > still wavelength switched. The allocation of functions to boxes isn't determining the functionality itself. The addition of OLI/VBI to the OLS and PXC boxes makes the combination a true cross connect. I can replace the set of boxes by a single box with an electrical fabric, and would get the same functionality from the network perspective. As such the OLS inlcuding 3R transponders makes that the PXC operates as a STM-N/OC-N/GE switch/cross connect (case of pre-OTN), or as an ODUk switch/cross connect (case of OTN). Take another example of bit interleaving... most people are used to this in the electrical domain; i.e. a parallel/serial converter circuit takes one bit of N parallel wires and outputs these N bits on a single wire... after this action the serial signal is these days typically converted into an optical signal... The alternative is to use OTDM techniques to perform the bit interleaving... the signals on the N parallel wires are electrically interleaved into signals onto e.g. 4 wires... the 4 resulting bit streams are then converted into the optical signals... then the final bit interleaving uses an OTDM circuit... As can be seen the functionality hasn't changed despite that a complete different technology is being deployed. To me this discussion is very helpful. It shows to me that LSC is an ambiguous term. As the transport plane doesn't have a "lambda" layer network, I believe that it is time to convert the current terminology of LSC and also TDM into the real transport layer terminology like OCh, ODUk (k=1,2,3), HOVC (VC-3,4,4-4c,...) and LOVC (VC-3,2,12,11). If GMPLS is intended to support connection management in the SDH and OTN networks, it should use the terminology applicable in these networks. > > > The transponders have > > terminated the wavelengths. Such combination will switch ODUk and/or > STM/OC-N > > signals. For the case the line systems do not have transponders, the PXC > > operates as true OCh (i.e. wavelength) switch. > agreed, this is an example of 15xx wavelength switching. > > > > > Most line systems in the core network today deploy 10G wavelengths, > whereas many > > service signals are at 2G5 level. Therefore, the transponders in the line > system > > may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there > will > > be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits > (case > > of 10G services). Here it is more obvious that the PXC doesn't switch > "wavelengths". > I don't see the difference here (except higher rates) from the first > example. Again, > if the PXC is speaking GMPLS, the PXC can be considered to be doing > wavelength switching since it is switching (e.g., 1310) wavelengths > transparently. A wavelength is never switched. A wavelenght is the representation of a tributary slot within a WDM signal. When the WDM signal terminates (i.e. in an OLS) the tributary slot ceases to exist. The optical signal transported via the trib slot is extracted and forwarded to the PXC. If there is a 3R transponder, the optical signal is terminated in the OLS also. If there is no 3R transponder, the optical signal is forwarded and the full capability of the PXC (i.e. to switch optical signals) is deployed. GMPLS or ASON isn't having any impact on the transport plane functionality of the PXC. The PXC managed by a NMS will provide the same transport plane functionality. Regards, Maarten > > > > > Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no > > transponders are present around the fabric. > This is not the definition in GMPLS. > > > > > Regards, > > s> > Maarten > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > I refer to LSC interface as defined in GMPLS architecture > > > document (i.e. interface which switch data based on the wavelength on > > > which the data is received e.g. PXC or OXC which operate at the level > > > of individual wavelength). I don't think it has any thing to do with > > > Och (G.709). > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Fwd: LSC Interface Doubt ... > > > >Date: Thu, 06 Dec 2001 11:42:02 +0100 > > > > > > > >Manoj, > > > > > > > >I assume you refer to G.709 OCh connections when you use the term "LSC > > > >LSP". If > > > >so, then a bi-directional OCh link connection will use the same OCh > > > >tributary > > > >slot in both directions; i.e. the same wavelenght is used for go and > return > > > >direction. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I need to establish a bi-directional LSC LSP then do I > > > > > need to configure the remote end wavelengths on an LSC interface ? > > > > > Is there any case where both the upstream and downstream labels of > an > > > > > bi-directional LSC LSP be same ? > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > --------------59EEFFCF4A7B4144BC9961AB Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------59EEFFCF4A7B4144BC9961AB-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 06:38:08 -0800 Cc: ccamp@ops.ietf.org, jplang@calient.net Message-ID: <3C1619F1.833AE35B@lucent.com> Date: Tue, 11 Dec 2001 15:36:33 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org, jplang@calient.net Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Content-Type: multipart/mixed; boundary="------------34D86F8B439D691F55D043D3" This is a multi-part message in MIME format. --------------34D86F8B439D691F55D043D3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Manoj, manoj juneja wrote: > = > Hi Marteen, > I fully agree with the diagram below. There will be a ATM V= P > link (VC-4-64c) between nodes A and D. > = > Can u please elaborate more on this one : > "ATM VP connection controllers in A and D exchange ATM VP labels to > setup ATM VP connections" > = > How will the ATM VP labels be distributed between nodes A and D ? Is it= > not with in the scope of GMPLS signalling ? ATM control plane uses PNNI to support ATM VP and ATM VC connection manag= ement. But if you consider GMPLS applicable also at these layers, then there wil= l be an ATM specific part in GMPLS, which defined VP labels (i.e. based on VPI) a= nd VC labels (i.e. based on VCI). Also, AAL2 layer network (supporting voice) w= ould have AAL2 labels. ATM VP connection controllers in nodes A and D would then have a relation= ship and pass ATM VP signalling messages. Besides ATM (with its PNNI/Q.2931 protocol), we will see ethernet with/wi= thout VLANs to become part of the transport plane. Ethernet PHYs are more and m= ore deployed to connect to the transport plane, and as a result the transport= equipment is extended with 10M, 100M, 1G and 10G ethernet interfaces. The= ethernet PHY is terminated immediately after the connector and the ethern= et frames are buffered and then forwarded via virtual concatenated VC-n-Xv s= ignals. The associated VC-n-Xv trails support Ethernet links. These ethernet link= s have trib slots as well, and labels will therefore be present... e.g. with VLA= N the VLAN identifier would be the basis for the label. These labels would be exchanged between two adjacent ethernet switches at the end of an etherne= t link. And of course not to forget, MPLS is expected to enter the transport netw= ork to support the ethernet transmission over the backbone networks... VLAN id r= ange is to restricted and the industry is looking at MPLS to perform the VLAN job= in the backbone. In this case there will be a MPLS link supported by VC-n(-Xv), = VC-n-Xc and ODUk(-Xv) trails. In this case MPLS switches in nodes A and D will ex= change MPLS labels. > = > If I am misinterpreting the concept of LSP hierarchies, please let me k= now > that too. GMPLS as connection management tool for SDH/SONET, OTN and pre-OTN needs = to recognise the layer network structure that is defined by these technologi= es. The LSP hierarchy terminology is not aligned with the layer networks in these= technologies. The actual hierarchy in the SDH/SONET/(pre-)OTN transport p= lane is LOVC (VC-11,VC-12,VC-2,VC-3) HOVC (VC-3,VC-4,VC-4-4c,VC-4-16c,VC-4-64c, VC-4-256c) [STM-N (STM-16, STM-64, STM-256)] =3D=3D> pre-OTN case ODU1 ODU2 ODU3 OCh ATM VP, Ethernet, MPLS, IP are clients of LOVC, HOVC, ODU1, ODU2, ODU3 l= ayers. Regards, Maarten > = > Regards, > manoj. > = > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency > >Date: Fri, 07 Dec 2001 11:00:54 +0100 > > > >Manoj, > > > >When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to t= he > >ATM VP > >layer network. As such, ATM VP signals are being routed via this ATM V= P > >link > >supported by the VC-4-64c trail. So ATM VP labels will be used between= > >nodes A > >and D. > > > > NE A NE B NE C NE D > >|<---------->|<---------------->|<------------------->|<--------------= ->| > > > > |||| |||| > >ATM VP Fabric ATM VP Fabric= > > |||||| |||||| > > VC-4-64c VC-4-64c > > port port > > | | > > | | > > | VC-4-64c Fabric VC-4-64c Fabric | > > | | |||| |||| | | > > STM-64 STM-64 STM-256 STM-256 STM-64 STM-64 > > port port port port port port > > | | | | | | > > ------------- ------------- ------------- > > > >When the ATM equipment at A needs a 10G link with the aTM equipment at= D, > >it > >requests a regular VC-4-64c connection between A and D. As the connect= ion > >terminates at VC-4-64c ports automatically there is an ATM VP link cre= ated. > >The > >ATM VP connection controllers in A and D exchange ATM VP labels to set= up > >ATM VP > >connections. > > > >When the Vc-4-64c connection had to be setup, the VC-4-64c connection > >controllers in A, B, C and D will exchange VC-4-64c labels. > > > >When the ATM equipment is in a user domain, the interface between node= s A > >and B > >and nodes C and D are UNIs. In that case the VC-4-64c connection > >controllers in > >nodes A and D are replaced by VC-4-64c call controllers. Then the > >interactions > >are between calling/called party call controllers (in nodes A and D) a= nd > >network > >call controllers, and network call controller and connection controlle= rs in > >nodes B and C. > > > >As you see there is no notion of FA needed. > > > >Regards, > > > >Maarten > > > > > >manoj juneja wrote: > > > > > > Hi Marteen, > > > Agreed. VC-4-64c connection can be advertised as a FA a= nd > > > can carry IP/ATM or ethernet traffic. > > > > > > Now take the case where multiple LSPs are to be tunneled through th= e > > > VC-4-64c connection (FA-LSP). > > > What about the label ? What type of label the tail end of VC-4-64c = FA > > > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c= FA > > > -LSP) ? > > > The LSP encoding and switching types are different for FA-LSP and t= he > > > LSP which is to be tunneled through the FA-LSP. > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: "'manoj juneja'" > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency > > > >Date: Thu, 06 Dec 2001 12:24:32 +0100 > > > > > > > >Manoj, > > > > > > > >In transport terminology I would refer to this as a VC-4-64c trail= > > > >supporting an > > > >IP, ATM or Ethernet link. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >Heiles Juergen wrote: > > > > > > > > > > Manoj, > > > > > > > > > > this has nothing to do with forwarding adjacency. It is a > >restriction of > > > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A= > >VC-4-64c > > > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or > > > >VC-3/2/12/11. > > > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or > >Ethernet > > > >clients. > > > > > > > > > > Juergen > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > > > > Hi Juergen, > > > > > > Does this mean the forwarding adjacency concept i= s not > > > > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > > > > adjacecny of > > > > > > virtual concatenated LSP should be allowed. > > > > > > > > > > > > Regards, > > > > > > manoj. > > > > > > > > > > > > > > > > > > >From: "Juergen Heiles" > > > > > > >To: "'manoj juneja'" , > > > > > > > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a= > > > > > > VC-4-64c. A > > > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > > > > > > > >Juergen > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > > > > An: ccamp@ops.ietf.org > > > > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > > > > forwarding > > > > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > > > > > > > Regards, > > > > > > > > manoj > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > > Get your FREE download of MSN Explorer at > > > > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________= ____ > > > > > > Get your FREE download of MSN Explorer at > > > > > http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > = > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.= asp --------------34D86F8B439D691F55D043D3 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------34D86F8B439D691F55D043D3-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 00:57:38 -0800 Date: Tue, 11 Dec 2001 00:49:24 -0800 (PST) From: Kireeti Kompella Message-Id: <200112110849.AAA02112@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP agenda Sorry, folks, due to a mix-up, the agenda was not published. Here it is. Unfortunately, I don't know who will be talking for some of the slots; please step forward and claim yours. Kireeti. ------- Agenda bashing (10 min) blue sheets & minute takers Status update (15 min) Trowbridge/ITU update (10 min) Bonica/GTTP Reqts (5 min) Farrell/GMPLS MIBs (10 min) draft-ietf-ccamp-lmp-mib-00.txt draft-nadeau-ccamp-gmpls-label-mib-00.txt draft-nadeau-ccamp-gmpls-lsr-mib-00.txt draft-nadeau-ccamp-gmpls-tc-mib-00.txt draft-nadeau-ccamp-gmpls-te-mib-00.txt Mannie/GMPLS Arch (5 min) draft-ietf-ccamp-gmpls-architecture-01.txt Mannie/SONET-SDH (5 min) draft-ietf-ccamp-gmpls-sonet-sdh-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt Mannie/GMPLS LBM (10 min) draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Papadimitriou/GMPLS for G.709 (10 min) Lang/LMP (5 min) Fredette/LMP-WDM (5 min) Papadimitriou/LMP for SONET-SDH (5 min) draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Lee/Path Request (5 min) draft-lee-mpls-path-request-02.txt Vasseur/Computation RSVP (5 min) Farrell/Crankback (5 min) draft-iwata-mpls-crankback-02.txt Lang/Recovery (5 min) draft-lang-ccamp-recovery-01.txt ?/Protection Restoration Signaling (5 min) draft-bala-protection-restoration-signaling-00.txt ?/Shared Mesh Restoration (5 min) draft-li-shared-mesh-restoration-01.txt ?/SRG (5 min) draft-many-ccamp-srg-01.txt Status Update 1) Most (if not all) issues on the signaling drafts addressed Base signaling: Lou sent mail yesterday draft-ietf-mpls-generalized-signaling-07.txt draft-ietf-mpls-generalized-rsvp-te-06.txt draft-ietf-mpls-generalized-crldp-05.txt SONET-SDH signaling: label issue resolved group signals resolved draft-ietf-ccamp-gmpls-sonet-sdh-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt Chairs' reading: we have rough consensus for IETF Last Call If you think there are issues that have been raised and not addressed, please send email to the list stating *specific* issue and date first raised by Tuesday Dec 18th and the editors will reply with their resolution. 2) Architecture document will catch up, then we'll seek consensus for a WG Last Call. 3) LMP Last Call done. 4) Discussions with ITU representatives; outcome: IETF will work on LMP-WDM for pre-OTN networks. ITU-T will work on VBI architecture for OTN, at which point LMP *may* be used for OTN. 5) Routing documents lagging. Will seek consensus for WG Last Call by year end. 6) MIBs under way. 7) Protection restoration work starts now 8) Single carrier, multi-area work starts now. Multiple carrier/domain out of scope. 9) May form design teams for the above two tasks. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 00:41:42 -0800 Message-ID: <3C15C6DA.6319D09E@npd.hcltech.com> Date: Tue, 11 Dec 2001 14:12:02 +0530 From: Rajaraman B MIME-Version: 1.0 To: Lou Berger , ccamp@ops.ietf.org Subject: Re: Comments on RSVP-TE-06 Content-Type: multipart/alternative; boundary="------------90DD5B327ED18CB6022972E2" --------------90DD5B327ED18CB6022972E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, But, When the label set is received in a Path message, that incoming Label Set is Compared(intersection-as given in the draft) against the downstream interface's set of label. That means, Incoming Label Set is compared with set of labels of the interface through which the Path message has come so that it can be used later while selecting a label for GENERALIZED_LABEL object in the corresponding Resv message which is sent through the interface the corresponding Path message has come already. Is it correct? Thanks, Rajaraman.B Lou Berger wrote: > At 02:15 AM 12/11/2001, Rajaraman B wrote: > >Hi, > > In the rsvp-te-06 draft, it has been written that "On reception of a > > Path message, the Label Set represented in the message is compared > > against the set of available labels at the downstream interface and the > > resulting intersecting Label Set is forwarded in a Path message.". > > > >My doubts are, > >1. Whether Downstream interface is with respect to Control Flow direction > >(direction of the Path message - Initiator to Terminator) or with respect > >to Data Flow direction (Terminator to Initiator - that is, direction of > >LSP path from Terminator to Initiator in the case of bidirectional LSP set > >up using UPSTREAM_LABEL) > > upstream (as always) = towards sender of path message > > >2. if the terminalogy "upstream and downstream" is with respect to Control > >Message flow direction, then whether Label Set object is used to restrict > >the Label Range for establishing upstream LSP(from Terminator to > >Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator > >to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and > >downstream LSP) > > generalized label. upstream label is selected by the upstream node, so > such restriction makes no sense. > > Lou > > >Thanks, > >Rajaraman. B > > --------------90DD5B327ED18CB6022972E2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    But, When the label set is received in a Path message, that incoming Label Set is Compared(intersection-as given in the draft) against the downstream interface's set of label. That means, Incoming Label Set is compared with set of labels of the interface through which the Path message has come so that it can be used later while selecting a label for GENERALIZED_LABEL object in the corresponding Resv message which is sent through the interface the corresponding Path message has come already.

Is it correct?

Thanks,
Rajaraman.B

Lou Berger wrote:

At 02:15 AM 12/11/2001, Rajaraman B wrote:
>Hi,
>     In the rsvp-te-06 draft, it has been written that "On reception of a
> Path message, the Label Set represented in the message is compared
> against the set of available labels at the downstream interface and the
> resulting intersecting Label Set is forwarded in a Path message.".
>
>My doubts are,
>1. Whether Downstream interface is with respect to Control Flow direction
>(direction of the Path message - Initiator to Terminator) or with respect
>to Data Flow direction (Terminator to Initiator - that is, direction of
>LSP path from Terminator to Initiator in the case of bidirectional LSP set
>up using UPSTREAM_LABEL)

upstream (as always) = towards sender of path message

>2. if the terminalogy "upstream and downstream" is with respect to Control
>Message flow direction, then whether Label Set object is used to restrict
>the Label Range for establishing upstream LSP(from Terminator to
>Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator
>to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and
>downstream LSP)

generalized label.  upstream label is selected by the upstream node, so
such restriction makes no sense.

Lou

>Thanks,
>Rajaraman. B
>

--------------90DD5B327ED18CB6022972E2-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Dec 2001 00:05:44 -0800 Message-Id: <4.3.2.7.2.20011211030305.021adea8@mo-ex1> Date: Tue, 11 Dec 2001 03:04:43 -0500 To: "Rajaraman B" From: Lou Berger Subject: Re: Comments on RSVP-TE-06 Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:15 AM 12/11/2001, Rajaraman B wrote: >Hi, > In the rsvp-te-06 draft, it has been written that "On reception of a > Path message, the Label Set represented in the message is compared > against the set of available labels at the downstream interface and the > resulting intersecting Label Set is forwarded in a Path message.". > >My doubts are, >1. Whether Downstream interface is with respect to Control Flow direction >(direction of the Path message - Initiator to Terminator) or with respect >to Data Flow direction (Terminator to Initiator - that is, direction of >LSP path from Terminator to Initiator in the case of bidirectional LSP set >up using UPSTREAM_LABEL) upstream (as always) = towards sender of path message >2. if the terminalogy "upstream and downstream" is with respect to Control >Message flow direction, then whether Label Set object is used to restrict >the Label Range for establishing upstream LSP(from Terminator to >Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator >to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and >downstream LSP) generalized label. upstream label is selected by the upstream node, so such restriction makes no sense. Lou >Thanks, >Rajaraman. B > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 23:14:12 -0800 Message-ID: <3C15B27A.A9FB3256@npd.hcltech.com> Date: Tue, 11 Dec 2001 12:45:06 +0530 From: Rajaraman B MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Comments on RSVP-TE-06 Content-Type: multipart/alternative; boundary="------------53080405A72C91465EF36370" --------------53080405A72C91465EF36370 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, In the rsvp-te-06 draft, it has been written that "On reception of a Path message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a Path message.". My doubts are, 1. Whether Downstream interface is with respect to Control Flow direction (direction of the Path message - Initiator to Terminator) or with respect to Data Flow direction (Terminator to Initiator - that is, direction of LSP path from Terminator to Initiator in the case of bidirectional LSP set up using UPSTREAM_LABEL) 2. if the terminalogy "upstream and downstream" is with respect to Control Message flow direction, then whether Label Set object is used to restrict the Label Range for establishing upstream LSP(from Terminator to Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and downstream LSP) Thanks, Rajaraman. B --------------53080405A72C91465EF36370 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    In the rsvp-te-06 draft, it has been written that "On reception of a Path message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a Path message.".

My doubts are,
1. Whether Downstream interface is with respect to Control Flow direction (direction of the Path message - Initiator to Terminator) or with respect to Data Flow direction (Terminator to Initiator - that is, direction of LSP path from Terminator to Initiator in the case of bidirectional LSP set up using UPSTREAM_LABEL)

2. if the terminalogy "upstream and downstream" is with respect to Control Message flow direction, then whether Label Set object is used to restrict the Label Range for establishing upstream LSP(from Terminator to Initiator) path using UPSTREAM_LABEL or only for downstream LSP(Initiator to Terminator) path using GENERALIZED_LABEL or Both (for upstream LSP and downstream LSP)

Thanks,
Rajaraman. B
  --------------53080405A72C91465EF36370-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 17:01:44 -0800 Message-ID: <3C1558C2.83055A2A@lucent.com> Date: Mon, 10 Dec 2001 17:52:18 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "David S. Miller" CC: "Mannie, Eric" , "'Dimitri Papadimitriou'" , Steve West , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, Virtual Concatenation, with or without LCAS accomodates differential delay for different parts of the payload. LCAS provides hitless add/remove. Also it provides for removal of failed components, even when this results in non-contiguous component numbering. LBM does not give you hitless add and remove from the payload. LBM also does not accomodate removal of non-contiguous components: e.g., if the 3rd of 10 concatenated VCs fail, I suppose you need to back down to 2 and then build up ... Steve "David S. Miller" wrote: > > Am I missing something? > > I thought that LCAS gains 2 things: > 1) Hitless and and remove of payload (dynamic bandwidth allocation) > but more importantly > 2) Differential Delay through the network for differents parts of the > payload (i.e. diverse routing of network traffic). > > How does GMPLS w/ LBM address the second issue? > > David Miller > Vitesse Semiconductor > > "Mannie, Eric" wrote: > > > > Hello Steve, > > > > Just to complement the answer of Dimitri, > > > > > You believe that the packet loss rate and robustness of LMB is > > > similar to LCAS ? > > > > LCAS waits for the end of control packet which is multi-framed to decide > > when the payload is significant (the "transition"). LBM uses for instance > > the C2 byte for the HOVC, since this byte appears directly in the POH and is > > not part of a control packet, that should go faster, right ? I.e. less > > glitch than with LCAS ? > > > > But having a field in the transport plane to indicate a transition (whatever > > is the field ) is not the most important issue. Even if you have that field, > > you need some time to provision the additional VCs/SPEs in the network. This > > is not done by LCAS, and any control plane or management plane will imply > > some time for that operation, and the glitch will really come from that > > process, not from the way that you detect a transition in the transport > > plane. > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > > could potentially be used with GMPLS or with other control plane or > > > management plane mechanisms ? > > > > When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS > > implies issues on this control plane. LCAS is a stand-alone solution that > > bypass the control plane to change the resource reservation in both end > > systems. A control plane maintains states in end systems (e.g. at the UNI) > > and in intermediate systems ! So, bandwidth modifications must be reflected > > in the control plane otherwise it will become inconsistent. > > > > Now, the control plane is natively designed to deal with these resource > > reservations including in the source and the destination (with the UNI). > > Moreover, GMPLS is natively designed to deal with bandwidth modification (in > > the packet world this was one of the major requirements). Originally, we > > just wanted to describe how to generalize these bandwidth modification > > principles to SDH/SONET and how to interwork with LCAS. > > > > Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all > > the protocol part. The rest was the issue about when to decide that a VC/SPE > > contains real user data or not (the transition). > > > > Since LCAS added a control message, naturally it used a field in that > > control message to indicate that transition. But with GMPLS we didn't need > > any new control message, se we looked at what was available *in the > > transport plane* to detect the fact that a VC/SPE contains now real user > > data (i.e the transition). We found natural to use the so-called SDH/SONET > > "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with > > the GMPLS label :-). So we added these aspects to the draft. This is the > > part that we expected to validate with the ITU-T/T1X1 folks, but flames came > > first... > > > > What we are certainly going to do, is to add in the draft a section about > > how GMPLS should work when LCAS is used at the same time. However, we think > > that using GMPLS and LCAS at the same time will be more complex than simply > > using GMPLS and will not bring something additional. So the natural > > observation came, "why should we use LCAS with GMPLS and build something > > more complex when there is almost no issue to solve when simply using GMPLS > > alone". Using GMPLS and LCAS at the same time to modify the bandwidth > > implies that we will have two signaling flows between the source and the > > destination running in parallel and overlapping. GMPLS will also speak with > > the source and the destination to do the same as LCAS, and with a > > distributed control plane you need GMPLS anyway (or PNNI or etc). > > > > We also added a section to explain how several GMPLS LSPs (i.e. circuits) > > can be combined together to form a larger virtually concatenated circuit. > > This allows to deal with the non co-routing of VCs/SPEs with GMPLS. > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Sunday, November 18, 2001 3:44 PM > > To: Steve West > > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; > > q11/15; t1x1.5 > > Subject: Re: [T1X1.5] Re: LCAS and > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Hi Steve, > > > > Thanks for your comments, see in-line... > > > > Steve West wrote: > > > > > > Dimitri: > > > > > > Please confirm my understanding of your proposal: > > > > > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > > > changes that occurs during transmission of a packet will not corrupt that > > > packet.) You believe that the packet loss rate and robustness of LMB is > > > similar to LCAS ? > > > > It is mentioned in the proposal that the source waits for a > > confirmation from the destination (i.e. Resv Message). THEN > > the source "equip" the VC/SPE and sends. After the destination > > sees in the POH that the VC is "equipped" (transition). > > > > So instead of using the transitions proposed in LCAS (based > > on the H4 CTRL words) we use the ones already available. > > > > Since we are the beginning, we were very cautious but we expect to > > reach more than reasonable robustness and reliability. > > > > > 2. LMB requires hardware coordination between the SONET payload mapper > > and > > > the SONET POH processor (C2 octet insertion/extraction logic) ? > > > > At the transport plane level C2 is the field that LBM uses for the > > transition in the HOVC POH. > > > > > 3. The hardware based synchronization performance requirements are > > similar > > > to those required by LCAS. Except that LCAS coordinates the critical > > > transitions using H4 instead of C2 ? And that Virtual Concatenation > > systems > > > require to coordinate their payload mappers with bits 1-4 of the H4 byte > > to > > > determine the sequence number anyway ? > > > > See above, yes and yes (since we re-use existing VC mechanisms) > > > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > > could potentially be used with GMPLS or with other control plane or > > > management plane mechanisms ? > > > > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact > > (from what i understand in your question) see it more from transport > > to control plane impact taking the assumption that you expect some > > hardware improvement. Let's first determine if this can be achieved > > and then discuss the implementation issues that can arise from this > > proposal. In a sense, GMPLS-LBM is a self-consistent solution. > > > > Regards, > > - dimitri. > > > > > Thanks, > > > > > > Steve > > > > > > -----Original Message----- > > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > > Sent: Friday, November 16, 2001 4:09 PM > > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > > > Cc: ccamp; q11/15; t1x1.5 > > > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Hi folks, > > > > > > What happens... when we start the technical discussion > > > all guys taking part to the previous one now are gone ? > > > > > > We would like to start a technical discussion.. rather > > > difficult if we stay alone... or everybody agree on > > > proposal made in the previous e-mail ? (this in order > > > to refine the mechanism detailed in the GMPLS LBM I-D.) > > > > > > Any technical feedback is highly appreciated. > > > > > > Cheers, > > > - dimitri. > > > > > > "Mannie, Eric" wrote: > > > > > > > > Hello Stephen > > > > > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > > > > No, please see explanations below. > > > > > > > > > If you use LBM and change the mappings at the two ends without some > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > (I think this is simple enough). > > > > > > > > No, please see below (C2 or V5 transition). > > > > > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > > > >because LCAS is "sacred", but because you are comparing apples to > > > > >oranges. Statements in this document such as "One drawback of LCAS is > > .." > > > > >are unnecessary and inappropriate in this context, since LBM does > > > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > > > >were solving the SAME problem better, this would be OK, but this > > > > >is not the case. > > > > > > > > No, please see below. > > > > > > > > Simple example: > > > > > > > > 1) you first signal an additional VC/SPE to the destination (via a > > Path). > > > > 2) the destination knows exactly which VC/SPE is added (via the label). > > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > > > so the VC/SPE is not yet added to concatenated signal. > > > > 4) then, you wait at the source for a confirmation from the destination > > > > (i.e. Resv). > > > > 5) the source "equip" the VC/SPE and sends. > > > > 6) the destination sees in the POH that the VC is "equipped" > > (transition). > > > > > > > > The difference between LCAS and LBM is that LCAS uses an additional > > > explicit > > > > indication in the overhead to say "this is the payload" to use. LBM > > > doesn't > > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > > >:-) > > > > > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > > > transitions > > > > to a significant payload. LBM proposes to do the same simply by looking > > at > > > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > > > anyway and that is used to indicate the type of payload. > > > > > > > > To be more precise about LCAS (I copy from the LCAS specification, > > section > > > > 6.3.1): "The first container frame to contain payload data for the new > > > > member shall be the container frame immediately following the container > > > > frame that contained the last bit(s) (i.e. the CRC) of the control > > packet > > > > with NORM/EOS message for that member" (the LCAS control packet). > > > > > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet > > in > > > > the POH with the appropriate transition of its CTRL field. LBM waits > > > simply > > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > > > (don't change SDH/SONET). > > > > > > > > By the way, this is version 0 of the draft and it was just posted. > > > > > > > > Suggestions, technical comments and improvements are welcome. > > > > > > > > I would appreciate if people could first read and speak before shooting > > > > directly :-) > > > > > > > > Kind regards, > > > > > > > > Eric > > > > > > > > -----Original Message----- > > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > > Sent: Friday, November 16, 2001 7:49 PM > > > > To: Mannie, Eric > > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > > > Eric, > > > > The point of my earlier email (items again below, this time with > > > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > > > > > The issue (and I think the reason for Maarten's strong reaction) is > > this: > > > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > (I hope this is not too subtle for non-native English speakers). > > > > > > > > LCAS is a method to hitlessly change the mappings at the two > > > > ends of a virtually concatenated trail to increase or decrease the > > > > bandwidth. It does not say anything about how components to be > > > > added or removed from the virtually concatenated "bundle" are > > > > set up or taken down. > > > > > > > > LBM talks about how to set up or take down those added or removed > > > > components, but not about the details of changing the mapping (other > > > > than that it is done after the new components are successfully > > > > established. > > > > > > > > If you use LBM and change the mappings at the two ends without some > > > > coordination such as LCAS, you will have a glitch to the traffic > > > > (I think this is simple enough). > > > > > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > > > because LCAS is "sacred", but because you are comparing apples to > > > > oranges. Statements in this document such as "One drawback of LCAS is > > .." > > > > are unnecessary and inappropriate in this context, since LBM does > > > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > > > were solving the SAME problem better, this would be OK, but this > > > > is not the case. > > > > > > > > Time to try to be constructive: > > > > - I think most of the current discussion of LCAS should be removed from > > > > this document. It is irrelevant since LCAS solves a different problem > > than > > > > LBM. To say that one is "better" than the other would only be meaningful > > > > if they were solving the same problem (can you really say that LBM > > solves > > > > problem A better than LCAS solves problem B?). > > > > - LCAS can be a good informative reference as a way to hitlessly modify > > > > the size of a virtually concatenated trail. > > > > - Clarify in the scope that the current draft describes the use of LBM > > > > without LCAS, which results in a traffic glitch when bandwidth is > > > modified. > > > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > > > the size of virtually concatenated pipes after LBM sets up new > > > component(s) > > > > or before LBM takes down old component(s) is a topic for further study > > > > and perhaps to be addressed in a future version of the draft. > > > > > > > > Regards, > > > > Steve > > > > > > > > Steve Trowbridge wrote: > > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > > > the traffic. > > > > > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > > > control plane knows that the different LSPs are part of the same > > > > > circuit. > > > > > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > > > be the preferred method for many applications. > > > > > > > > "Mannie, Eric" wrote: > > > > > > > > > > Hello Maarten, > > > > > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack > > of > > > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > > > document > > > > > and to compare GMPLS and LCAS functionalities ? > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 15:30:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3C1530B0.C2F56C88@vitesse.com> Date: Mon, 10 Dec 2001 17:01:20 -0500 From: "David S. Miller" To: "Mannie, Eric" CC: "'Dimitri Papadimitriou'" , Steve West , "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Am I missing something? I thought that LCAS gains 2 things: 1) Hitless and and remove of payload (dynamic bandwidth allocation) but more importantly 2) Differential Delay through the network for differents parts of the payload (i.e. diverse routing of network traffic). How does GMPLS w/ LBM address the second issue? David Miller Vitesse Semiconductor "Mannie, Eric" wrote: > > Hello Steve, > > Just to complement the answer of Dimitri, > > > You believe that the packet loss rate and robustness of LMB is > > similar to LCAS ? > > LCAS waits for the end of control packet which is multi-framed to decide > when the payload is significant (the "transition"). LBM uses for instance > the C2 byte for the HOVC, since this byte appears directly in the POH and is > not part of a control packet, that should go faster, right ? I.e. less > glitch than with LCAS ? > > But having a field in the transport plane to indicate a transition (whatever > is the field ) is not the most important issue. Even if you have that field, > you need some time to provision the additional VCs/SPEs in the network. This > is not done by LCAS, and any control plane or management plane will imply > some time for that operation, and the glitch will really come from that > process, not from the way that you detect a transition in the transport > plane. > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > could potentially be used with GMPLS or with other control plane or > > management plane mechanisms ? > > When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS > implies issues on this control plane. LCAS is a stand-alone solution that > bypass the control plane to change the resource reservation in both end > systems. A control plane maintains states in end systems (e.g. at the UNI) > and in intermediate systems ! So, bandwidth modifications must be reflected > in the control plane otherwise it will become inconsistent. > > Now, the control plane is natively designed to deal with these resource > reservations including in the source and the destination (with the UNI). > Moreover, GMPLS is natively designed to deal with bandwidth modification (in > the packet world this was one of the major requirements). Originally, we > just wanted to describe how to generalize these bandwidth modification > principles to SDH/SONET and how to interwork with LCAS. > > Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all > the protocol part. The rest was the issue about when to decide that a VC/SPE > contains real user data or not (the transition). > > Since LCAS added a control message, naturally it used a field in that > control message to indicate that transition. But with GMPLS we didn't need > any new control message, se we looked at what was available *in the > transport plane* to detect the fact that a VC/SPE contains now real user > data (i.e the transition). We found natural to use the so-called SDH/SONET > "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with > the GMPLS label :-). So we added these aspects to the draft. This is the > part that we expected to validate with the ITU-T/T1X1 folks, but flames came > first... > > What we are certainly going to do, is to add in the draft a section about > how GMPLS should work when LCAS is used at the same time. However, we think > that using GMPLS and LCAS at the same time will be more complex than simply > using GMPLS and will not bring something additional. So the natural > observation came, "why should we use LCAS with GMPLS and build something > more complex when there is almost no issue to solve when simply using GMPLS > alone". Using GMPLS and LCAS at the same time to modify the bandwidth > implies that we will have two signaling flows between the source and the > destination running in parallel and overlapping. GMPLS will also speak with > the source and the destination to do the same as LCAS, and with a > distributed control plane you need GMPLS anyway (or PNNI or etc). > > We also added a section to explain how several GMPLS LSPs (i.e. circuits) > can be combined together to form a larger virtually concatenated circuit. > This allows to deal with the non co-routing of VCs/SPEs with GMPLS. > > Kind regards, > > Eric > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Sunday, November 18, 2001 3:44 PM > To: Steve West > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; > q11/15; t1x1.5 > Subject: Re: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Hi Steve, > > Thanks for your comments, see in-line... > > Steve West wrote: > > > > Dimitri: > > > > Please confirm my understanding of your proposal: > > > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > > changes that occurs during transmission of a packet will not corrupt that > > packet.) You believe that the packet loss rate and robustness of LMB is > > similar to LCAS ? > > It is mentioned in the proposal that the source waits for a > confirmation from the destination (i.e. Resv Message). THEN > the source "equip" the VC/SPE and sends. After the destination > sees in the POH that the VC is "equipped" (transition). > > So instead of using the transitions proposed in LCAS (based > on the H4 CTRL words) we use the ones already available. > > Since we are the beginning, we were very cautious but we expect to > reach more than reasonable robustness and reliability. > > > 2. LMB requires hardware coordination between the SONET payload mapper > and > > the SONET POH processor (C2 octet insertion/extraction logic) ? > > At the transport plane level C2 is the field that LBM uses for the > transition in the HOVC POH. > > > 3. The hardware based synchronization performance requirements are > similar > > to those required by LCAS. Except that LCAS coordinates the critical > > transitions using H4 instead of C2 ? And that Virtual Concatenation > systems > > require to coordinate their payload mappers with bits 1-4 of the H4 byte > to > > determine the sequence number anyway ? > > See above, yes and yes (since we re-use existing VC mechanisms) > > > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > > could potentially be used with GMPLS or with other control plane or > > management plane mechanisms ? > > The scope of this proposal is to use GMPLS-LBM without LCAS. In fact > (from what i understand in your question) see it more from transport > to control plane impact taking the assumption that you expect some > hardware improvement. Let's first determine if this can be achieved > and then discuss the implementation issues that can arise from this > proposal. In a sense, GMPLS-LBM is a self-consistent solution. > > Regards, > - dimitri. > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Friday, November 16, 2001 4:09 PM > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > > Cc: ccamp; q11/15; t1x1.5 > > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Hi folks, > > > > What happens... when we start the technical discussion > > all guys taking part to the previous one now are gone ? > > > > We would like to start a technical discussion.. rather > > difficult if we stay alone... or everybody agree on > > proposal made in the previous e-mail ? (this in order > > to refine the mechanism detailed in the GMPLS LBM I-D.) > > > > Any technical feedback is highly appreciated. > > > > Cheers, > > - dimitri. > > > > "Mannie, Eric" wrote: > > > > > > Hello Stephen > > > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > > No, please see explanations below. > > > > > > > If you use LBM and change the mappings at the two ends without some > > > coordination such as LCAS, you will have a glitch to the traffic > > > (I think this is simple enough). > > > > > > No, please see below (C2 or V5 transition). > > > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > > >because LCAS is "sacred", but because you are comparing apples to > > > >oranges. Statements in this document such as "One drawback of LCAS is > .." > > > >are unnecessary and inappropriate in this context, since LBM does > > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > > >were solving the SAME problem better, this would be OK, but this > > > >is not the case. > > > > > > No, please see below. > > > > > > Simple example: > > > > > > 1) you first signal an additional VC/SPE to the destination (via a > Path). > > > 2) the destination knows exactly which VC/SPE is added (via the label). > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > > so the VC/SPE is not yet added to concatenated signal. > > > 4) then, you wait at the source for a confirmation from the destination > > > (i.e. Resv). > > > 5) the source "equip" the VC/SPE and sends. > > > 6) the destination sees in the POH that the VC is "equipped" > (transition). > > > > > > The difference between LCAS and LBM is that LCAS uses an additional > > explicit > > > indication in the overhead to say "this is the payload" to use. LBM > > doesn't > > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > >:-) > > > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > > transitions > > > to a significant payload. LBM proposes to do the same simply by looking > at > > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > > anyway and that is used to indicate the type of payload. > > > > > > To be more precise about LCAS (I copy from the LCAS specification, > section > > > 6.3.1): "The first container frame to contain payload data for the new > > > member shall be the container frame immediately following the container > > > frame that contained the last bit(s) (i.e. the CRC) of the control > packet > > > with NORM/EOS message for that member" (the LCAS control packet). > > > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet > in > > > the POH with the appropriate transition of its CTRL field. LBM waits > > simply > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > > (don't change SDH/SONET). > > > > > > By the way, this is version 0 of the draft and it was just posted. > > > > > > Suggestions, technical comments and improvements are welcome. > > > > > > I would appreciate if people could first read and speak before shooting > > > directly :-) > > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Friday, November 16, 2001 7:49 PM > > > To: Mannie, Eric > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Eric, > > > The point of my earlier email (items again below, this time with > > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > > > The issue (and I think the reason for Maarten's strong reaction) is > this: > > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > (I hope this is not too subtle for non-native English speakers). > > > > > > LCAS is a method to hitlessly change the mappings at the two > > > ends of a virtually concatenated trail to increase or decrease the > > > bandwidth. It does not say anything about how components to be > > > added or removed from the virtually concatenated "bundle" are > > > set up or taken down. > > > > > > LBM talks about how to set up or take down those added or removed > > > components, but not about the details of changing the mapping (other > > > than that it is done after the new components are successfully > > > established. > > > > > > If you use LBM and change the mappings at the two ends without some > > > coordination such as LCAS, you will have a glitch to the traffic > > > (I think this is simple enough). > > > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > > because LCAS is "sacred", but because you are comparing apples to > > > oranges. Statements in this document such as "One drawback of LCAS is > .." > > > are unnecessary and inappropriate in this context, since LBM does > > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > > were solving the SAME problem better, this would be OK, but this > > > is not the case. > > > > > > Time to try to be constructive: > > > - I think most of the current discussion of LCAS should be removed from > > > this document. It is irrelevant since LCAS solves a different problem > than > > > LBM. To say that one is "better" than the other would only be meaningful > > > if they were solving the same problem (can you really say that LBM > solves > > > problem A better than LCAS solves problem B?). > > > - LCAS can be a good informative reference as a way to hitlessly modify > > > the size of a virtually concatenated trail. > > > - Clarify in the scope that the current draft describes the use of LBM > > > without LCAS, which results in a traffic glitch when bandwidth is > > modified. > > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > > the size of virtually concatenated pipes after LBM sets up new > > component(s) > > > or before LBM takes down old component(s) is a topic for further study > > > and perhaps to be addressed in a future version of the draft. > > > > > > Regards, > > > Steve > > > > > > Steve Trowbridge wrote: > > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > > the traffic. > > > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > > control plane knows that the different LSPs are part of the same > > > > circuit. > > > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > > be the preferred method for many applications. > > > > > > "Mannie, Eric" wrote: > > > > > > > > Hello Maarten, > > > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack > of > > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > > document > > > > and to compare GMPLS and LCAS functionalities ? > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 13:27:15 -0800 Message-Id: <4.3.2.7.2.20011210133532.01de13a8@mo-ex1> Date: Mon, 10 Dec 2001 16:05:28 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: GMPLS signaling documents updated per last calls Cc: bwijnen@lucent.com,sob@harvard.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed All, As was discussed in this morning's SUB-IP session, the GMPLS signaling documents have been updated to reflect comments received during the extended last call. If you believe an issue that you have previously raised has not been addressed in the drafts, please send a message to the list. (We'll respond with either how the issue was addressed or if it was missed.) Here's a summary of changes: draft-ietf-mpls-generalized-signaling-07.txt see http://www.labn.net/docs/diff-sig-06-07.txt for change bar version. o changes were primarily in the area of GPID values. (Juergen has a couple of additions that we'll incorporate in next rev.) draft-ietf-mpls-generalized-rsvp-te-06.txt see http://www.labn.net/docs/diff-rsvp-05-06.txt o Minor editorial changes and clarifications based on comments from list draft-ietf-mpls-generalized-cr-ldp-05.txt http://www.labn.net/docs/diff-ldp-04-05.txt o Brings cr-ldp functionally in line with rsvp-te o Revised Admin Status Usage (per comments and also removed potential race condition) o Clarified text related to interface bundling (To be consistent with updated bundling draft.) o Added IANA Considerations o Minor editorial changes and clarifications Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 12:41:32 -0800 Message-Id: <4.3.2.7.2.20011210153234.02df5e68@mo-ex1> Date: Mon, 10 Dec 2001 15:35:51 -0500 To: "Zhi-Wei Lin" From: Lou Berger Subject: Re: comments on rsvp-te-06 Cc: "Berger, Lou" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:14 PM 12/10/2001, Zhi-Wei Lin wrote: >Hi Lou, See in-line > >Lou Berger wrote: > > >> In section 7.2.1, both step 3 are the same description. > > > > > > yes, this is intentional! > > > >But then what you're saying is that for ingress-initiated teardown, the >flow is: >(1) Path >(2) Resv >(3) PathTear > >While egress initiated it is: >(1) Resv >(2) PathTear this is correct. >This means that ingress-initiated takes 3 message passes. In OIF UNI >1.0, a different message flow is defined for ingress-initiated, that of: >(1) Path >(2) PathErr (with Path_State_Removed flag set) how nice... >Is this latter message flow allowed, and if not, why not? Note that the defined procedures say "SHOULD" not "MUST". > >> Based on the > >> flow of description, I think the first step 3 should read: > >> "Upon receiving the Admin Status Object with the Delete (D) bit set in > >> the Path message, the egress node sends a PathErr message (with > >> ^^^^ ^^^^^^ ^^^^^^^ ^^^^^ > >> Path_State_Removed flag set) upstream to remove the LSP and normal RSVP > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> processing takes place." > > > > > > The egress triggers the ingress to do the delete. > > > >See above. Actually, based on the original text, the ingress triggers >the egress which then triggers the ingress to do the delete...seems like >extra level of message...I thought that's one reason for defining the >Path_State_Removed flag for PathErr... > > >> In section 9.1, a statement under "recovery time": > >> A value of 0xffffffff indicates that resynchronization may > >> occur at a rate selected by the receiver. > >> while in section 9.5.2, the following statement is made: > >> A Recovery Time value of 0xffffffff indicates that the > >> Recovery Period is effectively infinite. > >> which is correct? or am I misinterpreting this? > > > > > > These statements are mutually consistent. If you'd like, I can just > > remove the text, but I think most will find the comment useful. > > > >I see the consistency now. You should keep the text. Glad to hear we're now in sync. Lou >Thanks >Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 11:35:54 -0800 Message-ID: <3C15098A.2050302@lucent.com> Date: Mon, 10 Dec 2001 14:14:18 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org Subject: Re: comments on rsvp-te-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Lou, See in-line Lou Berger wrote: >> In section 7.2.1, both step 3 are the same description. > > > yes, this is intentional! > But then what you're saying is that for ingress-initiated teardown, the flow is: (1) Path (2) Resv (3) PathTear While egress initiated it is: (1) Resv (2) PathTear This means that ingress-initiated takes 3 message passes. In OIF UNI 1.0, a different message flow is defined for ingress-initiated, that of: (1) Path (2) PathErr (with Path_State_Removed flag set) Is this latter message flow allowed, and if not, why not? >> Based on the >> flow of description, I think the first step 3 should read: >> "Upon receiving the Admin Status Object with the Delete (D) bit set in >> the Path message, the egress node sends a PathErr message (with >> ^^^^ ^^^^^^ ^^^^^^^ ^^^^^ >> Path_State_Removed flag set) upstream to remove the LSP and normal RSVP >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> processing takes place." > > > The egress triggers the ingress to do the delete. > See above. Actually, based on the original text, the ingress triggers the egress which then triggers the ingress to do the delete...seems like extra level of message...I thought that's one reason for defining the Path_State_Removed flag for PathErr... >> In section 9.1, a statement under "recovery time": >> A value of 0xffffffff indicates that resynchronization may >> occur at a rate selected by the receiver. >> while in section 9.5.2, the following statement is made: >> A Recovery Time value of 0xffffffff indicates that the >> Recovery Period is effectively infinite. >> which is correct? or am I misinterpreting this? > > > These statements are mutually consistent. If you'd like, I can just > remove the text, but I think most will find the comment useful. > I see the consistency now. You should keep the text. Thanks Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 10:52:36 -0800 Message-Id: <4.3.2.7.2.20011210123304.02670660@mo-ex1> Date: Mon, 10 Dec 2001 13:22:00 -0500 To: Ben Mack-Crane From: Lou Berger Subject: Re: Moving right along ... generalized-rsvp-te-05 Cc: Kireeti Kompella ,ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:08 PM 10/29/2001, Ben Mack-Crane wrote: >After reviewing draft-ietf-mpls-generalized-rsvp-te-05.txt >I have the following comments and questions: > >1) In the procedures regarding the Generalized Label Request > object, the statement is made that "The node may either > directly support the LSP or it may use a tunnel (FA), > i.e., another class of switching." please see the routing drafts. >A Tunnel (FA) is a type > of link, not a class of switching. This adds to the > confusion I've noted about the need for and use of Switching > Type. >2) Bandwidth Encoding use of the Intserv Tspec object seems > quite unusual since this use is not consistent with existing > uses of this object, and new uses could easily use a new > C-Type. I think either approach work. This topic was discussed by the authors at least 12-18 months. The current approach was decided then. >3) In the procedures for Generalized Label it states "If the label is > unacceptable then the recipient MUST generate a ResvErr message with > a "Routing problem/MPLS label allocation failure" indication." > I think "Unacceptable Label Value" would be more appropriate. okay. >4) In the Waveband Switching section it says "For compatibility reasons, > a new RSVP C-Type (3) is assigned." What is the compatability > problem this is solving? simply to distinguish types. I remove the text to avoid such confusion in the future. >5) In the Label Set object, why is the Label Type field 14 bits if > only the low order 8 bits are used? for CR-LDP compatibility. >6) Some new error strings are defined, "Label Set" and "Unsupported Link > Protection," but no values or placeholders are included. Where are new > error values to be documented? As part of IANA assignment. >7) The Notify message is intended to "enable expedited notification of > failures," but it relies on the IP layer which may be affected by the > failure that the Notify is reporting. This could defeat the goal > of rapid notification. Without some means of guaranteeing the Notify > doesn't have to wait for IP routing convergence to be delivered, > it isn't a satisfactory solution. > >8) The description of the C-Type field in the Label ERO subobject suggests > that this subobject contains a Label Object. Is this the case, or does > the Label ERO subobject simple contain label values, and the C-Type > matches the C-Type that would be used if the same label values were > included in a Label object? per the draft: Label: Variable This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label, see Section 3.2.1. >9) In deleting an LSP from the egress, the R bit is set in the Admin Status > object. The ingress responds with a PathTear message. Does this PathTear > contain the Admin Status object or should the R bit be cleared? It's not in the BNF, so no it's not included. >10)The Notify message may contain a new setting of the Admin Status. > Under what conditions would an intermediate or egress node change > Admin Status? It may be used at any time that a PathErr or ResvErr is generated. > What happens if the Notify receiver is not the ingress? same action as would be taken if/when the corresponding message is received. >11)In Interface Identification it says "Data channels are specified from >the view point > of the sender of the Path message." Is this true even for Resv messages > or should it read "Data channels are specified from the viewpoint > of the sender of the message."? current text is correct. >12)In Restart_Cap it says "Refreshing of Resv and Path state SHOULD be > suppressed during this waiting period." I assume this is refreshes > toward the failed neighbor, not to all neighbors for that LSP. True? yes. thanks for the comments, lou >Regards, >Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 09:50:57 -0800 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: LMP message length too small? Date: Mon, 10 Dec 2001 12:40:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181A1.C12F39E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C181A1.C12F39E0 Content-Type: text/plain; charset="iso-8859-1" Since the LMP message length field is only two bytes, this limits the length of a message to 2^16 bytes. Consider the link summary message. The length of this message is: 8 + 8 + 16 + N*28 Header Sz Msg ID Sz TE Link Sz N * Data Link Sz At best then, there can be 2338 data links in a TE link. This is assuming 4-byte addresses. If we allow for IPv6 addresses, it becomes: 8 + 8 + 40 + N*60 Header Sz Msg ID Sz TE Link Sz N * Data Link Sz so there can be 1091data links in a TE link. I am wondering if this is too restrictive. I think it is very possible that this would force some large scale TE links to be broken down into multiple TE links to run LMP on them. What do others think? Michael Mandelberg ------_=_NextPart_001_01C181A1.C12F39E0 Content-Type: text/html; charset="iso-8859-1"

Since the LMP message length field is only two bytes, this limits the length of a message to 2^16 bytes. Consider the link summary message.
The length of this message is:
 
      8          +           8          +          16          +           N*28
Header Sz          Msg ID Sz          TE Link Sz          N * Data Link Sz
 
At best then, there can be 2338 data links in a TE link. This is assuming 4-byte addresses. If we allow for IPv6 addresses, it becomes:
 
      8          +           8          +          40          +           N*60
Header Sz          Msg ID Sz          TE Link Sz          N * Data Link Sz
 
so there can be 1091data links in a TE link.
 
I am wondering if this is too restrictive. I think it is very possible that this would force some large scale TE links to be broken down into multiple TE links to run LMP on them. What do others think?
 
Michael Mandelberg
 
------_=_NextPart_001_01C181A1.C12F39E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 09:41:11 -0800 Message-Id: <4.3.2.7.2.20011210114322.01dcbd20@mo-ex1> Date: Mon, 10 Dec 2001 12:00:38 -0500 To: Ben Mack-Crane From: Lou Berger Subject: Re: Moving right along ... generalized-signaling-06 Cc: Kireeti Kompella ,ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:09 PM 10/29/2001, Ben Mack-Crane wrote: >After reviewing draft-ietf-mpls-generalized-signaling-06.txt I have >a few comments and questions: > >1) There seems to be no difference as far as label allocation > is concerned between LSP Encoding Types Ethernet V2/DIX (2) > and Ethernet 802.3 (10). One Encoding type would seem to > be sufficient. I agree, but some feel that this is needed to properly establish LSPs in systems what would terminate each type differently. >2) G-PID types (19), (20), and (21) are repeats of (16), (17), > and (18). see latest draft... > Since the Siganl Type will indicate whether the > LSP is VC-11/VT1.5 or VC-12/VT2, this encoding is redundant. the fields serve different purposes. >3) G-PID type (37) Lambda seems insufficient (too vague) to > support interoperability. Is there any practical use for this > value? yes, it's needed when doing fiber/port switching. >4) In the "Bandwidth Encoding" section it states "For non-packet LSPs, it > is useful to define discrete values to identify the bandwidth of the > LSP." For SONET/SDH this is unnecessary given the Signal Type is > provided. For the other non-packet LSP types (Lambda and Fiber) > it is not clear that all the values cited in the example are relevant > (for example, a DS0 lambda would seem wasteful...). > This is confusing, and should be clarified. In fact, a description of > exactly why this field is required is needed. We've gone over this text multiple times. Do you have any suggested wording. >5) The Waveband ID "is selected by the sender and reused in all > subsequent related messages." This seems more the sort of thing that > should be negotiated by LMP rather than during connection setup. The ID has significance within signaling context of the sender. (like message id). I don't think using another layer of complexity for provate information makes sense. >6) The definition of Start Label and End Label in waveband switching seems > inconsistent with the behavior described in generalized-rsvp-te-05. I don't see this. Feel free to suggest wording. > >7) In Protection Information it states "The resources allocated for a > secondary LSP MAY be used by other LSPs until the primary LSP fails > over to the secondary LSP." This may not always be the case. An > explicit flag indicating whether or not extra traffic may use the > secondary path resources is needed. ??? This is the purpose of this bit. >8) The Administrative Status Information includes a bit indicating > "Administratively down," but there is no reference to a definition > of this state. Is this intended to mirror the MIB variable? If so, > a reference is needed. If not, more definition is needed to ensure > the local behaviors driven by this bit are in some way consistent. > Whether this state defintion is consistent with current transport > network operations should also be considered. Per the document: The actions taken by a node based on a state local decision. >9) In Interface Identification, the IP Address for types 3,4, and 5 is > described as possibly "an IP address associated with the router ID." > Is this intended to mean the Router ID or any IP address owned by > the node? It seems the Router ID is the simplest solution, but the > wording is not clear. Text has been reworded in 07. It's any IP address configured on a node. >10)In describing the Interface ID the statement "The special value > 0xFFFFFFFF can be used to indicate the same label is to be valid > across all component links." What is the "label" referred to in > this case? I'll reword in the post IETF last call rev of the document. Lou >Regards, >Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 09:41:01 -0800 Message-Id: <4.3.2.7.2.20011210114155.027d3948@mo-ex1> Date: Mon, 10 Dec 2001 12:23:39 -0500 To: "Zhi-Wei Lin" From: Lou Berger Subject: Re: comments on rsvp-te-06 Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed per today's discussion: At 10:14 AM 11/30/2001, Zhi-Wei Lin wrote: >Hi folks, > >In rsvp-te-06, IANA consideration section, the Notify message message >type also needs to be assigned by IANA. agreed. there is no change to the document here. >Also, several error codes/values >were introduced in the document. I believe these also need to be >identified and assigned (e.g., routing problem/switching type, routing >problem/unsupported link protection) agreed. This will be part of the IANA assignment request. (Which will be forthcoming soon.) >In section 9.3, two error messages were defined: > "Control Channel Degraded State" > "Control Channel Active State" >Are these both new error codes, or a single error code with two error >values, or part of an existing error code? yes. will be part of the IANA assignment. >Also, the text says "inform other nodes of the restoration via a >PathErr...". What are the other nodes? Is it all RSVP-aware nodes, all >nodes where a LSP passes through the failed node, etc. ? > sorry, it should say "upstream" rather than "other". (It'll be this way in the post IETF last call rev.) >In section 4.3.1, reference to RFC2205 for error codes and values is >insufficient. Many of the relevant error codes are also in the RSVP-TE I-D. The reference is to the error_spec definition, which is rfc2205. >In section 7.2.1, both step 3 are the same description. yes, this is intentional! >Based on the >flow of description, I think the first step 3 should read: >"Upon receiving the Admin Status Object with the Delete (D) bit set in >the Path message, the egress node sends a PathErr message (with > ^^^^ ^^^^^^ ^^^^^^^ ^^^^^ >Path_State_Removed flag set) upstream to remove the LSP and normal RSVP >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >processing takes place." The egress triggers the ingress to do the delete. >In section 9.1, a statement under "recovery time": > A value of 0xffffffff indicates that resynchronization may > occur at a rate selected by the receiver. >while in section 9.5.2, the following statement is made: > A Recovery Time value of 0xffffffff indicates that the > Recovery Period is effectively infinite. >which is correct? or am I misinterpreting this? These statements are mutually consistent. If you'd like, I can just remove the text, but I think most will find the comment useful. Lou >Looking forward to comments... > >Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2001 09:10:50 -0800 Message-ID: <3C14EA2B.D0D05769@tellabs.com> Date: Mon, 10 Dec 2001 11:00:27 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: "Pagan, Joe" CC: "'ccamp@ops.ietf.org'" , "'ipo@ops.ietf.org'" , "'iporpr@ops.ietf.org'" , ip-optical@lists.bell-labs.com, stds-802-17@ieee.org Subject: Re: IP over DCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe - Standardization of IP over the DCC has just been completed within the ITU. You can find the spec a part of G.7712. I have attached the message originally sent by Kiretti on this subject. Jonathan Sadler ----- Original Email ----- Hi All, IETF'ers now have access to the ITU-T Study Group 15's communication statements to the IETF; the following email has the details. Please note that these documents are copyrighted by the ITU; please respect their copyrights, and use appropriate care in duplicating and distributing these materials. ITU Copyright Information: "Access to databases of the International Telecommunication Union (ITU) for consultation of documents and/or information retrieval is permitted by the ITU subject to the user's acceptance of ITU's provisions and conditions of copyright contained within each document which obliges the user not to duplicate the document or parts thereof for distribution or sale external to the user's organization. Such information may be utilised in the receiving organization, as required, to further the work of the ITU or any standards body developing related standards, to provide guidance for product or service development and implementation and to serve as support documentation associated with a product or service." Many thanks to Steven Trowbridge and others who made access possible. Also please note http://www.ietf.org/IESG/liaison.html which has the IETF liaison statements with other standards bodies, among them the ITU-T. Kireeti. -------------- Forwarded Mail ---------------- Scott, Kireeti, and Lyndon, I am pleased to inform you that we finally have some concensus within ITU-T that gives us a way to share the files related to the Study Group 15 communications statements with IETF participants. This mechanism will likely evolve in the future (more about this below), but at least for now we have a way to share these files with IETF participants. The relevant communications include two to ccamp: - SDH Signal and Group Structures - New Recommendations for Automatically Switched Optical Netorks and one to sigtran: - Draft Recommendation G.799.1 on interconnecting GSTN and IP Networks The information may be accessed via a web browser using the following URL (from an ITU-T ftp server): ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html In the future, the Telecommunications Standardization Bureau will likely provide a way for IETF participants who wish to collaborate with ITU-T to request their own logins and passwords to access this site, but for now, all can access the information using the common ID and password that you see embedded in the URL. The structure of the information is as follows: Main Page | |-->ccamp-->copyright---->Communication on SDH Signal Structures | | | -->Communication on ASON Recs | | | |-->G.8080_Y.1304.pdf | |-->G.7713_Y.1704.pdf | |-->G.7714_Y.1705.pdf | --->G.7712_Y.1703.pdf | --->sigtran-->copyright-->Communication on G.799.1 (GSTN and IP) | --->G.799-1-DRAFT-V6.pdf Please request that your members enter at the main page - this will help insure that those who access the documents will be aware of the ITU-T copyright restrictions. (rest clipped) "Pagan, Joe" wrote: > > Hi all, > > Before submitting a draft, I'd like to see if there's been any work on the standardization of transporting IP over SONET DCCs. > > I know that there was some kind of draft submitted to the Network and Services Integration Forum(?). Don't know its status but it doesn't address multiple DCC usage. Can someone please let me know if there's been any standards work in this area? > > Thanks, > Joe Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Dec 2001 12:25:51 -0800 Message-ID: <3C13C84B.C80B4858@lucent.com> Date: Sun, 09 Dec 2001 13:23:39 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Pagan, Joe" CC: "'ccamp@ops.ietf.org'" , "'ipo@ops.ietf.org'" , "'iporpr@ops.ietf.org'" , ip-optical@lists.bell-labs.com, stds-802-17@ieee.org Subject: Re: [IP-Optical] IP over DCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joe, Please see ITU-T Recommendation G.7712/Y.1703, "Architecture and Specification of Data Communication Network", just approved from the October 2001 meeting of ITU-T Study Group 15. If you are not an ITU-T member, this Recommendation was the subject of a communication from ITU-T to IETF ccamp, and can be obtained through the "ccamp" links from: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html This new Recommendation deals with use of IP only, OSI only, and mixed IP/OSI data communications networks. This should be relevant to SONET, as SONET is one of the regional flavors of SDH. Regards, Steve Trowbridge Vice-Chair, ITU-T Study Group 15 > "Pagan, Joe" wrote: > > Hi all, > > Before submitting a draft, I'd like to see if there's been any work on the standardization of transporting IP over SONET DCCs. > > I know that there was some kind of draft submitted to the Network and Services Integration Forum(?). Don't know its status but it doesn't address multiple DCC usage. Can someone please let me know > if there's been any standards work in this area? > > Thanks, > Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The information contained in this e-mail including any attachments may constitute Corvis Corporation Proprietary Information that is subject to Non-Disclosure Agreement and cannot be disclosed to > any other party without the express consent of Corvis Corporation. > > If you are neither the intended recipient of this e-mail nor responsible for delivering this e-mail to the intended recipient, note that any dissemination, distribution, copying, or retention of > this e-mail is prohibited. > > If you believe you have received this e-mail in error, we request that you notify the sender by return e-mail and then delete this e-mail and any return e-mail immediately. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Dec 2001 12:04:19 -0800 From: "Vipul Sharma" To: Subject: RE: agenda Date: Sun, 9 Dec 2001 14:55:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is there an agenda for SLC yet?? Vip -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of wesam.alanqar@mail.sprint.com Sent: Friday, December 07, 2001 3:38 PM To: ccamp@ops.ietf.org; vsharma@zagrosnetworks.com Subject: agenda Any idea when the agenda will come for SLC meeting? Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Dec 2001 04:58:15 -0800 Message-ID: <9F9151E5C822D4118C8F00508BCFE96F0142BA8A@EXCHGATEWAY1> From: "Pagan, Joe" To: "'ccamp@ops.ietf.org'" , "'ipo@ops.ietf.org'" , "'iporpr@ops.ietf.org'" , ip-optical@lists.bell-labs.com, stds-802-17@ieee.org Subject: IP over DCC Date: Sat, 8 Dec 2001 08:12:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17FEA.07D551E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17FEA.07D551E0 Content-Type: text/plain; charset="iso-8859-1" Hi all, Before submitting a draft, I'd like to see if there's been any work on the standardization of transporting IP over SONET DCCs. I know that there was some kind of draft submitted to the Network and Services Integration Forum(?). Don't know its status but it doesn't address multiple DCC usage. Can someone please let me know if there's been any standards work in this area? Thanks, Joe end The information contained in this e-mail including any attachments may constitute Corvis Corporation Proprietary Information that is subject to Non-Disclosure Agreement and cannot be disclosed to any other party without the express consent of Corvis Corporation. If you are neither the intended recipient of this e-mail nor responsible for delivering this e-mail to the intended recipient, note that any dissemination, distribution, copying, or retention of this e-mail is prohibited. If you believe you have received this e-mail in error, we request that you notify the sender by return e-mail and then delete this e-mail and any return e-mail immediately. ------_=_NextPart_001_01C17FEA.07D551E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

Before submitting a draft, I'd like to see if there's = been any=20 work on the standardization of=20 transporting IP over SONET DCCs.

I know that there was some=20 kind of draft submitted to the Network and Services Integration = Forum(?). Don't=20 know its status but it doesn't address multiple=20 DCC usage. Can someone please let me know if there's been = any standards work in this=20 area?

Thanks,
Joe=20

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

end

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The information contained in this = e-mail including any attachments may constitute Corvis Corporation = Proprietary Information that is subject to Non-Disclosure Agreement and = cannot be disclosed to any other party without the express consent of = Corvis Corporation.

If you are neither the intended = recipient of this e-mail nor responsible for delivering this e-mail to = the intended recipient, note that any dissemination, distribution, = copying, or retention of this e-mail is prohibited.

If you believe you have received this = e-mail in error, we request that you notify the sender by return e-mail = and then delete this e-mail and any return e-mail immediately. =

------_=_NextPart_001_01C17FEA.07D551E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 17:10:35 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Lambda LSP establishment Date: Fri, 07 Dec 2001 18:08:59 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If I have 5 nodes A, B, C, D and E connected as shown. Assume that only one wavelength is available on the path A to E (no wavelength conversion capability is there on the complete path). Let the capacity of the wavelength be C. Further assume a request arrives for connection from node C to E for a line capacity of C/4. This request will be successful as we have available wavelength. Now If another request comes at node A to establish another connection from node A to node E via nodes {A,B,C,D,E} for a line capacity of C/4. Should this request be successful as we have already allocated the wavelength ? If the previous connection from C to E of capacity C/4 had been advertised as a FA, in that case will the IInd request succeed ? If the previous connection from C to E of capacity C/4 had not been advertised as FA then what will be the fate of IInd connection ? A <--> B <---> C <----> D <---> <----> E Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 15:54:42 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "manoj juneja" To: ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be, kireeti@juniper.net, jplang@calient.net, dbasak@accelight.com, braja@tellium.com, jdrake@calient.net Bcc: Subject: Fwd: Re: AW: AW: VC-4-64c as forwarding adjacency Date: Fri, 07 Dec 2001 15:38:41 -0700 Hi All, I think the authors of GMPLS drafts should clarify the label allocation for the following scenario. If this scenario is not possible to establish through GMPLS then please point that too. Regards, manoj. Hi Marteen, I fully agree with the diagram below. There will be a ATM VP link (VC-4-64c) between nodes A and D. Can u please elaborate more on this one : "ATM VP connection controllers in A and D exchange ATM VP labels to setup ATM VP connections" How will the ATM VP labels be distributed between nodes A and D ? Is it not with in the scope of GMPLS signalling ? If I am misinterpreting the concept of LSP hierarchies, please let me know that too. Regards, manoj. >>From: Maarten Vissers >>To: manoj juneja >>CC: ccamp@ops.ietf.org >>Subject: Re: AW: AW: VC-4-64c as forwarding adjacency >>Date: Fri, 07 Dec 2001 11:00:54 +0100 >> >>Manoj, >> >>When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the >>ATM VP >>layer network. As such, ATM VP signals are being routed via this ATM VP >>link >>supported by the VC-4-64c trail. So ATM VP labels will be used between >>nodes A >>and D. >> >> NE A NE B NE C NE D >>|<---------->|<---------------->|<------------------->|<--------------->| >> >> |||| |||| >>ATM VP Fabric ATM VP Fabric >> |||||| |||||| >> VC-4-64c VC-4-64c >> port port >> | | >> | | >> | VC-4-64c Fabric VC-4-64c Fabric | >> | | |||| |||| | | >> STM-64 STM-64 STM-256 STM-256 STM-64 STM-64 >> port port port port port port >> | | | | | | >> ------------- ------------- ------------- >> >>When the ATM equipment at A needs a 10G link with the aTM equipment at D, >>it >>requests a regular VC-4-64c connection between A and D. As the connection >>terminates at VC-4-64c ports automatically there is an ATM VP link >>created. >>The >>ATM VP connection controllers in A and D exchange ATM VP labels to setup >>ATM VP >>connections. >> >>When the Vc-4-64c connection had to be setup, the VC-4-64c connection >>controllers in A, B, C and D will exchange VC-4-64c labels. >> >>When the ATM equipment is in a user domain, the interface between nodes A >>and B >>and nodes C and D are UNIs. In that case the VC-4-64c connection >>controllers in >>nodes A and D are replaced by VC-4-64c call controllers. Then the >>interactions >>are between calling/called party call controllers (in nodes A and D) and >>network >>call controllers, and network call controller and connection controllers >>in >>nodes B and C. >> >>As you see there is no notion of FA needed. >> >>Regards, >> >>Maarten >> >> >>manoj juneja wrote: >> > >> > Hi Marteen, >> > Agreed. VC-4-64c connection can be advertised as a FA and >> > can carry IP/ATM or ethernet traffic. >> > >> > Now take the case where multiple LSPs are to be tunneled through the >> > VC-4-64c connection (FA-LSP). >> > What about the label ? What type of label the tail end of VC-4-64c FA >> > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA >> > -LSP) ? >> > The LSP encoding and switching types are different for FA-LSP and the >> > LSP which is to be tunneled through the FA-LSP. >> > >> > Regards, >> > manoj. >> > >> > >From: Maarten Vissers >> > >To: "'manoj juneja'" >> > >CC: ccamp@ops.ietf.org >> > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency >> > >Date: Thu, 06 Dec 2001 12:24:32 +0100 >> > > >> > >Manoj, >> > > >> > >In transport terminology I would refer to this as a VC-4-64c trail >> > >supporting an >> > >IP, ATM or Ethernet link. >> > > >> > >Regards, >> > > >> > >Maarten >> > > >> > >Heiles Juergen wrote: >> > > > >> > > > Manoj, >> > > > >> > > > this has nothing to do with forwarding adjacency. It is a >>restriction of >> > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A >>VC-4-64c >> > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or >> > >VC-3/2/12/11. >> > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or >>Ethernet >> > >clients. >> > > > >> > > > Juergen >> > > > >> > > > > -----Ursprüngliche Nachricht----- >> > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >> > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 >> > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org >> > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency >> > > > > >> > > > > >> > > > > Hi Juergen, >> > > > > Does this mean the forwarding adjacency concept is >>not >> > > > > applicable to concatenated signals/LSPs ? I hope forwarding >> > > > > adjacecny of >> > > > > virtual concatenated LSP should be allowed. >> > > > > >> > > > > Regards, >> > > > > manoj. >> > > > > >> > > > > >> > > > > >From: "Juergen Heiles" >> > > > > >To: "'manoj juneja'" , >> > > > > >> > > > > >Subject: AW: VC-4-64c as forwarding adjacency >> > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 >> > > > > > >> > > > > >No, that is not possible as you cannot transport a VC-4 in a >> > > > > VC-4-64c. A >> > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. >> > > > > > >> > > > > >Juergen >> > > > > > >> > > > > > > -----Ursprüngliche Nachricht----- >> > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >> > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 >> > > > > > > An: ccamp@ops.ietf.org >> > > > > > > Betreff: VC-4-64c as forwarding adjacency >> > > > > > > >> > > > > > > >> > > > > > > Hi All, >> > > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c >> > > > > forwarding >> > > > > > > adjacency ? If yes, then what would be the {suklm} ? >> > > > > > > >> > > > > > > Regards, >> > > > > > > manoj >> > > > > > > >> > > > > > > >>_________________________________________________________________ >> > > > > > > Get your FREE download of MSN Explorer at >> > > > > > > http://explorer.msn.com/intl.asp >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > _________________________________________________________________ >> > > > > Get your FREE download of MSN Explorer at >> > > > http://explorer.msn.com/intl.asp >> > ><< mvissers.vcf >> >> > >> > _________________________________________________________________ >> > Get your FREE download of MSN Explorer at >>http://explorer.msn.com/intl.asp >><< mvissers.vcf >> > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 15:36:42 -0800 To: ccamp@ops.ietf.org Date: Fri, 07 Dec 2001 15:35:20 -0800 From: "mitali J" Message-ID: Mime-Version: 1.0 Reply-To: mitali5@lycos.com Subject: Optical Equipment Vendors Input Required Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Length: 455 Content-Transfer-Encoding: 7bit Hi All, My question is directed towards optical vendors. If a optical vendor gets GMPLS software stack from some portable software company where would u like to keep the GMPLS label allocation (resource allocation) module ? Whether the optical vendor would like the signalling module doing the label allocation or would like to keep the control of label allocation with itself ? Your Input will be appreciated. Thanks, mitali. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 12:41:53 -0800 From: wesam.alanqar@mail.sprint.com Date: Fri, 7 Dec 2001 14:38:08 -0600 Message-Id: Subject: agenda MIME-Version: 1.0 TO: ccamp@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" ;Creation-Date="Fri, 7 Dec 2001 14:38:08 -0600" Content-Transfer-Encoding: 8bit Any idea when the agenda will come for SLC meeting? Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 12:11:47 -0800 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org, jplang@calient.net Bcc: Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Date: Fri, 07 Dec 2001 13:10:15 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, I fully agree with the diagram below. There will be a ATM VP link (VC-4-64c) between nodes A and D. Can u please elaborate more on this one : "ATM VP connection controllers in A and D exchange ATM VP labels to setup ATM VP connections" How will the ATM VP labels be distributed between nodes A and D ? Is it not with in the scope of GMPLS signalling ? If I am misinterpreting the concept of LSP hierarchies, please let me know that too. Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency >Date: Fri, 07 Dec 2001 11:00:54 +0100 > >Manoj, > >When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the >ATM VP >layer network. As such, ATM VP signals are being routed via this ATM VP >link >supported by the VC-4-64c trail. So ATM VP labels will be used between >nodes A >and D. > > NE A NE B NE C NE D >|<---------->|<---------------->|<------------------->|<--------------->| > > |||| |||| >ATM VP Fabric ATM VP Fabric > |||||| |||||| > VC-4-64c VC-4-64c > port port > | | > | | > | VC-4-64c Fabric VC-4-64c Fabric | > | | |||| |||| | | > STM-64 STM-64 STM-256 STM-256 STM-64 STM-64 > port port port port port port > | | | | | | > ------------- ------------- ------------- > >When the ATM equipment at A needs a 10G link with the aTM equipment at D, >it >requests a regular VC-4-64c connection between A and D. As the connection >terminates at VC-4-64c ports automatically there is an ATM VP link created. >The >ATM VP connection controllers in A and D exchange ATM VP labels to setup >ATM VP >connections. > >When the Vc-4-64c connection had to be setup, the VC-4-64c connection >controllers in A, B, C and D will exchange VC-4-64c labels. > >When the ATM equipment is in a user domain, the interface between nodes A >and B >and nodes C and D are UNIs. In that case the VC-4-64c connection >controllers in >nodes A and D are replaced by VC-4-64c call controllers. Then the >interactions >are between calling/called party call controllers (in nodes A and D) and >network >call controllers, and network call controller and connection controllers in >nodes B and C. > >As you see there is no notion of FA needed. > >Regards, > >Maarten > > >manoj juneja wrote: > > > > Hi Marteen, > > Agreed. VC-4-64c connection can be advertised as a FA and > > can carry IP/ATM or ethernet traffic. > > > > Now take the case where multiple LSPs are to be tunneled through the > > VC-4-64c connection (FA-LSP). > > What about the label ? What type of label the tail end of VC-4-64c FA > > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA > > -LSP) ? > > The LSP encoding and switching types are different for FA-LSP and the > > LSP which is to be tunneled through the FA-LSP. > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: "'manoj juneja'" > > >CC: ccamp@ops.ietf.org > > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency > > >Date: Thu, 06 Dec 2001 12:24:32 +0100 > > > > > >Manoj, > > > > > >In transport terminology I would refer to this as a VC-4-64c trail > > >supporting an > > >IP, ATM or Ethernet link. > > > > > >Regards, > > > > > >Maarten > > > > > >Heiles Juergen wrote: > > > > > > > > Manoj, > > > > > > > > this has nothing to do with forwarding adjacency. It is a >restriction of > > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A >VC-4-64c > > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or > > >VC-3/2/12/11. > > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or >Ethernet > > >clients. > > > > > > > > Juergen > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > Hi Juergen, > > > > > Does this mean the forwarding adjacency concept is not > > > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > > > adjacecny of > > > > > virtual concatenated LSP should be allowed. > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > > > > > > >From: "Juergen Heiles" > > > > > >To: "'manoj juneja'" , > > > > > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > > > > VC-4-64c. A > > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > > > > > >Juergen > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > > > An: ccamp@ops.ietf.org > > > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > > > forwarding > > > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > > > > > Regards, > > > > > > > manoj > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > Get your FREE download of MSN Explorer at > > > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > > http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 09:55:33 -0800 Message-ID: From: Jonathan Lang To: 'Maarten Vissers' , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Fwd: LSC Interface Doubt ... Date: Fri, 7 Dec 2001 09:46:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Maarten, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, December 07, 2001 1:30 AM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Fwd: LSC Interface Doubt ... > > > Manoj, > > Are you aware that a PXC can be operated as an ODUk switch or > a STM/OC-N switch in addition to an OCh switch? > > The PXC is a name for an optical fabric equipment. As fabrics are typical more > transparent than the connected line/trib ports, those latter determine the > switching type. E.g. a PXC connected to optical line systems including > transponders will not operate at wavelenght level. A clarification here is needed. I agree that a PXC with integrated transponders can be TDM capable. However, if the OLS is a separate piece of equipment (most likely not speaking GMPLS), then from a GMPLS perspective, the PXC is doing wavelength switching. Granted the wavelengths actually being switched may all be the same wavelength (e.g., 1310), but they are still wavelength switched. > The transponders have > terminated the wavelengths. Such combination will switch ODUk and/or STM/OC-N > signals. For the case the line systems do not have transponders, the PXC > operates as true OCh (i.e. wavelength) switch. agreed, this is an example of 15xx wavelength switching. > > Most line systems in the core network today deploy 10G wavelengths, whereas many > service signals are at 2G5 level. Therefore, the transponders in the line system > may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there will > be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits (case > of 10G services). Here it is more obvious that the PXC doesn't switch "wavelengths". I don't see the difference here (except higher rates) from the first example. Again, if the PXC is speaking GMPLS, the PXC can be considered to be doing wavelength switching since it is switching (e.g., 1310) wavelengths transparently. > > Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no > transponders are present around the fabric. This is not the definition in GMPLS. > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > I refer to LSC interface as defined in GMPLS architecture > > document (i.e. interface which switch data based on the wavelength on > > which the data is received e.g. PXC or OXC which operate at the level > > of individual wavelength). I don't think it has any thing to do with > > Och (G.709). > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Fwd: LSC Interface Doubt ... > > >Date: Thu, 06 Dec 2001 11:42:02 +0100 > > > > > >Manoj, > > > > > >I assume you refer to G.709 OCh connections when you use the term "LSC > > >LSP". If > > >so, then a bi-directional OCh link connection will use the same OCh > > >tributary > > >slot in both directions; i.e. the same wavelenght is used for go and return > > >direction. > > > > > >Regards, > > > > > >Maarten > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I need to establish a bi-directional LSC LSP then do I > > > > need to configure the remote end wavelengths on an LSC interface ? > > > > Is there any case where both the upstream and downstream labels of an > > > > bi-directional LSC LSP be same ? > > > > > > > > Regards, > > > > manoj. > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 03:49:58 -0800 Message-ID: <3C10ACD2.3FB72830@npd.hcltech.com> Date: Fri, 07 Dec 2001 17:19:38 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: Jonathan Lang CC: "'Murugan .A'" , ccamp@ops.ietf.org Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Thanks for your kind explanation on this procedure. Finally we have got the procedure. Also my kind request is can you please add this explanation in the draft which will be helpful to the reader. Thanks, Ramesh Murugan ------ > This is where you are misunderstanding the process. If you can only receive > over one interface at a time, then you need to cycle through your interfaces > before declaring the test failed. Hence, the VerifyDeadInterval must be > long enough for you to check all potential data links. This is why the > receiver determines the VerifyDeadInterval. --------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 02:15:56 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C1096B6.685A2ABD@lucent.com> Date: Fri, 07 Dec 2001 11:15:18 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sergio Belotti Original-CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP Forwarding Adjacency Doubt Content-Type: multipart/mixed; boundary="------------3E1F2A8285EEDEDD9ECD7EEE" This is a multi-part message in MIME format. --------------3E1F2A8285EEDEDD9ECD7EEE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sergio, You are correct that the Link Resource Manager (LRM) or Managers get involved. When the Routing Controller (RC) has determined the link, the Connection Controller (CC) will query the associated LRM for a specific link connection within the link. Depending on the "SNPP link case" (refer to 7.3.3/G.8080) the local LRM (LRMA) can select the link connection independent of far end LRM (LRMZ) (case 1), or there is negotiation necessary between LRMA and LRMZ to select the link connection (case 2). Regards, Maarten Sergio Belotti wrote: > > Hello Marteen, > I read your examples just now and I have only one question regarding the sentence > referred to the fact that "The ODUk link is created as part of network planning > and/or (distributed) network engineering" . I agreebut, Shouldn't be a negotiation > phase between the Link Manager at both side before the CC could be able to perform > the connection ? > Thank you > > Sergio > > mvissers@lucent.com wrote: > > > Manoj, > > > > The transport plane is a multi layer network as described in G.805 and its > > technology specific recommendations G.803, G.872 and I.326. Each layer network > > operates independent from each other layer network. Each layer network uses the > > transport service provided by its server layer networks, and represents this > > transport service as (G.805) links within its own layer network. > > > > In your example with nodes A, B, C and D, nodes A and D could operate on the > > ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate > > on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have > > also OCh fabrics, but this is not necessary; OCh termination points would > > already be sufficient. > > > > Let me give a 3 node example (4 nodes don't fit the page width in this email) in > > which a STM-N signal is to be transported through A, B and C. At C the STM-N > > signal leaves the network within an OTM-0.m signal. > > > > node A node B node C > > |<----------->|<------------------------------>|<------------------------->| > > > > STM-N ---- > > | > > ------ > > |ODUk| > > |port| > > ------ > > | > > -------------- -------------------- > > | ODUk | | ODUk | > > | Fabric | | Fabric | > > -------------- -------------------- > > ||...|....||| |||...|....||...|... > > ------ ------ ------ > > |OTUk| |OTUk| |OTUk| > > |OCh | |OCh | |Och | > > |port| |port| |port| > > ------ ------ ------ > > | ||....|...| | > > | ---------------------------- ------------- | > > | | OCh | | OCh | | > > | | Fabric | | Fabric | | > > | ---------------------------- ------------- | > > ||||||||||| ||||||||||| ||||||||| ||||||||| | > > ----------- ----------- --------- --------- ------- > > | OTM-n | | OTM-n | | OTM-n | | OTM-n | |OTM-0| > > | port | | port | | port | | port | |port | > > ----------- ----------- --------- --------- ------- > > | | | | | > > | | | | | > > ------------------- ---------------------- ------ > > > > The above network can be represented by means of its ODUk and OCh layer networks > > as follows: > > > > node A node B node C > > |<----------->|<------------------------------>|<------------------------->| > > > > STM-N ---- > > | > > ------ > > |ODUk| > > |port| > > ------ > > | > > -------------- -------------------- > > | ODUk | | ODUk | > > | Fabric | | Fabric | > > -------------- -------------------- > > |||| ||||||||| |||||||||| |||||| > > | | | | | | | | > > -- | | ---------------------------------------- | | ------ > > | | ODUk Link | | ODUk Link > > ----- --------------------------------------------------------- ----------- > > > > As you can see at the ODUk layer network, nodes A and C are neighbors. The > > intermediate node B is totally invisible. ODUk signalling takes place therefore > > between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in > > nodes A and C are connected with each other via the signalling communication > > network. > > > > | | | > > ------ ------ ------ > > |OTUk| |OTUk| |OTUk| > > |OCh | |OCh | |Och | > > |port| |port| |port| > > ------ ------ ------ > > | ||....|...| | > > | ---------------------------- ------------- | > > | | OCh | | OCh | | > > | | Fabric | | Fabric | | > > | ---------------------------- ------------- | > > ||| ||||||| ||||||||| ||||||||| ||||||||| |||||| > > | | | | | | | | | | | | > > -- | | --------- | | -------------- | | --- > > | | OCh Link | | OCh Link | | > > ----- ----------------------- ------------------------------ -------- > > > > As you can see at the OCh layer network, nodes A and B and nodes B and C are > > neighbors. OCh signalling takes place therefore between nodes A, B and C. The > > OCh CCs in nodes A, B and C are connected with each other for this purpose via > > the signalling communication network. > > > > In the above 3-node example network, you will be able to setup ODUk connections > > when the ODUk link is setup first. The ODUk link is created as part of network > > planning and/or (distributed) network engineering. The ODUk link will exist when > > one or more OCh trails are setup in the OCh layer network. > > > > So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the > > Lambda level. > > > > Same principles apply of course to the SDH/SONET layer networks... i.e. you will > > have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS > > links. > > > > This multi-layer principle doesn't require to stack labels. > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi All, > > > If there are 4 nodes say A, B, C and D. There is a Lambda FA > > > established from A to D and if a new TDM LSP request comes to node A > > > which is to be tunneled through the already established lambda FA-LSP > > > then the node A sends the Path/label request message directly to node > > > D. What label the node D will send back to node A in the RESV/label > > > mapping message since the FA-LSP is just one label (lambda) ? Does it > > > mean that all the LSPs which are tunneled through the lambda FA-LSP > > > will be allocated the same label by node D to node A ? > > > > > > Please help. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------3E1F2A8285EEDEDD9ECD7EEE Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------3E1F2A8285EEDEDD9ECD7EEE-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 02:01:29 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C109356.A5F73A74@lucent.com> Date: Fri, 07 Dec 2001 11:00:54 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Content-Type: multipart/mixed; boundary="------------7793EECE02FF90D79ABCD0CE" This is a multi-part message in MIME format. --------------7793EECE02FF90D79ABCD0CE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Manoj, When the VC-4-64c is used as "FA" it provides e.g. an ATM VP link to the = ATM VP layer network. As such, ATM VP signals are being routed via this ATM VP l= ink supported by the VC-4-64c trail. So ATM VP labels will be used between no= des A and D. NE A NE B NE C NE D |<---------->|<---------------->|<------------------->|<--------------->|= |||| |||| ATM VP Fabric ATM VP Fabric |||||| |||||| VC-4-64c VC-4-64c port port | | | | | VC-4-64c Fabric VC-4-64c Fabric | | | |||| |||| | | STM-64 STM-64 STM-256 STM-256 STM-64 STM-64 port port port port port port | | | | | | ------------- ------------- ------------- When the ATM equipment at A needs a 10G link with the aTM equipment at D,= it requests a regular VC-4-64c connection between A and D. As the connection= terminates at VC-4-64c ports automatically there is an ATM VP link create= d. The ATM VP connection controllers in A and D exchange ATM VP labels to setup = ATM VP connections. When the Vc-4-64c connection had to be setup, the VC-4-64c connection controllers in A, B, C and D will exchange VC-4-64c labels. = When the ATM equipment is in a user domain, the interface between nodes A= and B and nodes C and D are UNIs. In that case the VC-4-64c connection controll= ers in nodes A and D are replaced by VC-4-64c call controllers. Then the interac= tions are between calling/called party call controllers (in nodes A and D) and = network call controllers, and network call controller and connection controllers = in nodes B and C. As you see there is no notion of FA needed. Regards, Maarten manoj juneja wrote: > = > Hi Marteen, > Agreed. VC-4-64c connection can be advertised as a FA and > can carry IP/ATM or ethernet traffic. > = > Now take the case where multiple LSPs are to be tunneled through the > VC-4-64c connection (FA-LSP). > What about the label ? What type of label the tail end of VC-4-64c FA > -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA > -LSP) ? > The LSP encoding and switching types are different for FA-LSP and the > LSP which is to be tunneled through the FA-LSP. > = > Regards, > manoj. > = > >From: Maarten Vissers > >To: "'manoj juneja'" > >CC: ccamp@ops.ietf.org > >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency > >Date: Thu, 06 Dec 2001 12:24:32 +0100 > > > >Manoj, > > > >In transport terminology I would refer to this as a VC-4-64c trail > >supporting an > >IP, ATM or Ethernet link. > > > >Regards, > > > >Maarten > > > >Heiles Juergen wrote: > > > > > > Manoj, > > > > > > this has nothing to do with forwarding adjacency. It is a restricti= on of > >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-= 4-64c > >supports IP, ATM, Ethernet as client signal, but not a VC-4 or > >VC-3/2/12/11. > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethe= rnet > >clients. > > > > > > Juergen > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > > > > Hi Juergen, > > > > Does this mean the forwarding adjacency concept is no= t > > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > > adjacecny of > > > > virtual concatenated LSP should be allowed. > > > > > > > > Regards, > > > > manoj. > > > > > > > > > > > > >From: "Juergen Heiles" > > > > >To: "'manoj juneja'" , > > > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > > > VC-4-64c. A > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > > > >Juergen > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > > An: ccamp@ops.ietf.org > > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > > > > Hi All, > > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > > forwarding > > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > > > Regards, > > > > > > manoj > > > > > > > > > > > > _____________________________________________________________= ____ > > > > > > Get your FREE download of MSN Explorer at > > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________= > > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > = > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.= asp --------------7793EECE02FF90D79ABCD0CE Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------7793EECE02FF90D79ABCD0CE-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 01:59:01 -0800 Message-ID: From: Heiles Juergen To: "'Maarten Vissers'" , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: Fwd: LSC Interface Doubt ... Date: Fri, 7 Dec 2001 10:57:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Maarten, when using the name transponder we should be more specific. In your answer you talk about 3-R transponders which terminate the OCh. For pure wavelength conversion one could use an analog o-e-o transponder. In this case the OCh (as it is the baseband signal without a wavelength assigned) is not terminated. Normally when speaking about transponders people mean 3-R transponders as they are most common today. Juergen > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, December 07, 2001 10:30 AM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: Fwd: LSC Interface Doubt ... > > > Manoj, > > Are you aware that a PXC can be operated as an ODUk switch or > a STM/OC-N switch > in addition to an OCh switch? > > The PXC is a name for an optical fabric equipment. As fabrics > are typical more > transparent than the connected line/trib ports, those latter > determine the > switching type. E.g. a PXC connected to optical line systems including > transponders will not operate at wavelenght level. The > transponders have > terminated the wavelenghts. Such combination will switch ODUk > and/or STM/OC-N > signals. For the case the line systems do not have > transponders, the PXC > operates as true OCh (i.e. wavelength) switch. > > Most line systems in the core network today deploy 10G > wavelengths, whereas many > service signals are at 2G5 level. Therefore, the transponders > in the line system > may include 4:1 TDM multiplex circuits. With future 40G > wavelengths, there will > be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM > mux circuits (case > of 10G services). Here it is more obvious that the PXC doesn't switch > "wavelenghts". > > Therefore LSC for me is limited to true G.709 OCh switching; > i.e. when no > transponders are present around the fabric. > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi Marteen, > > I refer to LSC interface as defined in GMPLS > architecture > > document (i.e. interface which switch data based on the > wavelength on > > which the data is received e.g. PXC or OXC which operate at > the level > > of individual wavelength). I don't think it has any thing to do with > > Och (G.709). > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Fwd: LSC Interface Doubt ... > > >Date: Thu, 06 Dec 2001 11:42:02 +0100 > > > > > >Manoj, > > > > > >I assume you refer to G.709 OCh connections when you use > the term "LSC > > >LSP". If > > >so, then a bi-directional OCh link connection will use the same OCh > > >tributary > > >slot in both directions; i.e. the same wavelenght is used > for go and return > > >direction. > > > > > >Regards, > > > > > >Maarten > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I need to establish a bi-directional LSC LSP > then do I > > > > need to configure the remote end wavelengths on an LSC > interface ? > > > > Is there any case where both the upstream and > downstream labels of an > > > > bi-directional LSC LSP be same ? > > > > > > > > Regards, > > > > manoj. > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 01:35:53 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C108C01.BE6A623E@lucent.com> Date: Fri, 07 Dec 2001 10:29:37 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Fwd: LSC Interface Doubt ... Content-Type: multipart/mixed; boundary="------------5AE51935B2C0DF2564A58A73" This is a multi-part message in MIME format. --------------5AE51935B2C0DF2564A58A73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, Are you aware that a PXC can be operated as an ODUk switch or a STM/OC-N switch in addition to an OCh switch? The PXC is a name for an optical fabric equipment. As fabrics are typical more transparent than the connected line/trib ports, those latter determine the switching type. E.g. a PXC connected to optical line systems including transponders will not operate at wavelenght level. The transponders have terminated the wavelenghts. Such combination will switch ODUk and/or STM/OC-N signals. For the case the line systems do not have transponders, the PXC operates as true OCh (i.e. wavelength) switch. Most line systems in the core network today deploy 10G wavelengths, whereas many service signals are at 2G5 level. Therefore, the transponders in the line system may include 4:1 TDM multiplex circuits. With future 40G wavelengths, there will be 16:1 TDM mux circuits (case of 2G5 services) and 4:1 TDM mux circuits (case of 10G services). Here it is more obvious that the PXC doesn't switch "wavelenghts". Therefore LSC for me is limited to true G.709 OCh switching; i.e. when no transponders are present around the fabric. Regards, Maarten manoj juneja wrote: > > Hi Marteen, > I refer to LSC interface as defined in GMPLS architecture > document (i.e. interface which switch data based on the wavelength on > which the data is received e.g. PXC or OXC which operate at the level > of individual wavelength). I don't think it has any thing to do with > Och (G.709). > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Fwd: LSC Interface Doubt ... > >Date: Thu, 06 Dec 2001 11:42:02 +0100 > > > >Manoj, > > > >I assume you refer to G.709 OCh connections when you use the term "LSC > >LSP". If > >so, then a bi-directional OCh link connection will use the same OCh > >tributary > >slot in both directions; i.e. the same wavelenght is used for go and return > >direction. > > > >Regards, > > > >Maarten > > > >manoj juneja wrote: > > > > > > Hi All, > > > If I need to establish a bi-directional LSC LSP then do I > > > need to configure the remote end wavelengths on an LSC interface ? > > > Is there any case where both the upstream and downstream labels of an > > > bi-directional LSC LSP be same ? > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------5AE51935B2C0DF2564A58A73 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------5AE51935B2C0DF2564A58A73-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Dec 2001 01:01:38 -0800 Message-ID: <3C108055.614B9DD7@alcatel.it> Date: Fri, 07 Dec 2001 09:39:49 +0100 From: Sergio Belotti Organization: ALCATEL TND MIME-Version: 1.0 To: mvissers@lucent.com CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP Forwarding Adjacency Doubt Content-Type: multipart/mixed; boundary="------------FF1F6A860B7864600806327D" This is a multi-part message in MIME format. --------------FF1F6A860B7864600806327D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Marteen, I read your examples just now and I have only one question regarding the sentence referred to the fact that "The ODUk link is created as part of network planning and/or (distributed) network engineering" . I agreebut, Shouldn't be a negotiation phase between the Link Manager at both side before the CC could be able to perform the connection ? Thank you Sergio mvissers@lucent.com wrote: > Manoj, > > The transport plane is a multi layer network as described in G.805 and its > technology specific recommendations G.803, G.872 and I.326. Each layer network > operates independent from each other layer network. Each layer network uses the > transport service provided by its server layer networks, and represents this > transport service as (G.805) links within its own layer network. > > In your example with nodes A, B, C and D, nodes A and D could operate on the > ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate > on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have > also OCh fabrics, but this is not necessary; OCh termination points would > already be sufficient. > > Let me give a 3 node example (4 nodes don't fit the page width in this email) in > which a STM-N signal is to be transported through A, B and C. At C the STM-N > signal leaves the network within an OTM-0.m signal. > > node A node B node C > |<----------->|<------------------------------>|<------------------------->| > > STM-N ---- > | > ------ > |ODUk| > |port| > ------ > | > -------------- -------------------- > | ODUk | | ODUk | > | Fabric | | Fabric | > -------------- -------------------- > ||...|....||| |||...|....||...|... > ------ ------ ------ > |OTUk| |OTUk| |OTUk| > |OCh | |OCh | |Och | > |port| |port| |port| > ------ ------ ------ > | ||....|...| | > | ---------------------------- ------------- | > | | OCh | | OCh | | > | | Fabric | | Fabric | | > | ---------------------------- ------------- | > ||||||||||| ||||||||||| ||||||||| ||||||||| | > ----------- ----------- --------- --------- ------- > | OTM-n | | OTM-n | | OTM-n | | OTM-n | |OTM-0| > | port | | port | | port | | port | |port | > ----------- ----------- --------- --------- ------- > | | | | | > | | | | | > ------------------- ---------------------- ------ > > The above network can be represented by means of its ODUk and OCh layer networks > as follows: > > node A node B node C > |<----------->|<------------------------------>|<------------------------->| > > STM-N ---- > | > ------ > |ODUk| > |port| > ------ > | > -------------- -------------------- > | ODUk | | ODUk | > | Fabric | | Fabric | > -------------- -------------------- > |||| ||||||||| |||||||||| |||||| > | | | | | | | | > -- | | ---------------------------------------- | | ------ > | | ODUk Link | | ODUk Link > ----- --------------------------------------------------------- ----------- > > As you can see at the ODUk layer network, nodes A and C are neighbors. The > intermediate node B is totally invisible. ODUk signalling takes place therefore > between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in > nodes A and C are connected with each other via the signalling communication > network. > > | | | > ------ ------ ------ > |OTUk| |OTUk| |OTUk| > |OCh | |OCh | |Och | > |port| |port| |port| > ------ ------ ------ > | ||....|...| | > | ---------------------------- ------------- | > | | OCh | | OCh | | > | | Fabric | | Fabric | | > | ---------------------------- ------------- | > ||| ||||||| ||||||||| ||||||||| ||||||||| |||||| > | | | | | | | | | | | | > -- | | --------- | | -------------- | | --- > | | OCh Link | | OCh Link | | > ----- ----------------------- ------------------------------ -------- > > As you can see at the OCh layer network, nodes A and B and nodes B and C are > neighbors. OCh signalling takes place therefore between nodes A, B and C. The > OCh CCs in nodes A, B and C are connected with each other for this purpose via > the signalling communication network. > > In the above 3-node example network, you will be able to setup ODUk connections > when the ODUk link is setup first. The ODUk link is created as part of network > planning and/or (distributed) network engineering. The ODUk link will exist when > one or more OCh trails are setup in the OCh layer network. > > So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the > Lambda level. > > Same principles apply of course to the SDH/SONET layer networks... i.e. you will > have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS > links. > > This multi-layer principle doesn't require to stack labels. > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi All, > > If there are 4 nodes say A, B, C and D. There is a Lambda FA > > established from A to D and if a new TDM LSP request comes to node A > > which is to be tunneled through the already established lambda FA-LSP > > then the node A sends the Path/label request message directly to node > > D. What label the node D will send back to node A in the RESV/label > > mapping message since the FA-LSP is just one label (lambda) ? Does it > > mean that all the LSPs which are tunneled through the lambda FA-LSP > > will be allocated the same label by node D to node A ? > > > > Please help. > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------FF1F6A860B7864600806327D Content-Type: text/x-vcard; charset=us-ascii; name="sergio.belotti.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sergio Belotti Content-Disposition: attachment; filename="sergio.belotti.vcf" begin:vcard n:Belotti;Sergio tel;fax:Alcanet (2210)4185 or +(39) 039-6864185 tel;home:+(39) 039 6081786 tel;work:Alcanet (2210)3033 or +(39) 039-6863033 x-mozilla-html:FALSE org:;Optics Group version:2.1 email;internet:sergio.belotti@netit.alcatel.it title:Network Management System Design adr;quoted-printable:;;via Trento 30 =0D=0A;vimercate;Italy;20059; fn:Sergio Belotti end:vcard --------------FF1F6A860B7864600806327D-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 23:51:04 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , mvissers@lucent.com Cc: ccamp@ops.ietf.org Subject: RE: Fwd: LSC Interface Doubt ... Date: Fri, 7 Dec 2001 08:49:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Manoj, that is exactly what the G.709 OCh does. In addition to the optical signal it has specific overhead functionality (transported via the OSC) assigned. Juergen > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Thursday, December 06, 2001 7:24 PM > To: mvissers@lucent.com > Cc: ccamp@ops.ietf.org > Subject: Re: Fwd: LSC Interface Doubt ... > > > Hi Marteen, > I refer to LSC interface as defined in GMPLS architecture > document (i.e. interface which switch data based on the wavelength on > which the data is received e.g. PXC or OXC which operate at the level > of individual wavelength). I don't think it has any thing to do with > Och (G.709). > > Regards, > manoj. > > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Fwd: LSC Interface Doubt ... > >Date: Thu, 06 Dec 2001 11:42:02 +0100 > > > >Manoj, > > > >I assume you refer to G.709 OCh connections when you use the > term "LSC > >LSP". If > >so, then a bi-directional OCh link connection will use the same OCh > >tributary > >slot in both directions; i.e. the same wavelenght is used > for go and return > >direction. > > > >Regards, > > > >Maarten > > > >manoj juneja wrote: > > > > > > Hi All, > > > If I need to establish a bi-directional LSC LSP then do I > > > need to configure the remote end wavelengths on an LSC interface ? > > > Is there any case where both the upstream and downstream > labels of an > > > bi-directional LSC LSP be same ? > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 22:19:13 -0800 Message-ID: <3C105F19.CCA6721@npd.hcltech.com> Date: Fri, 07 Dec 2001 11:48:01 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: Jonathan Lang CC: "'Murugan .A'" , ccamp@ops.ietf.org Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, As you said the Verify Dead interval is for "each" Test message and it is to be determined by the receiver side, based on the capability of the receiver of Test message. Agreed. Now suppose the receiver choosed a large Verify Deadinterval ( since it is going to listen on a single interface at a time ) and it needs to cycle through the potential data links ( as you said ). On what basis does it switches , listening from one interface to the next in the process of cycling through the interfaces.( since one can be listened at a time ). If you say that this timeout period is the VerifyDeadinterval for that datalink means the case what Murugan mentioned is a possible one. How that can be solved by choosing a large value of VerifyDead Interval. Now VerifyDeadInterval is the one upto which the sender will send the Test messages through the same interface. am i right. . But what is the timeout to listen on a single interface. On what basis the receiver will switch to the next interface and start lsitening on it. If this timeout is also equal to the VerifyDeadInterval what is the use of selecting a large value of VerifyDeadInterval timer. Then the case what Murugan mentioned is always possible. Kindly clarify me( if possible with the same example of Murugan's). Thanks, Ramesh ------- > This is where you are misunderstanding the process. If you can only receive > over one interface at a time, then you need to cycle through your interfaces > before declaring the test failed. Hence, the VerifyDeadInterval must be > long enough for you to check all potential data links. This is why the > receiver determines the VerifyDeadInterval. > ---- --------- > > > No. The VerifyDeadInterval is set for *each* Test message. > > This is > > > configured at the receiving node and indicates that if a > > Test message is not > > > seen within the VerifyDeadInterval, the Test procedure has > > failed for that > > > data link. In your above example, once the receiver sees a > > Test message, it > > > sends a TestStatusSuccess message to the sender. If > > instead, the > > > VerifyDeadInterval is reached without receiving a Test > > message, A > > > TestStatusFailure message is sent. At this point, the > > sender can transmit a > > > new Test message down the next data link. ------------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 10:55:23 -0800 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Date: Thu, 06 Dec 2001 11:49:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, Agreed. VC-4-64c connection can be advertised as a FA and can carry IP/ATM or ethernet traffic. Now take the case where multiple LSPs are to be tunneled through the VC-4-64c connection (FA-LSP). What about the label ? What type of label the tail end of VC-4-64c FA -LSP i.e. node D will pass to the node A (i.e. head end of vc-4-64c FA -LSP) ? The LSP encoding and switching types are different for FA-LSP and the LSP which is to be tunneled through the FA-LSP. Regards, manoj. >From: Maarten Vissers >To: "'manoj juneja'" >CC: ccamp@ops.ietf.org >Subject: Re: AW: AW: VC-4-64c as forwarding adjacency >Date: Thu, 06 Dec 2001 12:24:32 +0100 > >Manoj, > >In transport terminology I would refer to this as a VC-4-64c trail >supporting an >IP, ATM or Ethernet link. > >Regards, > >Maarten > >Heiles Juergen wrote: > > > > Manoj, > > > > this has nothing to do with forwarding adjacency. It is a restriction of >the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4-64c >supports IP, ATM, Ethernet as client signal, but not a VC-4 or >VC-3/2/12/11. > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet >clients. > > > > Juergen > > > > > -----Ursprüngliche Nachricht----- > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > Hi Juergen, > > > Does this mean the forwarding adjacency concept is not > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > adjacecny of > > > virtual concatenated LSP should be allowed. > > > > > > Regards, > > > manoj. > > > > > > > > > >From: "Juergen Heiles" > > > >To: "'manoj juneja'" , > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > > VC-4-64c. A > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > >Juergen > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > An: ccamp@ops.ietf.org > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > Hi All, > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > forwarding > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > Regards, > > > > > manoj > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 10:25:09 -0800 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Fwd: LSC Interface Doubt ... Date: Thu, 06 Dec 2001 11:23:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, I refer to LSC interface as defined in GMPLS architecture document (i.e. interface which switch data based on the wavelength on which the data is received e.g. PXC or OXC which operate at the level of individual wavelength). I don't think it has any thing to do with Och (G.709). Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Fwd: LSC Interface Doubt ... >Date: Thu, 06 Dec 2001 11:42:02 +0100 > >Manoj, > >I assume you refer to G.709 OCh connections when you use the term "LSC >LSP". If >so, then a bi-directional OCh link connection will use the same OCh >tributary >slot in both directions; i.e. the same wavelenght is used for go and return >direction. > >Regards, > >Maarten > >manoj juneja wrote: > > > > Hi All, > > If I need to establish a bi-directional LSC LSP then do I > > need to configure the remote end wavelengths on an LSC interface ? > > Is there any case where both the upstream and downstream labels of an > > bi-directional LSC LSP be same ? > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 09:35:46 -0800 Message-ID: From: Jonathan Lang To: "'Murugan .A'" , ccamp@ops.ietf.org Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions. Date: Thu, 6 Dec 2001 09:25:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Murugan, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Murugan .A [mailto:mamirtha@npd.hcltech.com] > Sent: Wednesday, December 05, 2001 11:11 PM > To: Jonathan Lang; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] LMP: Link verification procedure > suggestions. > > > Hi Jonathan Lang, > When mappings are not known, the procedure to find mappings are not that straight forward. > Some other pocedure over the LMP procedure is needed to find the mappings, which are not > efficient and straight forward(this i have discussed in "IETF:" section of my earlier mail). > Hence i have proposed some changes to LMP procedure itself(this i have discussed in > "My suggestion:" section in my earlier mail). > > Let me take an example where LMP procedure fails. > Both sender and receiver are capable of sending and receiving test messages sequentially ONLY. > Let us have 4 interfaces in each side. Both the nodes dont know the interface mappings. > > The internal order in which the sender is going to send test messages is as follows > S_interface_1 (using prefix S to denote sender) > S_interface_2 > S_interface_3 > S_interface_4 > > The internal order in which the reciver is going to wait > for receiving test messages is as follows > R_interface_4 (using prefix R to denote Receiver) > R_interface_3 > R_interface_2 > R_interface_1 > > The physical connection is as follows( in both directions) > S_interface_1 <-> R_interface_1 > S_interface_2 <-> R_interface_2 > S_interface_3 <-> R_interface_3 > S_interface_4 <-> R_interface_4 > > Now let us see what happens when testing is started with "Number of Data Links" set to 4. > Receiver is waiting in R_interface_4 upto VerifyDeadInterval, but the sender sends test messages in > S_interface_1 repearedly. This is where you are misunderstanding the process. If you can only receive over one interface at a time, then you need to cycle through your interfaces before declaring the test failed. Hence, the VerifyDeadInterval must be long enough for you to check all potential data links. This is why the receiver determines the VerifyDeadInterval. > The physical connection is between "S_interface_1 <-> > R_interface_1" > At the end of VerifyDeadInterval the receriver sends > TestStatusFailure, now the sender will send > estStatusAck( and move to the second link).. > The Recever receives TestStatusAck( and move to the next > link to listen) > > Now The Sender moves to S_interface_2, the receiver moves to > R_interface_3. > But the physical conenction is between "S_interface_2 > <-> R_interface_2". > Hence this also fails. > > Now The Sender moves to S_interface_3, the receiver moves to > R_interface_2. > But the physical conenction is between "S_interface_3 > <-> R_interface_3". > Hence this also fails. > > Now The Sender moves to S_interface_4, the receiver moves to > R_interface_1. > But the physical conenction is between "S_interface_4 > <-> R_interface_4". > Hence this also fails. > > The sender has received TestStatusFailure for all its four > interfaces. Similarly the receiver has not received > test messages in any of the interfaces as per the internal > ordering in which it waited. > Mapping is not found for any of the interfaces and the links > state is down. > > If the internal ordering of sending and receiving test > messages are configured as per the physical > connection then the above procedure succeeds. But this is > eqivalent to user/"any one" configuring the interface > mapping. > The LMP procedure doesnot find the interface mappings, it > only check if the interface mappings provided by the user > is correct or not > > Let me know if i have missed some thing. > > Thanks, > Murugan > Ramesh > > > >Hi, > > > Giving below the test procedures followed by the IETF > draft and my > > suggestions for them. > > > Both nodes exchange their testing > capabilites(sequential/simultaneous) > > through BeginVerify > > > and BeginVerifyAck. > > There is no notion of exchanging sequential/simultaneous > testing > > capabilities. The protocol is designed to support both > capabilities without > > negotiation. > > > > > > > > The local node also sends if it has the interface > mappings(not know > > intially) in BeginVerify. > > > When the mappings are known, if both nodes support's > simultaneous testing, > > simultaneous > > > testing is done. > > > > > >If only one node support's simultaneous testing, then > both nodes do > > sequential testing with > > >the know ordering. > > > > > > > > >1) sender testing capability:sequential, receiver testing > > capability:simultaneous, mappings > > > are not known. > > > IETF: > > > Verification procedure is started with number of links > to be tested equal > > to all links in > > > the TE/data set. Sender sends test message in one of the > links(as per its > > internal ordering). > > > Receiver waits in all the links. > > > > > > Receiver may receive test message in just one of the > links, for all other > > links it will not > > > receive test message within VerifyDeadInterval. At the > end of > > VerifyDeadInterval the remtoe > > > node would have send TestStatusSuccess or > TestStatusFailure for all the > > links. > > > > > > The sender sends TestStatusAck for all the links. The > verification > > procedure is completed. > > > > > > At the end of this verification procedure mapping is > found out for only > > one link(provided > > > beginVeryAck is received). > > > The above procedure has to be repeated again and again > unitl mapping is > > found for all links. > > No. The VerifyDeadInterval is set for *each* Test message. > This is > > configured at the receiving node and indicates that if a > Test message is not > > seen within the VerifyDeadInterval, the Test procedure has > failed for that > > data link. In your above example, once the receiver sees a > Test message, it > > sends a TestStatusSuccess message to the sender. If > instead, the > > VerifyDeadInterval is reached without receiving a Test > message, A > > TestStatusFailure message is sent. At this point, the > sender can transmit a > > new Test message down the next data link. > > > > > > > >My suggestion: > > > The sender informs the receiving side that it is capable > of testing > > sequentially only. It also > > > informs the remote node that it doesnot have interface > mappings. Receiver > > sends BeginVerifyAck, > > > with VerifyDeadInterval set to "locally configured > VerifyDeadInterval for > > single data link" > > > * "no of links to be tested". > > > The local node will send test messages in a interface > sequentially for > > every verify interval > > > and the number of retries for an interface will be > stopped based on local > > configuration > > >( retransmission count or timer). > > > > > > Remote node is waiting for "VerifyDeadInterval for > single data link" * "no > > of links to be > > > tested" for all interfaces. This time is enough to > receive test message > > send in any order > > > over the links. > > > > > > 2) sender testing capability:sequential, receiver > testing > > capability:sequential, mappings are > > > not known. > > > > > >IETF: > > > Not clear how testing is done in this case. Since sender > follows its own > > ordering for sending > > > test messages over different interfaces, where as the > receiver follows its > > own ordering > > > waiting to receive test messages over interfaces. There > is no correllation > > of the ordering > > > between the two. > > The LMP procedure is the same as I described above. > > > > > > > >My suggestion: > > > The sender informs the receiving side that it is capable > of testing > > sequentially only. It also > > > informs the remote node that it doesnot have interface > mappings. > > > > > > The receiver also informs the sender that it is capable > of doing testing > > sequentially and sets > > > VerifyDeadInterval to "locally configured > VerifyDeadInterval for single > > data link" * "no of > > > links to be tested". > > > > > > Remote node is waiting for "VerifyDeadInterval for > single data link" * "no > > of links to be > > > tested" for one interface. After the end of this period > it waits in the > > next interface. > > > > > > The local node will send test messages in a interface > sequentially for > > every verify interval > > > and the number of retries for an interface will be > stopped based on local > > configuration > > > ( retransmission count or timer). At the end of this > period it may know > > mapping for just > > > one link. Since the local node know that the remote node > is only capable > > of sequential testing > > > the above procedure has to be repated. > > > > > >Thanks, > > >Murugan > > >Ramesh > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 09:35:32 -0800 Message-ID: From: Jonathan Lang To: 'Fugui Wang' , "'Murugan .A'" , ccamp@ops.ietf.org Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions. Date: Thu, 6 Dec 2001 09:26:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Fugui, Please see my response to Murugan. Thanks, jonathan > -----Original Message----- > From: Fugui Wang [mailto:fwang@axiowave.com] > Sent: Thursday, December 06, 2001 7:13 AM > To: 'Murugan .A'; Jonathan Lang; ccamp@ops.ietf.org > Subject: RE: [IP-Optical] LMP: Link verification procedure > suggestions. > > > I also noticed the problem as Murugan described below. > Even worse, the TE link ID mapping could be unknown in > the BeginVerify (according to the LMP draft, Remote Link > ID is an optional object for BeginVerify). In such case, > if the receiver can receive test messages sequentially > ONLY, then it has to listen all of the data bearing links > between the neighboring nodes one by one (each for Verify > Dead Interval) to determine whether it is a TestStatusSuccess > or a TestStatusFailure. > > Fugui > > -----Original Message----- > From: Murugan .A [mailto:mamirtha@npd.hcltech.com] > Sent: Thursday, December 06, 2001 2:11 AM > To: Jonathan Lang; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] LMP: Link verification procedure > suggestions. > > > Hi Jonathan Lang, > When mappings are not known, the procedure to find > mappings are not that straight forward. > Some other pocedure over the LMP procedure is needed to > find the mappings, which are not > efficient and straight forward(this i have discussed in > "IETF:" section of my earlier mail). > Hence i have proposed some changes to LMP procedure > itself(this i have discussed in > "My suggestion:" section in my earlier mail). > > Let me take an example where LMP procedure fails. > Both sender and receiver are capable of sending and > receiving test messages sequentially ONLY. > Let us have 4 interfaces in each side. Both the nodes > dont know the interface mappings. > > The internal order in which the sender is going to send > test messages is as follows > S_interface_1 (using prefix S to denote sender) > S_interface_2 > S_interface_3 > S_interface_4 > > The internal order in which the reciver is going to wait > for receiving test messages is as follows > R_interface_4 (using prefix R to denote Receiver) > R_interface_3 > R_interface_2 > R_interface_1 > > The physical connection is as follows( in both > directions) > S_interface_1 <-> R_interface_1 > S_interface_2 <-> R_interface_2 > S_interface_3 <-> R_interface_3 > S_interface_4 <-> R_interface_4 > > Now let us see what happens when testing is started with > "Number of Data Links" set to 4. > Receiver is waiting in R_interface_4 upto > VerifyDeadInterval, but the sender sends test messages in > S_interface_1 repearedly. > The physical connection is between "S_interface_1 <-> > R_interface_1" > At the end of VerifyDeadInterval the receriver sends > TestStatusFailure, now the sender will send > estStatusAck( and move to the second link).. > The Recever receives TestStatusAck( and move to the next > link to listen) > > Now The Sender moves to S_interface_2, the receiver moves to > R_interface_3. > But the physical conenction is between "S_interface_2 > <-> R_interface_2". > Hence this also fails. > > Now The Sender moves to S_interface_3, the receiver moves to > R_interface_2. > But the physical conenction is between "S_interface_3 > <-> R_interface_3". > Hence this also fails. > > Now The Sender moves to S_interface_4, the receiver moves to > R_interface_1. > But the physical conenction is between "S_interface_4 > <-> R_interface_4". > Hence this also fails. > > The sender has received TestStatusFailure for all its four > interfaces. Similarly the receiver has not received > test messages in any of the interfaces as per the internal > ordering in which it waited. > Mapping is not found for any of the interfaces and the links > state is down. > > If the internal ordering of sending and receiving test > messages are configured as per the physical > connection then the above procedure succeeds. But this is > eqivalent to user/"any one" configuring the interface > mapping. > The LMP procedure doesnot find the interface mappings, it > only check if the interface mappings provided by the user > is correct or not > > Let me know if i have missed some thing. > > Thanks, > Murugan > Ramesh > > > >Hi, > > > Giving below the test procedures followed by the IETF > draft and my > > suggestions for them. > > > Both nodes exchange their testing > capabilites(sequential/simultaneous) > > through BeginVerify > > > and BeginVerifyAck. > > There is no notion of exchanging sequential/simultaneous > testing > > capabilities. The protocol is designed to support both > capabilities without > > negotiation. > > > > > > > > The local node also sends if it has the interface > mappings(not know > > intially) in BeginVerify. > > > When the mappings are known, if both nodes support's > simultaneous testing, > > simultaneous > > > testing is done. > > > > > >If only one node support's simultaneous testing, then > both nodes do > > sequential testing with > > >the know ordering. > > > > > > > > >1) sender testing capability:sequential, receiver testing > > capability:simultaneous, mappings > > > are not known. > > > IETF: > > > Verification procedure is started with number of links > to be tested equal > > to all links in > > > the TE/data set. Sender sends test message in one of the > links(as per its > > internal ordering). > > > Receiver waits in all the links. > > > > > > Receiver may receive test message in just one of the > links, for all other > > links it will not > > > receive test message within VerifyDeadInterval. At the > end of > > VerifyDeadInterval the remtoe > > > node would have send TestStatusSuccess or > TestStatusFailure for all the > > links. > > > > > > The sender sends TestStatusAck for all the links. The > verification > > procedure is completed. > > > > > > At the end of this verification procedure mapping is > found out for only > > one link(provided > > > beginVeryAck is received). > > > The above procedure has to be repeated again and again > unitl mapping is > > found for all links. > > No. The VerifyDeadInterval is set for *each* Test message. > This is > > configured at the receiving node and indicates that if a > Test message is not > > seen within the VerifyDeadInterval, the Test procedure has > failed for that > > data link. In your above example, once the receiver sees a > Test message, it > > sends a TestStatusSuccess message to the sender. If > instead, the > > VerifyDeadInterval is reached without receiving a Test > message, A > > TestStatusFailure message is sent. At this point, the > sender can transmit a > > new Test message down the next data link. > > > > > > > >My suggestion: > > > The sender informs the receiving side that it is capable > of testing > > sequentially only. It also > > > informs the remote node that it doesnot have interface > mappings. Receiver > > sends BeginVerifyAck, > > > with VerifyDeadInterval set to "locally configured > VerifyDeadInterval for > > single data link" > > > * "no of links to be tested". > > > The local node will send test messages in a interface > sequentially for > > every verify interval > > > and the number of retries for an interface will be > stopped based on local > > configuration > > >( retransmission count or timer). > > > > > > Remote node is waiting for "VerifyDeadInterval for > single data link" * "no > > of links to be > > > tested" for all interfaces. This time is enough to > receive test message > > send in any order > > > over the links. > > > > > > 2) sender testing capability:sequential, receiver > testing > > capability:sequential, mappings are > > > not known. > > > > > >IETF: > > > Not clear how testing is done in this case. Since sender > follows its own > > ordering for sending > > > test messages over different interfaces, where as the > receiver follows its > > own ordering > > > waiting to receive test messages over interfaces. There > is no correllation > > of the ordering > > > between the two. > > The LMP procedure is the same as I described above. > > > > > > > >My suggestion: > > > The sender informs the receiving side that it is capable > of testing > > sequentially only. It also > > > informs the remote node that it doesnot have interface > mappings. > > > > > > The receiver also informs the sender that it is capable > of doing testing > > sequentially and sets > > > VerifyDeadInterval to "locally configured > VerifyDeadInterval for single > > data link" * "no of > > > links to be tested". > > > > > > Remote node is waiting for "VerifyDeadInterval for > single data link" * "no > > of links to be > > > tested" for one interface. After the end of this period > it waits in the > > next interface. > > > > > > The local node will send test messages in a interface > sequentially for > > every verify interval > > > and the number of retries for an interface will be > stopped based on local > > configuration > > > ( retransmission count or timer). At the end of this > period it may know > > mapping for just > > > one link. Since the local node know that the remote node > is only capable > > of sequential testing > > > the above procedure has to be repated. > > > > > >Thanks, > > >Murugan > > >Ramesh > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 08:49:58 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C0FA12B.5F8047C2@lucent.com> Date: Thu, 06 Dec 2001 17:47:39 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dieter Beller Original-CC: ccamp@ops.ietf.org Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Content-Type: multipart/mixed; boundary="------------9C26A6D1F77CA4329B5E0637" This is a multi-part message in MIME format. --------------9C26A6D1F77CA4329B5E0637 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dieter, Formally the VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c layer networks are separate laye= r networks. And if we do not want any special cases to treat we should admi= nister and control those layer networks as separate layer networks. Nevertheless, in todays SDH/SONET networks the network management systems= typically control those layer networks as HOVC/STS "layer" (similarly we = have the LOVC/VT "layer"). The specific layer network has been more or less co= nverted into a signal type parameter. ASON is layer network based from the functional perspective. But one of t= he ASON components, the "protocol controller" can however have a 1:n relation wit= h other ASON components. In order to support the HOVC and LOVC "layer" approach, = one protocol controller can interact with e.g. VC-3 CC, VC-4 CC, VC-4-4c CC, = etc. I.e. the signalling messages from that single protocol controller contain= VC-3, VC-4, VC-4-Xc related information elements. = Idem for a "LOVC" protocol controller of course. Whether or not this merging will be done is a matter of HOVC [and LOVC] U= NI, E-NNI and I-NNI agreements. = Note - Within one vendor's subnetwork, a vendor may make its own = decision (there is no interconnect with other vendors's equipment). Note - I have proposed to go for HOVC and LOVC "layer" approaches in a June and a September contribution to Q.12/15. But, this level of = detail didn't fit in the first version of G.8080. It will again be = discussed for the next version or a related ASON recommendation. ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q12/01= 06/wd20-astn-ln-definition.pdf http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-lna01.doc http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/cd-ason-abc01.doc Separate from the interface specification, there is the implementation of= control plane functionality in equipment. ASON specifies a functional architecture, and it is up to the vendors to implement this functional architecture. Multiple implementations will exist, some which have merged= many functional components into a single implementation component, others whic= h are more 1:1 with the functional architecture. But my feeling is that it is k= ind of natural to combine VC-3/4/4-Xc functional components into HOVC implementa= tion components (as long as the functional behaviour is supported). And idem f= or LOVC. Combining multiple layer networks into a single "layer" may introduce an "interworking" item when there is no complete orthogonality. E.g. the VC-= 3 is part of both LOVC and HOVC "layers". A closer look some time ago revealed= however that there is no real issue here... I documented this in http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.doc http://ties.itu.int/u/tsg15/sg15/wp3/q12/0109/cd/lovc_hovc_ln01.pdf (if y= ou do not have access to ITU-T let me know and I forward file to you)... i.e. i= f there is a point in the network where AU3/VC3 signal is continued as TU3/VC3 si= gnal (within AU4/VC4), you have a HOVC fabric which is connected via a link to= a LOVC fabric. The HOVC fabric sees this link as a HOVC link supporting only VC-= 3 link connections, the LOVC fabric sees this link as a LOVC link supporting onl= y VC-3 link connections. Similarly, the ODU1, ODU2 and ODU3 layer networks are each others peers w= ith respect to the OCh layer network, but these ODUk layer networks have also= client/server relationships. At the time of writing the June/Sept contrib= utions I had the feeling that ODU1, ODU2 and ODU3 should be treated as separate = layer networks, and not be combined into an ODUk "layer". At this moment, with = the concept of protocol controller, it can be expected that there is one ODUk= protocol controller supporting ODU1, ODU2 and ODU3 layer network signalli= ng. With respect to advertising, I have the feeling that there will be no dif= ference between treating HOVC [LOVC, ODUk] layer networks separate or combined. T= he same information will be distributed, and the same operations will be possible= =2E It seems more a matter of how much of the specific details do we want to sho= w. E.g. take the HOVC case with its VC-3 link connections, Vc-4 link connections,= VC-4-4c link connections, etc. We can describe this set of link connectio= ns by means of a set of parallel VC-3 link, VC-4 link, VC-4-4c link, etc. (each= containing a single link connection type), or by means of a single HOVC l= ink (with multiple link connection types). The G.85x.y series uses the former= means, in my correspondence documents in the middle of the year I used the latte= r means ( ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q12/01= 06/wd08-cd-astn-ln01.pdf ). When we use the former and define separate VC-3, VC-4, etc links we have = to add explicit interactions between their Link Resource Managers (LRMs) or yet = to define related components to support the ability to change e.g. a group o= f 4 VC-4 link connections into a single VC-4-4c link connection. When we use = the latter and define a combined HOVC link with a single LRM, the change of l= ink structure can be taken care of within the single LRM component. But at th= e end we won't notice a difference. Up to so far... still some work to do :-) Regards, Maarten Dieter Beller wrote: > = > Maarten, > = > I fully share your view concerning the contiguous concatenated > signal. Moreover, I also read your mail regarding the "Lambda > LSP Forwarding Adjacency Doubt" where you describe the > layering of the transport plane. > = > Now, I have the question whether e.g. the HOVC layer in SDH > or SONET which supports multiple signal types (plain VC-4s, > VC-4-ncs, etc.) should be considered as strictly separated layers > at the same level, or whether they should rather be considered > as a single layer supporting multiple services? > = > This has of course some implications on routing (e.g. what is > advertised and which nodes share a Forwarding Adjacency) > = > Regards, > = > Dieter > = > Maarten Vissers wrote: > = > > Manoj, > > > > In transport terminology I would refer to this as a VC-4-64c trail su= pporting an > > IP, ATM or Ethernet link. > > > > Regards, > > > > Maarten > > > > Heiles Juergen wrote: > > > > > > Manoj, > > > > > > this has nothing to do with forwarding adjacency. It is a restricti= on of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A = VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or V= C-3/2/12/11. > > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethe= rnet clients. > > > > > > Juergen > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > > > > Hi Juergen, > > > > Does this mean the forwarding adjacency concept is no= t > > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > > adjacecny of > > > > virtual concatenated LSP should be allowed. > > > > > > > > Regards, > > > > manoj. > > > > > > > > > > > > >From: "Juergen Heiles" > > > > >To: "'manoj juneja'" , > > > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > > > VC-4-64c. A > > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > > > >Juergen > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > > An: ccamp@ops.ietf.org > > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > > > > Hi All, > > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > > forwarding > > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > > > Regards, > > > > > > manoj > > > > > > > > > > > > _____________________________________________________________= ____ > > > > > > Get your FREE download of MSN Explorer at > > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________= > > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp --------------9C26A6D1F77CA4329B5E0637 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------9C26A6D1F77CA4329B5E0637-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 07:20:44 -0800 Message-ID: From: Fugui Wang To: "'Murugan .A'" , Jonathan Lang , ccamp@ops.ietf.org Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions. Date: Thu, 6 Dec 2001 10:12:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I also noticed the problem as Murugan described below. Even worse, the TE link ID mapping could be unknown in the BeginVerify (according to the LMP draft, Remote Link ID is an optional object for BeginVerify). In such case, if the receiver can receive test messages sequentially ONLY, then it has to listen all of the data bearing links between the neighboring nodes one by one (each for Verify Dead Interval) to determine whether it is a TestStatusSuccess or a TestStatusFailure. Fugui -----Original Message----- From: Murugan .A [mailto:mamirtha@npd.hcltech.com] Sent: Thursday, December 06, 2001 2:11 AM To: Jonathan Lang; ccamp@ops.ietf.org Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions. Hi Jonathan Lang, When mappings are not known, the procedure to find mappings are not that straight forward. Some other pocedure over the LMP procedure is needed to find the mappings, which are not efficient and straight forward(this i have discussed in "IETF:" section of my earlier mail). Hence i have proposed some changes to LMP procedure itself(this i have discussed in "My suggestion:" section in my earlier mail). Let me take an example where LMP procedure fails. Both sender and receiver are capable of sending and receiving test messages sequentially ONLY. Let us have 4 interfaces in each side. Both the nodes dont know the interface mappings. The internal order in which the sender is going to send test messages is as follows S_interface_1 (using prefix S to denote sender) S_interface_2 S_interface_3 S_interface_4 The internal order in which the reciver is going to wait for receiving test messages is as follows R_interface_4 (using prefix R to denote Receiver) R_interface_3 R_interface_2 R_interface_1 The physical connection is as follows( in both directions) S_interface_1 <-> R_interface_1 S_interface_2 <-> R_interface_2 S_interface_3 <-> R_interface_3 S_interface_4 <-> R_interface_4 Now let us see what happens when testing is started with "Number of Data Links" set to 4. Receiver is waiting in R_interface_4 upto VerifyDeadInterval, but the sender sends test messages in S_interface_1 repearedly. The physical connection is between "S_interface_1 <-> R_interface_1" At the end of VerifyDeadInterval the receriver sends TestStatusFailure, now the sender will send estStatusAck( and move to the second link).. The Recever receives TestStatusAck( and move to the next link to listen) Now The Sender moves to S_interface_2, the receiver moves to R_interface_3. But the physical conenction is between "S_interface_2 <-> R_interface_2". Hence this also fails. Now The Sender moves to S_interface_3, the receiver moves to R_interface_2. But the physical conenction is between "S_interface_3 <-> R_interface_3". Hence this also fails. Now The Sender moves to S_interface_4, the receiver moves to R_interface_1. But the physical conenction is between "S_interface_4 <-> R_interface_4". Hence this also fails. The sender has received TestStatusFailure for all its four interfaces. Similarly the receiver has not received test messages in any of the interfaces as per the internal ordering in which it waited. Mapping is not found for any of the interfaces and the links state is down. If the internal ordering of sending and receiving test messages are configured as per the physical connection then the above procedure succeeds. But this is eqivalent to user/"any one" configuring the interface mapping. The LMP procedure doesnot find the interface mappings, it only check if the interface mappings provided by the user is correct or not Let me know if i have missed some thing. Thanks, Murugan Ramesh > >Hi, > > Giving below the test procedures followed by the IETF draft and my > suggestions for them. > > Both nodes exchange their testing capabilites(sequential/simultaneous) > through BeginVerify > > and BeginVerifyAck. > There is no notion of exchanging sequential/simultaneous testing > capabilities. The protocol is designed to support both capabilities without > negotiation. > > > > > The local node also sends if it has the interface mappings(not know > intially) in BeginVerify. > > When the mappings are known, if both nodes support's simultaneous testing, > simultaneous > > testing is done. > > > >If only one node support's simultaneous testing, then both nodes do > sequential testing with > >the know ordering. > > > > > >1) sender testing capability:sequential, receiver testing > capability:simultaneous, mappings > > are not known. > > IETF: > > Verification procedure is started with number of links to be tested equal > to all links in > > the TE/data set. Sender sends test message in one of the links(as per its > internal ordering). > > Receiver waits in all the links. > > > > Receiver may receive test message in just one of the links, for all other > links it will not > > receive test message within VerifyDeadInterval. At the end of > VerifyDeadInterval the remtoe > > node would have send TestStatusSuccess or TestStatusFailure for all the > links. > > > > The sender sends TestStatusAck for all the links. The verification > procedure is completed. > > > > At the end of this verification procedure mapping is found out for only > one link(provided > > beginVeryAck is received). > > The above procedure has to be repeated again and again unitl mapping is > found for all links. > No. The VerifyDeadInterval is set for *each* Test message. This is > configured at the receiving node and indicates that if a Test message is not > seen within the VerifyDeadInterval, the Test procedure has failed for that > data link. In your above example, once the receiver sees a Test message, it > sends a TestStatusSuccess message to the sender. If instead, the > VerifyDeadInterval is reached without receiving a Test message, A > TestStatusFailure message is sent. At this point, the sender can transmit a > new Test message down the next data link. > > > > >My suggestion: > > The sender informs the receiving side that it is capable of testing > sequentially only. It also > > informs the remote node that it doesnot have interface mappings. Receiver > sends BeginVerifyAck, > > with VerifyDeadInterval set to "locally configured VerifyDeadInterval for > single data link" > > * "no of links to be tested". > > The local node will send test messages in a interface sequentially for > every verify interval > > and the number of retries for an interface will be stopped based on local > configuration > >( retransmission count or timer). > > > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no > of links to be > > tested" for all interfaces. This time is enough to receive test message > send in any order > > over the links. > > > > 2) sender testing capability:sequential, receiver testing > capability:sequential, mappings are > > not known. > > > >IETF: > > Not clear how testing is done in this case. Since sender follows its own > ordering for sending > > test messages over different interfaces, where as the receiver follows its > own ordering > > waiting to receive test messages over interfaces. There is no correllation > of the ordering > > between the two. > The LMP procedure is the same as I described above. > > > > >My suggestion: > > The sender informs the receiving side that it is capable of testing > sequentially only. It also > > informs the remote node that it doesnot have interface mappings. > > > > The receiver also informs the sender that it is capable of doing testing > sequentially and sets > > VerifyDeadInterval to "locally configured VerifyDeadInterval for single > data link" * "no of > > links to be tested". > > > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no > of links to be > > tested" for one interface. After the end of this period it waits in the > next interface. > > > > The local node will send test messages in a interface sequentially for > every verify interval > > and the number of retries for an interface will be stopped based on local > configuration > > ( retransmission count or timer). At the end of this period it may know > mapping for just > > one link. Since the local node know that the remote node is only capable > of sequential testing > > the above procedure has to be repated. > > > >Thanks, > >Murugan > >Ramesh > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 05:25:16 -0800 Message-ID: <3C0F705D.3439C1E1@alcatel.de> Date: Thu, 06 Dec 2001 14:19:25 +0100 From: Dieter Beller Organization: Alcatel SEL AG, TND Stuttgart, Germany MIME-Version: 1.0 To: Maarten Vissers CC: "'manoj juneja'" , ccamp@ops.ietf.org Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Content-Type: multipart/mixed; boundary="------------EC3A02E86AD8694E2624642E" This is a multi-part message in MIME format. --------------EC3A02E86AD8694E2624642E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Maarten, I fully share your view concerning the contiguous concatenated signal. Moreover, I also read your mail regarding the "Lambda LSP Forwarding Adjacency Doubt" where you describe the layering of the transport plane. Now, I have the question whether e.g. the HOVC layer in SDH or SONET which supports multiple signal types (plain VC-4s, VC-4-ncs, etc.) should be considered as strictly separated layers at the same level, or whether they should rather be considered as a single layer supporting multiple services? This has of course some implications on routing (e.g. what is advertised and which nodes share a Forwarding Adjacency) Regards, Dieter Maarten Vissers wrote: > Manoj, > > In transport terminology I would refer to this as a VC-4-64c trail supporting an > IP, ATM or Ethernet link. > > Regards, > > Maarten > > Heiles Juergen wrote: > > > > Manoj, > > > > this has nothing to do with forwarding adjacency. It is a restriction of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or VC-3/2/12/11. > > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet clients. > > > > Juergen > > > > > -----Ursprüngliche Nachricht----- > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > > > > Hi Juergen, > > > Does this mean the forwarding adjacency concept is not > > > applicable to concatenated signals/LSPs ? I hope forwarding > > > adjacecny of > > > virtual concatenated LSP should be allowed. > > > > > > Regards, > > > manoj. > > > > > > > > > >From: "Juergen Heiles" > > > >To: "'manoj juneja'" , > > > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > > VC-4-64c. A > > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > > > >Juergen > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > > An: ccamp@ops.ietf.org > > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > > > > Hi All, > > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > > forwarding > > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > > > Regards, > > > > > manoj > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp --------------EC3A02E86AD8694E2624642E Content-Type: text/x-vcard; charset=us-ascii; name="D.Beller.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dieter Beller Content-Disposition: attachment; filename="D.Beller.vcf" begin:vcard n:Beller;Dieter tel;fax:+49 711 821 - 42303 tel;work:+49 711 821 - 43125 x-mozilla-html:FALSE org:Alcatel - Optics Group - Terrestrial Networks Division;US/EA3 version:2.1 email;internet:D.Beller@alcatel.de adr;quoted-printable:;;Alcatel SEL AG,=0D=0ALorenzstrasse 10;Stuttgart;;70435;Germany fn:Beller, Dieter end:vcard --------------EC3A02E86AD8694E2624642E-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 03:25:50 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C0F5570.4A529D76@lucent.com> Date: Thu, 06 Dec 2001 12:24:32 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "'manoj juneja'" Original-CC: ccamp@ops.ietf.org Subject: Re: AW: AW: VC-4-64c as forwarding adjacency Content-Type: multipart/mixed; boundary="------------768A3E894091DF809F3CFBC6" This is a multi-part message in MIME format. --------------768A3E894091DF809F3CFBC6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Manoj, In transport terminology I would refer to this as a VC-4-64c trail suppor= ting an IP, ATM or Ethernet link. Regards, Maarten Heiles Juergen wrote: > = > Manoj, > = > this has nothing to do with forwarding adjacency. It is a restriction o= f the transport plane. A VC-4 cannot be transported in a VC-4-64c. A VC-4= -64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or VC-3/= 2/12/11. > So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet= clients. > = > Juergen > = > > -----Urspr=FCngliche Nachricht----- > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > > Betreff: Re: AW: VC-4-64c as forwarding adjacency > > > > > > Hi Juergen, > > Does this mean the forwarding adjacency concept is not > > applicable to concatenated signals/LSPs ? I hope forwarding > > adjacecny of > > virtual concatenated LSP should be allowed. > > > > Regards, > > manoj. > > > > > > >From: "Juergen Heiles" > > >To: "'manoj juneja'" , > > > > >Subject: AW: VC-4-64c as forwarding adjacency > > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > > > >No, that is not possible as you cannot transport a VC-4 in a > > VC-4-64c. A > > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > > > >Juergen > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > > An: ccamp@ops.ietf.org > > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > > > > Hi All, > > > > Can I tunnel a request for VC-4 LSP on VC-4-64c > > forwarding > > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > > > Regards, > > > > manoj > > > > > > > > _________________________________________________________________= > > > > Get your FREE download of MSN Explorer at > > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp --------------768A3E894091DF809F3CFBC6 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------768A3E894091DF809F3CFBC6-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 02:43:21 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C0F4B7A.6587F0DD@lucent.com> Date: Thu, 06 Dec 2001 11:42:02 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Fwd: LSC Interface Doubt ... Content-Type: multipart/mixed; boundary="------------7D13873BFD9B2A464BC513DD" This is a multi-part message in MIME format. --------------7D13873BFD9B2A464BC513DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, I assume you refer to G.709 OCh connections when you use the term "LSC LSP". If so, then a bi-directional OCh link connection will use the same OCh tributary slot in both directions; i.e. the same wavelenght is used for go and return direction. Regards, Maarten manoj juneja wrote: > > Hi All, > If I need to establish a bi-directional LSC LSP then do I > need to configure the remote end wavelengths on an LSC interface ? > Is there any case where both the upstream and downstream labels of an > bi-directional LSC LSP be same ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------7D13873BFD9B2A464BC513DD Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------7D13873BFD9B2A464BC513DD-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 02:16:42 -0800 Message-ID: <3C0F454F.F16E0963@lucent.com> Date: Thu, 06 Dec 2001 11:15:44 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Lambda LSP Forwarding Adjacency Doubt Content-Type: multipart/mixed; boundary="------------D70300A46D75F7BB4BE71F36" This is a multi-part message in MIME format. --------------D70300A46D75F7BB4BE71F36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, The transport plane is a multi layer network as described in G.805 and its technology specific recommendations G.803, G.872 and I.326. Each layer network operates independent from each other layer network. Each layer network uses the transport service provided by its server layer networks, and represents this transport service as (G.805) links within its own layer network. In your example with nodes A, B, C and D, nodes A and D could operate on the ODUk layer network (i.e. having an ODUk fabric) and nodes B and C would operate on the OCh layer network (i.e. having an OCh fabric). Nodes A and D may have also OCh fabrics, but this is not necessary; OCh termination points would already be sufficient. Let me give a 3 node example (4 nodes don't fit the page width in this email) in which a STM-N signal is to be transported through A, B and C. At C the STM-N signal leaves the network within an OTM-0.m signal. node A node B node C |<----------->|<------------------------------>|<------------------------->| STM-N ---- | ------ |ODUk| |port| ------ | -------------- -------------------- | ODUk | | ODUk | | Fabric | | Fabric | -------------- -------------------- ||...|....||| |||...|....||...|... ------ ------ ------ |OTUk| |OTUk| |OTUk| |OCh | |OCh | |Och | |port| |port| |port| ------ ------ ------ | ||....|...| | | ---------------------------- ------------- | | | OCh | | OCh | | | | Fabric | | Fabric | | | ---------------------------- ------------- | ||||||||||| ||||||||||| ||||||||| ||||||||| | ----------- ----------- --------- --------- ------- | OTM-n | | OTM-n | | OTM-n | | OTM-n | |OTM-0| | port | | port | | port | | port | |port | ----------- ----------- --------- --------- ------- | | | | | | | | | | ------------------- ---------------------- ------ The above network can be represented by means of its ODUk and OCh layer networks as follows: node A node B node C |<----------->|<------------------------------>|<------------------------->| STM-N ---- | ------ |ODUk| |port| ------ | -------------- -------------------- | ODUk | | ODUk | | Fabric | | Fabric | -------------- -------------------- |||| ||||||||| |||||||||| |||||| | | | | | | | | -- | | ---------------------------------------- | | ------ | | ODUk Link | | ODUk Link ----- --------------------------------------------------------- ----------- As you can see at the ODUk layer network, nodes A and C are neighbors. The intermediate node B is totally invisible. ODUk signalling takes place therefore between nodes A and C. The ODUk Connection Controllers (CC) (refer to G.8080) in nodes A and C are connected with each other via the signalling communication network. | | | ------ ------ ------ |OTUk| |OTUk| |OTUk| |OCh | |OCh | |Och | |port| |port| |port| ------ ------ ------ | ||....|...| | | ---------------------------- ------------- | | | OCh | | OCh | | | | Fabric | | Fabric | | | ---------------------------- ------------- | ||| ||||||| ||||||||| ||||||||| ||||||||| |||||| | | | | | | | | | | | | -- | | --------- | | -------------- | | --- | | OCh Link | | OCh Link | | ----- ----------------------- ------------------------------ -------- As you can see at the OCh layer network, nodes A and B and nodes B and C are neighbors. OCh signalling takes place therefore between nodes A, B and C. The OCh CCs in nodes A, B and C are connected with each other for this purpose via the signalling communication network. In the above 3-node example network, you will be able to setup ODUk connections when the ODUk link is setup first. The ODUk link is created as part of network planning and/or (distributed) network engineering. The ODUk link will exist when one or more OCh trails are setup in the OCh layer network. So when you want to setup an ODUk [i.e. a TDM LSP] connection you can ignore the Lambda level. Same principles apply of course to the SDH/SONET layer networks... i.e. you will have a LOVC/VT layer with LOVC/VT links and a HOVC/STS layer with HOVC/STS links. This multi-layer principle doesn't require to stack labels. Regards, Maarten manoj juneja wrote: > > Hi All, > If there are 4 nodes say A, B, C and D. There is a Lambda FA > established from A to D and if a new TDM LSP request comes to node A > which is to be tunneled through the already established lambda FA-LSP > then the node A sends the Path/label request message directly to node > D. What label the node D will send back to node A in the RESV/label > mapping message since the FA-LSP is just one label (lambda) ? Does it > mean that all the LSPs which are tunneled through the lambda FA-LSP > will be allocated the same label by node D to node A ? > > Please help. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------D70300A46D75F7BB4BE71F36 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------D70300A46D75F7BB4BE71F36-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 00:51:57 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , Heiles Juergen , D.Basak@Accelight.com Cc: ccamp@ops.ietf.org Subject: AW: AW: Lambda LSP Forwarding Adjacency Doubt Date: Thu, 6 Dec 2001 09:43:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Manoj, I made only a suggestion. As I am not so familiar with FAs may be = others can comment. Juergen > -----Urspr=FCngliche Nachricht----- > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Gesendet: Mittwoch, 5. Dezember 2001 19:51 > An: juergen.heiles@icn.siemens.de; D.Basak@Accelight.com > Cc: ccamp@ops.ietf.org > Betreff: Re: AW: Lambda LSP Forwarding Adjacency Doubt >=20 >=20 > Hi Juergen, > The interface Id will be of forwarding adjacency (lambda=20 > Interface id). I have a doubt in label allocation. What label=20 > the node D=20 > will send to node A ? >=20 > Regards, > manoj. >=20 >=20 > >From: "Juergen Heiles" > >To: "'manoj juneja'" ,=20 > > > >CC: > >Subject: AW: Lambda LSP Forwarding Adjacency Doubt > >Date: Wed, 5 Dec 2001 10:18:49 +0100 > > > >For a TDM service you have to consider the specific signal=20 > format, for > >example SDH or G.709 ODU. > >I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique=20 > SUKLM numbering in > >the lable in additon to the interface ID. If nodes A and D=20 > include TDM and > >lambda switches the STM-N signal is no longer a interface=20 > (instead the WDM > >signal is the interface), so I would assume that the ID of=20 > the lambda=20 > >FA-LSP > >replaces the interface ID. > > > >Juergen > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > Gesendet: Mittwoch, 5. Dezember 2001 00:24 > > > An: D.Basak@Accelight.com > > > Cc: ccamp@ops.ietf.org > > > Betreff: RE: Lambda LSP Forwarding Adjacency Doubt > > > > > > > > > Hi Debashis, > > > In my example, A and D nodes are TDM and lambda = switch > > > capable but nodes B and C are lambda switch capable. I=20 > want to tunnel > > > TDM LSP through the lambda LSP (established earlier and > > > advertised as a > > > FA). My question was how the label allocation be done at node > > > D ? Is it > > > that for all the incoming TDM LSPs requests that need to=20 > be tunneled > > > through same lambda FA-LSP be assigned the same label at=20 > node D and > > > sent bck to node A in RESV message ? If no, then how to assign = the > > > different labels to different LSPs that are to be=20 > tunneled through the > > > same lambda FA-LSP. > > > > > > I think u are describing the case of how to tunnel LOVC LSP > > > in HOVC LSP > > > (HOVC LSP advertised as FA). > > > > > > Regards, > > > manoj. > > > > > > > > > >From: "Basak, Debashis" > > > >To: 'manoj juneja' > > > >CC: "'ccamp@ops.ietf.org'" > > > >Subject: RE: Lambda LSP Forwarding Adjacency Doubt > > > >Date: Tue, 4 Dec 2001 17:55:26 -0500 > > > > > > > >Manoj, > > > > > > > >The end points of the lambdapath in your example, nodes A to > > > D, are capable > > > >of establishing TDM services through it. Its probably > > > better referred as a > > > >TDM-FA, basically you have created a new TDM link between A > > > and D. For > > > >establishing TDM services on the new link, A and D in your > > > example should > > > >have a signaling peer relationship setup for the link. > > > Further TDM services > > > >would be set up as you would over any TDM link, by > > > exchanging TDM labels. > > > > > > > >-Debashis > > > > > > > >Accelight Networks > > > > > > > > > > > >-----Original Message----- > > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > >Sent: Tuesday, December 04, 2001 3:24 PM > > > >To: ccamp@ops.ietf.org > > > >Subject: Lambda LSP Forwarding Adjacency Doubt > > > > > > > > > > > >Hi All, > > > > If there are 4 nodes say A, B, C and D. There is a > > > Lambda FA > > > >established from A to D and if a new TDM LSP request=20 > comes to node A > > > >which is to be tunneled through the already established=20 > lambda FA-LSP > > > >then the node A sends the Path/label request message=20 > directly to node > > > >D. What label the node D will send back to node A in the=20 > RESV/label > > > >mapping message since the FA-LSP is just one label=20 > (lambda) ? Does it > > > >mean that all the LSPs which are tunneled through the=20 > lambda FA-LSP > > > >will be allocated the same label by node D to node A ? > > > > > > > >Please help. > > > > > > > >Regards, > > > >manoj. > > > > > > > = >_________________________________________________________________ > > > >Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > > > > > > > >=20 >=20 > _________________________________________________________________ > Get your FREE download of MSN Explorer at=20 http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2001 00:31:09 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , Heiles Juergen , ccamp@ops.ietf.org Subject: AW: AW: VC-4-64c as forwarding adjacency Date: Thu, 6 Dec 2001 09:26:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Manoj, this has nothing to do with forwarding adjacency. It is a restriction = of the transport plane. A VC-4 cannot be transported in a VC-4-64c. A = VC-4-64c supports IP, ATM, Ethernet as client signal, but not a VC-4 or = VC-3/2/12/11. So you can have a VC-4-64c forwarding adjacency for IP, ATM or Ethernet = clients. Juergen > -----Urspr=FCngliche Nachricht----- > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Gesendet: Mittwoch, 5. Dezember 2001 19:49 > An: juergen.heiles@icn.siemens.de; ccamp@ops.ietf.org > Betreff: Re: AW: VC-4-64c as forwarding adjacency >=20 >=20 > Hi Juergen, > Does this mean the forwarding adjacency concept is not=20 > applicable to concatenated signals/LSPs ? I hope forwarding=20 > adjacecny of=20 > virtual concatenated LSP should be allowed. >=20 > Regards, > manoj. >=20 >=20 > >From: "Juergen Heiles" > >To: "'manoj juneja'" ,=20 > > >Subject: AW: VC-4-64c as forwarding adjacency > >Date: Wed, 5 Dec 2001 10:19:03 +0100 > > > >No, that is not possible as you cannot transport a VC-4 in a=20 > VC-4-64c. A > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > > > >Juergen > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > > An: ccamp@ops.ietf.org > > > Betreff: VC-4-64c as forwarding adjacency > > > > > > > > > Hi All, > > > Can I tunnel a request for VC-4 LSP on VC-4-64c=20 > forwarding > > > adjacency ? If yes, then what would be the {suklm} ? > > > > > > Regards, > > > manoj > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > > > > > > > >=20 >=20 > _________________________________________________________________ > Get your FREE download of MSN Explorer at=20 http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 23:17:18 -0800 Message-ID: <007c01c17e25$4227f850$7264a8c0@hcltech.com> From: "Murugan .A" To: "Jonathan Lang" , Subject: Re: [IP-Optical] LMP: Link verification procedure suggestions. Date: Thu, 6 Dec 2001 12:41:21 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Jonathan Lang, When mappings are not known, the procedure to find mappings are not that straight forward. Some other pocedure over the LMP procedure is needed to find the mappings, which are not efficient and straight forward(this i have discussed in "IETF:" section of my earlier mail). Hence i have proposed some changes to LMP procedure itself(this i have discussed in "My suggestion:" section in my earlier mail). Let me take an example where LMP procedure fails. Both sender and receiver are capable of sending and receiving test messages sequentially ONLY. Let us have 4 interfaces in each side. Both the nodes dont know the interface mappings. The internal order in which the sender is going to send test messages is as follows S_interface_1 (using prefix S to denote sender) S_interface_2 S_interface_3 S_interface_4 The internal order in which the reciver is going to wait for receiving test messages is as follows R_interface_4 (using prefix R to denote Receiver) R_interface_3 R_interface_2 R_interface_1 The physical connection is as follows( in both directions) S_interface_1 <-> R_interface_1 S_interface_2 <-> R_interface_2 S_interface_3 <-> R_interface_3 S_interface_4 <-> R_interface_4 Now let us see what happens when testing is started with "Number of Data Links" set to 4. Receiver is waiting in R_interface_4 upto VerifyDeadInterval, but the sender sends test messages in S_interface_1 repearedly. The physical connection is between "S_interface_1 <-> R_interface_1" At the end of VerifyDeadInterval the receriver sends TestStatusFailure, now the sender will send estStatusAck( and move to the second link).. The Recever receives TestStatusAck( and move to the next link to listen) Now The Sender moves to S_interface_2, the receiver moves to R_interface_3. But the physical conenction is between "S_interface_2 <-> R_interface_2". Hence this also fails. Now The Sender moves to S_interface_3, the receiver moves to R_interface_2. But the physical conenction is between "S_interface_3 <-> R_interface_3". Hence this also fails. Now The Sender moves to S_interface_4, the receiver moves to R_interface_1. But the physical conenction is between "S_interface_4 <-> R_interface_4". Hence this also fails. The sender has received TestStatusFailure for all its four interfaces. Similarly the receiver has not received test messages in any of the interfaces as per the internal ordering in which it waited. Mapping is not found for any of the interfaces and the links state is down. If the internal ordering of sending and receiving test messages are configured as per the physical connection then the above procedure succeeds. But this is eqivalent to user/"any one" configuring the interface mapping. The LMP procedure doesnot find the interface mappings, it only check if the interface mappings provided by the user is correct or not Let me know if i have missed some thing. Thanks, Murugan Ramesh > >Hi, > > Giving below the test procedures followed by the IETF draft and my > suggestions for them. > > Both nodes exchange their testing capabilites(sequential/simultaneous) > through BeginVerify > > and BeginVerifyAck. > There is no notion of exchanging sequential/simultaneous testing > capabilities. The protocol is designed to support both capabilities without > negotiation. > > > > > The local node also sends if it has the interface mappings(not know > intially) in BeginVerify. > > When the mappings are known, if both nodes support's simultaneous testing, > simultaneous > > testing is done. > > > >If only one node support's simultaneous testing, then both nodes do > sequential testing with > >the know ordering. > > > > > >1) sender testing capability:sequential, receiver testing > capability:simultaneous, mappings > > are not known. > > IETF: > > Verification procedure is started with number of links to be tested equal > to all links in > > the TE/data set. Sender sends test message in one of the links(as per its > internal ordering). > > Receiver waits in all the links. > > > > Receiver may receive test message in just one of the links, for all other > links it will not > > receive test message within VerifyDeadInterval. At the end of > VerifyDeadInterval the remtoe > > node would have send TestStatusSuccess or TestStatusFailure for all the > links. > > > > The sender sends TestStatusAck for all the links. The verification > procedure is completed. > > > > At the end of this verification procedure mapping is found out for only > one link(provided > > beginVeryAck is received). > > The above procedure has to be repeated again and again unitl mapping is > found for all links. > No. The VerifyDeadInterval is set for *each* Test message. This is > configured at the receiving node and indicates that if a Test message is not > seen within the VerifyDeadInterval, the Test procedure has failed for that > data link. In your above example, once the receiver sees a Test message, it > sends a TestStatusSuccess message to the sender. If instead, the > VerifyDeadInterval is reached without receiving a Test message, A > TestStatusFailure message is sent. At this point, the sender can transmit a > new Test message down the next data link. > > > > >My suggestion: > > The sender informs the receiving side that it is capable of testing > sequentially only. It also > > informs the remote node that it doesnot have interface mappings. Receiver > sends BeginVerifyAck, > > with VerifyDeadInterval set to "locally configured VerifyDeadInterval for > single data link" > > * "no of links to be tested". > > The local node will send test messages in a interface sequentially for > every verify interval > > and the number of retries for an interface will be stopped based on local > configuration > >( retransmission count or timer). > > > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no > of links to be > > tested" for all interfaces. This time is enough to receive test message > send in any order > > over the links. > > > > 2) sender testing capability:sequential, receiver testing > capability:sequential, mappings are > > not known. > > > >IETF: > > Not clear how testing is done in this case. Since sender follows its own > ordering for sending > > test messages over different interfaces, where as the receiver follows its > own ordering > > waiting to receive test messages over interfaces. There is no correllation > of the ordering > > between the two. > The LMP procedure is the same as I described above. > > > > >My suggestion: > > The sender informs the receiving side that it is capable of testing > sequentially only. It also > > informs the remote node that it doesnot have interface mappings. > > > > The receiver also informs the sender that it is capable of doing testing > sequentially and sets > > VerifyDeadInterval to "locally configured VerifyDeadInterval for single > data link" * "no of > > links to be tested". > > > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no > of links to be > > tested" for one interface. After the end of this period it waits in the > next interface. > > > > The local node will send test messages in a interface sequentially for > every verify interval > > and the number of retries for an interface will be stopped based on local > configuration > > ( retransmission count or timer). At the end of this period it may know > mapping for just > > one link. Since the local node know that the remote node is only capable > of sequential testing > > the above procedure has to be repated. > > > >Thanks, > >Murugan > >Ramesh > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 15:14:34 -0800 From: "manoj juneja" To: kireeti@juniper.net, ccamp@ops.ietf.org, juergen.heiles@icn.siemens.de Bcc: Subject: Re: AW: VC-4-64c as forwarding adjacency Date: Wed, 05 Dec 2001 16:08:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Kireeti, I was thinking from the point of view that routing advertisement of VC-4-64c as a FA should not be allowed. Regards, manoj. >From: Kireeti Kompella >To: ccamp@ops.ietf.org, juergen.heiles@icn.siemens.de, >manojkumarjuneja@hotmail.com >Subject: Re: AW: VC-4-64c as forwarding adjacency >Date: Wed, 5 Dec 2001 15:00:59 -0800 (PST) > > > Does this mean the forwarding adjacency concept is not > > applicable to concatenated signals/LSPs ? > >Instead of misrepresenting FAs, why don't you read Juergen's mail again? > >Juergen wrote: > > >No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A > >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > >Nothing to do with FAs. Everything to do with VC-4-64c, emphasis on c. > >Kireeti. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 15:02:50 -0800 Date: Wed, 5 Dec 2001 15:00:59 -0800 (PST) From: Kireeti Kompella Message-Id: <200112052300.PAA25888@kummer.juniper.net> To: ccamp@ops.ietf.org, juergen.heiles@icn.siemens.de, manojkumarjuneja@hotmail.com Subject: Re: AW: VC-4-64c as forwarding adjacency > Does this mean the forwarding adjacency concept is not > applicable to concatenated signals/LSPs ? Instead of misrepresenting FAs, why don't you read Juergen's mail again? Juergen wrote: >No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A >VC-4-64c only supports dat clients like ATM, IP, Ethernet. Nothing to do with FAs. Everything to do with VC-4-64c, emphasis on c. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 13:09:41 -0800 Message-ID: From: Jonathan Lang To: "'Murugan .A'" , ccamp@ops.ietf.org Cc: rashanmu@npd.hcltech.com Subject: RE: [IP-Optical] LMP: Link verification procedure suggestions. Date: Wed, 5 Dec 2001 12:56:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Murugan, Please see inline. [Note, IPO list clipped to avoid cross-posting.] Thanks, Jonathan -----Original Message----- From: Murugan .A [mailto:mamirtha@npd.hcltech.com] Sent: Wednesday, December 05, 2001 5:58 AM To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com Cc: MURUGAN AMIRTHALINGAM; rashanmu@npd.hcltech.com Subject: [IP-Optical] LMP: Link verification procedure suggestions. >Hi, > Giving below the test procedures followed by the IETF draft and my suggestions for them. > Both nodes exchange their testing capabilites(sequential/simultaneous) through BeginVerify > and BeginVerifyAck. There is no notion of exchanging sequential/simultaneous testing capabilities. The protocol is designed to support both capabilities without negotiation. > > The local node also sends if it has the interface mappings(not know intially) in BeginVerify. > When the mappings are known, if both nodes support's simultaneous testing, simultaneous > testing is done. > >If only one node support's simultaneous testing, then both nodes do sequential testing with >the know ordering. > > >1) sender testing capability:sequential, receiver testing capability:simultaneous, mappings > are not known. > IETF: > Verification procedure is started with number of links to be tested equal to all links in > the TE/data set. Sender sends test message in one of the links(as per its internal ordering). > Receiver waits in all the links. > > Receiver may receive test message in just one of the links, for all other links it will not > receive test message within VerifyDeadInterval. At the end of VerifyDeadInterval the remtoe > node would have send TestStatusSuccess or TestStatusFailure for all the links. > > The sender sends TestStatusAck for all the links. The verification procedure is completed. > > At the end of this verification procedure mapping is found out for only one link(provided > beginVeryAck is received). > The above procedure has to be repeated again and again unitl mapping is found for all links. No. The VerifyDeadInterval is set for *each* Test message. This is configured at the receiving node and indicates that if a Test message is not seen within the VerifyDeadInterval, the Test procedure has failed for that data link. In your above example, once the receiver sees a Test message, it sends a TestStatusSuccess message to the sender. If instead, the VerifyDeadInterval is reached without receiving a Test message, A TestStatusFailure message is sent. At this point, the sender can transmit a new Test message down the next data link. > >My suggestion: > The sender informs the receiving side that it is capable of testing sequentially only. It also > informs the remote node that it doesnot have interface mappings. Receiver sends BeginVerifyAck, > with VerifyDeadInterval set to "locally configured VerifyDeadInterval for single data link" > * "no of links to be tested". > The local node will send test messages in a interface sequentially for every verify interval > and the number of retries for an interface will be stopped based on local configuration >( retransmission count or timer). > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no of links to be > tested" for all interfaces. This time is enough to receive test message send in any order > over the links. > > 2) sender testing capability:sequential, receiver testing capability:sequential, mappings are > not known. > >IETF: > Not clear how testing is done in this case. Since sender follows its own ordering for sending > test messages over different interfaces, where as the receiver follows its own ordering > waiting to receive test messages over interfaces. There is no correllation of the ordering > between the two. The LMP procedure is the same as I described above. > >My suggestion: > The sender informs the receiving side that it is capable of testing sequentially only. It also > informs the remote node that it doesnot have interface mappings. > > The receiver also informs the sender that it is capable of doing testing sequentially and sets > VerifyDeadInterval to "locally configured VerifyDeadInterval for single data link" * "no of > links to be tested". > > Remote node is waiting for "VerifyDeadInterval for single data link" * "no of links to be > tested" for one interface. After the end of this period it waits in the next interface. > > The local node will send test messages in a interface sequentially for every verify interval > and the number of retries for an interface will be stopped based on local configuration > ( retransmission count or timer). At the end of this period it may know mapping for just > one link. Since the local node know that the remote node is only capable of sequential testing > the above procedure has to be repated. > >Thanks, >Murugan >Ramesh Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 10:50:55 -0800 From: "manoj juneja" To: juergen.heiles@icn.siemens.de, D.Basak@Accelight.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: AW: Lambda LSP Forwarding Adjacency Doubt Date: Wed, 05 Dec 2001 11:50:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Juergen, The interface Id will be of forwarding adjacency (lambda Interface id). I have a doubt in label allocation. What label the node D will send to node A ? Regards, manoj. >From: "Juergen Heiles" >To: "'manoj juneja'" , > >CC: >Subject: AW: Lambda LSP Forwarding Adjacency Doubt >Date: Wed, 5 Dec 2001 10:18:49 +0100 > >For a TDM service you have to consider the specific signal format, for >example SDH or G.709 ODU. >I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique SUKLM numbering in >the lable in additon to the interface ID. If nodes A and D include TDM and >lambda switches the STM-N signal is no longer a interface (instead the WDM >signal is the interface), so I would assume that the ID of the lambda >FA-LSP >replaces the interface ID. > >Juergen > > > -----Ursprüngliche Nachricht----- > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Gesendet: Mittwoch, 5. Dezember 2001 00:24 > > An: D.Basak@Accelight.com > > Cc: ccamp@ops.ietf.org > > Betreff: RE: Lambda LSP Forwarding Adjacency Doubt > > > > > > Hi Debashis, > > In my example, A and D nodes are TDM and lambda switch > > capable but nodes B and C are lambda switch capable. I want to tunnel > > TDM LSP through the lambda LSP (established earlier and > > advertised as a > > FA). My question was how the label allocation be done at node > > D ? Is it > > that for all the incoming TDM LSPs requests that need to be tunneled > > through same lambda FA-LSP be assigned the same label at node D and > > sent bck to node A in RESV message ? If no, then how to assign the > > different labels to different LSPs that are to be tunneled through the > > same lambda FA-LSP. > > > > I think u are describing the case of how to tunnel LOVC LSP > > in HOVC LSP > > (HOVC LSP advertised as FA). > > > > Regards, > > manoj. > > > > > > >From: "Basak, Debashis" > > >To: 'manoj juneja' > > >CC: "'ccamp@ops.ietf.org'" > > >Subject: RE: Lambda LSP Forwarding Adjacency Doubt > > >Date: Tue, 4 Dec 2001 17:55:26 -0500 > > > > > >Manoj, > > > > > >The end points of the lambdapath in your example, nodes A to > > D, are capable > > >of establishing TDM services through it. Its probably > > better referred as a > > >TDM-FA, basically you have created a new TDM link between A > > and D. For > > >establishing TDM services on the new link, A and D in your > > example should > > >have a signaling peer relationship setup for the link. > > Further TDM services > > >would be set up as you would over any TDM link, by > > exchanging TDM labels. > > > > > >-Debashis > > > > > >Accelight Networks > > > > > > > > >-----Original Message----- > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > >Sent: Tuesday, December 04, 2001 3:24 PM > > >To: ccamp@ops.ietf.org > > >Subject: Lambda LSP Forwarding Adjacency Doubt > > > > > > > > >Hi All, > > > If there are 4 nodes say A, B, C and D. There is a > > Lambda FA > > >established from A to D and if a new TDM LSP request comes to node A > > >which is to be tunneled through the already established lambda FA-LSP > > >then the node A sends the Path/label request message directly to node > > >D. What label the node D will send back to node A in the RESV/label > > >mapping message since the FA-LSP is just one label (lambda) ? Does it > > >mean that all the LSPs which are tunneled through the lambda FA-LSP > > >will be allocated the same label by node D to node A ? > > > > > >Please help. > > > > > >Regards, > > >manoj. > > > > > >_________________________________________________________________ > > >Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 10:49:14 -0800 From: "manoj juneja" To: juergen.heiles@icn.siemens.de, ccamp@ops.ietf.org Bcc: Subject: Re: AW: VC-4-64c as forwarding adjacency Date: Wed, 05 Dec 2001 11:48:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Juergen, Does this mean the forwarding adjacency concept is not applicable to concatenated signals/LSPs ? I hope forwarding adjacecny of virtual concatenated LSP should be allowed. Regards, manoj. >From: "Juergen Heiles" >To: "'manoj juneja'" , >Subject: AW: VC-4-64c as forwarding adjacency >Date: Wed, 5 Dec 2001 10:19:03 +0100 > >No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A >VC-4-64c only supports dat clients like ATM, IP, Ethernet. > >Juergen > > > -----Ursprüngliche Nachricht----- > > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Gesendet: Dienstag, 4. Dezember 2001 23:44 > > An: ccamp@ops.ietf.org > > Betreff: VC-4-64c as forwarding adjacency > > > > > > Hi All, > > Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding > > adjacency ? If yes, then what would be the {suklm} ? > > > > Regards, > > manoj > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 10:46:20 -0800 From: "manoj juneja" To: Eric.Mannie@ebone.com, Juergen.Heiles@icn.siemens.de Cc: dimitri.papadimitriou@alcatel.be, kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format Date: Wed, 05 Dec 2001 11:44:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Eric, Agreeed. This special case of STM-0 should be mentioned in the drafts. Regards, manoj. >From: "Mannie, Eric" >To: 'manoj juneja' , >Juergen.Heiles@icn.siemens.de >CC: dimitri.papadimitriou@alcatel.be, kireeti@juniper.net >Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format >Date: Wed, 5 Dec 2001 19:34:01 +0100 > >Hi Manoj, > >I guess that I could simply write that for STM-0: S = 0 and U = 0. > >Since one knows the type of link (e.g. STM-0), you don't need more I think. > >About Juergen comments: > > >SONET and SDH have similar structures and using > >different {SUKLM} numbering schemes results in confusion and problems >like > >this that something is missing for one hierarchy. > >I'll clarify that at the IETF. The SONET label could be 100% different from >the SDH label that it would not change anything. There is NO >need/application for SDH to SONET label translation and vice versa. There >is >no reason to care about having similar formats since there is no need. The >only reason is for the beauty of the text. However, I am not against a nice >text, that's why we tried to have a similar label format, however this is >cosmetic. > > > I haven't seen a final decision concerning the {SUKLM} scheme so I have > >attached my proposal again. > >My personal final decision was to not change it. However, we need to see >the >consensus of the group during the next meeting. In any case, if someone ask >a modification he/she will have to justify the technical requirements or >reasons. > >Kind regards, > >Eric > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Wednesday, December 05, 2001 12:43 AM >To: Juergen.Heiles@icn.siemens.de >Cc: Mannie, Eric; dimitri.papadimitriou@alcatel.be; kireeti@juniper.net >Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format > > >Hi All, > If STM-0 signal can't be represented using {SUKLM} then >should not this be removed from the drafts ? > >Regards, >manoj. > > > >From: Heiles Juergen > >To: "'manoj juneja'" , ccamp@ops.ietf.org > >Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format > >Date: Tue, 20 Nov 2001 09:26:31 +0100 > > > >Manoj, > > > >indeed the STM-0 case is not covered in the current definition. This is >one > > >of the reasons for my proposed changes to the label definition I did sent > >out as a last call comment. SONET and SDH have similar structures and >using > > >different {SUKLM} numbering schemes results in confusion and problems >like > >this that something is missing for one hierarchy. > > I haven't seen a final decision concerning the {SUKLM} scheme so I have > >attached my proposal again. > > > >Juergen > > > > The format of the label for SDH and/or SONET TDM-LSR link is: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | S | U | K | L | M | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > For SDH, this is an extension of the numbering scheme defined in > > G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same > > signaling scheme is used in order to provide easy interworking >between > > SDH and SONET signaling. For the S field a STS-3 group, which > > corresponds with the SDH AUG-1 level is introduce. The U field > >indicates > > the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. > > > > Each letter indicates a possible branch number starting at the > > parent node in the multiplex structure. Branches are considered as > > numbered in increasing order, starting from the top of the > > multiplexing structure. The numbering starts at 1, zero is used to > > indicate a non-significant field. > > > > When a field is not significant in a particular context it MUST be > > set to zero when transmitted, and MUST be ignored when received. > > > > When hierarchical SDH/SONET LSPs are used, an LSP with a given > > bandwidth can be used to tunnel lower order LSPs. The higher > > order SDH/SONET LSP behaves as a virtual link with a given > > bandwidth (e.g. VC-3), it may also be used as a Forwarding > > Adjacency. A lower order SDH/SONET LSP can be established through > > that higher order LSP. Since a label is local to a (virtual) link, > > the highest part of that label is non-significant and is set to > > zero. > > > > For instance, a VC-3 LSP can be advertised as a forwarding > > adjacency. In that case the labels allocated between the two ends > > of that LSP (i.e. for that "link") will have S, U and K set to > > zero, i.e., non-significant, while L and M will be used to > > indicate the signal allocated in that VC-3. > > > > 1. S is the index of a particular AUG-1/STS-3 group. S=1->N > > indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN > > multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, > > and S=N indicates the last AUG-1/STS-3 group of this multiplex. > > S is not significant for STM-0/STS-1. > > > > 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 > > group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a > > AUG-1/STS-3 group or the single VC-3/STS-1-SPE in a STM-0/STS-1, > >while U=2->4 > > indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 > > group. > > > > 3. K is only significant for VC-4/STS-3c and must be ignored for > > higher order VC-3/STS-1-SPE. For SDH it indicates a specific branch > >of a VC-4. > > K=1 indicates that the VC-4 is not further subdivided and > > contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. > > For a SONET STS-3c-SPE it is fixed to K=1 as SONET doesn't support > > substructured STS-3c-SPE. > > > > 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. > > It is not significant for an unstructured VC-4/STS-3c-SPE. L=1 > > indicates that the TUG-3/VC-3/STS-1 SPE is not further > > subdivided and contains a VC-3/C-3 in SDH or the equivalent in > > SONET. L=2->8 indicates a specific TUG-2/VT Group inside the > > corresponding higher order signal. > > > > 5. M indicates a specific branch of a TUG-2/VT Group. It is not > > significant for an unstructured VC-4, STS-3c-SPE, TUG-3, VC-3 or > >STS-1 SPE. > > M=1 indicates that the TUG-2/VT Group is not further subdivided > > and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 > > inside the corresponding VT Group, these values MUST NOT be used > > for SDH since there is no equivalent of VT-3 with SDH. M=4->6 > > indicates a specific VC-12/VT-2 SPE inside the corresponding > > TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE > > inside the corresponding TUG-2/VT Group. Note that M=0 denotes > > an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). > > > > > > The M encoding is summarized in the following table: > > > > M SDH SONET > > ---------------------------------------------------------- > > 0 unstructured VC-4/VC-3 unstructured STS-1 SPE > > 1 VC-2 VT-6 > > 2 - 1st VT-3 > > 3 - 2nd VT-3 > > 4 1st VC-12 1st VT-2 > > 5 2nd VC-12 2nd VT-2 > > 6 3rd VC-12 3rd VT-2 > > 7 1st VC-11 1st VT-1.5 > > 8 2nd VC-11 2nd VT-1.5 > > 9 3rd VC-11 3rd VT-1.5 > > 10 4th VC-11 4th VT-1.5 > > > > In case of contiguous concatenation, the label that is used is the > > lowest label of the contiguously concatenated signal as explained > > before. The higher part of the label indicates where the signal > > starts and the lowest part is not significant. For instance, when > > requesting an VC-4-16c the label is S>0, U=0, K=0, L=0, M=0. > > > > Examples of labels: > > > > Example 1: S>0, U=1, K=1, L=0, M=0 > > Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 >group. > > > > Example 2: S>0, U=1, K>1, L=1, M=0 > > Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. > > > > Example 3: S>0, U>1, K=0, L=1, M=0 > > Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 > >group. > > > > Example 4: S>0, U>1, K=0, L>1, M=1 > > Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth >VC-3/STS-1 > >SPE of the Sth AUG-1/STS-3 group. > > > > Example 5: S>0, U>1, K=0, L>1, M=9 > > Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth > >VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. > > > > Example 6: S>0, U=1, K>1, L>1, M=5 > > Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 >of > >the Sth AUG-1. > > > > > > > -----Original Message----- > > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > Sent: Tuesday, November 20, 2001 1:49 AM > > > To: ccamp@ops.ietf.org > > > Subject: Representation of VC-3 in STM-0 in {SUKLM} format > > > > > > > > > Hi All, > > > If I have to allocate VC-3 on a STM-0 link then how to > > > represent it in {SUKLM}? As per gmpls-sdh-sonet draft, S is the index > > > of particular AUG-1 and can take values from 1 -> N. but there is no > > > AUG-1 in STM-0. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > > > > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 09:21:11 -0800 Message-ID: <031401c17db0$a8d2d4f0$7264a8c0@hcltech.com> From: "Murugan .A" To: , Subject: Fw: Link verification procedure suggestions( IETF sequential on both ends) Date: Wed, 5 Dec 2001 22:47:03 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0311_01C17DDE.C20DCAA0" This is a multi-part message in MIME format. ------=_NextPart_000_0311_01C17DDE.C20DCAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 > 2) sender testing capability:sequential, receiver testing = capability:sequential, mappings are not known. > > IETF: > Not clear how testing is done in this case. Since sender = follows its own ordering for=20 > sending test messages over different interfaces, where as the receiver = follows its own=20 > ordering waiting to receive test messages over interfaces.=20 > There is no correllation of the ordering between the two. With respect to IETF the following procedure can be followed: Sender does verification procedure repeatedly with "Number of Data = Links" set to one, until it gets a mapping from the remote side or there = are no more data links in the TE/Data set. In the sender side for each = repetetion test message is send on a different data link(as per local = preference). The receiver will wait on the same data link as per its = preference. For the sending side at the end of this procedure it could have got = mapping for a single data link. The above procedure has to be repeated with "Number of Data Links" set = to TWO, as the remote node will wait on the first interface for = VerifyDeadInterval and then wait on the second interface. Because the = receiver will always follow the same ordering as per its local = preference for untested links.=20 The sender will send test messages for the remaining data links. An optimization of the above procedure will be: Set the "Number of Data Links" to number of data links in the = TE/data set or the number of links to be tested. The sender will send = test messages sequentially(based on locally for the links as per its = internal ordering. The sender will send test messages in the fist = interface for the verify interval. Then it will send test messages in = the second interface. Once the above procedure is completed the sender will change it local = internal ordering. This can be done by moving the local interfaces in a = circular queue by ONE. After this the above procedure will be repeated. Thanks, Murugan ------=_NextPart_000_0311_01C17DDE.C20DCAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
       =20
> 2) = sender testing=20 capability:sequential, receiver testing capability:sequential, mappings = are not=20 known.
>
> IETF:
 >         = Not clear=20 how testing is done in this case. Since sender follows its own ordering = for=20
> sending test messages over = different=20 interfaces, where as the = receiver follows=20 its own
> ordering waiting to = receive test=20 messages over interfaces.
> There is no correllation of the = ordering=20 between the two.
 
        With=20 respect to IETF the following procedure can be followed:
 
    Sender does = verification=20 procedure repeatedly with "Number of Data = Links"=20 set to one, until it gets a mapping from the remote side or = there are=20 no more data links in the TE/Data set.  In the sender side for each = repetetion test message is = send on a=20 different data link(as per local preference). The receiver will wait on = the same=20 data link as per its preference.
 
For the sending side at  the end = of this=20 procedure it could have got mapping for a single data link.
The above procedure has to be repeated = with "Number=20 of Data Links" set to TWO, as the remote node will wait on the = first=20 interface for VerifyDeadInterval and then wait on the second interface. = Because=20 the receiver will always follow the same ordering as per its local = preference=20 for untested links.
The sender will send test messages for = the=20 remaining data links.
 
An optimization of the above procedure = will=20 be:
        Set the=20 "Number of Data Links" to number of data links in the TE/data set or = the number=20 of links to be tested. The sender will send test messages = sequentially(based on=20 locally  for the links as per its internal ordering. The sender = will send=20 test messages in the fist interface for the verify interval. Then it = will send=20 test messages in the second interface.
 
Once the above procedure is completed = the sender=20 will change it local internal ordering. This can be done by moving the = local=20 interfaces in a circular queue by ONE. After this the above procedure = will be=20 repeated.
 
Thanks,
Murugan
 
------=_NextPart_000_0311_01C17DDE.C20DCAA0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 06:13:50 -0800 Message-ID: <008a01c17d94$d13fdda0$7264a8c0@hcltech.com> From: "Murugan .A" To: , Cc: "MURUGAN AMIRTHALINGAM" , Subject: LMP: Link verification procedure suggestions. Date: Wed, 5 Dec 2001 19:27:34 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C17DC2.E3D180D0" This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C17DC2.E3D180D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Giving below the test procedures followed by the IETF draft and my = suggestions for them .=20 Both nodes exchange their testing = capabilites(sequential/simultaneous) through BeginVerify and = BeginVerifyAck. The local node also sends if it has the interface mappings(not know = intially) in BeginVerify.=20 When the mappings are known, if both nodes support's simultaneous = testing, simultaneous testing is done. If only one node support's simultaneous testing, then both nodes do = sequential testing with the know ordering. 1) sender testing capability:sequential, receiver testing = capability:simultaneous, mappings are not known. IETF: Verification procedure is started with number of links to be = tested equal to all links in the TE/data set. Sender sends test message = in one of the links(as per its internal ordering). Receiver waits in all = the links. =20 Receiver may receive test message in just one of the links, for all = other links it will not receive test message within VerifyDeadInterval. = At the end of VerifyDeadInterval the remtoe node would have send = TestStatusSuccess or TestStatusFailure for all the links. The sender = sends TestStatusAck for all the links. The verification procedure is = completed.=20 At the end of this verification procedure mapping is found out for only = one link(provided beginVeryAck is received). The above procedure has to be repeated again and again unitl mapping is = found for all links. My suggestion: The sender informs the receiving side that it is capable of = testing sequentially only. It also informs the remote node that it = doesnot have interface mappings. Receiver sends BeginVerifyAck, with = VerifyDeadInterval set to "locally configured VerifyDeadInterval for = single data link" * "no of links to be tested". The local node will send test messages in a interface = sequentially for every verify interval and the number of retries for an = interface will be stopped based on local configuration( retransmission = count or timer). Remote node is waiting for "VerifyDeadInterval for single data = link" * "no of links to be tested" for all interfaces. This time is = enough to receive test message send in any order over the links. 2) sender testing capability:sequential, receiver testing = capability:sequential, mappings are not known. IETF: Not clear how testing is done in this case. Since sender = follows its own ordering for sending test messages over different = interfaces, where as the receiver follows its own ordering waiting to = receive test messages over interfaces. There is no correllation of the = ordering between the two. My suggestion: The sender informs the receiving side that it is capable of = testing sequentially only. It also informs the remote node that it = doesnot have interface mappings. The receiver also informs the sender that it is capable of doing = testing sequentially and sets VerifyDeadInterval to "locally configured = VerifyDeadInterval for single data link" * "no of links to be tested". =20 Remote node is waiting for "VerifyDeadInterval for single data = link" * "no of links to be tested" for one interface. After the end of = this period it waits in the next interface. =20 The local node will send test messages in a interface sequentially = for every verify interval and the number of retries for an interface = will be stopped based on local configuration( retransmission count or = timer). At the end of this period it may know mapping for just one link. = Since the local node know that the remote node is only capable of = sequential testing the above procedure has to be repated. Thanks, Murugan Ramesh ------=_NextPart_000_0087_01C17DC2.E3D180D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    Giving below the = test=20 procedures  followed by the IETF draft and my suggestions for=20 them
 
.
     Both nodes = exchange their=20 testing capabilites(sequential/simultaneous) through BeginVerify and=20 BeginVerifyAck.
 
    The local node also = sends if it=20 has the interface mappings(not know intially) in BeginVerify. =
    When the mappings = are known, if=20 both nodes support's simultaneous testing, simultaneous testing is=20 done.
    If only one node = support's=20 simultaneous testing, then both nodes do sequential testing with the = know=20 ordering.
 
1) sender testing = capability:sequential, receiver=20 testing capability:simultaneous, mappings are not known.
    =20 IETF:
          &nbs= p;=20 Verification procedure is started with number of links to be tested = equal to all=20 links in the TE/data set. Sender sends test message in one of the = links(as per=20 its internal ordering). Receiver waits in all the links. =20
Receiver may receive test message in = just one of=20 the links, for all other links it will not receive test message within=20 VerifyDeadInterval. At the end of VerifyDeadInterval the remtoe node = would have=20 send  TestStatusSuccess or TestStatusFailure for all the links. The = sender=20 sends TestStatusAck for all the links. The verification procedure is = completed.=20
 
At the end of this verification = procedure mapping=20 is found out for only one link(provided beginVeryAck is = received).
The=20 above  procedure has to be repeated again and again unitl mapping = is found=20 for all links.
 
My suggestion:
        = The sender=20 informs the receiving side that it is capable of testing = sequentially only.=20 It also informs the remote node that = it doesnot=20 have interface mappings. Receiver sends BeginVerifyAck, with=20 VerifyDeadInterval  set to "locally configured =20 VerifyDeadInterval for single data link" * "no of links to be=20 tested".
      The = local node will=20 send test messages in a =20 interface sequentially for every verify = interval and=20 the number of retries for an = interface will be=20 stopped based on local configuration( retransmission  count or = timer).
     Remote = node is=20 waiting for "VerifyDeadInterval for single data link" * "no of = links to be=20 tested" for  all interfaces. This time is = enough to=20 receive test message send in any order over the links.
 
2) sender = testing=20 capability:sequential, receiver testing capability:sequential, mappings = are not=20 known.
 
IETF:
          Not = clear how=20 testing is done in this case. Since sender follows its own ordering for = sending=20 test messages over different interfaces, where as the receiver follows its own ordering waiting to=20 receive test messages over interfaces. There is no correllation of = the=20 ordering between the two.
 
My suggestion:
        = The sender=20 informs the receiving side that it is capable of testing = sequentially only.=20 It also informs the=20 remote node that it doesnot=20 have interface mappings.
       = The receiver=20 also informs the sender that it is capable of doing testing=20 sequentially and sets=20 VerifyDeadInterval to "locally configured  = VerifyDeadInterval for=20 single data link" * "no of links to be = tested".
 
      Remote node is=20 waiting for "VerifyDeadInterval for single data link" * "no of = links to be=20 tested" for one interface. After the end of this = period it=20 waits in the next interface.
      =
      The = local node will=20 send test messages in a=20 interface sequentially for every verify = interval and=20 the number of retries for an = interface will be=20 stopped based on local configuration( retransmission  count or = timer). At the end of this = period it may=20 know mapping for just one link. Since the local node know that the = remote node=20 is only capable of sequential testing the above procedure has to be=20 repated.
 
Thanks,
Murugan
Ramesh
------=_NextPart_000_0087_01C17DC2.E3D180D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 03:02:52 -0800 Message-ID: <3C0DFE44.126D64ED@alcatel.be> Date: Wed, 05 Dec 2001 12:00:20 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------1881898109D5420C5A141631" This is a multi-part message in MIME format. --------------1881898109D5420C5A141631 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, See in-line... Maarten Vissers wrote: > > Dimitri, > > I am not comparing the two methods. I am describing how LCAS operates the SEQ > IDs and how connection management has to support virtual concatenation with > LCAS. GMPLS is an implementation of distributed connection management, and must > therefore support what I described. This is what i was trying to demonstrate (see previous email). > In addition, connection management must support a means to perform the same > capabilities for the case one or both endpoints do not support LCAS, but allow > resizing the pipe. The proposal you made in your LBM document is much more > restrictive than LCAS capable implementations. It is up to the operators to > decide if these restrictions are acceptable. It is most likely a trade of > between less restrictions/more complex protocol and more restrictions/less > complex protocol. This is a first proposal be sure the next version will be improved. > Personally, I would like to compare two proposals: one that supports all LCAS > capabilities (except of course the hitless one), the other that includes > restrictions. If the complexity difference is not too large, go for the full > capabilities support, otherwise select the one with the restrictions. Agreed. But one should be in agreement in what we consider by "not too large" Regards, - dimitri. > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Maarten, > > > > First for people reading these e-mails the discussion here > > is not focused on a comparison between LCAS versus something > > else but only on control plane issues (more precisely which > > are the GMPLS mechanisms to be provided in order to enable > > bandwidth modification on different scenarios) > > > > Now, to continue the discussion we have defined in the GMPLS > > LBM I-D the Circuit ID and the LSP Sequence Number for that > > purpose (see Section 5.2). Together with the following rule: > > > > "All LSPs belonging to the same circuit MUST have the same > > Circuit ID. All LSPs MUST have a unique LSP sequence number > > in that Circuit ID, the LSP sequence number MUST be the > > sequence number of the first SPE/VC of the overall virtually > > concatenated circuit." > > > > Therefore, the scenarios you have defined are a combination > > of the methods described in Section 5.1 and 5.2. > > > > To illustrate this, let's take your example back: > > > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > > > VC-4 SNPs. > > > > > > VC-4 with G1 via route A > > > VC-4 with G2 via route A > > > VC-4 with G3 via route B > > > VC-4 with G4 via route B > > > VC-4 with G5 not connected > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > => Circuit ID #1 (for instance) will include LSP SEQ ID#0 > > and LSP SEQ ID#1 (here we assume that Route A is link > > diverse from Route B to preserve generality of the > > proposed method) > > > > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > > > the second one is via G4, then this one passes through the signal with SEQ ID=1. > > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > > > > > VC-4 with G1 via route A SEQ ID=3 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route B SEQ ID=2 > > > VC-4 with G4 via route B SEQ ID=1 > > > VC-4 with G5 not connected > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > => As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP > > SEQ ID#1 to the SEQ ID=0 > > > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > > > > > VC-4 with G1 via route A SEQ ID=3 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route B SEQ ID=2 > > > VC-4 with G4 via route B SEQ ID=1 > > > VC-4 with G5 via route A SEQ ID=4 > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > => To update the LSP SEQ#0 you follow the rules defined in > > the Section 5.1 > > > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > > > of SEQ ID, only there will be an indication not to transmit over those VC-4 > > > trails. If later on it is decided to continue over route A only, the SEQ IDs > > > are adapted as follows: > > > > > > VC-4 with G1 via route A SEQ ID=1 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 not connected > > > VC-4 with G4 not connected > > > VC-4 with G5 via route A SEQ ID=2 > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > => you delete the VC-4 components with the re-sequencing as described > > at the end of the Section 5.1 with the restriction that "SPEs/VCs > > can be removed from an LSP but only at the end of that LSP (i.e. > > starting at SPE/VC sequence number X)" > > > > > If the demand for bandwidth doubles again, it is possible to add say three more > > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > > > VC-4 with G1 via route A SEQ ID=1 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route C SEQ ID=4 > > > VC-4 with G4 via route C SEQ ID=5 > > > VC-4 with G5 via route A SEQ ID=2 > > > VC-4 with G6 via route C SEQ ID=3 > > > VC-4 with G7 not connected > > > > => once again you follow the rule described in Section 5.1 > > > > There is no need to use the multiplier for this purpose (this > > field is used for instance to operate a change on multiple LSP > > using the same message - it has been provided to avoid lengthy > > repetitions of the same operation) > > > > Once again (i think that Eric has already provided this comment) > > the scope of the LSP SEQ ID is not to reproduce the LCAS defined > > structures within the control plan but to provide a consistent > > control plane definition (allowing a level of consistency checking > > between the control plane and the transport plane.) > > > > Are we in agreement, or do you want further comparison of both > > methods ? > > > > Regards, > > - dimitri. > > > > Maarten Vissers wrote: > > > > > > Dimitri, > > > > > > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a > > > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed... > > > this is under control of LCAS and may change with time... > > > > > > When you set up the connection to transport the VC-4-4v signal via two routes > > > (A, B), two VC-4 termination points will be connected to the A route, two other > > > to the B route. > > > There are typically 7 VC-4 termination points per GbE port... let's refer to > > > those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1 > > > .. G7. > > > > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > > > VC-4 SNPs. > > > > > > VC-4 with G1 via route A > > > VC-4 with G2 via route A > > > VC-4 with G3 via route B > > > VC-4 with G4 via route B > > > VC-4 with G5 not connected > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > > > the second one is via G4, then this one passes through the signal with SEQ ID=1. > > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > > > > > VC-4 with G1 via route A SEQ ID=3 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route B SEQ ID=2 > > > VC-4 with G4 via route B SEQ ID=1 > > > VC-4 with G5 not connected > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > > > > > VC-4 with G1 via route A SEQ ID=3 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route B SEQ ID=2 > > > VC-4 with G4 via route B SEQ ID=1 > > > VC-4 with G5 via route A SEQ ID=4 > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > > > of SEQ ID, only there will be an indication not to transmit over those VC-4 > > > trails. If later on it is decided to continue over route A only, the SEQ IDs > > > are adapted as follows: > > > > > > VC-4 with G1 via route A SEQ ID=1 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 not connected > > > VC-4 with G4 not connected > > > VC-4 with G5 via route A SEQ ID=2 > > > VC-4 with G6 not connected > > > VC-4 with G7 not connected > > > > > > If the demand for bandwidth doubles again, it is possible to add say three more > > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > > > VC-4 with G1 via route A SEQ ID=1 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route C SEQ ID=4 > > > VC-4 with G4 via route C SEQ ID=5 > > > VC-4 with G5 via route A SEQ ID=2 > > > VC-4 with G6 via route C SEQ ID=3 > > > VC-4 with G7 not connected > > > > > > Looking at the connection setup details, I do not setup a VC-4-2v via A and > > > another VC-4-2v via B initially... I do setup two groups of two VC-4 > > > connections, which together support the VC-4-4v trail; a VC-4-4v is not the > > > same as two times a VC-4-2v. The use of NVC parameter here seems as such not > > > appropriate. The only alternative present is the MT field. > > > > > > Alternative is to redefine NVC as "This field indicates the number of identical > > > co-routed connections that are requested for this LSP. These connections are all > > > of the same type." > > > > > > But if I assume for a moment an alternative example in which the > > > virtual concatenated endpoints are outside of the network of > > > interest, then a UNI/E-NNI request using MT will result in the > > > same connections being setup compared to such request using the > > > modified NVC definition. What am I missing here? > > > > > > The traffic parameters for these two group-connections supporting the VC-4-Xv > > > trail are thus: > > > > > > initially: > > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > > > after 5th VC-4 trail addition: > > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > > > after route B connections being released: > > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > > > after 4th, 5th, 6th connection being added via route C: > > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > > > To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a > > > MODIFY message is required. In your LBM document you propose to signal the diff > > > value only, and consequently let the switch nodes compute the new total (i.e. > > > new = original + diff). It will work as well to signal the new value and let the > > > switch nodes compute the difference (i.e. diff = new - original). We need to > > > evaluate the pros/cons of both approaches before selecting one. > > > > > > When the group-connection via route B is removed, this group-connection has to > > > be released. > > > > > > When the group-connection via route C is to be added, this group-connection has > > > to be setup. > > > > > > In addition to these cases, the MODIFY message has to support also the decrease > > > case. E.g. assume that route A is more expensive than route C, then one would > > > obviously prefer to release a VC-4 connection via route A when the total > > > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s. > > > > > > after 3rd connection via route A is removed: > > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > > > VC-4 with G1 via route A SEQ ID=1 > > > VC-4 with G2 via route A SEQ ID=0 > > > VC-4 with G3 via route C SEQ ID=3 > > > VC-4 with G4 via route C SEQ ID=4 > > > VC-4 with G5 not connected > > > VC-4 with G6 via route C SEQ ID=2 > > > VC-4 with G7 not connected > > > > > > When using a MODIFY message which includes the new traffic parameters (and not > > > the diff ones), the same MODIFY message can be used for addition and removal of > > > connections to/from the group. This looks like a pro for a MODIFY message > > > definition including the new traffic parameters. > > > > > > One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a > > > single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to > > > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to > > > request the setup of two 2-group-connections to SNPP "G1-G7" and let the local > > > switch node decide which specific SNPs will be allocated. > > > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection, > > > and to add the 4/5/6th VC-4 connections via route C later on. > > > > > > I hope this clarifies some of the capabilities of the control plane needs to > > > support when a group-connection is to be modified, and the operation of the SEQ > > > ID within virtual concatenation with LCAS. > > > > > > Regards, > > > > > > Maarten > > > > > > Dimitri Papadimitriou wrote: > > > > > > > > Maarten, > > > > > > > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used > > > > for bandwidth increase purpose since it is used for a different > > > > semantic. > > > > > > > > SPEs/VCs can only be added at the end of an LSP. For instance, > > > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is > > > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the > > > > sequence numbered from 0 to X+Y-1. > > > > > > > > The number Y of SPEs/VCs to add is given by the following > > > > equation: new NVC - old NVC. The first new SPE/VC will have a > > > > sequence number equals to the sequence number of the previously > > > > last VC + 1 (i.e. X). > > > > > > > > In such a case (in your below example) > > > > > > > > - Connection X - A - Y traffic parameters > > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 > > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 > > > > > > > > remember that MT = 0 is an invalid value (as per draft-ietf-ccamp > > > > -gmpls-sonet-sdh-02.txt) > > > > > > > > The MT field in this picture is used in the following way (the > > > > number Y of SPEs/VCs to add is given by the following equation: > > > > (new NVC * new MT) - (old NVC * old MT) just notice that in most > > > > cases new MT will be equal to old MT): > > > > > > > > - 2 Connections X - A - Y traffic paramters > > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 > > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 > > > > > > > > Your second example is depicted in the section 5.2 of the > > > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use > > > > of the multiplier (MT) in that context is not recommended. > > > > > > > > Regards, > > > > - dimitri. > > > > > > > > Maarten Vissers wrote: > > > > > > > > > > Manoj, > > > > > > > > > > There is a difference between > > > > > 1) modifying the bandwidth of a connection and > > > > > 2) replacing the connection by a different connection. > > > > > > > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 > > > > > connection is a connection in a VC-4 network layer. These network layers are > > > > > independent, and as such you can only replace a VC-3 connection by a VC-4 > > > > > connection by releasing the VC-3 connection and requesting to set up a VC-4 > > > > > connection. > > > > > > > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT > > > > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. > > > > > > > > > > Example: Consider VC-4-Xv trail between nodes X and Y which > > > > > supports an Ethernet link between these two nodes. When X is > > > > > increased from 4 to 5, the Ethernet link bandwdith is increased > > > > > from 600 Mb/s to 750 Mbit/s. > > > > > > > > > > Assume that the VC-4-Xv trail is supported via two diverse > > > > > routes (X - A - Y and X - B - Y), each providing two VC-4 > > > > > connections. Then the bandwidth modification will increase > > > > > the number of connections on one of the two routes; e.g. the > > > > > route via A. The associated traffic parameters will be: > > > > > > > > > > - Connection X - A - Y traffic parameters > > > > > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 > > > > > - Connection X - B - Y traffic parameters (unchanged) > > > > > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > > > > > > > What is needed is a MODIFY request which allows for an identified connection to > > > > > modify the MT value. > > > > > > > > > > (*) Note that the parameter NVC is interpreted as to represent the number of > > > > > components in a virtual concatenated signal connection... in this example NVC=4 > > > > > and grows to NVC=5. As the virtual concatenated signal is transported via two > > > > > routes, each having half of the member connections, I have the impression that > > > > > MT is the parameter to use. > > > > > > > > > > Or to turn this around and look at the source for the bandwidth modification > > > > > first, we may assume that over the e.g. Ethernet UNI the call controller > > > > > (G.8080) at the network side receives a request to increase the enthernet link > > > > > from 600 to 750 Mbit/s. The call controller then decides to support this > > > > > ehternet bandwidth modification request by means of a modification of the > > > > > group-connection via route A... it then issues a connection modification request > > > > > for this group-connection... etc. > > > > > > > > > > Add 1) True bandwidth modification of an individual connection is possible for > > > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS > > > > > links (G.805) over which the connection is transported have spare capacity, the > > > > > bandwidth of an individual VP, VC or LSP can be increased. > > > > > > > > > > Regards, > > > > > > > > > > Maarten > > > > > > > > > > manoj juneja wrote: > > > > > > > > > > > > Hi All, > > > > > > If the bandwidth modification is not supported by GMPLS then > > > > > > it should be clearly mentioned in the drafts (at least the architecture > > > > > > draft). Please see the attached mail for reference. > > > > > > > > > > > > I am still not clear whether GMPLS supports SE-style of reservation. > > > > > > My original question related to SE-style of reservation was and I didn't > > > > > > get any reply on the mailing list : > > > > > > > > > > > > " I have a doubt related to SE style of reservation in GMPLS. As > > > > > > in RSVP-TE, multiple senders can share the reservation but they can be > > > > > > assigned different labels to distinguish different senders from one > > > > > > other. > > > > > > In GMPLS, as the label itself is a resource on the link, it means that > > > > > > if there are multiple senders in the same session sharing reservation, > > > > > > they should be assigned the same label. They can't be assigned > > > > > > different labels or is it that GMPLS does not support SE style of > > > > > > reservation ?" > > > > > > > > > > > > Please correct me if I am missing something. > > > > > > > > > > > > Regards, > > > > > > manoj. > > > > > > > > > > > > >From: Maarten Vissers > > > > > > >To: manoj juneja > > > > > > >CC: ccamp@ops.ietf.org > > > > > > >Subject: Re: Bandwidth modification in GMPLS > > > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > > > > > > > > > >Manoj, > > > > > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > > > > > Hi All, > > > > > > > > Is it possible to modify/increase the bandwidth of an existing > > > > > > >GMPLS > > > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > > > > > > >possible to > > > > > > > > increase the bandwidth to say VC-4 ? > > > > > > > > > > > > > >No, this is not possible. > > > > > > > > > > > > > >Regards, > > > > > > > > > > > > > >Maarten > > > > > > > > > > > > > > > > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > > > > > > > > > > > Regards, > > > > > > > > manoj. > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > > Get your FREE download of MSN Explorer at > > > > > > >http://explorer.msn.com/intl.asp > > > > > > ><< mvissers.vcf >> > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------1881898109D5420C5A141631 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------1881898109D5420C5A141631-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 02:09:55 -0800 Message-ID: <3C0DF182.37AA89E6@alcatel.fr> Date: Wed, 05 Dec 2001 11:05:54 +0100 From: Richard Douville Organization: Alcatel R&I - URP MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: draft-douville-ccamp-gmpls-waveband-extensions-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, We have posted the following draft: "Extensions to GMPLS for Waveband Switching", http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-00.txt We proposed band-dedicated extensions to GMPLS protocols including support of waveband interface component in optical networks as defined in the http://www.ietf.org/internet-drafts/draft-dotaro-ipo-optical-multi-granularity-01.txt . Looking forward to comments. Regards, Richard Douville -- Richard Douville Richard.Douville@alcatel.fr Alcatel Research & Innovation Photonic Networks Unit, URP Route de Nozay Tel: 33-1-69.63.44.31 F-91460 Marcoussis, France. Fax: 33-1-69.63.18.65 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 01:23:08 -0800 From: "Juergen Heiles" To: "'manoj juneja'" , Cc: Subject: AW: Lambda LSP Forwarding Adjacency Doubt Date: Wed, 5 Dec 2001 10:18:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit For a TDM service you have to consider the specific signal format, for example SDH or G.709 ODU. I ncase of SDH each LSP (e.g. VC-4, VC-12) has a unique SUKLM numbering in the lable in additon to the interface ID. If nodes A and D include TDM and lambda switches the STM-N signal is no longer a interface (instead the WDM signal is the interface), so I would assume that the ID of the lambda FA-LSP replaces the interface ID. Juergen > -----Ursprüngliche Nachricht----- > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Gesendet: Mittwoch, 5. Dezember 2001 00:24 > An: D.Basak@Accelight.com > Cc: ccamp@ops.ietf.org > Betreff: RE: Lambda LSP Forwarding Adjacency Doubt > > > Hi Debashis, > In my example, A and D nodes are TDM and lambda switch > capable but nodes B and C are lambda switch capable. I want to tunnel > TDM LSP through the lambda LSP (established earlier and > advertised as a > FA). My question was how the label allocation be done at node > D ? Is it > that for all the incoming TDM LSPs requests that need to be tunneled > through same lambda FA-LSP be assigned the same label at node D and > sent bck to node A in RESV message ? If no, then how to assign the > different labels to different LSPs that are to be tunneled through the > same lambda FA-LSP. > > I think u are describing the case of how to tunnel LOVC LSP > in HOVC LSP > (HOVC LSP advertised as FA). > > Regards, > manoj. > > > >From: "Basak, Debashis" > >To: 'manoj juneja' > >CC: "'ccamp@ops.ietf.org'" > >Subject: RE: Lambda LSP Forwarding Adjacency Doubt > >Date: Tue, 4 Dec 2001 17:55:26 -0500 > > > >Manoj, > > > >The end points of the lambdapath in your example, nodes A to > D, are capable > >of establishing TDM services through it. Its probably > better referred as a > >TDM-FA, basically you have created a new TDM link between A > and D. For > >establishing TDM services on the new link, A and D in your > example should > >have a signaling peer relationship setup for the link. > Further TDM services > >would be set up as you would over any TDM link, by > exchanging TDM labels. > > > >-Debashis > > > >Accelight Networks > > > > > >-----Original Message----- > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > >Sent: Tuesday, December 04, 2001 3:24 PM > >To: ccamp@ops.ietf.org > >Subject: Lambda LSP Forwarding Adjacency Doubt > > > > > >Hi All, > > If there are 4 nodes say A, B, C and D. There is a > Lambda FA > >established from A to D and if a new TDM LSP request comes to node A > >which is to be tunneled through the already established lambda FA-LSP > >then the node A sends the Path/label request message directly to node > >D. What label the node D will send back to node A in the RESV/label > >mapping message since the FA-LSP is just one label (lambda) ? Does it > >mean that all the LSPs which are tunneled through the lambda FA-LSP > >will be allocated the same label by node D to node A ? > > > >Please help. > > > >Regards, > >manoj. > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 01:22:41 -0800 From: "Juergen Heiles" To: "'manoj juneja'" , Subject: AW: VC-4-64c as forwarding adjacency Date: Wed, 5 Dec 2001 10:19:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit No, that is not possible as you cannot transport a VC-4 in a VC-4-64c. A VC-4-64c only supports dat clients like ATM, IP, Ethernet. Juergen > -----Ursprüngliche Nachricht----- > Von: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Gesendet: Dienstag, 4. Dezember 2001 23:44 > An: ccamp@ops.ietf.org > Betreff: VC-4-64c as forwarding adjacency > > > Hi All, > Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding > adjacency ? If yes, then what would be the {suklm} ? > > Regards, > manoj > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2001 00:21:51 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Fwd: LSC Interface Doubt ... Date: Wed, 05 Dec 2001 01:20:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If I need to establish a bi-directional LSC LSP then do I need to configure the remote end wavelengths on an LSC interface ? Is there any case where both the upstream and downstream labels of an bi-directional LSC LSP be same ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 16:41:23 -0800 Date: Tue, 4 Dec 2001 16:38:32 -0800 (PST) From: Kireeti Kompella To: manoj juneja cc: ccamp@ops.ietf.org Subject: Re: Lambda LSP Forwarding Adjacency Doubt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 4 Dec 2001, Yangguang Xu wrote: > In this case A and D are neighbors in the TDM network. So A and D need to build > up TDM label mapping table between them over the new interfaces connected > through the Lambda FA-LSP. The TDM labels are at a different space from the > Lambda labels. They are at different logical layers. What he said. And what Debashis said. Not what George Young said. > Thanks a lot for the immediate reply. Does this mean that concept > of forwarding adjacency is not applicable for FSC/LSC interfaces > presently? That would be the ultimate irony. FAs, while useful for 'regular' MPLS, were really conceived for GMPLS (i.e., non-packet LSPs). Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 15:24:38 -0800 From: "manoj juneja" To: D.Basak@Accelight.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 04 Dec 2001 16:23:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Debashis, In my example, A and D nodes are TDM and lambda switch capable but nodes B and C are lambda switch capable. I want to tunnel TDM LSP through the lambda LSP (established earlier and advertised as a FA). My question was how the label allocation be done at node D ? Is it that for all the incoming TDM LSPs requests that need to be tunneled through same lambda FA-LSP be assigned the same label at node D and sent bck to node A in RESV message ? If no, then how to assign the different labels to different LSPs that are to be tunneled through the same lambda FA-LSP. I think u are describing the case of how to tunnel LOVC LSP in HOVC LSP (HOVC LSP advertised as FA). Regards, manoj. >From: "Basak, Debashis" >To: 'manoj juneja' >CC: "'ccamp@ops.ietf.org'" >Subject: RE: Lambda LSP Forwarding Adjacency Doubt >Date: Tue, 4 Dec 2001 17:55:26 -0500 > >Manoj, > >The end points of the lambdapath in your example, nodes A to D, are capable >of establishing TDM services through it. Its probably better referred as a >TDM-FA, basically you have created a new TDM link between A and D. For >establishing TDM services on the new link, A and D in your example should >have a signaling peer relationship setup for the link. Further TDM services >would be set up as you would over any TDM link, by exchanging TDM labels. > >-Debashis > >Accelight Networks > > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Tuesday, December 04, 2001 3:24 PM >To: ccamp@ops.ietf.org >Subject: Lambda LSP Forwarding Adjacency Doubt > > >Hi All, > If there are 4 nodes say A, B, C and D. There is a Lambda FA >established from A to D and if a new TDM LSP request comes to node A >which is to be tunneled through the already established lambda FA-LSP >then the node A sends the Path/label request message directly to node >D. What label the node D will send back to node A in the RESV/label >mapping message since the FA-LSP is just one label (lambda) ? Does it >mean that all the LSPs which are tunneled through the lambda FA-LSP >will be allocated the same label by node D to node A ? > >Please help. > >Regards, >manoj. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 15:11:17 -0800 From: "manoj juneja" To: xuyg@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 04 Dec 2001 16:08:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Yangguang, How the TDM mapping be established at nodes A and D ? There is no signalling for this. I am not aware of any draft that talks of such kind of mapping. Can u please point me to appropriate text in the drafts ? Regards, manoj. >From: Yangguang Xu >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Lambda LSP Forwarding Adjacency Doubt >Date: Tue, 04 Dec 2001 18:00:28 -0500 > > > >manoj, > > > > >Hi All, > > > > If there are 4 nodes say A, B, C and D. There is a Lambda FA > > > >established from A to D and if a new TDM LSP request comes to node A > > > >which is to be tunneled through the already established lambda FA-LSP > > > >then the node A sends the Path/label request message directly to node > > > >D. What label the node D will send back to node A in the RESV/label > > > >mapping message since the FA-LSP is just one label (lambda) ? Does it > > > >mean that all the LSPs which are tunneled through the lambda FA-LSP > > > >will be allocated the same label by node D to node A ? > > > > > >In this case A and D are neighbors in the TDM network. So A and D need to >build >up TDM label mapping table between them over the new interfaces connected >through the Lambda FA-LSP. The TDM labels are at a different space from the >Lambda labels. They are at different logical layers. > >Regards, > >Yangguang _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 15:05:44 -0800 Message-ID: <3C0D558C.11F984B@lucent.com> Date: Tue, 04 Dec 2001 18:00:28 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org Subject: Re: Lambda LSP Forwarding Adjacency Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit manoj, > > >Hi All, > > > If there are 4 nodes say A, B, C and D. There is a Lambda FA > > >established from A to D and if a new TDM LSP request comes to node A > > >which is to be tunneled through the already established lambda FA-LSP > > >then the node A sends the Path/label request message directly to node > > >D. What label the node D will send back to node A in the RESV/label > > >mapping message since the FA-LSP is just one label (lambda) ? Does it > > >mean that all the LSPs which are tunneled through the lambda FA-LSP > > >will be allocated the same label by node D to node A ? > > > In this case A and D are neighbors in the TDM network. So A and D need to build up TDM label mapping table between them over the new interfaces connected through the Lambda FA-LSP. The TDM labels are at a different space from the Lambda labels. They are at different logical layers. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 14:59:38 -0800 Message-ID: From: "Basak, Debashis" To: 'manoj juneja' Cc: "'ccamp@ops.ietf.org'" Subject: RE: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 4 Dec 2001 17:55:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, The end points of the lambdapath in your example, nodes A to D, are capable of establishing TDM services through it. Its probably better referred as a TDM-FA, basically you have created a new TDM link between A and D. For establishing TDM services on the new link, A and D in your example should have a signaling peer relationship setup for the link. Further TDM services would be set up as you would over any TDM link, by exchanging TDM labels. -Debashis Accelight Networks -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Tuesday, December 04, 2001 3:24 PM To: ccamp@ops.ietf.org Subject: Lambda LSP Forwarding Adjacency Doubt Hi All, If there are 4 nodes say A, B, C and D. There is a Lambda FA established from A to D and if a new TDM LSP request comes to node A which is to be tunneled through the already established lambda FA-LSP then the node A sends the Path/label request message directly to node D. What label the node D will send back to node A in the RESV/label mapping message since the FA-LSP is just one label (lambda) ? Does it mean that all the LSPs which are tunneled through the lambda FA-LSP will be allocated the same label by node D to node A ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 14:46:38 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: VC-4-64c as forwarding adjacency Date: Tue, 04 Dec 2001 15:44:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Can I tunnel a request for VC-4 LSP on VC-4-64c forwarding adjacency ? If yes, then what would be the {suklm} ? Regards, manoj _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 14:19:57 -0800 From: "manoj juneja" To: george.young@meriton.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 04 Dec 2001 15:16:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi George, Thanks a lot for the immediate reply. Does this mean that concept of forwarding adjacency is not applicable for FSC/LSC interfaces presently ? Regards, manoj. >From: "George Young" >To: "manoj juneja" >CC: >Subject: RE: Lambda LSP Forwarding Adjacency Doubt >Date: Tue, 4 Dec 2001 16:05:08 -0500 > >Hello Manoj, > >The use of a label to designate a circuit mode connection works well in >a homogeneous network (e.g. everybody switching OC-48 paths). > >If the OC-48 switched network is itself obtaining connections from (say) >a lambda-switched network, the lambda-switched network should have its >own set of labels mapping to lambda connections. The concept of label >stacking doesn't seem to carry over well from the packet world. > >There's work that I'm familiar with just starting in OIF on this >inter-layer cooperation, under the NNI project. ITU has also done work >in this area. > >Regards, >George R. Young >Meriton Networks Inc. >329 March Rd., Kanata, ON, Canada, K2K 2E1 >phone: +1 613-270-9279 Ext 287 >fax: +1 613-270-9268 > > > >-----Original Message----- > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > >Sent: Tuesday, December 04, 2001 3:24 PM > >To: ccamp@ops.ietf.org > >Subject: Lambda LSP Forwarding Adjacency Doubt > > > > > >Hi All, > > If there are 4 nodes say A, B, C and D. There is a Lambda FA > >established from A to D and if a new TDM LSP request comes to node A > >which is to be tunneled through the already established lambda FA-LSP > >then the node A sends the Path/label request message directly to node > >D. What label the node D will send back to node A in the RESV/label > >mapping message since the FA-LSP is just one label (lambda) ? Does it > >mean that all the LSPs which are tunneled through the lambda FA-LSP > >will be allocated the same label by node D to node A ? > > > >Please help. > > > >Regards, > >manoj. > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 13:05:53 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 4 Dec 2001 16:05:08 -0500 Message-ID: Thread-Topic: Lambda LSP Forwarding Adjacency Doubt Thread-Index: AcF9BIIGJ4rSqrCZSea71rcQLxl6ogAAcFfg From: "George Young" To: "manoj juneja" Cc: Hello Manoj, The use of a label to designate a circuit mode connection works well in a homogeneous network (e.g. everybody switching OC-48 paths). If the OC-48 switched network is itself obtaining connections from (say) a lambda-switched network, the lambda-switched network should have its own set of labels mapping to lambda connections. The concept of label stacking doesn't seem to carry over well from the packet world. There's work that I'm familiar with just starting in OIF on this inter-layer cooperation, under the NNI project. ITU has also done work in this area. Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Tuesday, December 04, 2001 3:24 PM >To: ccamp@ops.ietf.org >Subject: Lambda LSP Forwarding Adjacency Doubt > > >Hi All, > If there are 4 nodes say A, B, C and D. There is a Lambda FA >established from A to D and if a new TDM LSP request comes to node A >which is to be tunneled through the already established lambda FA-LSP >then the node A sends the Path/label request message directly to node >D. What label the node D will send back to node A in the RESV/label >mapping message since the FA-LSP is just one label (lambda) ? Does it >mean that all the LSPs which are tunneled through the lambda FA-LSP >will be allocated the same label by node D to node A ? > >Please help. > >Regards, >manoj. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at=20 >http://explorer.msn.com/intl.asp > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 12:27:22 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Lambda LSP Forwarding Adjacency Doubt Date: Tue, 04 Dec 2001 13:24:15 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If there are 4 nodes say A, B, C and D. There is a Lambda FA established from A to D and if a new TDM LSP request comes to node A which is to be tunneled through the already established lambda FA-LSP then the node A sends the Path/label request message directly to node D. What label the node D will send back to node A in the RESV/label mapping message since the FA-LSP is just one label (lambda) ? Does it mean that all the LSPs which are tunneled through the lambda FA-LSP will be allocated the same label by node D to node A ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2001 03:46:46 -0800 Cc: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Message-ID: <3C0CB531.F6CE6351@lucent.com> Date: Tue, 04 Dec 2001 12:36:17 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------28B3AE269E886FB78A163294" This is a multi-part message in MIME format. --------------28B3AE269E886FB78A163294 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, I am not comparing the two methods. I am describing how LCAS operates the SEQ IDs and how connection management has to support virtual concatenation with LCAS. GMPLS is an implementation of distributed connection management, and must therefore support what I described. In addition, connection management must support a means to perform the same capabilities for the case one or both endpoints do not support LCAS, but allow resizing the pipe. The proposal you made in your LBM document is much more restrictive than LCAS capable implementations. It is up to the operators to decide if these restrictions are acceptable. It is most likely a trade of between less restrictions/more complex protocol and more restrictions/less complex protocol. Personally, I would like to compare two proposals: one that supports all LCAS capabilities (except of course the hitless one), the other that includes restrictions. If the complexity difference is not too large, go for the full capabilities support, otherwise select the one with the restrictions. Regards, Maarten Dimitri Papadimitriou wrote: > > Maarten, > > First for people reading these e-mails the discussion here > is not focused on a comparison between LCAS versus something > else but only on control plane issues (more precisely which > are the GMPLS mechanisms to be provided in order to enable > bandwidth modification on different scenarios) > > Now, to continue the discussion we have defined in the GMPLS > LBM I-D the Circuit ID and the LSP Sequence Number for that > purpose (see Section 5.2). Together with the following rule: > > "All LSPs belonging to the same circuit MUST have the same > Circuit ID. All LSPs MUST have a unique LSP sequence number > in that Circuit ID, the LSP sequence number MUST be the > sequence number of the first SPE/VC of the overall virtually > concatenated circuit." > > Therefore, the scenarios you have defined are a combination > of the methods described in Section 5.1 and 5.2. > > To illustrate this, let's take your example back: > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > > VC-4 SNPs. > > > > VC-4 with G1 via route A > > VC-4 with G2 via route A > > VC-4 with G3 via route B > > VC-4 with G4 via route B > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > => Circuit ID #1 (for instance) will include LSP SEQ ID#0 > and LSP SEQ ID#1 (here we assume that Route A is link > diverse from Route B to preserve generality of the > proposed method) > > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > > the second one is via G4, then this one passes through the signal with SEQ ID=1. > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > => As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP > SEQ ID#1 to the SEQ ID=0 > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 via route A SEQ ID=4 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > => To update the LSP SEQ#0 you follow the rules defined in > the Section 5.1 > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > > of SEQ ID, only there will be an indication not to transmit over those VC-4 > > trails. If later on it is decided to continue over route A only, the SEQ IDs > > are adapted as follows: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 not connected > > VC-4 with G4 not connected > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > => you delete the VC-4 components with the re-sequencing as described > at the end of the Section 5.1 with the restriction that "SPEs/VCs > can be removed from an LSP but only at the end of that LSP (i.e. > starting at SPE/VC sequence number X)" > > > If the demand for bandwidth doubles again, it is possible to add say three more > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=4 > > VC-4 with G4 via route C SEQ ID=5 > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 via route C SEQ ID=3 > > VC-4 with G7 not connected > > => once again you follow the rule described in Section 5.1 > > There is no need to use the multiplier for this purpose (this > field is used for instance to operate a change on multiple LSP > using the same message - it has been provided to avoid lengthy > repetitions of the same operation) > > Once again (i think that Eric has already provided this comment) > the scope of the LSP SEQ ID is not to reproduce the LCAS defined > structures within the control plan but to provide a consistent > control plane definition (allowing a level of consistency checking > between the control plane and the transport plane.) > > Are we in agreement, or do you want further comparison of both > methods ? > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Dimitri, > > > > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a > > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed... > > this is under control of LCAS and may change with time... > > > > When you set up the connection to transport the VC-4-4v signal via two routes > > (A, B), two VC-4 termination points will be connected to the A route, two other > > to the B route. > > There are typically 7 VC-4 termination points per GbE port... let's refer to > > those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1 > > .. G7. > > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > > VC-4 SNPs. > > > > VC-4 with G1 via route A > > VC-4 with G2 via route A > > VC-4 with G3 via route B > > VC-4 with G4 via route B > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > > the second one is via G4, then this one passes through the signal with SEQ ID=1. > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 via route A SEQ ID=4 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > > of SEQ ID, only there will be an indication not to transmit over those VC-4 > > trails. If later on it is decided to continue over route A only, the SEQ IDs > > are adapted as follows: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 not connected > > VC-4 with G4 not connected > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > If the demand for bandwidth doubles again, it is possible to add say three more > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=4 > > VC-4 with G4 via route C SEQ ID=5 > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 via route C SEQ ID=3 > > VC-4 with G7 not connected > > > > Looking at the connection setup details, I do not setup a VC-4-2v via A and > > another VC-4-2v via B initially... I do setup two groups of two VC-4 > > connections, which together support the VC-4-4v trail; a VC-4-4v is not the > > same as two times a VC-4-2v. The use of NVC parameter here seems as such not > > appropriate. The only alternative present is the MT field. > > > > Alternative is to redefine NVC as "This field indicates the number of identical > > co-routed connections that are requested for this LSP. These connections are all > > of the same type." > > > > But if I assume for a moment an alternative example in which the > > virtual concatenated endpoints are outside of the network of > > interest, then a UNI/E-NNI request using MT will result in the > > same connections being setup compared to such request using the > > modified NVC definition. What am I missing here? > > > > The traffic parameters for these two group-connections supporting the VC-4-Xv > > trail are thus: > > > > initially: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > after 5th VC-4 trail addition: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > after route B connections being released: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > after 4th, 5th, 6th connection being added via route C: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a > > MODIFY message is required. In your LBM document you propose to signal the diff > > value only, and consequently let the switch nodes compute the new total (i.e. > > new = original + diff). It will work as well to signal the new value and let the > > switch nodes compute the difference (i.e. diff = new - original). We need to > > evaluate the pros/cons of both approaches before selecting one. > > > > When the group-connection via route B is removed, this group-connection has to > > be released. > > > > When the group-connection via route C is to be added, this group-connection has > > to be setup. > > > > In addition to these cases, the MODIFY message has to support also the decrease > > case. E.g. assume that route A is more expensive than route C, then one would > > obviously prefer to release a VC-4 connection via route A when the total > > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s. > > > > after 3rd connection via route A is removed: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=3 > > VC-4 with G4 via route C SEQ ID=4 > > VC-4 with G5 not connected > > VC-4 with G6 via route C SEQ ID=2 > > VC-4 with G7 not connected > > > > When using a MODIFY message which includes the new traffic parameters (and not > > the diff ones), the same MODIFY message can be used for addition and removal of > > connections to/from the group. This looks like a pro for a MODIFY message > > definition including the new traffic parameters. > > > > One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a > > single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to > > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to > > request the setup of two 2-group-connections to SNPP "G1-G7" and let the local > > switch node decide which specific SNPs will be allocated. > > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection, > > and to add the 4/5/6th VC-4 connections via route C later on. > > > > I hope this clarifies some of the capabilities of the control plane needs to > > support when a group-connection is to be modified, and the operation of the SEQ > > ID within virtual concatenation with LCAS. > > > > Regards, > > > > Maarten > > > > Dimitri Papadimitriou wrote: > > > > > > Maarten, > > > > > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used > > > for bandwidth increase purpose since it is used for a different > > > semantic. > > > > > > SPEs/VCs can only be added at the end of an LSP. For instance, > > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is > > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the > > > sequence numbered from 0 to X+Y-1. > > > > > > The number Y of SPEs/VCs to add is given by the following > > > equation: new NVC - old NVC. The first new SPE/VC will have a > > > sequence number equals to the sequence number of the previously > > > last VC + 1 (i.e. X). > > > > > > In such a case (in your below example) > > > > > > - Connection X - A - Y traffic parameters > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 > > > > > > remember that MT = 0 is an invalid value (as per draft-ietf-ccamp > > > -gmpls-sonet-sdh-02.txt) > > > > > > The MT field in this picture is used in the following way (the > > > number Y of SPEs/VCs to add is given by the following equation: > > > (new NVC * new MT) - (old NVC * old MT) just notice that in most > > > cases new MT will be equal to old MT): > > > > > > - 2 Connections X - A - Y traffic paramters > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 > > > > > > Your second example is depicted in the section 5.2 of the > > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use > > > of the multiplier (MT) in that context is not recommended. > > > > > > Regards, > > > - dimitri. > > > > > > Maarten Vissers wrote: > > > > > > > > Manoj, > > > > > > > > There is a difference between > > > > 1) modifying the bandwidth of a connection and > > > > 2) replacing the connection by a different connection. > > > > > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 > > > > connection is a connection in a VC-4 network layer. These network layers are > > > > independent, and as such you can only replace a VC-3 connection by a VC-4 > > > > connection by releasing the VC-3 connection and requesting to set up a VC-4 > > > > connection. > > > > > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT > > > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. > > > > > > > > Example: Consider VC-4-Xv trail between nodes X and Y which > > > > supports an Ethernet link between these two nodes. When X is > > > > increased from 4 to 5, the Ethernet link bandwdith is increased > > > > from 600 Mb/s to 750 Mbit/s. > > > > > > > > Assume that the VC-4-Xv trail is supported via two diverse > > > > routes (X - A - Y and X - B - Y), each providing two VC-4 > > > > connections. Then the bandwidth modification will increase > > > > the number of connections on one of the two routes; e.g. the > > > > route via A. The associated traffic parameters will be: > > > > > > > > - Connection X - A - Y traffic parameters > > > > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 > > > > - Connection X - B - Y traffic parameters (unchanged) > > > > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > > > > > What is needed is a MODIFY request which allows for an identified connection to > > > > modify the MT value. > > > > > > > > (*) Note that the parameter NVC is interpreted as to represent the number of > > > > components in a virtual concatenated signal connection... in this example NVC=4 > > > > and grows to NVC=5. As the virtual concatenated signal is transported via two > > > > routes, each having half of the member connections, I have the impression that > > > > MT is the parameter to use. > > > > > > > > Or to turn this around and look at the source for the bandwidth modification > > > > first, we may assume that over the e.g. Ethernet UNI the call controller > > > > (G.8080) at the network side receives a request to increase the enthernet link > > > > from 600 to 750 Mbit/s. The call controller then decides to support this > > > > ehternet bandwidth modification request by means of a modification of the > > > > group-connection via route A... it then issues a connection modification request > > > > for this group-connection... etc. > > > > > > > > Add 1) True bandwidth modification of an individual connection is possible for > > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS > > > > links (G.805) over which the connection is transported have spare capacity, the > > > > bandwidth of an individual VP, VC or LSP can be increased. > > > > > > > > Regards, > > > > > > > > Maarten > > > > > > > > manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If the bandwidth modification is not supported by GMPLS then > > > > > it should be clearly mentioned in the drafts (at least the architecture > > > > > draft). Please see the attached mail for reference. > > > > > > > > > > I am still not clear whether GMPLS supports SE-style of reservation. > > > > > My original question related to SE-style of reservation was and I didn't > > > > > get any reply on the mailing list : > > > > > > > > > > " I have a doubt related to SE style of reservation in GMPLS. As > > > > > in RSVP-TE, multiple senders can share the reservation but they can be > > > > > assigned different labels to distinguish different senders from one > > > > > other. > > > > > In GMPLS, as the label itself is a resource on the link, it means that > > > > > if there are multiple senders in the same session sharing reservation, > > > > > they should be assigned the same label. They can't be assigned > > > > > different labels or is it that GMPLS does not support SE style of > > > > > reservation ?" > > > > > > > > > > Please correct me if I am missing something. > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > >From: Maarten Vissers > > > > > >To: manoj juneja > > > > > >CC: ccamp@ops.ietf.org > > > > > >Subject: Re: Bandwidth modification in GMPLS > > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > > > > > > > >Manoj, > > > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > Is it possible to modify/increase the bandwidth of an existing > > > > > >GMPLS > > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > > > > > >possible to > > > > > > > increase the bandwidth to say VC-4 ? > > > > > > > > > > > >No, this is not possible. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Maarten > > > > > > > > > > > > > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > > > > > > > > > Regards, > > > > > > > manoj. > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > Get your FREE download of MSN Explorer at > > > > > >http://explorer.msn.com/intl.asp > > > > > ><< mvissers.vcf >> > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------28B3AE269E886FB78A163294 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------28B3AE269E886FB78A163294-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 20:43:04 -0800 Date: Mon, 3 Dec 2001 23:38:06 -0500 (EST) From: Jim Boyle To: "Ash, Gerald R (Jerry), ALCTA" cc: , Subject: RE: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, hello, there appears to be an echo in here. One list please, as this is a discussion of requirements, I'll reply just to the tewg list. cheers, Jim On Mon, 3 Dec 2001, Ash, Gerald R (Jerry), ALCTA wrote: > We would like to call for agreement that > > a) draft-ietf-tewg-restore-hierarchy-00.txt calls for multi-area TE > requirements to be generated, but contains no such requirements (Section 3 > says "requirements for multi-area traffic engineering need to be developed > to provide guidance for any necessary protocol extensions"), and > b) draft-ash-multi-area-te-reqmts-01.txt be adopted as a multi-area TE > requirements draft. > > In addition, Section 6.3 of draft-ietf-tewg-restore-hierarchy-00.txt says > "To support edge-to-edge signaling in the above network scenarios within the > framework of existing horizontal hierarchies, current traffic engineering > (TE) methods [19, 5] may need to be extended. Requirements for multi-area TE > need to be developed to provide guidance for any necessary protocol > extensions." > > In regard to 'necessary protocol extensions', there are numerous multi-area > TE approaches, so there is a need to converge on one or a subset of the > approaches (rather than support them all). > draft-ash-multi-area-te-rqmts-01.txt summarizes what protocol extensions > have been proposed by various multi-area TE drafts, including: > http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-02.t > xt > http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te > -02.txt > http://search.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-0 > 0.txt > http://www.ietf.org/internet-drafts/draft-lee-mpls-path-request-02.txt > http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-02.txt. > > draft-ash-multi-area-te-rqmts-01.txt also compares the > advantages/disadvantages of each proposed multi-area TE method, and how well > the method meets the proposed requirements. The analysis can be used to > focus discussion and to select among the approaches. > > In summary, we would like to hear any objections to adopting > draft-ash-multi-area-te-rqmts-01.txt as a multi-area TE requirements draft. > > Thanks, > Jerry Ash > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, November 30, 2001 6:00 AM > To: IETF-Announce; @wsscan.att.com > Subject: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Requirements for Multi-Area TE > Author(s) : J. Ash et al. > Filename : draft-ash-multi-area-te-reqmts-01.txt > Pages : 16 > Date : 29-Nov-01 > > This draft describes requirements for multi-area TE within the context of > GMPLS. Based on the requirements, the goal is to eventually provide > protocol extensions needed for multi-area TE. Various approaches to > multi-area TE are considered, and these approaches are evaluated against the > requirements. These approaches include state dependent routing (SDR) LSP > selection, event dependent routing (EDR) LSP selection, and time dependent > routing (TDR) LSP selection. These approaches include needs to support > path-computation server (PCS) functionality, query functionality, crankback > functionality, TE feedback functionality, and summary-LSA functionality. The > target in future releases of this document will be to converge on a reduced > subset of the required multi-area TE methods and protocol > extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 15:49:15 -0800 Message-ID: <28F05913385EAC43AF019413F674A0170B24AD@OCCLUST04EVS1.ugd.att.com> From: "Ash, Gerald R (Jerry), ALCTA" To: te-wg@ops.ietf.org Cc: "Ash, Gerald R (Jerry), ALCTA" , ccamp@ops.ietf.org Subject: RE: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt Date: Mon, 3 Dec 2001 18:48:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" We would like to call for agreement that a) draft-ietf-tewg-restore-hierarchy-00.txt calls for multi-area TE requirements to be generated, but contains no such requirements (Section 3 says "requirements for multi-area traffic engineering need to be developed to provide guidance for any necessary protocol extensions"), and b) draft-ash-multi-area-te-reqmts-01.txt be adopted as a multi-area TE requirements draft. In addition, Section 6.3 of draft-ietf-tewg-restore-hierarchy-00.txt says "To support edge-to-edge signaling in the above network scenarios within the framework of existing horizontal hierarchies, current traffic engineering (TE) methods [19, 5] may need to be extended. Requirements for multi-area TE need to be developed to provide guidance for any necessary protocol extensions." In regard to 'necessary protocol extensions', there are numerous multi-area TE approaches, so there is a need to converge on one or a subset of the approaches (rather than support them all). draft-ash-multi-area-te-rqmts-01.txt summarizes what protocol extensions have been proposed by various multi-area TE drafts, including: http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-02.t xt http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te -02.txt http://search.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-0 0.txt http://www.ietf.org/internet-drafts/draft-lee-mpls-path-request-02.txt http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-02.txt. draft-ash-multi-area-te-rqmts-01.txt also compares the advantages/disadvantages of each proposed multi-area TE method, and how well the method meets the proposed requirements. The analysis can be used to focus discussion and to select among the approaches. In summary, we would like to hear any objections to adopting draft-ash-multi-area-te-rqmts-01.txt as a multi-area TE requirements draft. Thanks, Jerry Ash -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 30, 2001 6:00 AM To: IETF-Announce; @wsscan.att.com Subject: I-D ACTION:draft-ash-multi-area-te-reqmts-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Multi-Area TE Author(s) : J. Ash et al. Filename : draft-ash-multi-area-te-reqmts-01.txt Pages : 16 Date : 29-Nov-01 This draft describes requirements for multi-area TE within the context of GMPLS. Based on the requirements, the goal is to eventually provide protocol extensions needed for multi-area TE. Various approaches to multi-area TE are considered, and these approaches are evaluated against the requirements. These approaches include state dependent routing (SDR) LSP selection, event dependent routing (EDR) LSP selection, and time dependent routing (TDR) LSP selection. These approaches include needs to support path-computation server (PCS) functionality, query functionality, crankback functionality, TE feedback functionality, and summary-LSA functionality. The target in future releases of this document will be to converge on a reduced subset of the required multi-area TE methods and protocol extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-multi-area-te-reqmts-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 14:38:51 -0800 From: "manoj juneja" To: dimitri.papadimitriou@alcatel.be, mvissers@lucent.com Cc: ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, hhelvoort@lucent.com Bcc: Subject: Re: Bandwidth modification in GMPLS Date: Mon, 03 Dec 2001 15:34:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Dimitri/Marteen, I got the idea that the bandwidth modification for SDH/SONET LSPs has to be supported by using the LBM draft. What about the bandwidth modification for LSC LSPs ? How these are supported ? Are the bandwidth modification for LSC LSPs need to be supported using the RSVP-TE procedures ? I hope that the bandwidth modification for FSC LSPs is not allowed ? What about the SE style of reservation ? Is it supported in GMPLS ? Is it that bandwidth modification for LSC/FSC LSPs are allowed by first establsihing the new LSP and then tearing down the old (with/without double booking of resources) ? Please correct me I am wrong. Regards, manoj. >From: Dimitri Papadimitriou >To: Maarten Vissers >CC: manoj juneja , ccamp@ops.ietf.org, >kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" > >Subject: Re: Bandwidth modification in GMPLS >Date: Mon, 03 Dec 2001 22:02:54 +0100 > >Maarten, > >First for people reading these e-mails the discussion here >is not focused on a comparison between LCAS versus something >else but only on control plane issues (more precisely which >are the GMPLS mechanisms to be provided in order to enable >bandwidth modification on different scenarios) > >Now, to continue the discussion we have defined in the GMPLS >LBM I-D the Circuit ID and the LSP Sequence Number for that >purpose (see Section 5.2). Together with the following rule: > >"All LSPs belonging to the same circuit MUST have the same >Circuit ID. All LSPs MUST have a unique LSP sequence number >in that Circuit ID, the LSP sequence number MUST be the >sequence number of the first SPE/VC of the overall virtually >concatenated circuit." > >Therefore, the scenarios you have defined are a combination >of the methods described in Section 5.1 and 5.2. > >To illustrate this, let's take your example back: > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 >to > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not >connected > > VC-4 SNPs. > > > > VC-4 with G1 via route A > > VC-4 with G2 via route A > > VC-4 with G3 via route B > > VC-4 with G4 via route B > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > >=> Circuit ID #1 (for instance) will include LSP SEQ ID#0 > and LSP SEQ ID#1 (here we assume that Route A is link > diverse from Route B to preserve generality of the > proposed method) > > > Assume that the VC-4 trail via G2 is the first one which clears its >Signal Fail > > (SF) condition, then this trail will pass through the signal with SEQ >ID=0. If > > the second one is via G4, then this one passes through the signal with >SEQ ID=1. > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ >ID=3. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > >=> As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP > SEQ ID#1 to the SEQ ID=0 > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry >SEQ ID #4. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 via route A SEQ ID=4 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > >=> To update the LSP SEQ#0 you follow the rules defined in > the Section 5.1 > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be >no change > > of SEQ ID, only there will be an indication not to transmit over those >VC-4 > > trails. If later on it is decided to continue over route A only, the SEQ >IDs > > are adapted as follows: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 not connected > > VC-4 with G4 not connected > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > >=> you delete the VC-4 components with the re-sequencing as described > at the end of the Section 5.1 with the restriction that "SPEs/VCs > can be removed from an LSP but only at the end of that LSP (i.e. > starting at SPE/VC sequence number X)" > > > If the demand for bandwidth doubles again, it is possible to add say >three more > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the >order > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=4 > > VC-4 with G4 via route C SEQ ID=5 > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 via route C SEQ ID=3 > > VC-4 with G7 not connected > >=> once again you follow the rule described in Section 5.1 > >There is no need to use the multiplier for this purpose (this >field is used for instance to operate a change on multiple LSP >using the same message - it has been provided to avoid lengthy >repetitions of the same operation) > >Once again (i think that Eric has already provided this comment) >the scope of the LSP SEQ ID is not to reproduce the LCAS defined >structures within the control plan but to provide a consistent >control plane definition (allowing a level of consistency checking >between the control plane and the transport plane.) > >Are we in agreement, or do you want further comparison of both >methods ? > >Regards, >- dimitri. > >Maarten Vissers wrote: > > > > Dimitri, > > > > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal >has a > > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not >fixed... > > this is under control of LCAS and may change with time... > > > > When you set up the connection to transport the VC-4-4v signal via two >routes > > (A, B), two VC-4 termination points will be connected to the A route, >two other > > to the B route. > > There are typically 7 VC-4 termination points per GbE port... let's >refer to > > those 7 VC-4 termination points by means of SubNetwork Point (SNP) >addresses G1 > > .. G7. > > > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 >to > > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not >connected > > VC-4 SNPs. > > > > VC-4 with G1 via route A > > VC-4 with G2 via route A > > VC-4 with G3 via route B > > VC-4 with G4 via route B > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > Assume that the VC-4 trail via G2 is the first one which clears its >Signal Fail > > (SF) condition, then this trail will pass through the signal with SEQ >ID=0. If > > the second one is via G4, then this one passes through the signal with >SEQ ID=1. > > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ >ID=3. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 not connected > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry >SEQ ID #4. > > > > VC-4 with G1 via route A SEQ ID=3 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route B SEQ ID=2 > > VC-4 with G4 via route B SEQ ID=1 > > VC-4 with G5 via route A SEQ ID=4 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be >no change > > of SEQ ID, only there will be an indication not to transmit over those >VC-4 > > trails. If later on it is decided to continue over route A only, the SEQ >IDs > > are adapted as follows: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 not connected > > VC-4 with G4 not connected > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 not connected > > VC-4 with G7 not connected > > > > If the demand for bandwidth doubles again, it is possible to add say >three more > > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the >order > > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=4 > > VC-4 with G4 via route C SEQ ID=5 > > VC-4 with G5 via route A SEQ ID=2 > > VC-4 with G6 via route C SEQ ID=3 > > VC-4 with G7 not connected > > > > Looking at the connection setup details, I do not setup a VC-4-2v via A >and > > another VC-4-2v via B initially... I do setup two groups of two VC-4 > > connections, which together support the VC-4-4v trail; a VC-4-4v is not >the > > same as two times a VC-4-2v. The use of NVC parameter here seems as such >not > > appropriate. The only alternative present is the MT field. > > > > Alternative is to redefine NVC as "This field indicates the number of >identical > > co-routed connections that are requested for this LSP. These connections >are all > > of the same type." > > > > But if I assume for a moment an alternative example in which the > > virtual concatenated endpoints are outside of the network of > > interest, then a UNI/E-NNI request using MT will result in the > > same connections being setup compared to such request using the > > modified NVC definition. What am I missing here? > > > > The traffic parameters for these two group-connections supporting the >VC-4-Xv > > trail are thus: > > > > initially: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > after 5th VC-4 trail addition: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > > > after route B connections being released: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > after 4th, 5th, 6th connection being added via route C: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > To add the 3rd VC-4 connection to the VC-4 group-connection over route >A, a > > MODIFY message is required. In your LBM document you propose to signal >the diff > > value only, and consequently let the switch nodes compute the new total >(i.e. > > new = original + diff). It will work as well to signal the new value and >let the > > switch nodes compute the difference (i.e. diff = new - original). We >need to > > evaluate the pros/cons of both approaches before selecting one. > > > > When the group-connection via route B is removed, this group-connection >has to > > be released. > > > > When the group-connection via route C is to be added, this >group-connection has > > to be setup. > > > > In addition to these cases, the MODIFY message has to support also the >decrease > > case. E.g. assume that route A is more expensive than route C, then one >would > > obviously prefer to release a VC-4 connection via route A when the total > > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s. > > > > after 3rd connection via route A is removed: > > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > > > VC-4 with G1 via route A SEQ ID=1 > > VC-4 with G2 via route A SEQ ID=0 > > VC-4 with G3 via route C SEQ ID=3 > > VC-4 with G4 via route C SEQ ID=4 > > VC-4 with G5 not connected > > VC-4 with G6 via route C SEQ ID=2 > > VC-4 with G7 not connected > > > > When using a MODIFY message which includes the new traffic parameters >(and not > > the diff ones), the same MODIFY message can be used for addition and >removal of > > connections to/from the group. This looks like a pro for a MODIFY >message > > definition including the new traffic parameters. > > > > One note to the above scenarios... the set of 7 VC-4 SNPs can be >operated as a > > single SNP Pool (SNPP). Instead of requesting the setup of a >group-connection to > > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could >choose to > > request the setup of two 2-group-connections to SNPP "G1-G7" and let the >local > > switch node decide which specific SNPs will be allocated. > > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 >connection, > > and to add the 4/5/6th VC-4 connections via route C later on. > > > > I hope this clarifies some of the capabilities of the control plane >needs to > > support when a group-connection is to be modified, and the operation of >the SEQ > > ID within virtual concatenation with LCAS. > > > > Regards, > > > > Maarten > > > > Dimitri Papadimitriou wrote: > > > > > > Maarten, > > > > > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used > > > for bandwidth increase purpose since it is used for a different > > > semantic. > > > > > > SPEs/VCs can only be added at the end of an LSP. For instance, > > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is > > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the > > > sequence numbered from 0 to X+Y-1. > > > > > > The number Y of SPEs/VCs to add is given by the following > > > equation: new NVC - old NVC. The first new SPE/VC will have a > > > sequence number equals to the sequence number of the previously > > > last VC + 1 (i.e. X). > > > > > > In such a case (in your below example) > > > > > > - Connection X - A - Y traffic parameters > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 > > > > > > remember that MT = 0 is an invalid value (as per draft-ietf-ccamp > > > -gmpls-sonet-sdh-02.txt) > > > > > > The MT field in this picture is used in the following way (the > > > number Y of SPEs/VCs to add is given by the following equation: > > > (new NVC * new MT) - (old NVC * old MT) just notice that in most > > > cases new MT will be equal to old MT): > > > > > > - 2 Connections X - A - Y traffic paramters > > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 > > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 > > > > > > Your second example is depicted in the section 5.2 of the > > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use > > > of the multiplier (MT) in that context is not recommended. > > > > > > Regards, > > > - dimitri. > > > > > > Maarten Vissers wrote: > > > > > > > > Manoj, > > > > > > > > There is a difference between > > > > 1) modifying the bandwidth of a connection and > > > > 2) replacing the connection by a different connection. > > > > > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, >whereas a VC-4 > > > > connection is a connection in a VC-4 network layer. These network >layers are > > > > independent, and as such you can only replace a VC-3 connection by a >VC-4 > > > > connection by releasing the VC-3 connection and requesting to set up >a VC-4 > > > > connection. > > > > > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. >NVC(*) or MT > > > > >= 1), by adding/removing connection members. If this >group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) >then the supported client link's bandwidth is modified as a result. > > > > > > > > Example: Consider VC-4-Xv trail between nodes X and Y which > > > > supports an Ethernet link between these two nodes. When X is > > > > increased from 4 to 5, the Ethernet link bandwdith is >increased > > > > from 600 Mb/s to 750 Mbit/s. > > > > > > > > Assume that the VC-4-Xv trail is supported via two diverse > > > > routes (X - A - Y and X - B - Y), each providing two VC-4 > > > > connections. Then the bandwidth modification will increase > > > > the number of connections on one of the two routes; e.g. the > > > > route via A. The associated traffic parameters will be: > > > > > > > > - Connection X - A - Y traffic parameters > > > > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, >T=0 > > > > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, >T=0 > > > > - Connection X - B - Y traffic parameters (unchanged) > > > > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > > > > > What is needed is a MODIFY request which allows for an identified >connection to > > > > modify the MT value. > > > > > > > > (*) Note that the parameter NVC is interpreted as to represent the >number of > > > > components in a virtual concatenated signal connection... in this >example NVC=4 > > > > and grows to NVC=5. As the virtual concatenated signal is >transported via two > > > > routes, each having half of the member connections, I have the >impression that > > > > MT is the parameter to use. > > > > > > > > Or to turn this around and look at the source for the bandwidth >modification > > > > first, we may assume that over the e.g. Ethernet UNI the call >controller > > > > (G.8080) at the network side receives a request to increase the >enthernet link > > > > from 600 to 750 Mbit/s. The call controller then decides to support >this > > > > ehternet bandwidth modification request by means of a modification >of the > > > > group-connection via route A... it then issues a connection >modification request > > > > for this group-connection... etc. > > > > > > > > Add 1) True bandwidth modification of an individual connection is >possible for > > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM >VC or MPLS > > > > links (G.805) over which the connection is transported have spare >capacity, the > > > > bandwidth of an individual VP, VC or LSP can be increased. > > > > > > > > Regards, > > > > > > > > Maarten > > > > > > > > manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If the bandwidth modification is not supported by GMPLS >then > > > > > it should be clearly mentioned in the drafts (at least the >architecture > > > > > draft). Please see the attached mail for reference. > > > > > > > > > > I am still not clear whether GMPLS supports SE-style of >reservation. > > > > > My original question related to SE-style of reservation was and I >didn't > > > > > get any reply on the mailing list : > > > > > > > > > > " I have a doubt related to SE style of reservation in >GMPLS. As > > > > > in RSVP-TE, multiple senders can share the reservation but they >can be > > > > > assigned different labels to distinguish different senders from >one > > > > > other. > > > > > In GMPLS, as the label itself is a resource on the link, it means >that > > > > > if there are multiple senders in the same session sharing >reservation, > > > > > they should be assigned the same label. They can't be assigned > > > > > different labels or is it that GMPLS does not support SE style of > > > > > reservation ?" > > > > > > > > > > Please correct me if I am missing something. > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > >From: Maarten Vissers > > > > > >To: manoj juneja > > > > > >CC: ccamp@ops.ietf.org > > > > > >Subject: Re: Bandwidth modification in GMPLS > > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > > > > > > > >Manoj, > > > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > Is it possible to modify/increase the bandwidth of an >existing > > > > > >GMPLS > > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it >be > > > > > >possible to > > > > > > > increase the bandwidth to say VC-4 ? > > > > > > > > > > > >No, this is not possible. > > > > > > > > > > > >Regards, > > > > > > > > > > > >Maarten > > > > > > > > > > > > > > > > > > > > Should the new request be considered independent of previous >one ? > > > > > > > > > > > > > > Regards, > > > > > > > manoj. > > > > > > > > > > > > > > >_________________________________________________________________ > > > > > > > Get your FREE download of MSN Explorer at > > > > > >http://explorer.msn.com/intl.asp > > > > > ><< mvissers.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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 13:05:22 -0800 Message-ID: <3C0BE87E.902ED5F@alcatel.be> Date: Mon, 03 Dec 2001 22:02:54 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------B286F227B1DAE0F570364138" This is a multi-part message in MIME format. --------------B286F227B1DAE0F570364138 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, First for people reading these e-mails the discussion here is not focused on a comparison between LCAS versus something else but only on control plane issues (more precisely which are the GMPLS mechanisms to be provided in order to enable bandwidth modification on different scenarios) Now, to continue the discussion we have defined in the GMPLS LBM I-D the Circuit ID and the LSP Sequence Number for that purpose (see Section 5.2). Together with the following rule: "All LSPs belonging to the same circuit MUST have the same Circuit ID. All LSPs MUST have a unique LSP sequence number in that Circuit ID, the LSP sequence number MUST be the sequence number of the first SPE/VC of the overall virtually concatenated circuit." Therefore, the scenarios you have defined are a combination of the methods described in Section 5.1 and 5.2. To illustrate this, let's take your example back: > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > VC-4 SNPs. > > VC-4 with G1 via route A > VC-4 with G2 via route A > VC-4 with G3 via route B > VC-4 with G4 via route B > VC-4 with G5 not connected > VC-4 with G6 not connected > VC-4 with G7 not connected => Circuit ID #1 (for instance) will include LSP SEQ ID#0 and LSP SEQ ID#1 (here we assume that Route A is link diverse from Route B to preserve generality of the proposed method) > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > the second one is via G4, then this one passes through the signal with SEQ ID=1. > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > VC-4 with G1 via route A SEQ ID=3 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route B SEQ ID=2 > VC-4 with G4 via route B SEQ ID=1 > VC-4 with G5 not connected > VC-4 with G6 not connected > VC-4 with G7 not connected => As such LSP SEQ ID#0 corresponds to the SEQ ID=0 and LSP SEQ ID#1 to the SEQ ID=0 > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > VC-4 with G1 via route A SEQ ID=3 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route B SEQ ID=2 > VC-4 with G4 via route B SEQ ID=1 > VC-4 with G5 via route A SEQ ID=4 > VC-4 with G6 not connected > VC-4 with G7 not connected => To update the LSP SEQ#0 you follow the rules defined in the Section 5.1 > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > of SEQ ID, only there will be an indication not to transmit over those VC-4 > trails. If later on it is decided to continue over route A only, the SEQ IDs > are adapted as follows: > > VC-4 with G1 via route A SEQ ID=1 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 not connected > VC-4 with G4 not connected > VC-4 with G5 via route A SEQ ID=2 > VC-4 with G6 not connected > VC-4 with G7 not connected => you delete the VC-4 components with the re-sequencing as described at the end of the Section 5.1 with the restriction that "SPEs/VCs can be removed from an LSP but only at the end of that LSP (i.e. starting at SPE/VC sequence number X)" > If the demand for bandwidth doubles again, it is possible to add say three more > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > VC-4 with G1 via route A SEQ ID=1 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route C SEQ ID=4 > VC-4 with G4 via route C SEQ ID=5 > VC-4 with G5 via route A SEQ ID=2 > VC-4 with G6 via route C SEQ ID=3 > VC-4 with G7 not connected => once again you follow the rule described in Section 5.1 There is no need to use the multiplier for this purpose (this field is used for instance to operate a change on multiple LSP using the same message - it has been provided to avoid lengthy repetitions of the same operation) Once again (i think that Eric has already provided this comment) the scope of the LSP SEQ ID is not to reproduce the LCAS defined structures within the control plan but to provide a consistent control plane definition (allowing a level of consistency checking between the control plane and the transport plane.) Are we in agreement, or do you want further comparison of both methods ? Regards, - dimitri. Maarten Vissers wrote: > > Dimitri, > > Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a > SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed... > this is under control of LCAS and may change with time... > > When you set up the connection to transport the VC-4-4v signal via two routes > (A, B), two VC-4 termination points will be connected to the A route, two other > to the B route. > There are typically 7 VC-4 termination points per GbE port... let's refer to > those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1 > .. G7. > > Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to > connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected > VC-4 SNPs. > > VC-4 with G1 via route A > VC-4 with G2 via route A > VC-4 with G3 via route B > VC-4 with G4 via route B > VC-4 with G5 not connected > VC-4 with G6 not connected > VC-4 with G7 not connected > > Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail > (SF) condition, then this trail will pass through the signal with SEQ ID=0. If > the second one is via G4, then this one passes through the signal with SEQ ID=1. > If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. > > VC-4 with G1 via route A SEQ ID=3 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route B SEQ ID=2 > VC-4 with G4 via route B SEQ ID=1 > VC-4 with G5 not connected > VC-4 with G6 not connected > VC-4 with G7 not connected > > When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. > > VC-4 with G1 via route A SEQ ID=3 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route B SEQ ID=2 > VC-4 with G4 via route B SEQ ID=1 > VC-4 with G5 via route A SEQ ID=4 > VC-4 with G6 not connected > VC-4 with G7 not connected > > Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change > of SEQ ID, only there will be an indication not to transmit over those VC-4 > trails. If later on it is decided to continue over route A only, the SEQ IDs > are adapted as follows: > > VC-4 with G1 via route A SEQ ID=1 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 not connected > VC-4 with G4 not connected > VC-4 with G5 via route A SEQ ID=2 > VC-4 with G6 not connected > VC-4 with G7 not connected > > If the demand for bandwidth doubles again, it is possible to add say three more > VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order > those trails become available is G6, G3, G4 then the SEQ IDs will be: > > VC-4 with G1 via route A SEQ ID=1 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route C SEQ ID=4 > VC-4 with G4 via route C SEQ ID=5 > VC-4 with G5 via route A SEQ ID=2 > VC-4 with G6 via route C SEQ ID=3 > VC-4 with G7 not connected > > Looking at the connection setup details, I do not setup a VC-4-2v via A and > another VC-4-2v via B initially... I do setup two groups of two VC-4 > connections, which together support the VC-4-4v trail; a VC-4-4v is not the > same as two times a VC-4-2v. The use of NVC parameter here seems as such not > appropriate. The only alternative present is the MT field. > > Alternative is to redefine NVC as "This field indicates the number of identical > co-routed connections that are requested for this LSP. These connections are all > of the same type." > > But if I assume for a moment an alternative example in which the > virtual concatenated endpoints are outside of the network of > interest, then a UNI/E-NNI request using MT will result in the > same connections being setup compared to such request using the > modified NVC definition. What am I missing here? > > The traffic parameters for these two group-connections supporting the VC-4-Xv > trail are thus: > > initially: > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > after 5th VC-4 trail addition: > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > > after route B connections being released: > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > after 4th, 5th, 6th connection being added via route C: > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a > MODIFY message is required. In your LBM document you propose to signal the diff > value only, and consequently let the switch nodes compute the new total (i.e. > new = original + diff). It will work as well to signal the new value and let the > switch nodes compute the difference (i.e. diff = new - original). We need to > evaluate the pros/cons of both approaches before selecting one. > > When the group-connection via route B is removed, this group-connection has to > be released. > > When the group-connection via route C is to be added, this group-connection has > to be setup. > > In addition to these cases, the MODIFY message has to support also the decrease > case. E.g. assume that route A is more expensive than route C, then one would > obviously prefer to release a VC-4 connection via route A when the total > bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s. > > after 3rd connection via route A is removed: > route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] > route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] > > VC-4 with G1 via route A SEQ ID=1 > VC-4 with G2 via route A SEQ ID=0 > VC-4 with G3 via route C SEQ ID=3 > VC-4 with G4 via route C SEQ ID=4 > VC-4 with G5 not connected > VC-4 with G6 via route C SEQ ID=2 > VC-4 with G7 not connected > > When using a MODIFY message which includes the new traffic parameters (and not > the diff ones), the same MODIFY message can be used for addition and removal of > connections to/from the group. This looks like a pro for a MODIFY message > definition including the new traffic parameters. > > One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a > single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to > SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to > request the setup of two 2-group-connections to SNPP "G1-G7" and let the local > switch node decide which specific SNPs will be allocated. > And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection, > and to add the 4/5/6th VC-4 connections via route C later on. > > I hope this clarifies some of the capabilities of the control plane needs to > support when a group-connection is to be modified, and the operation of the SEQ > ID within virtual concatenation with LCAS. > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Maarten, > > > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used > > for bandwidth increase purpose since it is used for a different > > semantic. > > > > SPEs/VCs can only be added at the end of an LSP. For instance, > > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is > > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the > > sequence numbered from 0 to X+Y-1. > > > > The number Y of SPEs/VCs to add is given by the following > > equation: new NVC - old NVC. The first new SPE/VC will have a > > sequence number equals to the sequence number of the previously > > last VC + 1 (i.e. X). > > > > In such a case (in your below example) > > > > - Connection X - A - Y traffic parameters > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 > > > > remember that MT = 0 is an invalid value (as per draft-ietf-ccamp > > -gmpls-sonet-sdh-02.txt) > > > > The MT field in this picture is used in the following way (the > > number Y of SPEs/VCs to add is given by the following equation: > > (new NVC * new MT) - (old NVC * old MT) just notice that in most > > cases new MT will be equal to old MT): > > > > - 2 Connections X - A - Y traffic paramters > > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 > > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 > > > > Your second example is depicted in the section 5.2 of the > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use > > of the multiplier (MT) in that context is not recommended. > > > > Regards, > > - dimitri. > > > > Maarten Vissers wrote: > > > > > > Manoj, > > > > > > There is a difference between > > > 1) modifying the bandwidth of a connection and > > > 2) replacing the connection by a different connection. > > > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 > > > connection is a connection in a VC-4 network layer. These network layers are > > > independent, and as such you can only replace a VC-3 connection by a VC-4 > > > connection by releasing the VC-3 connection and requesting to set up a VC-4 > > > connection. > > > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT > > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. > > > > > > Example: Consider VC-4-Xv trail between nodes X and Y which > > > supports an Ethernet link between these two nodes. When X is > > > increased from 4 to 5, the Ethernet link bandwdith is increased > > > from 600 Mb/s to 750 Mbit/s. > > > > > > Assume that the VC-4-Xv trail is supported via two diverse > > > routes (X - A - Y and X - B - Y), each providing two VC-4 > > > connections. Then the bandwidth modification will increase > > > the number of connections on one of the two routes; e.g. the > > > route via A. The associated traffic parameters will be: > > > > > > - Connection X - A - Y traffic parameters > > > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 > > > - Connection X - B - Y traffic parameters (unchanged) > > > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > > > What is needed is a MODIFY request which allows for an identified connection to > > > modify the MT value. > > > > > > (*) Note that the parameter NVC is interpreted as to represent the number of > > > components in a virtual concatenated signal connection... in this example NVC=4 > > > and grows to NVC=5. As the virtual concatenated signal is transported via two > > > routes, each having half of the member connections, I have the impression that > > > MT is the parameter to use. > > > > > > Or to turn this around and look at the source for the bandwidth modification > > > first, we may assume that over the e.g. Ethernet UNI the call controller > > > (G.8080) at the network side receives a request to increase the enthernet link > > > from 600 to 750 Mbit/s. The call controller then decides to support this > > > ehternet bandwidth modification request by means of a modification of the > > > group-connection via route A... it then issues a connection modification request > > > for this group-connection... etc. > > > > > > Add 1) True bandwidth modification of an individual connection is possible for > > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS > > > links (G.805) over which the connection is transported have spare capacity, the > > > bandwidth of an individual VP, VC or LSP can be increased. > > > > > > Regards, > > > > > > Maarten > > > > > > manoj juneja wrote: > > > > > > > > Hi All, > > > > If the bandwidth modification is not supported by GMPLS then > > > > it should be clearly mentioned in the drafts (at least the architecture > > > > draft). Please see the attached mail for reference. > > > > > > > > I am still not clear whether GMPLS supports SE-style of reservation. > > > > My original question related to SE-style of reservation was and I didn't > > > > get any reply on the mailing list : > > > > > > > > " I have a doubt related to SE style of reservation in GMPLS. As > > > > in RSVP-TE, multiple senders can share the reservation but they can be > > > > assigned different labels to distinguish different senders from one > > > > other. > > > > In GMPLS, as the label itself is a resource on the link, it means that > > > > if there are multiple senders in the same session sharing reservation, > > > > they should be assigned the same label. They can't be assigned > > > > different labels or is it that GMPLS does not support SE style of > > > > reservation ?" > > > > > > > > Please correct me if I am missing something. > > > > > > > > Regards, > > > > manoj. > > > > > > > > >From: Maarten Vissers > > > > >To: manoj juneja > > > > >CC: ccamp@ops.ietf.org > > > > >Subject: Re: Bandwidth modification in GMPLS > > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > > > > > >Manoj, > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > Hi All, > > > > > > Is it possible to modify/increase the bandwidth of an existing > > > > >GMPLS > > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > > > > >possible to > > > > > > increase the bandwidth to say VC-4 ? > > > > > > > > > >No, this is not possible. > > > > > > > > > >Regards, > > > > > > > > > >Maarten > > > > > > > > > > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > > > > > > > Regards, > > > > > > manoj. > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at > > > > >http://explorer.msn.com/intl.asp > > > > ><< mvissers.vcf >> > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------B286F227B1DAE0F570364138 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------B286F227B1DAE0F570364138-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 10:51:35 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: LSC Interface Doubt ... Date: Mon, 03 Dec 2001 11:47:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If I need to establish a bi-directional LSC LSP then do I need to configure the remote end wavelengths on an LSC interface ? Is there any case where both the upstream and downstream labels of an bi-directional LSC LSP be same ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 09:32:13 -0800 Message-ID: <3C0BB64B.24F87ACF@alcatel.be> Date: Mon, 03 Dec 2001 18:28:43 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Brungard, Deborah A, ALCTA" CC: "'Maarten Vissers'" , ccamp , q14/15 Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Content-Type: multipart/mixed; boundary="------------22AC4632B1AD86832A33DBA8" This is a multi-part message in MIME format. --------------22AC4632B1AD86832A33DBA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah, all, The "label" format issue is orthogonal to the discussion we are engaging with this I-D. Nevertheless we have already received numerous comments and lengthy discuss this issue; therefore i think the decision will be endorsed during the next IETF meeting (... from the control plane viewpoint) but this orthogonality implies that different LSP Encoding Type for SDH and Sonet do not preclude "same" or better "equivalent" SUKLM label notation. So please do not take this I-D in this context. Now, you (Maarten as well by the way) are arguing since a long time now to merge the two corresponding SDH and SONET LSP Encoding Type codepoints into a single unique SDH/Sonet value. This is an different issue. My point of view on this issue has always been the same if the transmission plane defines inter- working between both "encoding" without any explicit processing coming from control plane then your proposal can be considered. This would result in merging of the SDH and SONET codepoints into a G.707 codepoint for instance for the LSP Encoding Type. Nevertheless it seems that when comparing your statement (as well as the conclusion of Maarten) and the differences listed it looks like there is a contradiction: if differences may appear between ETSI SDH interfaces themselves these differences can't be fewer when including ANSI SONET interfaces within the same set. I am not saying these differences are significative for the control plane (Maarten describes them as "noise") but i would like to open the discussion and clearly determine if they are impacting the control plane specification and corresponding processing - and to which extend of course: if we define a common value and then plenty of exceptions what's the advantage ? - This is one of the objective of the document, it is not at all the aim to "redefine" the interworking section 6.4 of G.707. Your point of view seems to be very clear: abstract these differences... we will see in our future discussions if this can be achieved without any impact on the control plane definition. Remember also that this I-D is informational. Hope this clarifies a little bit the situation. Regards, - dimitri. "Brungard, Deborah A, ALCTA" wrote: > > Just back from vacation, my comments may be late but they are not much > different from my previous comments. It seems we are still discussing one > label vs. two... > > I, and others, have continually commented that G.707 contains both ETSI SDH > and ANSI SONET. It has always contained both. Supporting two gmpls general > labels - one for ANSI T1.105 and one for ITU-T G.707 - is incorrect and adds > unnecessary complexity for both equipment and operators. If by sdh, the > implication is the TUG-3 structure, than refer to this explicitly in the > label. Or say ETSI sdh. The preference by international operators is to > simplify - we prefer one general label with technology specific details > (TUG3 vs. TUG2) to be addressed by the technology specific documents. Other > international operators have supported my comments on this exploder. If > this comment is not acceptable by the editors of the mpls-gen signaling > document, it would be productive to have a response as to why? > > If the draft on sonet-sdh-interwork is intended to be a rationale for > maintaining two different labels, we can grueling go thru the exercise on > this exploder and comment on it. I would propose (as Randy has already > requested) for sdh/sonet technology discussions, let's take the discussion > to the ITU-T exploder i.e. my first comment on this draft is the incorrect > assumption that one needs to do transport level processing to interwork a > VC-3 with a STS-1 SPE. This is incorrect - one does not touch the signal - > no removal of fixed stuff bytes is required - the VC-3 and STS-1 SPE are > equivalent for DS3 mappings and 34M (note the DS3 mapping is different than > a 34M mapping). It is simply transporting a VC-3 containing a DS3 (or 34M) > via AU3 or via AU4 (both supported in G.707!). If the authors of this > document need additional info, just ask via the ITU-T Q11 exploder. Or we > can discuss here... > > We can continue to go thru the draft line by line, or to move this > discussion quickly, if we go to section 4, the only interworking rule which > is listed as needed, is the conversion of the LSP encoding type from sdh to > sonet. IF the same label would apply, there would be no need for gmpls > sdh-sonet interworking. > > As Maarten notes below, there are many capabilities (positive > connotation)/differences (negative connotation) within ETSI SDH and within > ANSI SONET which do not allow for simply connecting two pieces of equipment > either at a link level or end-to-end path level. A simple connection request > may not even work between the same vendor's equipment :-( Defining different > gmpls labels for sdh vs. sonet does not guarantee transport connectivity for > SDH equipment or SONET equipment. > > Deborah Brungard > AT&T > > > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, November 23, 2001 4:49 AM > To: Dimitri Papadimitriou > Cc: ccamp; q14/15 > Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt > > Dimitri, > > These differences are not specifically between SDH and SONET, you will also > find > a number of those between SDH and SDH or between SONET and SONET. > Furthermore > there are many more items that may require negotiation between elements in > the > connection. > > If you look into the items you will notice that they are associated with the > ports at the end of the connection or at intermediate points along the > connection. As such a generic mechanism is required that establishes > interworking for the case two ports (monitoring points) have different > options > selected. > > Port types to be considered (just a first quick list; still very > incomplete): > > VC-m (m=11,12,2) port > - Path Trace Identifier (J2): 16-byte and 64-byte path trace identifier > strings > - performance monitoring: BIP violation counting, Errored Block (EB) > counting > > VC-m (m=11,12,2) SNC protected port > - all kind of SNC protection related parameters; e.g. SNC protection type, > operation type, holdoff timer, etc. > > VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) port > - Path Trace Identifier (J1): 16-byte and 64-byte path trace identifier > strings > - Path Trace Identifier (J1): 64-byte path trace identifier formats > - performance monitoring: BIP violation counting, Errored Block (EB) > counting > - user channel support: none/F2/F2F3/F3 > > VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) TCM port > - Tandem connection monitoring: option I and II > > VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) SNC protected port > - all kind of SNC protection related parameters; e.g. SNC protection type, > operation type, holdoff timer, etc. > > STM-N (N=0,1,4,16,64,256) RS port > - Regenerator Section Trace Identifier (J0): 1-byte and 16-byte section > trace > identifier strings > - RS-DCC support > - RS orderwire support > - RS user channel support > > STM-N MS port > - older AU/STS pointer processors: ss-bits source processing: generation of > "10" or "00" pattern, sink processing: verify presence of ss-bit pattern or > ignore ss-bit pattern > - newer AU/STS pointer processors: source generates ss-bits "10", sink > ignores > ss-bits ==> i.e. no interworking issue > - Synchronisation Status Message (SSM) code set: option I, II or III (see > G.781) > - MS-REI: MS-REI supported/not-supported > - STM-64 MS-REI: M0M1 or M1 only > - MS-DCC support > - RS orderwire support > > STM-N (N=0,1,4,16,64,256) MS protected port > - K1K2 MSP-APS switching type codes (uni-/bi-directional) in K2[6-8] for > case of > 1:n > - all kind of MS protection related parameters (see G.841 and G.783); e.g. > switching type, operation type, architecture type, etc. > > STM-N (N=16,64,256) MS SPRing protected port > - all kind of MS SPring protection related parameters > > In general, the setup of the connection may have more than one phase > associated: > 1) connection bearer setup > 2) connection monitoring setup > 3) connection protection setup > > The latter two phases require a detailed review of the MI_XXX parameters in > the > atomic functions in G.705, G.781, G.783, G.798 as well as a review of the > set of > atomic functions that represent normally optional functionality. Everything > that > allows selectivity on a per connection basis needs to be identified and > allocated to connection monitoring and protection service signalling. > > As you can see the few specific SONET/SDH differences are like noise and > don't > deserve separate LSP encoding types. Different LSP encoding types will > complicate things more than help. > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Hi Maarten, > > > > Thanks for these comments, it has been left for further consideration > > within this document, but you know that they are "differences" between > > Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are > > mainly J0 at RS/SOH and K2 MS/LOH. > > > > Nevertheless, the key question is does it impact the control plane > > specification ? And this is one of the purpose of this document (again > > at a first stage). > > > > So, prior to propose a merge of the control plane code-points i would > > like first to ask you if the current proposals made in order to provide > > interoperability have been accepted and integrated. Knowing that we can > > then evaluate the impact on the control plane and after we could > > consider > > your proposal. > > > > Many thanks, > > - dimitri. > > > > Maarten Vissers wrote: > > > > > > All, > > > > > > I had a look on contribution > > > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to > provide > > > some comment. > > > > > > 1) I "liked" :-( the first sentence in section 2: "This section > describes how > > > SDH and SONET can interwork at the transport plane level." I only > thought that > > > this was already defined for many years in G.707. :-) > > > A reference to section 6.4/G.707 seems more appropriate, as it will show > > > interconnection in general between VC-3 transport in multiplex sections > (AU-3, > > > STS-1) and VC-4 paths (TU-3). > > > It will also show interconnection between VC-11 transport in VC-11 link > > > connections (TU-11, VT1.5) and VC-12 link connections (TU-12). > > > > > > 2) From a connection management perspective (scope of the control > plane), the > > > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one > signal type. > > > Interworking happens simply within the VC-3 layer network by means of > connecting > > > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP. > > > It is unimportant how the VC-3/STS-1 arrives/departs at/from the > VC-3/STS-1 SNP; > > > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3. > > > > > > Links (link bundles) which support VC-3/STS-1 link connections will > simply > > > advertise this capability via their LSAs. A VC-3 fabric having two VC-3 > > > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP > within > > > the first link to a VC-3/STS-1 SNP within the second link. > > > > > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary > due to the > > > fact that two LSP Encoding Types were allocated. If just one LSP > Encoding Type > > > would be allocated for both SDH and SONET, we would not require any > GMPLS > > > SDH-SONET interworking functionality. > > > > > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one > > > codepoint referred to as SDH/SONET. > > > > > > Regards, > > > > > > Maarten --------------22AC4632B1AD86832A33DBA8 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------22AC4632B1AD86832A33DBA8-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 08:51:25 -0800 Message-ID: From: Jonathan Lang To: 'Robin Qiu' , kireeti@juniper.net Cc: ccamp@ops.ietf.org Subject: RE: Two week Last Call on LMP Date: Mon, 3 Dec 2001 08:44:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Robin, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Robin Qiu [mailto:robin_qiu@hotmail.com] > Sent: Tuesday, November 27, 2001 8:05 AM > To: kireeti@juniper.net > Cc: ccamp@ops.ietf.org > Subject: RE: Two week Last Call on LMP > > > > Hi, > > A few comments/questions/requests. Appreciate your response: > 1. In secion 2 "LMP Overview", paragraph 7, it says "however, > (for link connectivity verification procedure) the > control channel MUST terminate on the same two nodes that the > TE link spans". Why is this a requirement? This prevents a > "proxy" LMP implementation. I'm not sure of the application here... > 2. In section 3.2.1, it says "Once it has both sent and received a > Hello message, the control channel moves to the UP state". Should > a "valid" (expected RcvSeqNum) Hello be received before moving to > UP state? We will add text to clarify that the received Hello must be "valid" as you say. > 3. In section 4 "Link Property Correlation MUST be done before the > link is brought up". Is it necessary to be "MUST"? Ramesh S. > brought up this issue too and Jonathan answered. This will be changed to a SHOULD. > 4. Section 5 "Verify Link Connectivity", paragraph 9 "It is also > permissible for the sender to terminate the Test procedure > without receiving a TestStatusSuccess or TestStatusFailure > message by sending an EndVerify message". This seems misleading > that the sender can't terminate the Test procedure in other > situations. Can it be more straightforward like this "It is also > permissible for the sender to terminate the Test procedure anytime > after sending BeginVerify. An EndVerify message SHOULD be sent > for this purpose."? ok. > 5. In section 7 "Message_Id Usage", can something be added to describe > how to identify a message_id value wrapping? Because the message_id > is made by the other node, it is impossible to know when it wraps > without some common rule. For example, can we dictate that > message_id be incremented by 1? In the draft it states that the Message_Id value is incremental. We will change "incremental" to "monotonically increasing". > 6. In section 8 "Graceful Restart", it doesn't cover the scenario where > both ends restart. In this case, both sides must process the > LinkSummary process as described in section 4. Thanks. We'll update the text. > 7. In section 12.1 "Control Channel FSM", if a CC is brought down > administratively by one side, should it only be brought up by that > same side? Based on the current specification, either side can bring > it up again. It seems to me that this is an implementation issue that I don't think needs to be specified in the protocol spec. > 8. In section 13, is 140 officially assigned to LMP? no. The protocol Id needs to be assigned by IANA. > 9. In 13.6.5, 13.6.6, can object be put at the end of the > object list for both EndVerifyAck and Test, i.e. > ::= > ::= > This is consistent with other messages, so that it is easier to > comply with the recommendation "The transmission order SHOULD be > followed". ok > 10. In general, can default values be suggested for various LMP timers? These are very closely related to the transmission medium for the control channel, so I'm not sure it is appropriate. > 11. In section 14.9 "BEGIN_VERIFY Class", what is the expected usage > for "Number of Data Links" on the receiving side? The Test process > is driven by the sending side until a EndVerify is received. Should > receiving side count the number of data links tested and take some > action after it exceeds "number of data links"? After the receive side meets the "number of data links", it no longer has to look for Test messages for that Verification procedure. > 12. In section 14.12 "TE_LINK Class", don't know who has the authority > to request this, but C-Type=4 should be reserved for OIF, just as > in LOCAL_LINK_ID Class (14.3.1). We will add C-Type=4 for OIF. > > Regards, > > Robin Qiu > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, November 12, 2001 9:00 PM > To: ccamp@ops.ietf.org > Subject: Two week Last Call on LMP > > > Hi All, > > This is to announce a two week Last Call on the LMP draft: > draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > > Please send questions, comments and requests for clarifications > to the CCAMP list. > > Kireeti. > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 06:55:37 -0800 Cc: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Message-ID: <3C0B91F7.F18FE17A@lucent.com> Date: Mon, 03 Dec 2001 15:53:43 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com, "Helvoort, Huub van" Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------F2A3021FF59DA1AD3F1B7E40" This is a multi-part message in MIME format. --------------F2A3021FF59DA1AD3F1B7E40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, Assume the VC-4-4v signal consisting of 4 VC-4 signals. Each VC-4 signal has a SEQ ID (0,1,2,3). Which SEQ ID is associated with which VC-4 is not not fixed... this is under control of LCAS and may change with time... When you set up the connection to transport the VC-4-4v signal via two routes (A, B), two VC-4 termination points will be connected to the A route, two other to the B route. There are typically 7 VC-4 termination points per GbE port... let's refer to those 7 VC-4 termination points by means of SubNetwork Point (SNP) addresses G1 .. G7. Assume the connection controller selects VC-4 SNPs with addresses G1, G2 to connect to route A, and G3, G4 to connect to route B. G5 to G7 are not connected VC-4 SNPs. VC-4 with G1 via route A VC-4 with G2 via route A VC-4 with G3 via route B VC-4 with G4 via route B VC-4 with G5 not connected VC-4 with G6 not connected VC-4 with G7 not connected Assume that the VC-4 trail via G2 is the first one which clears its Signal Fail (SF) condition, then this trail will pass through the signal with SEQ ID=0. If the second one is via G4, then this one passes through the signal with SEQ ID=1. If 3rd is via G3, then this gets SEQ ID=2 and finally via G1 gets SEQ ID=3. VC-4 with G1 via route A SEQ ID=3 VC-4 with G2 via route A SEQ ID=0 VC-4 with G3 via route B SEQ ID=2 VC-4 with G4 via route B SEQ ID=1 VC-4 with G5 not connected VC-4 with G6 not connected VC-4 with G7 not connected When adding the 5th VC-4 (e.g. via VC-4 SNP G5), this VC-4 will carry SEQ ID #4. VC-4 with G1 via route A SEQ ID=3 VC-4 with G2 via route A SEQ ID=0 VC-4 with G3 via route B SEQ ID=2 VC-4 with G4 via route B SEQ ID=1 VC-4 with G5 via route A SEQ ID=4 VC-4 with G6 not connected VC-4 with G7 not connected Now route B fails; i.e. VC-4 with SEQ ID #1 and #2 fail. There will be no change of SEQ ID, only there will be an indication not to transmit over those VC-4 trails. If later on it is decided to continue over route A only, the SEQ IDs are adapted as follows: VC-4 with G1 via route A SEQ ID=1 VC-4 with G2 via route A SEQ ID=0 VC-4 with G3 not connected VC-4 with G4 not connected VC-4 with G5 via route A SEQ ID=2 VC-4 with G6 not connected VC-4 with G7 not connected If the demand for bandwidth doubles again, it is possible to add say three more VC-4 trails via e.g. route C (X - C - Y); e.g. via G3, G4 and G6. If the order those trails become available is G6, G3, G4 then the SEQ IDs will be: VC-4 with G1 via route A SEQ ID=1 VC-4 with G2 via route A SEQ ID=0 VC-4 with G3 via route C SEQ ID=4 VC-4 with G4 via route C SEQ ID=5 VC-4 with G5 via route A SEQ ID=2 VC-4 with G6 via route C SEQ ID=3 VC-4 with G7 not connected Looking at the connection setup details, I do not setup a VC-4-2v via A and another VC-4-2v via B initially... I do setup two groups of two VC-4 connections, which together support the VC-4-4v trail; a VC-4-4v is not the same as two times a VC-4-2v. The use of NVC parameter here seems as such not appropriate. The only alternative present is the MT field. Alternative is to redefine NVC as "This field indicates the number of identical co-routed connections that are requested for this LSP. These connections are all of the same type." But if I assume for a moment an alternative example in which the virtual concatenated endpoints are outside of the network of interest, then a UNI/E-NNI request using MT will result in the same connections being setup compared to such request using the modified NVC definition. What am I missing here? The traffic parameters for these two group-connections supporting the VC-4-Xv trail are thus: initially: route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] after 5th VC-4 trail addition: route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] route B: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] after route B connections being released: route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] after 4th, 5th, 6th connection being added via route C: route A: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] To add the 3rd VC-4 connection to the VC-4 group-connection over route A, a MODIFY message is required. In your LBM document you propose to signal the diff value only, and consequently let the switch nodes compute the new total (i.e. new = original + diff). It will work as well to signal the new value and let the switch nodes compute the difference (i.e. diff = new - original). We need to evaluate the pros/cons of both approaches before selecting one. When the group-connection via route B is removed, this group-connection has to be released. When the group-connection via route C is to be added, this group-connection has to be setup. In addition to these cases, the MODIFY message has to support also the decrease case. E.g. assume that route A is more expensive than route C, then one would obviously prefer to release a VC-4 connection via route A when the total bandwidth of the VC-4-Xv has to be shrunk from 900 Mb/s to 750 Mbit/s. after 3rd connection via route A is removed: route A: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 [or NVC=2, MT=1] route C: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 [or NVC=3, MT=1] VC-4 with G1 via route A SEQ ID=1 VC-4 with G2 via route A SEQ ID=0 VC-4 with G3 via route C SEQ ID=3 VC-4 with G4 via route C SEQ ID=4 VC-4 with G5 not connected VC-4 with G6 via route C SEQ ID=2 VC-4 with G7 not connected When using a MODIFY message which includes the new traffic parameters (and not the diff ones), the same MODIFY message can be used for addition and removal of connections to/from the group. This looks like a pro for a MODIFY message definition including the new traffic parameters. One note to the above scenarios... the set of 7 VC-4 SNPs can be operated as a single SNP Pool (SNPP). Instead of requesting the setup of a group-connection to SNPs G1 and G2 (route A) and to SNPs G3 and G4 (route B), one could choose to request the setup of two 2-group-connections to SNPP "G1-G7" and let the local switch node decide which specific SNPs will be allocated. And the same SNPP "G1-G7" address can be used to add the 5th VC-4 connection, and to add the 4/5/6th VC-4 connections via route C later on. I hope this clarifies some of the capabilities of the control plane needs to support when a group-connection is to be modified, and the operation of the SEQ ID within virtual concatenation with LCAS. Regards, Maarten Dimitri Papadimitriou wrote: > > Maarten, > > As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used > for bandwidth increase purpose since it is used for a different > semantic. > > SPEs/VCs can only be added at the end of an LSP. For instance, > when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is > numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the > sequence numbered from 0 to X+Y-1. > > The number Y of SPEs/VCs to add is given by the following > equation: new NVC - old NVC. The first new SPE/VC will have a > sequence number equals to the sequence number of the previously > last VC + 1 (i.e. X). > > In such a case (in your below example) > > - Connection X - A - Y traffic parameters > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 > > remember that MT = 0 is an invalid value (as per draft-ietf-ccamp > -gmpls-sonet-sdh-02.txt) > > The MT field in this picture is used in the following way (the > number Y of SPEs/VCs to add is given by the following equation: > (new NVC * new MT) - (old NVC * old MT) just notice that in most > cases new MT will be equal to old MT): > > - 2 Connections X - A - Y traffic paramters > * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 > * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 > > Your second example is depicted in the section 5.2 of the > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use > of the multiplier (MT) in that context is not recommended. > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Manoj, > > > > There is a difference between > > 1) modifying the bandwidth of a connection and > > 2) replacing the connection by a different connection. > > > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 > > connection is a connection in a VC-4 network layer. These network layers are > > independent, and as such you can only replace a VC-3 connection by a VC-4 > > connection by releasing the VC-3 connection and requesting to set up a VC-4 > > connection. > > > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT > > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. > > > > Example: Consider VC-4-Xv trail between nodes X and Y which > > supports an Ethernet link between these two nodes. When X is > > increased from 4 to 5, the Ethernet link bandwdith is increased > > from 600 Mb/s to 750 Mbit/s. > > > > Assume that the VC-4-Xv trail is supported via two diverse > > routes (X - A - Y and X - B - Y), each providing two VC-4 > > connections. Then the bandwidth modification will increase > > the number of connections on one of the two routes; e.g. the > > route via A. The associated traffic parameters will be: > > > > - Connection X - A - Y traffic parameters > > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 > > - Connection X - B - Y traffic parameters (unchanged) > > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > > > What is needed is a MODIFY request which allows for an identified connection to > > modify the MT value. > > > > (*) Note that the parameter NVC is interpreted as to represent the number of > > components in a virtual concatenated signal connection... in this example NVC=4 > > and grows to NVC=5. As the virtual concatenated signal is transported via two > > routes, each having half of the member connections, I have the impression that > > MT is the parameter to use. > > > > Or to turn this around and look at the source for the bandwidth modification > > first, we may assume that over the e.g. Ethernet UNI the call controller > > (G.8080) at the network side receives a request to increase the enthernet link > > from 600 to 750 Mbit/s. The call controller then decides to support this > > ehternet bandwidth modification request by means of a modification of the > > group-connection via route A... it then issues a connection modification request > > for this group-connection... etc. > > > > Add 1) True bandwidth modification of an individual connection is possible for > > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS > > links (G.805) over which the connection is transported have spare capacity, the > > bandwidth of an individual VP, VC or LSP can be increased. > > > > Regards, > > > > Maarten > > > > manoj juneja wrote: > > > > > > Hi All, > > > If the bandwidth modification is not supported by GMPLS then > > > it should be clearly mentioned in the drafts (at least the architecture > > > draft). Please see the attached mail for reference. > > > > > > I am still not clear whether GMPLS supports SE-style of reservation. > > > My original question related to SE-style of reservation was and I didn't > > > get any reply on the mailing list : > > > > > > " I have a doubt related to SE style of reservation in GMPLS. As > > > in RSVP-TE, multiple senders can share the reservation but they can be > > > assigned different labels to distinguish different senders from one > > > other. > > > In GMPLS, as the label itself is a resource on the link, it means that > > > if there are multiple senders in the same session sharing reservation, > > > they should be assigned the same label. They can't be assigned > > > different labels or is it that GMPLS does not support SE style of > > > reservation ?" > > > > > > Please correct me if I am missing something. > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: Bandwidth modification in GMPLS > > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > > > >Manoj, > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > Is it possible to modify/increase the bandwidth of an existing > > > >GMPLS > > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > > > >possible to > > > > > increase the bandwidth to say VC-4 ? > > > > > > > >No, this is not possible. > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------F2A3021FF59DA1AD3F1B7E40 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------F2A3021FF59DA1AD3F1B7E40-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 04:08:30 -0800 Message-ID: <3C0B6A80.722557C9@alcatel.be> Date: Mon, 03 Dec 2001 13:05:20 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: manoj juneja , ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------6C57299699DB8646AC2737A1" This is a multi-part message in MIME format. --------------6C57299699DB8646AC2737A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, As per GMPLS-LBM, the multiplier field (MT) SHOULD not be used for bandwidth increase purpose since it is used for a different semantic. SPEs/VCs can only be added at the end of an LSP. For instance, when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the sequence numbered from 0 to X+Y-1. The number Y of SPEs/VCs to add is given by the following equation: new NVC - old NVC. The first new SPE/VC will have a sequence number equals to the sequence number of the previously last VC + 1 (i.e. X). In such a case (in your below example) - Connection X - A - Y traffic parameters * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=1, T=0 * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=1, T=0 remember that MT = 0 is an invalid value (as per draft-ietf-ccamp -gmpls-sonet-sdh-02.txt) The MT field in this picture is used in the following way (the number Y of SPEs/VCs to add is given by the following equation: (new NVC * new MT) - (old NVC * old MT) just notice that in most cases new MT will be equal to old MT): - 2 Connections X - A - Y traffic paramters * Before increase VC-4-2v: ST=6, RCC=0, NCC=0, NVC=2, MT=2, T=0 * Increase to VC-4-3v: ST=6, RCC=0, NCC=0, NVC=1, MT=2, T=0 Your second example is depicted in the section 5.2 of the draft-mannie-ccamp-gmpls-lbm-tdm-00.txt but again the use of the multiplier (MT) in that context is not recommended. Regards, - dimitri. Maarten Vissers wrote: > > Manoj, > > There is a difference between > 1) modifying the bandwidth of a connection and > 2) replacing the connection by a different connection. > > Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 > connection is a connection in a VC-4 network layer. These network layers are > independent, and as such you can only replace a VC-3 connection by a VC-4 > connection by releasing the VC-3 connection and requesting to set up a VC-4 > connection. > > Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT > >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. > > Example: Consider VC-4-Xv trail between nodes X and Y which > supports an Ethernet link between these two nodes. When X is > increased from 4 to 5, the Ethernet link bandwdith is increased > from 600 Mb/s to 750 Mbit/s. > > Assume that the VC-4-Xv trail is supported via two diverse > routes (X - A - Y and X - B - Y), each providing two VC-4 > connections. Then the bandwidth modification will increase > the number of connections on one of the two routes; e.g. the > route via A. The associated traffic parameters will be: > > - Connection X - A - Y traffic parameters > * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 > - Connection X - B - Y traffic parameters (unchanged) > * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 > > What is needed is a MODIFY request which allows for an identified connection to > modify the MT value. > > (*) Note that the parameter NVC is interpreted as to represent the number of > components in a virtual concatenated signal connection... in this example NVC=4 > and grows to NVC=5. As the virtual concatenated signal is transported via two > routes, each having half of the member connections, I have the impression that > MT is the parameter to use. > > Or to turn this around and look at the source for the bandwidth modification > first, we may assume that over the e.g. Ethernet UNI the call controller > (G.8080) at the network side receives a request to increase the enthernet link > from 600 to 750 Mbit/s. The call controller then decides to support this > ehternet bandwidth modification request by means of a modification of the > group-connection via route A... it then issues a connection modification request > for this group-connection... etc. > > Add 1) True bandwidth modification of an individual connection is possible for > e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS > links (G.805) over which the connection is transported have spare capacity, the > bandwidth of an individual VP, VC or LSP can be increased. > > Regards, > > Maarten > > manoj juneja wrote: > > > > Hi All, > > If the bandwidth modification is not supported by GMPLS then > > it should be clearly mentioned in the drafts (at least the architecture > > draft). Please see the attached mail for reference. > > > > I am still not clear whether GMPLS supports SE-style of reservation. > > My original question related to SE-style of reservation was and I didn't > > get any reply on the mailing list : > > > > " I have a doubt related to SE style of reservation in GMPLS. As > > in RSVP-TE, multiple senders can share the reservation but they can be > > assigned different labels to distinguish different senders from one > > other. > > In GMPLS, as the label itself is a resource on the link, it means that > > if there are multiple senders in the same session sharing reservation, > > they should be assigned the same label. They can't be assigned > > different labels or is it that GMPLS does not support SE style of > > reservation ?" > > > > Please correct me if I am missing something. > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: Bandwidth modification in GMPLS > > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > > > >Manoj, > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > Is it possible to modify/increase the bandwidth of an existing > > >GMPLS > > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > > >possible to > > > > increase the bandwidth to say VC-4 ? > > > > > >No, this is not possible. > > > > > >Regards, > > > > > >Maarten > > > > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > > > Regards, > > > > manoj. > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------6C57299699DB8646AC2737A1 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" 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 --------------6C57299699DB8646AC2737A1-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2001 03:38:19 -0800 Cc: ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com Message-ID: <3C0B62BD.3C0A7886@lucent.com> Date: Mon, 03 Dec 2001 12:32:13 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org, kireeti@juniper.net, eric.mannie@gtsgroup.com Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------99607886477D13FE72C680C3" This is a multi-part message in MIME format. --------------99607886477D13FE72C680C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, There is a difference between 1) modifying the bandwidth of a connection and 2) replacing the connection by a different connection. Add 2) A VC-3 connection is a connection in a VC-3 network layer, whereas a VC-4 connection is a connection in a VC-4 network layer. These network layers are independent, and as such you can only replace a VC-3 connection by a VC-4 connection by releasing the VC-3 connection and requesting to set up a VC-4 connection. Add 1) You can modify the "bandwidth" of a group-connection (i.e. NVC(*) or MT >= 1), by adding/removing connection members. If this group-connection supports a virtual concatenated trail (VC-n-Xv, ODUk-Xv) then the supported client link's bandwidth is modified as a result. Example: Consider VC-4-Xv trail between nodes X and Y which supports an Ethernet link between these two nodes. When X is increased from 4 to 5, the Ethernet link bandwdith is increased from 600 Mb/s to 750 Mbit/s. Assume that the VC-4-Xv trail is supported via two diverse routes (X - A - Y and X - B - Y), each providing two VC-4 connections. Then the bandwidth modification will increase the number of connections on one of the two routes; e.g. the route via A. The associated traffic parameters will be: - Connection X - A - Y traffic parameters * Before increase: ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 * After increase: ST=6, RCC=0, NCC=0, NVC=0, MT=3, T=0 - Connection X - B - Y traffic parameters (unchanged) * ST=6, RCC=0, NCC=0, NVC=0, MT=2, T=0 What is needed is a MODIFY request which allows for an identified connection to modify the MT value. (*) Note that the parameter NVC is interpreted as to represent the number of components in a virtual concatenated signal connection... in this example NVC=4 and grows to NVC=5. As the virtual concatenated signal is transported via two routes, each having half of the member connections, I have the impression that MT is the parameter to use. Or to turn this around and look at the source for the bandwidth modification first, we may assume that over the e.g. Ethernet UNI the call controller (G.8080) at the network side receives a request to increase the enthernet link from 600 to 750 Mbit/s. The call controller then decides to support this ehternet bandwidth modification request by means of a modification of the group-connection via route A... it then issues a connection modification request for this group-connection... etc. Add 1) True bandwidth modification of an individual connection is possible for e.g. ATM VP, ATM VC and MPLS connections. As long as the ATM VP, ATM VC or MPLS links (G.805) over which the connection is transported have spare capacity, the bandwidth of an individual VP, VC or LSP can be increased. Regards, Maarten manoj juneja wrote: > > Hi All, > If the bandwidth modification is not supported by GMPLS then > it should be clearly mentioned in the drafts (at least the architecture > draft). Please see the attached mail for reference. > > I am still not clear whether GMPLS supports SE-style of reservation. > My original question related to SE-style of reservation was and I didn't > get any reply on the mailing list : > > " I have a doubt related to SE style of reservation in GMPLS. As > in RSVP-TE, multiple senders can share the reservation but they can be > assigned different labels to distinguish different senders from one > other. > In GMPLS, as the label itself is a resource on the link, it means that > if there are multiple senders in the same session sharing reservation, > they should be assigned the same label. They can't be assigned > different labels or is it that GMPLS does not support SE style of > reservation ?" > > Please correct me if I am missing something. > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: Bandwidth modification in GMPLS > >Date: Fri, 30 Nov 2001 11:45:25 +0100 > > > >Manoj, > > > >manoj juneja wrote: > > > > > > Hi All, > > > Is it possible to modify/increase the bandwidth of an existing > >GMPLS > > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be > >possible to > > > increase the bandwidth to say VC-4 ? > > > >No, this is not possible. > > > >Regards, > > > >Maarten > > > > > > > > Should the new request be considered independent of previous one ? > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------99607886477D13FE72C680C3 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Optical Network Group;Lucent Technologies Nederland version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------99607886477D13FE72C680C3--