Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 18:26:49 -0700 From: "manoj juneja" To: skatukam@cisco.com, ccamp@ops.ietf.org Bcc: Subject: Re: Label Set and Suggested Label Date: Fri, 29 Jun 2001 18:24:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Suresh, The SDH/SONET case u are talking of is not mentioned in GMPLS drafts. But the O-UNI draft clearly talks about this case. I think the GMPLS draft also need to have this information. Regards, manoj. >From: Suresh Katukam >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Label Set and Suggested Label >Date: Fri, 29 Jun 2001 18:06:35 -0700 > > >Manoj, > > > In the GMPLS drafts, it is mentioned that the use of label set > > is in the following cases : > > > > a) End equipment is only capable of transmitting and > > receiving on a small set of wavelengths. > > b) There are sequence of interfaces which can't support > > wavelength conversion. > > c) It is desireable to limit the amount of wavelength > > conversion to reduce the distortion on the optical > > signals. > > d) Two ends of a link support different sets of wavelengths. > > > > All the above four points are valid only in case LSP encoding type is > > lambda. Does this mean if a label set is received in cases where LSP > > encoding type is other than Lambda, it should be ignored or considered > > protocol error ? > >I am not sure whether it is the intention of GMPLS authors to list >all possible scenerios under which a label set is used. There are >other scenerios under which label set can be used. In TDM, for example, >one may want to use same time slot (for BLSRs) assigned along the >entire BLSR segment. In such a scenerio, BLSR headend lists all available >labels and forwards the PATH message. Each node in BLSR knows what >label to use when it receives a RESV message. > >There may be other reasons too. In anycase, you should not consider >that to be a protocol error. > >Thanks, >Suresh > > > > What about the suggested Label ? Is it also defined to take care of > > specific LSP encoding type ? > > > > Please Clarify. > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 18:09:00 -0700 Message-ID: <3B3D261B.3C571E9@cisco.com> Date: Fri, 29 Jun 2001 18:06:35 -0700 From: Suresh Katukam Organization: Cisco Systems MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org Subject: Re: Label Set and Suggested Label Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, > In the GMPLS drafts, it is mentioned that the use of label set > is in the following cases : > > a) End equipment is only capable of transmitting and > receiving on a small set of wavelengths. > b) There are sequence of interfaces which can't support > wavelength conversion. > c) It is desireable to limit the amount of wavelength > conversion to reduce the distortion on the optical > signals. > d) Two ends of a link support different sets of wavelengths. > > All the above four points are valid only in case LSP encoding type is > lambda. Does this mean if a label set is received in cases where LSP > encoding type is other than Lambda, it should be ignored or considered > protocol error ? I am not sure whether it is the intention of GMPLS authors to list all possible scenerios under which a label set is used. There are other scenerios under which label set can be used. In TDM, for example, one may want to use same time slot (for BLSRs) assigned along the entire BLSR segment. In such a scenerio, BLSR headend lists all available labels and forwards the PATH message. Each node in BLSR knows what label to use when it receives a RESV message. There may be other reasons too. In anycase, you should not consider that to be a protocol error. Thanks, Suresh > > What about the suggested Label ? Is it also defined to take care of > specific LSP encoding type ? > > Please Clarify. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 17:13:57 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: LSP Encoding Type Date: Fri, 29 Jun 2001 17:13:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If a particular implementation supports LSP encoding type as SDH ITU-T G-707 1996, Does this mean it can't support signals like AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 17:11:57 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: GMPLS Doubt Date: Fri, 29 Jun 2001 17:11:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In the draft draft-ietf-mpls-generalized-signalling-04.txt, different values of LSP encoding type are defined. What all values of LSP encoding type are currently supported by GMPLS ? The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH etc. I think the only supported values of LSP encoding type are : SDH ITU-T G.707 1996 SONET ANSI T1.105-1995 SDH ITU-T G.707 2000 SONET ANSI T1.105-2000 Fiber Lambda Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ] Please comment. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 17:11:49 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bandwidth Encoding Type Doubt ..... Date: Fri, 29 Jun 2001 17:10:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can someone please tell me the reason for bandwidth encoding parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated will be drived from the signal type field. How the bandwidth encoding type will be interpreted in case of other LSP encoding types ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 16:06:30 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Explicit Label Control Date: Fri, 29 Jun 2001 16:05:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In GMPLS drafts, the concept of Egress/explicit Label control is described. Is this valid only at egress or intermediate nodes also ? I mean to say whether the Egress Label object will only be at the end of ERO or it can appear in between ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 15:55:03 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bi-directional LSPs Date: Fri, 29 Jun 2001 15:54:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In case of bi-directional LSPs, it is mentioned that an intermediate node must allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing upstream label and propagating the path message. Furthermore, the terminator node process the path message as usual, with the exception that the upstream label can immediately be used to transport data towards the initiator. What is the benefit of doing this ? We are also mentioning that if there is an error in processing of the path message, both the labels will be invalid. I think there may be some billing issues if the receiver node start transmitting the data packets, but the path message received from the prior node is in error. I think, the downstream label will be valid only after receipt of RESV message at the source and the upstream label will be valid after the receipt of RESVCONF at the destination. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 15:16:06 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590A21B3B@MILAN> From: bhaskara@turinnetworks.com To: ccamp@ops.ietf.org, mpls@uu.net Subject: lmp mib Date: Fri, 29 Jun 2001 15:12:40 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100E8.9CACAF60" 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_01C100E8.9CACAF60 Content-Type: text/plain; charset="iso-8859-1" > Hi, > > In lmpTeLinkTable of "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType > SYNTAX is given as uint32 in table entry index and when it is > defined it is given as INTEGER type. which one is correct? > > thanks > regards > bhaskara ------_=_NextPart_001_01C100E8.9CACAF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable lmp mib


Hi,

In lmpTeLinkTable of  = "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType SYNTAX = is given as uint32 in table entry index and when it is

defined it is given as INTEGER = type.  which one is correct?

thanks
regards
bhaskara

------_=_NextPart_001_01C100E8.9CACAF60-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 13:09:59 -0700 Message-ID: <3B3CDF58.F7190F4@alcatel.be> Date: Fri, 29 Jun 2001 22:04:40 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG MIME-Version: 1.0 To: Heiles Juergen CC: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: draft-fontana-gmpls-control-g709-00.txt Content-Type: multipart/mixed; boundary="------------40F56A4E57D25EB88717B4D0" This is a multi-part message in MIME format. --------------40F56A4E57D25EB88717B4D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Juergen, Yes, the alignment of the last section of the previous version needed to be performed (it is quite normal, since last version publication ODUk multiplexing has been now clearly defined, also we have update the GPID list of values, and much more). Now it has been done. The updated version will be published very soon and in order to let people the time to read it, comment it, etc. Regards, Dimitri. Heiles Juergen wrote: > > My vote is c) and b). > Even so it is not all wrong, large parts and specially the GMPLS extensions in section 5 to not fit to G.709. > I will contribute to the work. > > Regards > > Juergen > > > -----Original Message----- > > From: Kireeti Kompella [SMTP:kireeti@juniper.net] > > Sent: Tuesday, June 19, 2001 4:00 AM > > To: ccamp@ops.ietf.org > > Subject: draft-fontana-gmpls-control-g709-00.txt > > > > Hi All, > > > > There is a draft on signaling for G.709 networks, URL: > > http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt > > > > Please send comments to the CCAMP mailing list on whether you > > think that this draft should be made a CCAMP WG document or not, > > and why: > > a) yes, this draft is pretty good as it stands; > > b) yes, this draft needs some work, but is okay; > > c) no, this draft is all wrong, but signaling in G.709 networks > > is something that the IETF should be working on; > > d) no, this is not a subject that the IETF should touch. > > > > (Just to make it clear: this proposal is not an architecture, or even > > a re-architecture of G.709 -- that work belongs in the ITU.) > > > > Thanks, > > Kireeti & Vijay. --------------40F56A4E57D25EB88717B4D0 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 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 --------------40F56A4E57D25EB88717B4D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 29 Jun 2001 10:38:27 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Label Set and Suggested Label Date: Fri, 29 Jun 2001 10:34:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In the GMPLS drafts, it is mentioned that the use of label set is in the following cases : a) End equipment is only capable of transmitting and receiving on a small set of wavelengths. b) There are sequence of interfaces which can't support wavelength conversion. c) It is desireable to limit the amount of wavelength conversion to reduce the distortion on the optical signals. d) Two ends of a link support different sets of wavelengths. All the above four points are valid only in case LSP encoding type is lambda. Does this mean if a label set is received in cases where LSP encoding type is other than Lambda, it should be ignored or considered protocol error ? What about the suggested Label ? Is it also defined to take care of specific LSP encoding type ? Please Clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 12:42:09 -0700 Message-ID: From: "Mannie, Eric" To: 'manoj juneja' , ccamp@ops.ietf.org Cc: "'lberger@movaz.com'" Subject: RE: {SUKLM} numbering scheme Date: Thu, 28 Jun 2001 21:38:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Manoj, The label is the same of course. The difference between SDH ITU-T G.707 1996 and SDH ITU-T G.707 2000 is a small bug coming from an old version. That should be removed by Lou. We should have only one SDH LSP encoding type value for SDH (same for SONET). Lou: thanks to correct it. For the conversion table, Maarten should still have it. Kind regards, Eric -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Thursday, June 28, 2001 8:28 PM To: ccamp@ops.ietf.org Subject: {SUKLM} numbering scheme Hi All, I have a doubt regarding {SUKLM} numbering scheme. If I allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH ITU-T G.707 2000 ? Eric, on the ipo u and marteen once exchanged the conversion table for EDCBA and SU, If that table is correct, can u please tell me the formula from which u derived that table ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 12:33:11 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: LSP Encoding Type Date: Thu, 28 Jun 2001 12:31:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If a particular implementation supports LSP encoding type as SDH ITU-T G-707 1996, Does this mean it can't support signals like AUG-1, AUG-4, AUG-16, AUG-64 or AUG-256 ? If it can support then how ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 11:28:23 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: {SUKLM} numbering scheme Date: Thu, 28 Jun 2001 11:27:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a doubt regarding {SUKLM} numbering scheme. If I allocate one VC-4 signal from STM-64 link, will the {SUKLM} returned be different if LSP encoding type indicates SDH ITU-T G.707 1996 or SDH ITU-T G.707 2000 ? Eric, on the ipo u and marteen once exchanged the conversion table for EDCBA and SU, If that table is correct, can u please tell me the formula from which u derived that table ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 11:15:21 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590A21B38@MILAN> From: bhaskara@turinnetworks.com To: ccamp@ops.ietf.org, mpls@UU.NET Subject: looking for LMP Date: Thu, 28 Jun 2001 11:10:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFFD.A9462850" 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_01C0FFFD.A9462850 Content-Type: text/plain; charset="iso-8859-1" Hi, Does any one know about the LMP public domain availability? Or any interop testing tool for testing the functionality of LMP? thank you with regards bhaskara ------_=_NextPart_001_01C0FFFD.A9462850 Content-Type: text/html; charset="iso-8859-1" looking for LMP

Hi,

Does any one know about the LMP public domain availability?
Or any interop testing tool for testing the functionality of LMP?

thank you

with regards
bhaskara

------_=_NextPart_001_01C0FFFD.A9462850-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 08:35:58 -0700 Message-ID: <3B3B3F70.80E8EBCE@sandburst.com> Date: Thu, 28 Jun 2001 10:30:08 -0400 From: Eric Gray MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: ccamp-wg Subject: Re: Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bert, I think most people would agree that being told to subscribe to yet another mailing list is an inferior proposal even in comparison with simply cross-posting. Just for example, if I were to use your proposal, I would be obliged to post the message - =================================================================== Hey CCAMP people! There's a discussion of "MIBs for GMPLS" going on on the MPLS mailing list. If this topic is of interest to you and you are not already subscribed to the MPLS mailing list, then you should subscribe to the MPLS mailing list now. =================================================================== - because this is exactly what is happening. What I would suggest is that - if indeed the mailing lists have so many subscribers in common (an assertion you, and some others, have made but nobody can prove) - then collapse the mailing lists. Since it is not POSSIBLE for an individual to ascertain on their own what overlap - if any - exists between the CCAMP and MPLS mailing lists, then no one has any business climbing down anyone else's throat because they decide to cross-post rather than send separate messages on multiple lists. -- Eric Gray You wrote (in part): > I did send that posting about "pls do not cross-post". > I think that if we have a specific topic, then we should be able > to figure out in which WG it belongs, or which WG chairs agree > to discuss the topic on their WG mailing list. Once we have > decided that, then it is appropriate to ONLY discuss it there, > and then if anyone feels that some other mlist should be aware, > then you could do a short posting to state that "discussion X > is going on over in WG Z, pls join us on mlist Z if this topic > is in your interest area". > > Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 06:41:04 -0700 Message-ID: From: Heiles Juergen To: "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: draft-fontana-gmpls-control-g709-00.txt Date: Thu, 28 Jun 2001 15:40:32 +0200 MIME-Version: 1.0 Content-Type: text/plain My vote is c) and b). Even so it is not all wrong, large parts and specially the GMPLS extensions in section 5 to not fit to G.709. I will contribute to the work. Regards Juergen > -----Original Message----- > From: Kireeti Kompella [SMTP:kireeti@juniper.net] > Sent: Tuesday, June 19, 2001 4:00 AM > To: ccamp@ops.ietf.org > Subject: draft-fontana-gmpls-control-g709-00.txt > > Hi All, > > There is a draft on signaling for G.709 networks, URL: > http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt > > Please send comments to the CCAMP mailing list on whether you > think that this draft should be made a CCAMP WG document or not, > and why: > a) yes, this draft is pretty good as it stands; > b) yes, this draft needs some work, but is okay; > c) no, this draft is all wrong, but signaling in G.709 networks > is something that the IETF should be working on; > d) no, this is not a subject that the IETF should touch. > > (Just to make it clear: this proposal is not an architecture, or even > a re-architecture of G.709 -- that work belongs in the ITU.) > > Thanks, > Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 28 Jun 2001 06:14:59 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CD29D5A@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eric Gray Cc: ccamp-wg Subject: RE: Question Date: Thu, 28 Jun 2001 15:13:51 +0200 MIME-Version: 1.0 Content-Type: text/plain > ---------- > From: Eric Gray[SMTP:eric.gray@sandburst.com] > Sent: Wednesday, June 27, 2001 5:31 PM > To: Common Control and Measurement Protocols - List Manager > Cc: Common Control and Measurement Protocols > Subject: Question > > Hi. > > My understanding of IETF policy is that the mailing lists are > required to be public. This is necessary in order for someone who > is posting to such a list to be able to determine who might be a > recipient. > I am not aware that there are any rules that anybody should be able to find out. In fact... I'd rather see that not just anybody can go and query the IETF mailing list subscriptions and then use that info for spamming us. > This turns out to be a fair and important requirement based on > recent discussions concerning 'cross-posting'. I would like to I did send that posting about "pls do not cross-post". I think that if we have a specific topic, then we should be able to figure out in which WG it belongs, or which WG chairs agree to discuss the topic on their WG mailing list. Once we have decided that, then it is appropriate to ONLY discuss it there, and then if anyone feels that some other mlist should be aware, then you could do a short posting to state that "discussion X is going on over in WG Z, pls join us on mlist Z if this topic is in your interest area". Bert > be able to determine - on my own - whether or not there is in > fact a large cross-section in common between this mailing list > and the mailing list for MPLS. I would also like to be able to > explicitly detemine who is 'missing' from each list. This is very > useful when - for example - I discover that I (or someone else) > has inadvertently posted to the wrong list and I do not want to > send duplicate messages. > > Please advise how I am supposed to be able to do this if you > have disabled the 'who' command for this public mailing list? > > -- > Eric Gray > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 23:53:57 -0700 Message-ID: From: Sasha Vainshtein To: "'manoj juneja'" , ccamp@ops.ietf.org Cc: "Igor Danilovich (E-mail)" Subject: RE: sdh Doubt Date: Thu, 28 Jun 2001 09:48:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, AFAIK, the answer is YES. In SDH, once you have performed concatenation, on a certain stream, you cannot allocate access separate substreams. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, June 27, 2001 9:12 PM > To: ccamp@ops.ietf.org > Subject: sdh Doubt > > > Hi All, > AUG-256 may consist of : > 1. 4 AUG-64 > 2. 1 AU-4-256c > > If AUG-256 consists of 1 AU-4-256c, does this mean it can't > allocate > signals of less granularity than this (viz. one VC-4 or > VC-4-64c or VC-4-16c > etc) ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 12:29:06 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: GMPLS Doubt Date: Wed, 27 Jun 2001 12:27:33 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In the draft draft-ietf-mpls-generalized-signalling-04.txt, different values of LSP encoding type are defined. What all values of LSP encoding type are currently supported by GMPLS ? The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH etc. I think the only supported values of LSP encoding type are : SDH ITU-T G.707 1996 SONET ANSI T1.105-1995 SDH ITU-T G.707 2000 SONET ANSI T1.105-2000 Fiber Lambda Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ] Please comment. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 12:13:00 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: sdh Doubt Date: Wed, 27 Jun 2001 12:11:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, AUG-256 may consist of : 1. 4 AUG-64 2. 1 AU-4-256c If AUG-256 consists of 1 AU-4-256c, does this mean it can't allocate signals of less granularity than this (viz. one VC-4 or VC-4-64c or VC-4-16c etc) ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 09:56:54 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Gray Cc: Common Control and Measurement Protocols Subject: Re: Question Message-Id: Date: Wed, 27 Jun 2001 09:51:15 -0700 > My understanding of IETF policy is that the mailing lists are > required to be public. This is necessary in order for someone who > is posting to such a list to be able to determine who might be a > recipient. the postings to the list are public. i am not aware of a requirement that the list of subscribers should be. randy Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 09:56:54 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B8F7F@ICARIAN> From: Fong Liaw To: 'Suresh Katukam' , Yangguang Xu Cc: Eric Gray , ccamp@ops.ietf.org Subject: RE: Suggested Label Doubt Date: Wed, 27 Jun 2001 09:51:27 -0700 MIME-Version: 1.0 Content-Type: text/plain Suresh > > It is completely waste for bidirectional LSPs in TDM > networks. In TDM networks, > the label must be same and current draft (OIF) specifies > that the upstream > lable should be same as Suggested label. It should be really > made optional > so that if an upstream node wants to suggest, then it has > freedom to do so. Can you elaborate on which one should be optional, in context of either OIF or GMPLS. The current OIF UNI applies only to SONET/SDH, and it also said that a node should specify the same label in Label Set if it does not support different labels of upstream and downstream for bidirectional LSP. Suggested label is always optional in both cases, and if you specify Label Set in this case, you would most likely not need to specify Suggested label ... Thanks. -Fong > > Thanks, > Suresh > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 09:43:41 -0700 Message-ID: From: John Drake To: 'Giovanni Fiaschi' , John Drake Cc: John Drake , 'Heiles Juergen' , 'Yangguang Xu' , Diego Caviglia , Ayan Banerjee , ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 09:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The unreserved bandwidth information is useful but it is thresholded so that an LSA is not issued every time an LSp is activated or deactivated, and the thresholds may be configured by the network owner so that the volume of LSA traffic is controlled. -----Original Message----- From: Giovanni Fiaschi [mailto:Giovanni.Fiaschi@marconi.com] Sent: Wednesday, June 27, 2001 9:36 AM To: John Drake Cc: John Drake; 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia; Ayan Banerjee; ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Ok, got it. If I understand well, this advises against dynamic information distribution for the unreliability of this kind of information. Thus, for example, the Unreserved Bandwidth TLVs in draft-ietf-ospf-diff-te-00.txt should not be used. John Drake on 27/06/2001 18.07.38 To: Giovanni Fiaschi/MAIN/MC1@MCMAIN, John Drake cc: "'Heiles Juergen'" , John Drake , "'Yangguang Xu'" , Diego Caviglia/MAIN/MC1@MCMAIN, Ayan Banerjee , ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 The point is that there is always a race condition wrt to resource availability. Routing can give you an acceptable path but signalling tells you whether the resources along that path are available at the time the attempt is made to establish the LSP. Advertising resource availability information is usually not a good idea as it causes a flooding load and doesn't prevent the race condition. Advertising impairments in routing and using them to determine whether a path is feasible makes sense but advertising wavelength availability or wavelength conversion capapbility, if it is a limited resource, doesn't. -----Original Message----- From: Giovanni Fiaschi [mailto:Giovanni.Fiaschi@marconi.com] Sent: Wednesday, June 27, 2001 8:53 AM To: John Drake Cc: 'Heiles Juergen'; John Drake; 'Yangguang Xu'; Diego Caviglia; Ayan Banerjee; ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 I don't see the point of some calculations during routing and some other during signaling. Either I find during routing a path that works, that is with both wavelength continuty (if conversion is not allowed in some network sub areas) and acceptable signal degradation, or I accept crankback or unavailable resource answers during signaling (when it is too late to attempt alternate routes) due to any of wavelength not found or unacceptable signal. JD: I think that we might be agreeing with each other; i.e., impairments should be handled in routing and wavelength continuity should be handled in signalling. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 09:13:29 -0700 Message-ID: From: John Drake To: 'Giovanni Fiaschi' , John Drake Cc: 'Heiles Juergen' , John Drake , 'Yangguang Xu' , Diego Caviglia , Ayan Banerjee , ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 09:07:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The point is that there is always a race condition wrt to resource availability. Routing can give you an acceptable path but signalling tells you whether the resources along that path are available at the time the attempt is made to establish the LSP. Advertising resource availability information is usually not a good idea as it causes a flooding load and doesn't prevent the race condition. Advertising impairments in routing and using them to determine whether a path is feasible makes sense but advertising wavelength availability or wavelength conversion capapbility, if it is a limited resource, doesn't. -----Original Message----- From: Giovanni Fiaschi [mailto:Giovanni.Fiaschi@marconi.com] Sent: Wednesday, June 27, 2001 8:53 AM To: John Drake Cc: 'Heiles Juergen'; John Drake; 'Yangguang Xu'; Diego Caviglia; Ayan Banerjee; ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 I don't see the point of some calculations during routing and some other during signaling. Either I find during routing a path that works, that is with both wavelength continuty (if conversion is not allowed in some network sub areas) and acceptable signal degradation, or I accept crankback or unavailable resource answers during signaling (when it is too late to attempt alternate routes) due to any of wavelength not found or unacceptable signal. JD: I think that we might be agreeing with each other; i.e., impairments should be handled in routing and wavelength continuity should be handled in signalling. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 08:52:35 -0700 Message-ID: From: John Drake To: 'Diego Caviglia' , John Drake Cc: 'Heiles Juergen' , 'Yangguang Xu' , Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 08:51:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] Sent: Wednesday, June 27, 2001 2:27 AM To: John Drake Cc: 'Heiles Juergen'; 'Yangguang Xu'; Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Hi John, please see my comments in line. Best regards. Diego. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com John Drake on 26/06/2001 23.57.48 To: "'Heiles Juergen'" , "'Yangguang Xu'" , Diego Caviglia/MAIN/MC1@MCMAIN cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi/MAIN/MC1@MCMAIN Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Announcing wavelength availability information in routing doesn't work because of the flooding traffic it would generate, plus there are still race conditions that would have to be handled by signalling anyway. [dc] John could you please clarify why distribute wavelength availability that could be even encoded in only 160 bits per fiber (1 lambda available 0 lambda unavailable) doesn't scale while distribute other link related information such as those described in OSPF TE extension scales? JD: A 160 bit vector may not be sufficient, rather we might have to advertise frequency and spacing information. In any case, we would be causing excessive flooding if we issued an LSA every the value of the bit vector changed. There are provider configurable thresholds associated with unreserved bandwidth so that an LSA is not issued whenever an LSP is created or deleted. Wavelength availability can't be dealt with the same way. Yes I agree that race condition is always a problem when resource information is distributed in a non-instantaneous way. But this is also valid for Unreserved Bandwidth sub-TLV in OSPF TE extension. Label set was intended to support wavelength continuity issues. Also, in the short term, we're dealing with transponder based interfaces to the DWDM systems so this is a non-issue. In the longer term, this is just another issue like PMD and OSNR that will need to be dealt with. [dc] I know that at present OXC are bordered with transponder but in this case what is the purpose of Label set object? I mean in this scenario (DWDM line terminal always perform OEO conversion) from a routing perspective we don't have to worry at all about optical impairments we have just to leave them to DWDM network planning engineers. JD: I think that the intent of label sets was to deal with heterogeneous node/link capabilities in the future. I.e., address it now so that when nodes or links without wavelength conversion capabilities are added to a network things don't break. -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Tuesday, June 26, 2001 7:43 AM To: 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Yangguang, wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. Regards Juergen > -----Original Message----- > From: Yangguang Xu [SMTP:xuyg@lucent.com] > Sent: Tuesday, June 26, 2001 3:13 PM > To: Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > Diego, > > As indicated by the document that Ayan pointed to you, there are many constrains > for the optical networking. These constrains can be considered at network > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > setup time(GMPLS signaling). When a constrain is considered is an engineering > issue. We just have to figure out when and where is the best and cheapest to > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > to handle. > > Thanks, > > Yangguang > > Diego Caviglia wrote: > > > > Ayan, > > > > Thanks for your answer but I don't understand why lambda conversion is > > a signalling problem and thus is covered in generalized signalling draft while > > others optical impairments are routing problem and are covered in a separate > > document. > > > > Moreover even if the document you quoted is a well written and very useful one > > it is an informative contribution that simply points out the physically > > impairments of an all optical network. It doesn't propose any extension to > > OSPF/IS-IS in order to support optical routing. > > > > Given that in an All Optical Network we have to cope with lots of new > > information, as you stated in your document, are we sure that OSPF, in this > > environment, scales? > > > > I mean if it doesn't scale for wavelength availability information distribution > > why it has to scales for other optical impairment distribution? > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > Subject: RE: Optical impairments in > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > ---------------------------------------------------------------------------- ---- > > > > Diego, > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > Thanks, > > Ayan > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Monday, June 25, 2001 6:19 AM > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > Cc: Giovanni Fiaschi > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > Peter ,all, > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > the > > draft there is the label set object that is very useful in All optical > > networks > > with CI-incapable nodes but lambda conversion is only one of the > > problems > > related to path establishment in such networks. I mean what about OSNR > > and > > non-linear impairments? What about gain variation and power equalization? > > Where > > are covered these topic? > > > > If I can find a path feasible from the lambda continuity point of view > > who > > assure me that I have the needed Q at the end of the all optical path? > > > > Best regards. > > > > ---------------------------------------------------------------- > > Diego Caviglia> > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 08:42:40 -0700 Message-ID: From: John Drake To: 'Heiles Juergen' , John Drake , 'Yangguang Xu' , Diego Caviglia Cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 08:37:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Wednesday, June 27, 2001 12:19 AM To: 'John Drake'; Heiles Juergen; 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 John, wavelength availability and wavelength conversion are two different points in my view. A optical corss-connect without wavelength conversion can be seen as a connection matrix with limited connectivity (e.g. only connections between inputand output ports with the same lambda are possible), while a corss-connect with wavelength conversion has full connectivity if no other constrains apply. This is a static information that doesn't change over time. It is detected during startup of the network and will not result in flooding traffic. JD: Good point, and as I indicated in my note, today we're implicitly assuming that every link is capable of wavelength conversion and has no impairments. Perhaps a note to this effect should be added to the routing draft. (In general, I think the plan was to assume as a default that links were unimpaired and that links with impairments would be advertised as exceptions.) However, wavelength conversion capabilities are not advertised between areas or ASs, so signalling still has to deal with wavelength continuity. Further, in the future wavelength conversion may be a node based limited resource, both wrt capacity as well as capability (i.e., which input frequency can be converted to which output frequency), so it probably won't be static and advertising it could cause a flooding load. And, again, it doesn't help between areas or ASs and there are race conditions so signalling still has to deal with wavelength continuity. The available connectivity of a connection matrix can be taken into account by the routing. Wavelength availability is a second issue. If you want to annouce the used and unused wavelengths in real-time you end up with flooding traffic and race conditions, I agree. But this is independent of wavelength conversion availability. A label set helps in my view only if you have wavelength conversion as it allows you to select between different wavelengths. JD: Peter and Lou are the experts, but I think that the point of label sets was to allow you to discover points along the path with wavelength conversion capabilities as part of signalling. Without wavelength conversion you are stuck to a fixed wavelength. What you need is a cranck back mechanism if you detect that all possible wavelengths are occupied. The availabiity of wavelength conversion and the connectivity of a connection matrix as such is a separate issue from PMD or OSNR. Note that even in TDM systesm (SONET) you may have limited connectivity. Some SONET ADMs for example don'tsupport time slot interchange for the line-line connection. That results in the same connectivity restricitions as an Optical ADM without wavelength conversion between the line interfaces. We should separate the issue of wavelength conversion (-> limited connectivity) and signal impairments. Wavelength conversion usually has impact on signal parameters, but that can be modelled as a separate process wich can also exists without wavelength conversion. Today wavelength conversion ist mostly based on o-e-o conversin with re-timing (3-R). The 3-R process resets the otpical signal parameters, but it influences timing parameters (jitte, wander). Wavelength conversion based on o-e-o conversion with re-shaping (limiting amplifier), but without re-timing is also available (2-R). This has influence on other parameters. Pure optical wavelength conversion will have other influences. We don't know exactly which today and it may depend on the specific process used. Consideration of signal impairments in the routing process is a much more complex issue compared to limited connectivity if I look on the tools we use today to design an optical path. JD: I think that we might be agreeing with each other; i.e., impairments should be handled in routing and wavelength continuity should be handled in signalling. Juergen > -----Original Message----- > From: John Drake [SMTP:jdrake@calient.net] > Sent: Tuesday, June 26, 2001 11:58 PM > To: 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 > > Announcing wavelength availability information in routing doesn't work > because of the flooding traffic it would generate, plus there are still race > conditions that would have to be handled by signalling anyway. Label set > was intended to support wavelength continuity issues. > > Also, in the short term, we're dealing with transponder based interfaces to > the DWDM systems so this is a non-issue. In the longer term, this is just > another issue like PMD and OSNR that will need to be dealt with. > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Tuesday, June 26, 2001 7:43 AM > To: 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > > Yangguang, > > wavelength conversion is in my view an issue for path selection as you > cannot select a certain path if the wavelength doesn't fit and you have no> > wavelength conversion.> > > Regards > > Juergen > > > -----Original Message----- > > From: Yangguang Xu [SMTP:xuyg@lucent.com] > > Sent: Tuesday, June 26, 2001 3:13 PM > > To: Diego Caviglia > > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > > Subject: Re: Optical impairments in > draft-ietf-mpls-generalized-signaling-04 > > > > > > Diego, > > > > As indicated by the document that Ayan pointed to you, there are many > constrains > > for the optical networking. These constrains can be considered at network > > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or > connection > > setup time(GMPLS signaling). When a constrain is considered is an > engineering > > issue. We just have to figure out when and where is the best and cheapest > to > > consider a constrain. To wavelength conversion, GMPLS signaling is a good > place > > to handle. > > > > Thanks, > > > > Yangguang > > > > Diego Caviglia wrote: > > > > > > Ayan, > > > > > > Thanks for your answer but I don't understand why lambda > conversion is > > > a signalling problem and thus is covered in generalized signalling > draft while > > > others optical impairments are routing problem and are covered in a > separate > > > document. > > > > > > Moreover even if the document you quoted is a well written and very > useful one > > > it is an informative contribution that simply points out the > physically > > > impairments of an all optical network. It doesn't propose any > extension to > > > OSPF/IS-IS in order to support optical routing. > > > > > > Given that in an All Optical Network we have to cope with > lots of new > > > information, as you stated in your document, are we sure that OSPF, > in this > > > environment, scales? > > > > > > I mean if it doesn't scale for wavelength availability information > distribution > > > why it has to scales for other optical impairment distribution? > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com > > > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > > > > > Subject: RE: Optical impairments in > > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > Diego, > > > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > > > Thanks, > > > Ayan > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Monday, June 25, 2001 6:19 AM > > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > > Cc: Giovanni Fiaschi > > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Peter ,all, > > > > > > a comment about draft-ietf-mpls-generalized-signaling-04. > In > > > the > > > draft there is the label set object that is very useful in All optical > > > networks > > > with CI-incapable nodes but lambda conversion is only one of the > > > problems > > > related to path establishment in such networks. I mean what about > OSNR > > > and > > > non-linear impairments? What about gain variation and power > equalization? > > > Where > > > are covered these topic? > > > > > > If I can find a path feasible from the lambda continuity point of > view > > > who > > > assure me that I have the needed Q at the end of the all optical path? > > > > > > Best regards. > > > > > > ----------------------------------------------------------------> > > > Diego Caviglia> > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 08:35:21 -0700 Message-ID: <3B39FC47.DC3CE9D6@sandburst.com> Date: Wed, 27 Jun 2001 11:31:19 -0400 From: Eric Gray MIME-Version: 1.0 To: Common Control and Measurement Protocols - List Manager Cc: Common Control and Measurement Protocols Subject: Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. My understanding of IETF policy is that the mailing lists are required to be public. This is necessary in order for someone who is posting to such a list to be able to determine who might be a recipient. This turns out to be a fair and important requirement based on recent discussions concerning 'cross-posting'. I would like to be able to determine - on my own - whether or not there is in fact a large cross-section in common between this mailing list and the mailing list for MPLS. I would also like to be able to explicitly detemine who is 'missing' from each list. This is very useful when - for example - I discover that I (or someone else) has inadvertently posted to the wrong list and I do not want to send duplicate messages. Please advise how I am supposed to be able to do this if you have disabled the 'who' command for this public mailing list? -- Eric Gray Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 08:20:42 -0700 Message-ID: From: John Drake To: 'Yangguang Xu' , John Drake Cc: ccamp@ops.ietf.org Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 08:15:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I'll defer to Peter Ashwood-Smith or Lou Berger, as they were the ones who designed label sets -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: Wednesday, June 27, 2001 8:06 AM To: John Drake Cc: ccamp@ops.ietf.org Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 John, Can you (or anybody else) give me an example that there are more than one labels in the label set for the inclusive case? Here is a simple picture: A,B,C and D are OXCs +---+ +---+ +---+ +---+ -----| A |-----| B |----| C |---| D | | |-----| |----| |---| | | |-----| |----| |---| |----- +---+ +---+ +---+ +---+ In your example, please specify your assumption about each OXC, that is whether or not it support wavelength conversion. Thanks a lot, Yangguang John Drake wrote: > > Announcing wavelength availability information in routing doesn't work > because of the flooding traffic it would generate, plus there are still race > conditions that would have to be handled by signalling anyway. Label set > was intended to support wavelength continuity issues. > > Also, in the short term, we're dealing with transponder based interfaces to > the DWDM systems so this is a non-issue. In the longer term, this is just > another issue like PMD and OSNR that will need to be dealt with. > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Tuesday, June 26, 2001 7:43 AM > To: 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > Yangguang, > > wavelength conversion is in my view an issue for path selection as you > cannot select a certain path if the wavelength doesn't fit and you have no > wavelength conversion. > > Regards > > Juergen > > > -----Original Message----- > > From: Yangguang Xu [SMTP:xuyg@lucent.com] > > Sent: Tuesday, June 26, 2001 3:13 PM > > To: Diego Caviglia > > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > > Subject: Re: Optical impairments in > draft-ietf-mpls-generalized-signaling-04 > > > > > > Diego, > > > > As indicated by the document that Ayan pointed to you, there are many > constrains > > for the optical networking. These constrains can be considered at network > > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or > connection > > setup time(GMPLS signaling). When a constrain is considered is an > engineering > > issue. We just have to figure out when and where is the best and cheapest > to > > consider a constrain. To wavelength conversion, GMPLS signaling is a good > place > > to handle. > > > > Thanks, > > > > Yangguang > > > > Diego Caviglia wrote: > > > > > > Ayan, > > > > > > Thanks for your answer but I don't understand why lambda > conversion is > > > a signalling problem and thus is covered in generalized signalling > draft while > > > others optical impairments are routing problem and are covered in a > separate > > > document. > > > > > > Moreover even if the document you quoted is a well written and very > useful one > > > it is an informative contribution that simply points out the > physically > > > impairments of an all optical network. It doesn't propose any > extension to > > > OSPF/IS-IS in order to support optical routing. > > > > > > Given that in an All Optical Network we have to cope with > lots of new > > > information, as you stated in your document, are we sure that OSPF, > in this > > > environment, scales? > > > > > > I mean if it doesn't scale for wavelength availability information > distribution > > > why it has to scales for other optical impairment distribution? > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com > > > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > > > > > Subject: RE: Optical impairments in > > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > Diego, > > > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > > > Thanks, > > > Ayan > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Monday, June 25, 2001 6:19 AM > > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > > Cc: Giovanni Fiaschi > > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Peter ,all, > > > > > > a comment about draft-ietf-mpls-generalized-signaling-04. > In > > > the > > > draft there is the label set object that is very useful in All optical > > > networks > > > with CI-incapable nodes but lambda conversion is only one of the > > > problems > > > related to path establishment in such networks. I mean what about > OSNR > > > and > > > non-linear impairments? What about gain variation and power > equalization? > > > Where > > > are covered these topic? > > > > > > If I can find a path feasible from the lambda continuity point of > view > > > who > > > assure me that I have the needed Q at the end of the all optical path? > > > > > > Best regards. > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia> > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 08:10:03 -0700 Message-ID: <3B39F64B.BFDDE78B@lucent.com> Date: Wed, 27 Jun 2001 11:05:47 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, Can you (or anybody else) give me an example that there are more than one labels in the label set for the inclusive case? Here is a simple picture: A,B,C and D are OXCs +---+ +---+ +---+ +---+ -----| A |-----| B |----| C |---| D | | |-----| |----| |---| | | |-----| |----| |---| |----- +---+ +---+ +---+ +---+ In your example, please specify your assumption about each OXC, that is whether or not it support wavelength conversion. Thanks a lot, Yangguang John Drake wrote: > > Announcing wavelength availability information in routing doesn't work > because of the flooding traffic it would generate, plus there are still race > conditions that would have to be handled by signalling anyway. Label set > was intended to support wavelength continuity issues. > > Also, in the short term, we're dealing with transponder based interfaces to > the DWDM systems so this is a non-issue. In the longer term, this is just > another issue like PMD and OSNR that will need to be dealt with. > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Tuesday, June 26, 2001 7:43 AM > To: 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > Yangguang, > > wavelength conversion is in my view an issue for path selection as you > cannot select a certain path if the wavelength doesn't fit and you have no > wavelength conversion. > > Regards > > Juergen > > > -----Original Message----- > > From: Yangguang Xu [SMTP:xuyg@lucent.com] > > Sent: Tuesday, June 26, 2001 3:13 PM > > To: Diego Caviglia > > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > > Subject: Re: Optical impairments in > draft-ietf-mpls-generalized-signaling-04 > > > > > > Diego, > > > > As indicated by the document that Ayan pointed to you, there are many > constrains > > for the optical networking. These constrains can be considered at network > > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or > connection > > setup time(GMPLS signaling). When a constrain is considered is an > engineering > > issue. We just have to figure out when and where is the best and cheapest > to > > consider a constrain. To wavelength conversion, GMPLS signaling is a good > place > > to handle. > > > > Thanks, > > > > Yangguang > > > > Diego Caviglia wrote: > > > > > > Ayan, > > > > > > Thanks for your answer but I don't understand why lambda > conversion is > > > a signalling problem and thus is covered in generalized signalling > draft while > > > others optical impairments are routing problem and are covered in a > separate > > > document. > > > > > > Moreover even if the document you quoted is a well written and very > useful one > > > it is an informative contribution that simply points out the > physically > > > impairments of an all optical network. It doesn't propose any > extension to > > > OSPF/IS-IS in order to support optical routing. > > > > > > Given that in an All Optical Network we have to cope with > lots of new > > > information, as you stated in your document, are we sure that OSPF, > in this > > > environment, scales? > > > > > > I mean if it doesn't scale for wavelength availability information > distribution > > > why it has to scales for other optical impairment distribution? > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com > > > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > > > > > Subject: RE: Optical impairments in > > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > Diego, > > > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > > > Thanks, > > > Ayan > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Monday, June 25, 2001 6:19 AM > > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > > Cc: Giovanni Fiaschi > > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Peter ,all, > > > > > > a comment about draft-ietf-mpls-generalized-signaling-04. > In > > > the > > > draft there is the label set object that is very useful in All optical > > > networks > > > with CI-incapable nodes but lambda conversion is only one of the > > > problems > > > related to path establishment in such networks. I mean what about > OSNR > > > and > > > non-linear impairments? What about gain variation and power > equalization? > > > Where > > > are covered these topic? > > > > > > If I can find a path feasible from the lambda continuity point of > view > > > who > > > assure me that I have the needed Q at the end of the all optical path? > > > > > > Best regards. > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia> > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 02:38:55 -0700 From: "Diego Caviglia" To: John Drake cc: "'Heiles Juergen'" , "'Yangguang Xu'" , Ayan Banerjee , ccamp@ops.ietf.org, "Giovanni Fiaschi" Message-ID: <80256A78.0033EEFF.00@marconicomms.com> Date: Wed, 27 Jun 2001 11:27:04 +0200 Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi John, please see my comments in line. Best regards. Diego. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com John Drake on 26/06/2001 23.57.48 To: "'Heiles Juergen'" , "'Yangguang Xu'" , Diego Caviglia/MAIN/MC1@MCMAIN cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi/MAIN/MC1@MCMAIN Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Announcing wavelength availability information in routing doesn't work because of the flooding traffic it would generate, plus there are still race conditions that would have to be handled by signalling anyway. [dc] John could you please clarify why distribute wavelength availability that could be even encoded in only 160 bits per fiber (1 lambda available 0 lambda unavailable) doesn't scale while distribute other link related information such as those described in OSPF TE extension scales? Yes I agree that race condition is always a problem when resource information is distributed in a non-instantaneous way. But this is also valid for Unreserved Bandwidth sub-TLV in OSPF TE extension. Label set was intended to support wavelength continuity issues. Also, in the short term, we're dealing with transponder based interfaces to the DWDM systems so this is a non-issue. In the longer term, this is just another issue like PMD and OSNR that will need to be dealt with. [dc] I know that at present OXC are bordered with transponder but in this case what is the purpose of Label set object? I mean in this scenario (DWDM line terminal always perform OEO conversion) from a routing perspective we don't have to worry at all about optical impairments we have just to leave them to DWDM network planning engineers. -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Tuesday, June 26, 2001 7:43 AM To: 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Yangguang, wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. Regards Juergen > -----Original Message----- > From: Yangguang Xu [SMTP:xuyg@lucent.com] > Sent: Tuesday, June 26, 2001 3:13 PM > To: Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > Diego, > > As indicated by the document that Ayan pointed to you, there are many constrains > for the optical networking. These constrains can be considered at network > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > setup time(GMPLS signaling). When a constrain is considered is an engineering > issue. We just have to figure out when and where is the best and cheapest to > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > to handle. > > Thanks, > > Yangguang > > Diego Caviglia wrote: > > > > Ayan, > > > > Thanks for your answer but I don't understand why lambda conversion is > > a signalling problem and thus is covered in generalized signalling draft while > > others optical impairments are routing problem and are covered in a separate > > document. > > > > Moreover even if the document you quoted is a well written and very useful one > > it is an informative contribution that simply points out the physically > > impairments of an all optical network. It doesn't propose any extension to > > OSPF/IS-IS in order to support optical routing. > > > > Given that in an All Optical Network we have to cope with lots of new > > information, as you stated in your document, are we sure that OSPF, in this > > environment, scales? > > > > I mean if it doesn't scale for wavelength availability information distribution > > why it has to scales for other optical impairment distribution? > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > Subject: RE: Optical impairments in > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > ---------------------------------------------------------------------------- ---- > > > > Diego, > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > Thanks, > > Ayan > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Monday, June 25, 2001 6:19 AM > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > Cc: Giovanni Fiaschi > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > Peter ,all, > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > the > > draft there is the label set object that is very useful in All optical > > networks > > with CI-incapable nodes but lambda conversion is only one of the > > problems > > related to path establishment in such networks. I mean what about OSNR > > and > > non-linear impairments? What about gain variation and power equalization? > > Where > > are covered these topic? > > > > If I can find a path feasible from the lambda continuity point of view > > who > > assure me that I have the needed Q at the end of the all optical path? > > > > Best regards. > > > > ---------------------------------------------------------------- > > Diego Caviglia> > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 27 Jun 2001 00:19:58 -0700 Message-ID: From: Heiles Juergen To: "'John Drake'" , Heiles Juergen , "'Yangguang Xu'" , Diego Caviglia Cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 09:19:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John, wavelength availability and wavelength conversion are two different points in my view. A optical corss-connect without wavelength conversion can be seen as a connection matrix with limited connectivity (e.g. only connections between inputand output ports with the same lambda are possible), while a corss-connect with wavelength conversion has full connectivity if no other constrains apply. This is a static information that doesn't change over time. It is detected during startup of the network and will not result in flooding traffic. The available connectivity of a connection matrix can be taken into account by the routing. Wavelength availability is a second issue. If you want to annouce the used and unused wavelengths in real-time you end up with flooding traffic and race conditions, I agree. But this is independent of wavelength conversion availability. A label set helps in my view only if you have wavelength conversion as it allows you to select between different wavelengths. Without wavelength conversion you are stuck to a fixed wavelength. What you need is a cranck back mechanism if you detect that all possible wavelengths are occupied. The availabiity of wavelength conversion and the connectivity of a connection matrix as such is a separate issue from PMD or OSNR. Note that even in TDM systesm (SONET) you may have limited connectivity. Some SONET ADMs for example don'tsupport time slot interchange for the line-line connection. That results in the same connectivity restricitions as an Optical ADM without wavelength conversion between the line interfaces. We should separate the issue of wavelength conversion (-> limited connectivity) and signal impairments. Wavelength conversion usually has impact on signal parameters, but that can be modelled as a separate process wich can also exists without wavelength conversion. Today wavelength conversion ist mostly based on o-e-o conversin with re-timing (3-R). The 3-R process resets the otpical signal parameters, but it influences timing parameters (jitte, wander). Wavelength conversion based on o-e-o conversion with re-shaping (limiting amplifier), but without re-timing is also available (2-R). This has influence on other parameters. Pure optical wavelength conversion will have other influences. We don't know exactly which today and it may depend on the specific process used. Consideration of signal impairments in the routing process is a much more complex issue compared to limited connectivity if I look on the tools we use today to design an optical path. Juergen > -----Original Message----- > From: John Drake [SMTP:jdrake@calient.net] > Sent: Tuesday, June 26, 2001 11:58 PM > To: 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 > > Announcing wavelength availability information in routing doesn't work > because of the flooding traffic it would generate, plus there are still race > conditions that would have to be handled by signalling anyway. Label set > was intended to support wavelength continuity issues. > > Also, in the short term, we're dealing with transponder based interfaces to > the DWDM systems so this is a non-issue. In the longer term, this is just > another issue like PMD and OSNR that will need to be dealt with. > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Tuesday, June 26, 2001 7:43 AM > To: 'Yangguang Xu'; Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > > Yangguang, > > wavelength conversion is in my view an issue for path selection as you > cannot select a certain path if the wavelength doesn't fit and you have no> > wavelength conversion.> > > Regards > > Juergen > > > -----Original Message----- > > From: Yangguang Xu [SMTP:xuyg@lucent.com] > > Sent: Tuesday, June 26, 2001 3:13 PM > > To: Diego Caviglia > > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > > Subject: Re: Optical impairments in > draft-ietf-mpls-generalized-signaling-04 > > > > > > Diego, > > > > As indicated by the document that Ayan pointed to you, there are many > constrains > > for the optical networking. These constrains can be considered at network > > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or > connection > > setup time(GMPLS signaling). When a constrain is considered is an > engineering > > issue. We just have to figure out when and where is the best and cheapest > to > > consider a constrain. To wavelength conversion, GMPLS signaling is a good > place > > to handle. > > > > Thanks, > > > > Yangguang > > > > Diego Caviglia wrote: > > > > > > Ayan, > > > > > > Thanks for your answer but I don't understand why lambda > conversion is > > > a signalling problem and thus is covered in generalized signalling > draft while > > > others optical impairments are routing problem and are covered in a > separate > > > document. > > > > > > Moreover even if the document you quoted is a well written and very > useful one > > > it is an informative contribution that simply points out the > physically > > > impairments of an all optical network. It doesn't propose any > extension to > > > OSPF/IS-IS in order to support optical routing. > > > > > > Given that in an All Optical Network we have to cope with > lots of new > > > information, as you stated in your document, are we sure that OSPF, > in this > > > environment, scales? > > > > > > I mean if it doesn't scale for wavelength availability information > distribution > > > why it has to scales for other optical impairment distribution? > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com > > > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > > > > > Subject: RE: Optical impairments in > > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > Diego, > > > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > > > Thanks, > > > Ayan > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Monday, June 25, 2001 6:19 AM > > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > > Cc: Giovanni Fiaschi > > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Peter ,all, > > > > > > a comment about draft-ietf-mpls-generalized-signaling-04. > In > > > the > > > draft there is the label set object that is very useful in All optical > > > networks > > > with CI-incapable nodes but lambda conversion is only one of the > > > problems > > > related to path establishment in such networks. I mean what about > OSNR > > > and > > > non-linear impairments? What about gain variation and power > equalization? > > > Where > > > are covered these topic? > > > > > > If I can find a path feasible from the lambda continuity point of > view > > > who > > > assure me that I have the needed Q at the end of the all optical path? > > > > > > Best regards. > > > > > > ----------------------------------------------------------------> > > > Diego Caviglia> > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 20:04:29 -0700 From: "Susumu Yoneda" To: "John Drake" , "'Heiles Juergen'" , "'Yangguang Xu'" , "Diego Caviglia" Cc: "Ayan Banerjee" , , "Giovanni Fiaschi" Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Wed, 27 Jun 2001 12:07:21 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi For a full optical network, as Mr. Drake mentioned, there are some issues to be resolved, eg. optical 2R/3R, WC, and PMD, etc. However, by use of a combination between lambda and fiber cable, we can provide a good solution for a limited size of network. By use of GMPLS, we should only avoid the case such that more than two defferent sources have the same lambda and are "wdm"ed to the same fiber cable. Thank you, -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of John Drake Sent: Wednesday, June 27, 2001 6:58 AM To: 'Heiles Juergen'; 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Announcing wavelength availability information in routing doesn't work because of the flooding traffic it would generate, plus there are still race conditions that would have to be handled by signalling anyway. Label set was intended to support wavelength continuity issues. Also, in the short term, we're dealing with transponder based interfaces to the DWDM systems so this is a non-issue. In the longer term, this is just another issue like PMD and OSNR that will need to be dealt with. -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Tuesday, June 26, 2001 7:43 AM To: 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Yangguang, wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. Regards Juergen > -----Original Message----- > From: Yangguang Xu [SMTP:xuyg@lucent.com] > Sent: Tuesday, June 26, 2001 3:13 PM > To: Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > Diego, > > As indicated by the document that Ayan pointed to you, there are many constrains > for the optical networking. These constrains can be considered at network > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > setup time(GMPLS signaling). When a constrain is considered is an engineering > issue. We just have to figure out when and where is the best and cheapest to > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > to handle. > > Thanks, > > Yangguang > > Diego Caviglia wrote: > > > > Ayan, > > > > Thanks for your answer but I don't understand why lambda conversion is > > a signalling problem and thus is covered in generalized signalling draft while > > others optical impairments are routing problem and are covered in a separate > > document. > > > > Moreover even if the document you quoted is a well written and very useful one > > it is an informative contribution that simply points out the physically > > impairments of an all optical network. It doesn't propose any extension to > > OSPF/IS-IS in order to support optical routing. > > > > Given that in an All Optical Network we have to cope with lots of new > > information, as you stated in your document, are we sure that OSPF, in this > > environment, scales? > > > > I mean if it doesn't scale for wavelength availability information distribution > > why it has to scales for other optical impairment distribution? > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > Subject: RE: Optical impairments in > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > ---------------------------------------------------------------------------- ---- > > > > Diego, > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > Thanks, > > Ayan > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Monday, June 25, 2001 6:19 AM > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > Cc: Giovanni Fiaschi > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > Peter ,all, > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > the > > draft there is the label set object that is very useful in All optical > > networks > > with CI-incapable nodes but lambda conversion is only one of the > > problems > > related to path establishment in such networks. I mean what about OSNR > > and > > non-linear impairments? What about gain variation and power equalization? > > Where > > are covered these topic? > > > > If I can find a path feasible from the lambda continuity point of view > > who > > assure me that I have the needed Q at the end of the all optical path? > > > > Best regards. > > > > ---------------------------------------------------------------- > > Diego Caviglia> > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 15:34:14 -0700 Message-ID: <710197BD5AF9D4119E4400508BCFA136010C2908@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: ccamp@ops.ietf.org Cc: "Sandra Ballarte" , "Ewart Tempest" , Fong Liaw Subject: Question on Acceptable Label Set Object class number Date: Tue, 26 Jun 2001 18:32:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FE8F.D210AAE0" 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_01C0FE8F.D210AAE0 Content-Type: text/plain; charset="iso-8859-1" > Can anyone enlighten me as to why the Acceptable Label Set Object > specified in draft-ietf-mpls-generalized-rsvp-te-03 has a class number of > the form 11bbbbbb as opposed to 10bbbbbb. Specifically, the Acceptable > Label Set only has relevance between two GMPLS compliant neighbouring > parties, so what value does propagating this information beyond its local > significance have, especially given that: > > * The generator of the ResvErr or PathErr is under no obligation to > reveal its IP address in the ERROR_SPEC object? > * The Acceptable Label Set object does not specify the local > interfaces to which the labels apply? > > Thanks. > > Ewart > > Ewart Tempest, > Nortel Networks, > 1341 Baseline Rd., > MS 045/22/E11, > Ottawa, Ontario, Canada, K2C 0A7 > > Tel. 613-768-0610 (ESN 398-0610) > Fax: 613-765-7610 > Pager: 613-760-5403 > ------_=_NextPart_001_01C0FE8F.D210AAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on Acceptable Label Set Object class number

Can anyone enlighten me as to why the = Acceptable Label Set Object specified in = draft-ietf-mpls-generalized-rsvp-te-03 has a class number of the form = 11bbbbbb as opposed to 10bbbbbb. Specifically, the Acceptable Label Set = only has relevance between two GMPLS compliant neighbouring parties, so = what value does propagating this information beyond its local = significance have, especially given that:

  • The generator of the ResvErr or = PathErr is under no obligation to reveal its IP address in the = ERROR_SPEC object?
  • The Acceptable Label Set object does = not specify the local interfaces to which the labels apply?

Thanks.

Ewart

Ewart Tempest,
Nortel Networks,
1341 Baseline Rd.,
MS 045/22/E11,
Ottawa, Ontario, Canada, K2C = 0A7

Tel. 613-768-0610 (ESN = 398-0610)
Fax: 613-765-7610
Pager: 613-760-5403

------_=_NextPart_001_01C0FE8F.D210AAE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 15:01:28 -0700 Message-ID: From: John Drake To: 'Heiles Juergen' , 'Yangguang Xu' , Diego Caviglia Cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Tue, 26 Jun 2001 14:57:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Announcing wavelength availability information in routing doesn't work because of the flooding traffic it would generate, plus there are still race conditions that would have to be handled by signalling anyway. Label set was intended to support wavelength continuity issues. Also, in the short term, we're dealing with transponder based interfaces to the DWDM systems so this is a non-issue. In the longer term, this is just another issue like PMD and OSNR that will need to be dealt with. -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Tuesday, June 26, 2001 7:43 AM To: 'Yangguang Xu'; Diego Caviglia Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Yangguang, wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. Regards Juergen > -----Original Message----- > From: Yangguang Xu [SMTP:xuyg@lucent.com] > Sent: Tuesday, June 26, 2001 3:13 PM > To: Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > Diego, > > As indicated by the document that Ayan pointed to you, there are many constrains > for the optical networking. These constrains can be considered at network > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > setup time(GMPLS signaling). When a constrain is considered is an engineering > issue. We just have to figure out when and where is the best and cheapest to > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > to handle. > > Thanks, > > Yangguang > > Diego Caviglia wrote: > > > > Ayan, > > > > Thanks for your answer but I don't understand why lambda conversion is > > a signalling problem and thus is covered in generalized signalling draft while > > others optical impairments are routing problem and are covered in a separate > > document. > > > > Moreover even if the document you quoted is a well written and very useful one > > it is an informative contribution that simply points out the physically > > impairments of an all optical network. It doesn't propose any extension to > > OSPF/IS-IS in order to support optical routing. > > > > Given that in an All Optical Network we have to cope with lots of new > > information, as you stated in your document, are we sure that OSPF, in this > > environment, scales? > > > > I mean if it doesn't scale for wavelength availability information distribution > > why it has to scales for other optical impairment distribution? > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > Subject: RE: Optical impairments in > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > ---------------------------------------------------------------------------- ---- > > > > Diego, > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > Thanks, > > Ayan > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Monday, June 25, 2001 6:19 AM > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > Cc: Giovanni Fiaschi > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > Peter ,all, > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > the > > draft there is the label set object that is very useful in All optical > > networks > > with CI-incapable nodes but lambda conversion is only one of the > > problems > > related to path establishment in such networks. I mean what about OSNR > > and > > non-linear impairments? What about gain variation and power equalization? > > Where > > are covered these topic? > > > > If I can find a path feasible from the lambda continuity point of view > > who > > assure me that I have the needed Q at the end of the all optical path? > > > > Best regards. > > > > ---------------------------------------------------------------- > > Diego Caviglia> > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 10:37:33 -0700 Message-Id: <200106261102.HAA27267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt Date: Tue, 26 Jun 2001 07:02:32 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : New TE LSAs to extend OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-00.txt Pages : 36 Date : 25-Jun-01 OSPF is a well established link state routing protocol used for topology discovery and computing forwarding table based on shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) will use criteria different from shortest-path so as to route traffic around congestion paths and meet varying Service Level agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625101030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 08:50:36 -0700 From: "Diego Caviglia" To: Yangguang Xu cc: Ayan Banerjee , ccamp@ops.ietf.org, "Giovanni Fiaschi" Message-ID: <80256A77.00541C4F.00@marconicomms.com> Date: Tue, 26 Jun 2001 17:01:55 +0200 Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling -04 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Yangguang, I understand your point and may be I haven't express well mine. I'm thinking about an All Optical network with limited lambda conversion (in the sense that not all the PXC are lambda conversion capable) which is too large to ensure that all potential routes have adequate Q at the end node. In this scenario I must know, in order to plan a route that assures sufficient Q, not only if a node is lambda conversion capable but also in which way it performs lambda conversion. I mean if conversion is done by OEO operated by classical transponder I have not to worry about performance penalties (in fact I have 3R regeneration of the signal) but if it is done in the optical domain (e.g. with Semiconductor Optical Amplifier) I have to consider the loss introduced by this kind of conversion. Suppose I have the following network scenario: A----------B-----//-----C--------D---------E A and E are source and destination node for a lightpath. Suppose that due to optical impairments I have to regenerate electrically the signal between node C and D I choose node C in order to have better Q at the receiver, then at node D due to lambda unavailability I have to do WC but node D is able to do only OEO conversion so I have two consecutive OEO conversion while just one is necessary. On the other hand if I have sufficient budget to cover the whole path without taking into account the penalties due to SOA lambda conversion if I do WC with SOA I risk to degrade too much the signal. Summarizing what I would like to say about WC is that it implies some considerations on routing: If I do OEO WC I restart the penalties counting If I do optical WC I have to add penalties to the routing calculation. This from my point of view impacts the way I calculate a route. Thus lambda availability and signal degradation calculation must be taken into account together, either during the routing or the signaling or both. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modeling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Yangguang Xu on 26/06/2001 15.13.16 To: Diego Caviglia/MAIN/MC1@MCMAIN cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi/MAIN/MC1@MCMAIN Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Diego, As indicated by the document that Ayan pointed to you, there are many constrains for the optical networking. These constrains can be considered at network planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection setup time(GMPLS signaling). When a constrain is considered is an engineering issue. We just have to figure out when and where is the best and cheapest to consider a constrain. To wavelength conversion, GMPLS signaling is a good place to handle. Thanks, Yangguang Diego Caviglia wrote: > > Ayan, > > Thanks for your answer but I don't understand why lambda conversion is > a signalling problem and thus is covered in generalized signalling draft while > others optical impairments are routing problem and are covered in a separate > document. > > Moreover even if the document you quoted is a well written and very useful one > it is an informative contribution that simply points out the physically > impairments of an all optical network. It doesn't propose any extension to > OSPF/IS-IS in order to support optical routing. > > Given that in an All Optical Network we have to cope with lots of new > information, as you stated in your document, are we sure that OSPF, in this > environment, scales? > > I mean if it doesn't scale for wavelength availability information distribution > why it has to scales for other optical impairment distribution? > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modelling > E-mail: diego.caviglia@marconi.com > Tel: +39 (0) 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > petera@nortelnetworks.con, ccamp@ops.ietf.org > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > > -------------------------------------------------------------------------------- > > Diego, > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > Thanks, > Ayan > > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Monday, June 25, 2001 6:19 AM > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > Cc: Giovanni Fiaschi > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > Peter ,all, > > a comment about draft-ietf-mpls-generalized-signaling-04. In > the > draft there is the label set object that is very useful in All optical > networks > with CI-incapable nodes but lambda conversion is only one of the > problems > related to path establishment in such networks. I mean what about OSNR > and > non-linear impairments? What about gain variation and power equalization? > Where > are covered these topic? > > If I can find a path feasible from the lambda continuity point of view > who > assure me that I have the needed Q at the end of the all optical path? > > Best regards. > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modelling > E-mail: diego.caviglia@marconi.com > Tel: +39 (0) 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 08:48:58 -0700 Message-ID: From: Ayan Banerjee To: 'Diego Caviglia' Cc: ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Tue, 26 Jun 2001 08:46:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Diego, At the last IETF we did present the following draft : draft-banerjee-routing-impairments-00.txt, which proposed minimal extensions to the OSPF/ISIS routing protocols. It was decided that the IPO group would enhance the draft: draft-chiu-strand-unique-olcp-02.txt with the requirements for all optical routing and only then extensions to the routing protocols were to be submitted to the CCAMP WG. Thanks, Ayan -----Original Message----- From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] Sent: Tuesday, June 26, 2001 2:27 AM To: Ayan Banerjee Cc: petera@nortelnetworks.con; ccamp@ops.ietf.org; Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Ayan, Thanks for your answer but I don't understand why lambda conversion is a signalling problem and thus is covered in generalized signalling draft while others optical impairments are routing problem and are covered in a separate document. Moreover even if the document you quoted is a well written and very useful one it is an informative contribution that simply points out the physically impairments of an all optical network. It doesn't propose any extension to OSPF/IS-IS in order to support optical routing. Given that in an All Optical Network we have to cope with lots of new information, as you stated in your document, are we sure that OSPF, in this environment, scales? I mean if it doesn't scale for wavelength availability information distribution why it has to scales for other optical impairment distribution? ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modelling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Ayan Banerjee on 25/06/2001 22.26.02 To: Diego Caviglia/MAIN/MC1@MCMAIN, petera@nortelnetworks.con, ccamp@ops.ietf.org cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 07:57:12 -0700 Message-ID: <3B38A282.1BADFFC4@lucent.com> Date: Tue, 26 Jun 2001 10:56:02 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Heiles Juergen CC: ccamp@ops.ietf.org Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen, I agree with you. However, at the signaling time, "label set" can be a handy tool if you don't have algorithms that is smart enough to consider the wavelength conversion. It depends what you have now and what's the cost. Thanks, Yangguang Heiles Juergen wrote: > > Yangguang, > > wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. > > Regards > > Juergen > > > -----Original Message----- > > From: Yangguang Xu [SMTP:xuyg@lucent.com] > > Sent: Tuesday, June 26, 2001 3:13 PM > > To: Diego Caviglia > > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Diego, > > > > As indicated by the document that Ayan pointed to you, there are many constrains > > for the optical networking. These constrains can be considered at network > > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > > setup time(GMPLS signaling). When a constrain is considered is an engineering > > issue. We just have to figure out when and where is the best and cheapest to > > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > > to handle. > > > > Thanks, > > > > Yangguang > > > > Diego Caviglia wrote: > > > > > > Ayan, > > > > > > Thanks for your answer but I don't understand why lambda conversion is > > > a signalling problem and thus is covered in generalized signalling draft while > > > others optical impairments are routing problem and are covered in a separate > > > document. > > > > > > Moreover even if the document you quoted is a well written and very useful one > > > it is an informative contribution that simply points out the physically > > > impairments of an all optical network. It doesn't propose any extension to > > > OSPF/IS-IS in order to support optical routing. > > > > > > Given that in an All Optical Network we have to cope with lots of new > > > information, as you stated in your document, are we sure that OSPF, in this > > > environment, scales? > > > > > > I mean if it doesn't scale for wavelength availability information distribution > > > why it has to scales for other optical impairment distribution? > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com > > > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > > > > > Subject: RE: Optical impairments in > > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > Diego, > > > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > > > Thanks, > > > Ayan > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Monday, June 25, 2001 6:19 AM > > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > > Cc: Giovanni Fiaschi > > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > > > Peter ,all, > > > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > > the > > > draft there is the label set object that is very useful in All optical > > > networks > > > with CI-incapable nodes but lambda conversion is only one of the > > > problems > > > related to path establishment in such networks. I mean what about OSNR > > > and > > > non-linear impairments? What about gain variation and power equalization? > > > Where > > > are covered these topic? > > > > > > If I can find a path feasible from the lambda continuity point of view > > > who > > > assure me that I have the needed Q at the end of the all optical path? > > > > > > Best regards. > > > > > > ---------------------------------------------------------------- > > > Diego Caviglia> > > > Photonic Networks Design and Modelling > > > E-mail: diego.caviglia@marconi.com > > > Tel: +39 (0) 10 6003 808 > > > Via A. Negrone 1A 16153 Genoa (Italy) > > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 07:44:44 -0700 Message-ID: From: Heiles Juergen To: "'Yangguang Xu'" , Diego Caviglia Cc: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Tue, 26 Jun 2001 16:43:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yangguang, wavelength conversion is in my view an issue for path selection as you cannot select a certain path if the wavelength doesn't fit and you have no wavelength conversion. Regards Juergen > -----Original Message----- > From: Yangguang Xu [SMTP:xuyg@lucent.com] > Sent: Tuesday, June 26, 2001 3:13 PM > To: Diego Caviglia > Cc: Ayan Banerjee; ccamp@ops.ietf.org; Giovanni Fiaschi > Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > Diego, > > As indicated by the document that Ayan pointed to you, there are many constrains > for the optical networking. These constrains can be considered at network > planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection > setup time(GMPLS signaling). When a constrain is considered is an engineering > issue. We just have to figure out when and where is the best and cheapest to > consider a constrain. To wavelength conversion, GMPLS signaling is a good place > to handle. > > Thanks, > > Yangguang > > Diego Caviglia wrote: > > > > Ayan, > > > > Thanks for your answer but I don't understand why lambda conversion is > > a signalling problem and thus is covered in generalized signalling draft while > > others optical impairments are routing problem and are covered in a separate > > document. > > > > Moreover even if the document you quoted is a well written and very useful one > > it is an informative contribution that simply points out the physically > > impairments of an all optical network. It doesn't propose any extension to > > OSPF/IS-IS in order to support optical routing. > > > > Given that in an All Optical Network we have to cope with lots of new > > information, as you stated in your document, are we sure that OSPF, in this > > environment, scales? > > > > I mean if it doesn't scale for wavelength availability information distribution > > why it has to scales for other optical impairment distribution? > > > > ---------------------------------------------------------------- > > Diego Caviglia > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com > > > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > > petera@nortelnetworks.con, ccamp@ops.ietf.org > > > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > > > > > Subject: RE: Optical impairments in > > draft-ietf-mpls-generalized-signaling- 04 > > > > > > -------------------------------------------------------------------------------- > > > > Diego, > > > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > > > Thanks, > > Ayan > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Monday, June 25, 2001 6:19 AM > > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > > Cc: Giovanni Fiaschi > > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > > > Peter ,all, > > > > a comment about draft-ietf-mpls-generalized-signaling-04. In > > the > > draft there is the label set object that is very useful in All optical > > networks > > with CI-incapable nodes but lambda conversion is only one of the > > problems > > related to path establishment in such networks. I mean what about OSNR > > and > > non-linear impairments? What about gain variation and power equalization? > > Where > > are covered these topic? > > > > If I can find a path feasible from the lambda continuity point of view > > who > > assure me that I have the needed Q at the end of the all optical path? > > > > Best regards. > > > > ---------------------------------------------------------------- > > Diego Caviglia> > > Photonic Networks Design and Modelling > > E-mail: diego.caviglia@marconi.com > > Tel: +39 (0) 10 6003 808 > > Via A. Negrone 1A 16153 Genoa (Italy) > > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 06:17:24 -0700 Message-ID: <3B388A6C.8FB3FB0@lucent.com> Date: Tue, 26 Jun 2001 09:13:16 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Diego Caviglia CC: Ayan Banerjee , ccamp@ops.ietf.org, Giovanni Fiaschi Subject: Re: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diego, As indicated by the document that Ayan pointed to you, there are many constrains for the optical networking. These constrains can be considered at network planning time, path selection time (routing using OSPF-TE/ISIS-TE) or connection setup time(GMPLS signaling). When a constrain is considered is an engineering issue. We just have to figure out when and where is the best and cheapest to consider a constrain. To wavelength conversion, GMPLS signaling is a good place to handle. Thanks, Yangguang Diego Caviglia wrote: > > Ayan, > > Thanks for your answer but I don't understand why lambda conversion is > a signalling problem and thus is covered in generalized signalling draft while > others optical impairments are routing problem and are covered in a separate > document. > > Moreover even if the document you quoted is a well written and very useful one > it is an informative contribution that simply points out the physically > impairments of an all optical network. It doesn't propose any extension to > OSPF/IS-IS in order to support optical routing. > > Given that in an All Optical Network we have to cope with lots of new > information, as you stated in your document, are we sure that OSPF, in this > environment, scales? > > I mean if it doesn't scale for wavelength availability information distribution > why it has to scales for other optical impairment distribution? > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modelling > E-mail: diego.caviglia@marconi.com > Tel: +39 (0) 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com > > Ayan Banerjee on 25/06/2001 22.26.02 > > > > > > > > To: Diego Caviglia/MAIN/MC1@MCMAIN, > petera@nortelnetworks.con, ccamp@ops.ietf.org > > cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN > > > > Subject: RE: Optical impairments in > draft-ietf-mpls-generalized-signaling- 04 > > > -------------------------------------------------------------------------------- > > Diego, > > Please see draft-ietf-ipo-impairments-00.txt for optical constraints. > > Thanks, > Ayan > > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Monday, June 25, 2001 6:19 AM > To: petera@nortelnetworks.con; ccamp@ops.ietf.org > Cc: Giovanni Fiaschi > Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 > > Peter ,all, > > a comment about draft-ietf-mpls-generalized-signaling-04. In > the > draft there is the label set object that is very useful in All optical > networks > with CI-incapable nodes but lambda conversion is only one of the > problems > related to path establishment in such networks. I mean what about OSNR > and > non-linear impairments? What about gain variation and power equalization? > Where > are covered these topic? > > If I can find a path feasible from the lambda continuity point of view > who > assure me that I have the needed Q at the end of the all optical path? > > Best regards. > > ---------------------------------------------------------------- > Diego Caviglia > Photonic Networks Design and Modelling > E-mail: diego.caviglia@marconi.com > Tel: +39 (0) 10 6003 808 > Via A. Negrone 1A 16153 Genoa (Italy) > http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 04:10:49 -0700 Message-ID: <20010626110809.38066.qmail@web13904.mail.yahoo.com> Date: Tue, 26 Jun 2001 04:08:09 -0700 (PDT) From: Kireeti Kompella Subject: RE: Control Channel Doubt To: "v.sharma@ieee.org" Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Vishal, --- Vishal Sharma wrote: > Bert, > > While I understand your concern, I have a question. > Since both MPLS and CCAMP WGs had issued a joint > last call on the > GMPLS drafts, aren't at least the GMPLS-related > drafts are the subject of both > WGs. Yes, indeed. Does that justify filling many many mailboxes with duplicate mails? I suspect the overlap between the ccamp and mpls mailing lists is very high -- more relevantly, I suspect that the number of folks interested in GMPLS who are *not* subscribed to CCAMP AND are subscribed to MPLS is close to zero. Especially after Bert's mail asking to minimize cross-postings. Kireeti. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 04:03:41 -0700 Message-Id: <200106261102.HAA27267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-srisuresh-ospf-te-00.txt Date: Tue, 26 Jun 2001 07:02:32 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : New TE LSAs to extend OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-00.txt Pages : 36 Date : 25-Jun-01 OSPF is a well established link state routing protocol used for topology discovery and computing forwarding table based on shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) will use criteria different from shortest-path so as to route traffic around congestion paths and meet varying Service Level agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625101030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010625101030.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 26 Jun 2001 02:30:10 -0700 From: "Diego Caviglia" To: Ayan Banerjee cc: petera@nortelnetworks.con, ccamp@ops.ietf.org, "Giovanni Fiaschi" Message-ID: <80256A77.0033F26C.00@marconicomms.com> Date: Tue, 26 Jun 2001 11:27:16 +0200 Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f" Content-Disposition: inline --0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable Ayan, Thanks for your answer but I don't understand why lambda conv= ersion is a signalling problem and thus is covered in generalized signalling dr= aft while others optical impairments are routing problem and are covered in a= separate document. Moreover even if the document you quoted is a well written and very u= seful one it is an informative contribution that simply points out the p= hysically impairments of an all optical network. It doesn't propose any ext= ension to OSPF/IS-IS in order to support optical routing. Given that in an All Optical Network we have to cope with lo= ts of new information, as you stated in your document, are we sure that OSPF= , in this environment, scales? I mean if it doesn't scale for wavelength availability information dis= tribution why it has to scales for other optical impairment distribution? ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modelling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Ayan Banerjee on 25/06/2001 22.26.02 = =20 = =20 = =20 =20 =20 =20 To: Diego Caviglia/MAIN/MC1@MCMAIN, =20 petera@nortelnetworks.con, ccamp@ops.ietf.org =20 =20 cc: Giovanni Fiaschi/MAIN/MC1@MCMAIN =20 =20 =20 =20 Subject: RE: Optical impairments in =20 draft-ietf-mpls-generalized-signaling- 04 =20 =20 = --0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f Content-type: text/plain; charset=us-ascii Content-Disposition: inline Diego, Please see draft-ietf-ipo-impairments-00.txt for optical constraints. Thanks, Ayan -----Original Message----- From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] Sent: Monday, June 25, 2001 6:19 AM To: petera@nortelnetworks.con; ccamp@ops.ietf.org Cc: Giovanni Fiaschi Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Peter ,all, a comment about draft-ietf-mpls-generalized-signaling-04. In the draft there is the label set object that is very useful in All optical networks with CI-incapable nodes but lambda conversion is only one of the problems related to path establishment in such networks. I mean what about OSNR and non-linear impairments? What about gain variation and power equalization? Where are covered these topic? If I can find a path feasible from the lambda continuity point of view who assure me that I have the needed Q at the end of the all optical path? Best regards. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modelling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com --0__=P653YbRnInKijSNl742SFCNCMkycZVjcVx9yxoCKnh9iJX1NNngdla6f-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 13:30:00 -0700 Message-ID: From: Ayan Banerjee To: 'Diego Caviglia' , petera@nortelnetworks.con, ccamp@ops.ietf.org Cc: Giovanni Fiaschi Subject: RE: Optical impairments in draft-ietf-mpls-generalized-signaling- 04 Date: Mon, 25 Jun 2001 13:26:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Diego, Please see draft-ietf-ipo-impairments-00.txt for optical constraints. Thanks, Ayan -----Original Message----- From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] Sent: Monday, June 25, 2001 6:19 AM To: petera@nortelnetworks.con; ccamp@ops.ietf.org Cc: Giovanni Fiaschi Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Peter ,all, a comment about draft-ietf-mpls-generalized-signaling-04. In the draft there is the label set object that is very useful in All optical networks with CI-incapable nodes but lambda conversion is only one of the problems related to path establishment in such networks. I mean what about OSNR and non-linear impairments? What about gain variation and power equalization? Where are covered these topic? If I can find a path feasible from the lambda continuity point of view who assure me that I have the needed Q at the end of the all optical path? Best regards. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modelling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 11:57:26 -0700 To: "Yangguang Xu" , "Suresh Katukam" Date: Mon, 25 Jun 2001 11:56:30 -0700 From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 Cc: "Eric Gray" , "ccamp@ops.ietf.org" Reply-To: lyndon_ong@eudoramail.com Subject: Re: Suggested Label Doubt Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Length: 681 Content-Transfer-Encoding: 7bit Isn't it Label Set that is used rather than Suggested Label when you want a bidirectional use of the same label value? At least in the UNI... Cheers, L. Ong -- On Mon, 25 Jun 2001 11:20:57 Suresh Katukam wrote: > >It is completely waste for bidirectional LSPs in TDM networks. In TDM networks, >the label must be same and current draft (OIF) specifies that the upstream >lable should be same as Suggested label. It should be really made optional >so that if an upstream node wants to suggest, then it has freedom to do so. > >Thanks, >Suresh > > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 11:53:05 -0700 Message-ID: <3B378875.3D84EB0E@sandburst.com> Date: Mon, 25 Jun 2001 14:52:37 -0400 From: Eric Gray MIME-Version: 1.0 To: Suresh Katukam Cc: Yangguang Xu , "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Suresh, I suspect that you're hitting close to the heart of the issue. It is arguable that suggested label is redundant in the TDM case - simply because it is intended to be the same. Clearly this is not going to be the case in other technologies within the GMPLS scope. A major objective of GMPLS is to develop common signaling for a number of technologies. There is no reason not to include a suggested label in a label request, even if it is redundant and it may be needed when it is not redundant. The suggested label is optional in all cases. -- Eric Gray You wrote: > Please see my response in line. > > > > > > In my understanding, the purpose of "suggested label" is to speed up circuit > > > > connection procedure by letting the upstream node to specify a label rather than > > > > following the conventional MPLS signaling procedure that receiving the label in > > > > the response. > > > > > > > > My questions are: > > > > > > > > (1) From a protocol design perspective, what's the benefit to suggest something > > > > that could be declined? > > > > > > The benefit is in optimizing the likely. As you point out below, it is likely > > > that the suggestion will be accepted, therefore - for the optimization reason > > > that you mention above (connection speedup) - it makes sense to allow the > > > 'suggestion'. > > > > > > > The key is that the likely is not likely in optical network. > > > > Basically, "suggested label" adds the local negotiation capability. > > Therotically, it's a good idea. But it's not necessary in the optical network. > > It is completely waste for bidirectional LSPs in TDM networks. In TDM networks, > the label must be same and current draft (OIF) specifies that the upstream > lable should be same as Suggested label. It should be really made optional > so that if an upstream node wants to suggest, then it has freedom to do so. > > Thanks, > Suresh Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 11:23:43 -0700 Message-ID: <3B378109.B5305A4B@cisco.com> Date: Mon, 25 Jun 2001 11:20:57 -0700 From: Suresh Katukam Organization: Cisco Systems MIME-Version: 1.0 To: Yangguang Xu CC: Eric Gray , "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please see my response in line. > > > > In my understanding, the purpose of "suggested label" is to speed up circuit > > > connection procedure by letting the upstream node to specify a label rather than > > > following the conventional MPLS signaling procedure that receiving the label in > > > the response. > > > > > > My questions are: > > > > > > (1) From a protocol design perspective, what's the benefit to suggest something > > > that could be declined? > > > > The benefit is in optimizing the likely. As you point out below, it is likely > > that the suggestion will be accepted, therefore - for the optimization reason > > that you mention above (connection speedup) - it makes sense to allow the > > 'suggestion'. > > > > The key is that the likely is not likely in optical network. > > Basically, "suggested label" adds the local negotiation capability. > Therotically, it's a good idea. But it's not necessary in the optical network. It is completely waste for bidirectional LSPs in TDM networks. In TDM networks, the label must be same and current draft (OIF) specifies that the upstream lable should be same as Suggested label. It should be really made optional so that if an upstream node wants to suggest, then it has freedom to do so. Thanks, Suresh Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 11:23:40 -0700 Message-ID: <3B378105.57D3C938@sandburst.com> Date: Mon, 25 Jun 2001 14:20:53 -0400 From: Eric Gray MIME-Version: 1.0 To: Yangguang Xu Cc: "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang, So, I was sure that this sort of discussion had occurred previously. It has. For example, you and I had an exchange on almost the exact same subject in March. See "Question regarding bi-directional connection set up" and later "Question regarding bi-directional connection set up - And Port-ID in Label object" threads for details. Both threads were discussed on both ccamp and mpls mailing lists, but not all postings appear in both archives. We SHOULD strive to avoid repeating arguments. Please see responses recursively embedded below. You wrote: > Eric, > > Please see my response in line. > > > > In my understanding, the purpose of "suggested label" is to speed up circuit > > > connection procedure by letting the upstream node to specify a label rather than > > > following the conventional MPLS signaling procedure that receiving the label in > > > the response. > > > > > > My questions are: > > > > > > (1) From a protocol design perspective, what's the benefit to suggest something > > > that could be declined? > > > > The benefit is in optimizing the likely. As you point out below, it is likely > > that the suggestion will be accepted, therefore - for the optimization reason > > that you mention above (connection speedup) - it makes sense to allow the > > 'suggestion'. > > > > The key is that the likely is not likely in optical network. By what definition of optical network? It is certainly likely in lambda switching. Also, the 'G' in "GMPLS" does not stand for "optical". > > > Basically, "suggested label" adds the local negotiation capability. > (Theoretically), it's a good idea. But it's not necessary in the optical network. Apparently, some people feel it is a good idea in practice, as well. This discussion has been hashed out multiple times before. > > > > > > > > > > > (2) Label is of local significance. In optical network, labels are physically > > > bound, not logically bound. This is different from conventional IP network. This > > > is also why there is no difference of which node (upstream or downstream) to > > > choose the label in optical network. (Normally upstream and downstream node > > > share almost the same knowledge of links that connect them.) > > > > This is a presumption, not necessarily guaranteed. > > > > Would you please give me an example that what I said is not true? Okay. Local significance - not every switch in an optical domain is necessarily capable of performing the same kind of "optical switching". This does not mean that they cannot interoperate - but it does mean that they may not interoperate in the way that you expect. Under these circumstances, the choice of "label" may have greater than local significance. Moreover, you cannot end up lambda switching two light beams of the same color into a single piece of glass. Upstream/Downstream indifference of choice - true in optical networks (at least "Normally"), but not particularly relevant. One or the other MUST have the final say and the model to-date has been that the final word is given by the downstream. Given that there MAY BE a scenario in which one or the other has less than complete knowledge, it is necessary to have a negotiation/arbitration mechanism. > > > Comparing to conventional IP MPLS, many "logical" value become "physical". This > has many implications to GMPLS. "All" logical values becoming physical MIGHT have implications on GMPLS. "Many" absolutely DOES NOT have such implications, since protocols need to support all interesting cases, not just many. > > > > > > > > > > > (3) In optical transport network, a upstream node may decline a label from a > > > downstream node as a downstream node may decline a "suggested label" from a > > > upstream node. The rejections are of the same reasons and frequency. > > > > True. > > > > > > > > > > > Why do we need to make the suggested label's operation so special? and not > > > necessary. > > > > As you have just described, the semantics - as they are now specified > > - make use of suggested label (from upstream) and distributed label > > (from downstream) equally in the form of a suggestion. But, look at how > > this true: if the upstream peer does not like a label distributed to it, it is > > required to request a new one (while holding onto the current one) and > > then release the one it does not want to use. The analog behavior for > > a more forceful 'suggested' label woud be for the downstream to issue > > a new label and then withdraw the requested label. This behavior is > > either explicitly disallowed or very much not supported in signaling. > > > > Therefore, I would tend to look at the current approach as making the > > suggested label NOT special. > > > > I don't disagree with your point. > > Indeed, you make me believe that "suggested label" may be a good idea for > conventional MPLS. Although it may add some complications. Assume that it adds just a jot of complexity, and next to no benefit at all, and it would not have been worth doing even when doing so would not also have meant joggling specifications in mature stages. > > > However, for optical network, I just don't see any application that can benefit > from the current semantics of the "suggested label". Can you give me an example? Examples have been given before. I'll not repeat them. > > > > > > > > > > > So I propose to change the semantic of the suggested label as such: (1) The > > > suggested label object/TLV is optional (2) However, if it is presented, it is > > > treated as the final decision. That is if the downstream node couldn't accept > > > the "suggested label", a connection rejection is responded. > > > > > > I am looking forward to hearing your opinions. > > > > I disagree. For one thing, given the current signaling specifications, what > > is likely to prevent the upstream from suggesting the exact same label > > again? > > > > Then, what is likely to prevent the downstream node from distributing the exact > same label again? If you read the above carefully, you will note that the upstream requests a new label while still retaining the old one. In this case, the downstream is required to give a different label. > > > Again, because of the change of many concepts from "logical" to "physical", the > role of upstream and downstream nodes are not different anymore in optical > network. In this case, it's not a "suggested" label anymore. It's just a > "distributed" label from upstream. It sounds to me like you are making observations based on assumptions about symmetry that are not necessarily true in all forms of "label" switching that might be supported by GMPLS. Is this the case? If so, then these are not particularly relevant observations. > > > Thanks, > > Yangguang To summarize, one objection raised in earlier discussions on the subject of merging upstream label and suggested label was that one was a request while the other was an assertion. You would now like to address this by making both assertions. It seems to me that there are other objections. It also seems to me that there is very little support to change the status quo. I suggest letting the issue drop. -- Eric Gray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 07:36:22 -0700 Message-ID: <3B374C1C.B8B05BFF@lucent.com> Date: Mon, 25 Jun 2001 10:35:08 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Eric Gray CC: "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Please see my response in line. > > In my understanding, the purpose of "suggested label" is to speed up circuit > > connection procedure by letting the upstream node to specify a label rather than > > following the conventional MPLS signaling procedure that receiving the label in > > the response. > > > > My questions are: > > > > (1) From a protocol design perspective, what's the benefit to suggest something > > that could be declined? > > The benefit is in optimizing the likely. As you point out below, it is likely > that the suggestion will be accepted, therefore - for the optimization reason > that you mention above (connection speedup) - it makes sense to allow the > 'suggestion'. > The key is that the likely is not likely in optical network. Basically, "suggested label" adds the local negotiation capability. Therotically, it's a good idea. But it's not necessary in the optical network. > > > > > > (2) Label is of local significance. In optical network, labels are physically > > bound, not logically bound. This is different from conventional IP network. This > > is also why there is no difference of which node (upstream or downstream) to > > choose the label in optical network. (Normally upstream and downstream node > > share almost the same knowledge of links that connect them.) > > This is a presumption, not necessarily guaranteed. > Would you please give me an example that what I said is not true? Comparing to conventional IP MPLS, many "logical" value become "physical". This has many implications to GMPLS. > > > > > > (3) In optical transport network, a upstream node may decline a label from a > > downstream node as a downstream node may decline a "suggested label" from a > > upstream node. The rejections are of the same reasons and frequency. > > True. > > > > > > > Why do we need to make the suggested label's operation so special? and not > > necessary. > > As you have just described, the semantics - as they are now specified > - make use of suggested label (from upstream) and distributed label > (from downstream) equally in the form of a suggestion. But, look at how > this true: if the upstream peer does not like a label distributed to it, it is > required to request a new one (while holding onto the current one) and > then release the one it does not want to use. The analog behavior for > a more forceful 'suggested' label woud be for the downstream to issue > a new label and then withdraw the requested label. This behavior is > either explicitly disallowed or very much not supported in signaling. > > Therefore, I would tend to look at the current approach as making the > suggested label NOT special. > I don't disagree with your point. Indeed, you make me believe that "suggested label" may be a good idea for conventional MPLS. Although it may add some complications. However, for optical network, I just don't see any application that can benefit from the current semantics of the "suggested label". Can you give me an example? > > > > > > So I propose to change the semantic of the suggested label as such: (1) The > > suggested label object/TLV is optional (2) However, if it is presented, it is > > treated as the final decision. That is if the downstream node couldn't accept > > the "suggested label", a connection rejection is responded. > > > > I am looking forward to hearing your opinions. > > I disagree. For one thing, given the current signaling specifications, what > is likely to prevent the upstream from suggesting the exact same label > again? > Then, what is likely to prevent the downstream node from distributing the exact same label again? Again, because of the change of many concepts from "logical" to "physical", the role of upstream and downstream nodes are not different anymore in optical network. In this case, it's not a "suggested" label anymore. It's just a "distributed" label from upstream. Thanks, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 06:52:23 -0700 Message-ID: <3B3741B7.4D9C6375@sandburst.com> Date: Mon, 25 Jun 2001 09:50:47 -0400 From: Eric Gray MIME-Version: 1.0 To: Yangguang Xu Cc: "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yangguang, Please see comments in line. You wrote: > Hello All, > > Just want to use this thread to clarify one of my confusions of current GMPLS > signaling - "suggested label". > > In my understanding, the purpose of "suggested label" is to speed up circuit > connection procedure by letting the upstream node to specify a label rather than > following the conventional MPLS signaling procedure that receiving the label in > the response. > > My questions are: > > (1) From a protocol design perspective, what's the benefit to suggest something > that could be declined? The benefit is in optimizing the likely. As you point out below, it is likely that the suggestion will be accepted, therefore - for the optimization reason that you mention above (connection speedup) - it makes sense to allow the 'suggestion'. > > > (2) Label is of local significance. In optical network, labels are physically > bound, not logically bound. This is different from conventional IP network. This > is also why there is no difference of which node (upstream or downstream) to > choose the label in optical network. (Normally upstream and downstream node > share almost the same knowledge of links that connect them.) This is a presumption, not necessarily guaranteed. > > > (3) In optical transport network, a upstream node may decline a label from a > downstream node as a downstream node may decline a "suggested label" from a > upstream node. The rejections are of the same reasons and frequency. True. > > > Why do we need to make the suggested label's operation so special? and not > necessary. As you have just described, the semantics - as they are now specified - make use of suggested label (from upstream) and distributed label (from downstream) equally in the form of a suggestion. But, look at how this true: if the upstream peer does not like a label distributed to it, it is required to request a new one (while holding onto the current one) and then release the one it does not want to use. The analog behavior for a more forceful 'suggested' label woud be for the downstream to issue a new label and then withdraw the requested label. This behavior is either explicitly disallowed or very much not supported in signaling. Therefore, I would tend to look at the current approach as making the suggested label NOT special. > > > So I propose to change the semantic of the suggested label as such: (1) The > suggested label object/TLV is optional (2) However, if it is presented, it is > treated as the final decision. That is if the downstream node couldn't accept > the "suggested label", a connection rejection is responded. > > I am looking forward to hearing your opinions. I disagree. For one thing, given the current signaling specifications, what is likely to prevent the upstream from suggesting the exact same label again? > > > Regards, > > Yangguang -- Eric Gray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 06:24:14 -0700 From: "Yuri Landry" To: ccamp@ops.ietf.org Bcc: Subject: How about other extensions to GMPLS? Date: Mon, 25 Jun 2001 13:23:16 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Some recent emails mentioned the OIF UNI document. I went through it and saw some new objects defined. I am not going to discuss OIF works here. But I have questions to ADs and WG Chairs about IETF GMPLS drafts. Should IETF GMPLS be the umbrella for all such related work? Current GMPLS signaling covers objects extensions. I am sure there will be more and more objects defined later when new applications being identified. These objects may be generalized and not technology specific as SONET/SDH and OTN. So shall we add them to the current GMPLS drafts? Regards, Yuri _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 25 Jun 2001 06:23:12 -0700 From: "Diego Caviglia" To: petera@nortelnetworks.con, ccamp@ops.ietf.org cc: "Giovanni Fiaschi" Message-ID: <80256A76.00491F52.00@marconicomms.com> Date: Mon, 25 Jun 2001 15:18:30 +0200 Subject: Optical impairments in draft-ietf-mpls-generalized-signaling-04 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Peter ,all, a comment about draft-ietf-mpls-generalized-signaling-04. In the draft there is the label set object that is very useful in All optical networks with CI-incapable nodes but lambda conversion is only one of the problems related to path establishment in such networks. I mean what about OSNR and non-linear impairments? What about gain variation and power equalization? Where are covered these topic? If I can find a path feasible from the lambda continuity point of view who assure me that I have the needed Q at the end of the all optical path? Best regards. ---------------------------------------------------------------- Diego Caviglia Photonic Networks Design and Modelling E-mail: diego.caviglia@marconi.com Tel: +39 (0) 10 6003 808 Via A. Negrone 1A 16153 Genoa (Italy) http://www.marconi.com Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Jun 2001 12:54:08 -0700 Message-ID: <01C0FCAC.D0FD2780.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'Wijnen, Bert (Bert)'" , ccamp-wg , "eric.gray@sandburst.com" , manoj juneja Subject: RE: Control Channel Doubt Date: Sun, 24 Jun 2001 12:54:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bert, While I understand your concern, I have a question. Since both MPLS and CCAMP WGs had issued a joint last call on the GMPLS drafts, aren't at least the GMPLS-related drafts are the subject of both WGs. Thanks, -Vishal On Friday, June 22, 2001 3:05 PM, Wijnen, Bert (Bert) [SMTP:bwijnen@lucent.com] wrote: > GMPLS related discussion is CCAMP > > Bert > > > ---------- > > From: manoj juneja[SMTP:manojkumarjuneja@hotmail.com] > > Sent: Friday, June 22, 2001 11:36 PM > > To: ccamp@ops.ietf.org; bwijnen@lucent.com; eric.gray@sandburst.com > > Subject: Re: Control Channel Doubt > > > > Eric, > > U are absolutely on track. This is what I was about to post. In > > response to my query, some people are copying the response on ccamp and > > some on mpls mailing list. Please clarify the procedure. I think we > > should have one mailing list. By keeping more mailing lists, we > > are confusing the people. Also, there is no clear demarcation of > > activities in WGs. Either we should shift whole GMPLS related stuff on > > ccamp mailing list otherwise we have to suffer these minor things. > > > > Regards, > > manoj. > > > > > > > > > > >From: Eric Gray > > >To: "Wijnen, Bert (Bert)" > > >CC: ccamp-wg , manoj juneja > > > > > >Subject: Re: Control Channel Doubt > > >Date: Fri, 22 Jun 2001 17:12:10 -0400 > > > > > >Bert, > > > > > > What would be the general procedure you would recommend for > > >a person wishing to post a question that applies to multiple groups? > > >What approach do you recommend they use to determine in advance > > >whether or not there is a largely overlapping audience? > > > > > >-- > > >Eric Gray > > > > > >You wrote: > > > > > > > Please DO NOT cross post to multiple mailing lists with largely > > > > overlapping audiences. Choose one list and discuss it there. > > > > > > > > Thanks, Bert > > > > > > > > > --- > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Jun 2001 08:56:42 -0700 Message-ID: <3B360CEC.8409D6BE@lucent.com> Date: Sun, 24 Jun 2001 11:53:16 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: Re: Suggested Label Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, Just want to use this thread to clarify one of my confusions of current GMPLS signaling - "suggested label". In my understanding, the purpose of "suggested label" is to speed up circuit connection procedure by letting the upstream node to specify a label rather than following the conventional MPLS signaling procedure that receiving the label in the response. My questions are: (1) From a protocol design perspective, what's the benefit to suggest something that could be declined? (2) Label is of local significance. In optical network, labels are physically bound, not logically bound. This is different from conventional IP network. This is also why there is no difference of which node (upstream or downstream) to choose the label in optical network. (Normally upstream and downstream node share almost the same knowledge of links that connect them.) (3) In optical transport network, a upstream node may decline a label from a downstream node as a downstream node may decline a "suggested label" from a upstream node. The rejections are of the same reasons and frequency. Why do we need to make the suggested label's operation so special? and not necessary. So I propose to change the semantic of the suggested label as such: (1) The suggested label object/TLV is optional (2) However, if it is presented, it is treated as the final decision. That is if the downstream node couldn't accept the "suggested label", a connection rejection is responded. I am looking forward to hearing your opinions. Regards, Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 24 Jun 2001 02:42:12 -0700 Message-ID: From: neil.2.harrison@bt.com To: fliaw@zaffire.com, manojkumarjuneja@hotmail.com, ccamp@ops.ietf.org Subject: RE: Diversity of Routes Doubt Date: Sun, 24 Jun 2001 10:27:39 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" 3 observations: 1 It difficult to understand the need for diversity and SVC-like connections......diversity becomes an increasingly important factor as trail holding time increases. So diversity is something important for permanent/semi-permanent trails set under the management-plane or, in a management proxy-type mode, by the control-plane (S-PVC-like). 2 All client layers inherit their connectivity from the duct network....so a knowledge of the topology of the duct network is essential to ensure diversity in a client network. However, no operator will own all the layers 'to the duct' globally......so peering via exterior-NNIs will be essential. This means that there will be no visibility of the duct topology (nor allowed control of L1 resources) outside of a single domain. Hence, the ability to calculate/force a strict source explicit route (or routes for diversity) across inter-oprerator boundaries will in general not be possible. 3 Item 2 above will impact other issues related to resilience. For example, even assuming one believes pre-emption will yield any tangible/deterministic benefit within a single domain it is hard to see how this concept could be extended across exterior-NNIs. Neil > -----Original Message----- > From: Fong Liaw [mailto:fliaw@zaffire.com] > Sent: 23 June 2001 01:25 > To: 'manoj juneja'; ccamp@ops.ietf.org > Subject: RE: Diversity of Routes Doubt > > > Manoj > > I am not sure CCAMP is the right email list to discuss > OIF UNI specific attributes/object. I will respond here, > but we can take it off-line or to oif-signal@oiforum.com > if needed. > > > -----Original Message----- > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Sent: Friday, June 22, 2001 4:43 PM > > To: ccamp@ops.ietf.org > > Subject: Diversity of Routes Doubt > > > > > > Hi All, > > The OIF-UNI draft contains diversity sub-object (part of > > Generalized UNI Attribute object). There is no such object in GMPLS > > drafts. In a typical scenario, where one O-UNI request has to be > > converted/translated/mapped to one GMPLS (NNI) request, how to > > interpret/translate the diversity TLV/object ? > > The UNI diversity subobject includes a connection identifier and > the diversity requirement, e.g. node, link, etc. The first > switch (ONE) should use the connection identifier to find out > the path (links and nodes) of the identified connection and > then use it to compute ERO that would diverse from the nodes, > links, or SRLG. > > > Is it the responsibility of network manager to offline > calculate the > > ERO (and pass in the path message from the edge/ingress ONE) which > > statisfies the diverstiy of the route desired by the client > > I don't think this can be done offline, since it changes > according to which connection you want to diversify from. > But it can be done by either centralized or distributed > computation, and precomputation might be possible. > > > equipment ? Does this mean the usage of strict routes in ERO ? > > Should we be having the diversity object in GMPLS drafts also ? > > Use of strict route in ERO is probably the simplest and common > approach in single domain. Using loose route ERO is possible > but could be more complicate. This may come into GMPLS/OIF NNI > if diversity across multiple domain becomes a requirement. > We don't have this requirement yet, so there is no need to introduce > it into GMPLS yet. > > Regards, > -Fong > > > > > Please clarify my doubt. > > > > Regards, > > manoj. > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 19:44:30 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3B340257.3628C7AB@lucent.com> Date: Sat, 23 Jun 2001 04:43:35 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------07B35EC38897359B71009661" This is a multi-part message in MIME format. --------------07B35EC38897359B71009661 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, manoj juneja wrote: > > Marteen, > Agreed, As per G.707, STM-64 consist of 64 VC-4 signals. I > have one doubt here. I want to discuss two cases in where two signals > viz. VC-4-3c (contiguously concatenated signals) and VC-4-3v (virtually > concatenated signals) have to be allocated to satisfy the two Label > Request/Path messages. Let's use a defined contiguous concatenated signal instead of the undefined VC-4-3c; i.e. let's make the example with VC-4-4c and VC-4-4v. > In case of VC-4-3c, do I have to allocate the contiguous VC-4s (viz. > say 4th, 5th and 6th and not 10th, 20th and 30th) ? Contiguous concatenation implies per G.707 the use of X contiguous timeslots to transport a VC-4-Xc. For the case of VC-4 these timeslots are really contiguous. Which timeslots to use for a VC-4-Xc (X=4,16,64,256) is defined in section 7/G.707 (10/2000). Subsection 7.3.2.3/G.707 specifies explictly the columns to use for the case of a VC-4-4c in a STM-64. E.g. for the case the VC-4-4c is transported via address (1,2,0,0), columns 5, 6, 7 and 8 of the STM-64 are the first 4 columns in which the VC-4-4c (1,2,0,0) is transported. The rest of this VC-4-4c (1,2,0,0) is transported in groups of 4 contiguous columns interspaced by 60 columns. Please be aware that for the case of a STS-Xc, groups of X/3 columns are contiguous in time. E.g. for the case of a STS-3c at (1,2,4,0) the first column is STM-64 column 8, the 2nd column is column 72 and the 3rd column is column 136. > If I allocate the > contiguous signal, does this mean in this case I have to pass only one > label corresponding to the multiplexing position of 4th VC-4 (Lowest > one) and other VC-4s will be derived by the receiving end from the > lowest signal. You have to pass the position of the 1st time slot which is occupied by the VC-4-4c signal. In the case of the example this is number 5. > > In case of contiguous concatenation, Can the contiguous VC-4 signals > span the AUG-Xc in STM-N [ like STM-64 consist of AUG-64. Say it > consist of 4 VC-4-16c. An AUG-Xc doesn't exist. A VC-4-Xc (X=4,16,64,256) fits exactly the AUG-X. E.g. in a STM-64 there is one AUG-64. This AUG-64 can contain either one AU-4-64c, or four AUG-16's. Each of the AUG-16's can contain either one AU-4-16c, or four AUG-4's. Each AUG-4 can contain either one AU-4-4c or four AUG-1's. Each AUG-1 can contain either one AU-4 or three AU-3's. A VC-4-16c is transported via a AU-4-16c. Within a STM-64, VC-4-16c signals can be transported via addresses (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0). Refer to section 7.3.2.4/G.707. > If I have to allocate 20 VC-4s in contiguous > concatenation, can I span VC-4s allocation across the AU-4-16cs ? Contiguous concatenation defined in G.707 doesn't support VC-4-20c. This would only be supported by the proprieraty arbitrary concatenation. In this case the VC-4-20c will be transported in a AU-4-20c. > > In case of virtual concatenation, Can I allocate non-contiguous signals > (viz. 10th, 20th, 30th) ? Virtual concatenation (e.g. VC-4-4v) as defined by G.707 allows you to transport the four VC-4 signals via either one STM-N signal, or via two STM-N signals, or via three STM-N singals or via four STM-N signals. For the case more than one (e.g. Y) of the X VC-4 signals in the VC-4-Xv signal is transported via the same STM-N signal, Y arbitrary selected AU-4 timeslots can be used; i.e. those timeslots may be contiguous or non-contiguous. GMPLS doesn't support this G.707 feature completely. GMPLS adds the restriction that all X VC-4 signals within the VC-4-Xv must be transported via the same STM-N signal. :-( Essentially, GMPLS is not suited to setup a VC-4-Xv; VC-4-Xv signals have to be setup via the management plane due to this restriction. > In this case I have to pass 3 labels > corresponding to each VC-4 position in the multiplexing hierarchy. For a VC-4-3v you have to pass a generalised label including 3 labels in the label field. > Does this hold true for arbitrary concatenation also ? Arbitrary contiguous concatenation is an extension of contiguous concatenation, allowing X to be any value in the range 1 to N. It has the same characteristics as contiguous concatenation, i.e. contiguous timeslots are used. As such, only one label has to be transmitted in the label field. Regards, Maarten > > Please clarify. > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: Eric.Mannie@ebone.com, ccamp@ops.ietf.org > >Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > >Date: Wed, 20 Jun 2001 03:46:04 +0200 > > > >Manoj, > > > >A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64 > >VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of > >VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer > >to G.707). > > > >A VC-4-16c signal can be transported in either one of the four AU-4-16c > >tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to > >7.2.3.4/G.707. > > > >Regards, > > > >Maarten > > > >manoj juneja wrote: > > > > > > Hi Eric, > > > Thanks for the reply. I have one more doubt : > > > > > > A STM-64 interface consist of 64 STM-1s that are byte interleaved. If > > > I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT > > > with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0, > > > MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to > > > allocate contiguous VC-4s in STM-64 link. > > > Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link. > > > Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal) > > > i.e. only one label will be passed in RESV/Label Mapping message. The > > > receiving node will drive the subsequent labels from this onwards. > > > > > > In case of arbitrary or virtual concatenation, Can I allocate non > > > -contiguous signals from a link ? The label corresponding to each > > > arbitrary or virtually concatenated signal will be passed in > > > RESV/Mapping message. > > > > > > If I have a STM-64 interface configured, and no signal is allocated yet > >from > > > the link. > > > If I have to allocate a signal STM-3c-7v (virtual concatenation of 7 > > > STM-3c), Can I allocate the whole signal from this link ? > > > > > > Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have > >to > > > pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0}, > > > {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ]. > > > > > > Does this mean that each STS-3c in STM-3c-7v should be contiguous ? > > > > > > Please tell me if my understanding is correct. > > > > > > Regards, > > > manoj. > > > > > > Regards, > > > manoj. > > > > > > >From: "Mannie, Eric" > > > >To: 'manoj juneja' , ccamp@ops.ietf.org > > > >Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > > >Date: Tue, 19 Jun 2001 10:02:56 +0200 > > > > > > > >Hello Manoj, > > > > > > > >The virtual concatenation is indicated in a separate field (NVC). The > > > >reason > > > >is to allow to code the virtual concatenation of contiguously > >concatenated > > > >signals (like the virtual concatenation of several STS-3c's. > > > > > > > >Kind regards, > > > > > > > >Eric > > > > > > > >-----Original Message----- > > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > > >Sent: Tuesday, June 19, 2001 3:03 AM > > > >To: ccamp@ops.ietf.org > > > >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > > > > > > > > > > >Hi, > > > > > > > > I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : > > > > > > > > The CCT field can have values no concatenation, standard > > > >concatenation, arbitrary, vendor specific. > > > >But why can't virtual concatenation ? It was there in original draft. > > > >But in the exmaples section for SDH/SONET signals, it is shown that a > > > >virtually concatenated signal can be built using NVC field with CCT > > > >value as 0. Please clarify the reason in doing so. > > > > > > > >Regards, > > > >manoj. > > > > > > > >_________________________________________________________________ > > > >Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > ><< mvissers.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------07B35EC38897359B71009661 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 --------------07B35EC38897359B71009661-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 18:26:36 -0700 Message-ID: <01C0FB48.FC80F220.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'manoj juneja'" , "ccamp@ops.ietf.org" Subject: RE: Suggested Label Doubt Date: Fri, 22 Jun 2001 18:27:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Manoj, The answer to your question is "Yes." The reason is, the the purpose of the label set is to request subsequent nodes to pick wavlengths from the set specified in the label set (for example, nodes may have a limited wavelength translation capability, restricting them to certain wavelengths), since previous nodes would have done so. If, however, the setup request crosses a fully wavelength translation capable node, that node could drop the label set. (Note, however, that if the node immediately following this one has restrictions, that node could again introduce a new/different label set.) -Vishal On Friday, June 22, 2001 6:02 PM, manoj juneja [SMTP:manojkumarjuneja@hotmail.com] wrote: > Vishal, > > As u mentioned, that label set may get restricted in > transit, but can the label set be completely dropped out at some > transit node ? I mean to say if u reach at a node (transit node) which > is capable of wavelength conversion (say any LAMBDA m to LAMBDA n i.e. > any to any capability), Can this node drop the label set ? > > Regards, > manoj. > > > > > >From: Vishal Sharma > >Reply-To: "v.sharma@ieee.org" > >To: "'manoj juneja'" , > >"ccamp@ops.ietf.org" > >Subject: RE: Suggested Label Doubt > >Date: Fri, 22 Jun 2001 17:35:23 -0700 > > > >Manoj, > > > >You think correctly. A label, by definition, has local significance > >(between > >adjacent > >MPLS nodes). > > > >That the suggested label and label set may have significance beyond a > >single > >MPLS hop is simply because the nodes choose to assert the same value for > >subsequent hops as well. > >And yes, technically both the suggested label and the label set may change > >at each hop. > >(For example, consider an optical network with no wavelength conversion > >capability. > > A label set that represents the wavelengths that can be allocated [say, > >lambda1 through lamba6] may, for example, > >become more restricted as the request advances, since subsequent nodes may > >not > >have all of these > >wavelengths available [only lambda2 and lambda4 may be available beyond > >some > >node for instance]). > > > >-Vishal > > > >On Friday, June 22, 2001 5:13 PM, manoj juneja > >[SMTP:manojkumarjuneja@hotmail.com] wrote: > > > Hi All, > > > Can Suggested Label change hop-by-hop (or even dropped at > > > some transit node) like Label set may change hop-by-hop (or even > > > dropped at some transit node) ? I think both should have a link by link > > > significance as in case of label. > > > > > > Please clarify. > > > > > > Regards, > > > manoj. > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 18:03:21 -0700 From: "manoj juneja" To: v.sharma@ieee.org, ccamp@ops.ietf.org Bcc: Subject: RE: Suggested Label Doubt Date: Fri, 22 Jun 2001 18:02:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Vishal, As u mentioned, that label set may get restricted in transit, but can the label set be completely dropped out at some transit node ? I mean to say if u reach at a node (transit node) which is capable of wavelength conversion (say any LAMBDA m to LAMBDA n i.e. any to any capability), Can this node drop the label set ? Regards, manoj. >From: Vishal Sharma >Reply-To: "v.sharma@ieee.org" >To: "'manoj juneja'" , >"ccamp@ops.ietf.org" >Subject: RE: Suggested Label Doubt >Date: Fri, 22 Jun 2001 17:35:23 -0700 > >Manoj, > >You think correctly. A label, by definition, has local significance >(between >adjacent >MPLS nodes). > >That the suggested label and label set may have significance beyond a >single >MPLS hop is simply because the nodes choose to assert the same value for >subsequent hops as well. >And yes, technically both the suggested label and the label set may change >at each hop. >(For example, consider an optical network with no wavelength conversion >capability. > A label set that represents the wavelengths that can be allocated [say, >lambda1 through lamba6] may, for example, >become more restricted as the request advances, since subsequent nodes may >not >have all of these >wavelengths available [only lambda2 and lambda4 may be available beyond >some >node for instance]). > >-Vishal > >On Friday, June 22, 2001 5:13 PM, manoj juneja >[SMTP:manojkumarjuneja@hotmail.com] wrote: > > Hi All, > > Can Suggested Label change hop-by-hop (or even dropped at > > some transit node) like Label set may change hop-by-hop (or even > > dropped at some transit node) ? I think both should have a link by link > > significance as in case of label. > > > > Please clarify. > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 17:32:49 -0700 Message-ID: <01C0FB41.B84130E0.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'manoj juneja'" , "ccamp@ops.ietf.org" Subject: RE: Suggested Label Doubt Date: Fri, 22 Jun 2001 17:35:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Manoj, You think correctly. A label, by definition, has local significance (between adjacent MPLS nodes). That the suggested label and label set may have significance beyond a single MPLS hop is simply because the nodes choose to assert the same value for subsequent hops as well. And yes, technically both the suggested label and the label set may change at each hop. (For example, consider an optical network with no wavelength conversion capability. A label set that represents the wavelengths that can be allocated [say, lambda1 through lamba6] may, for example, become more restricted as the request advances, since subsequent nodes may not have all of these wavelengths available [only lambda2 and lambda4 may be available beyond some node for instance]). -Vishal On Friday, June 22, 2001 5:13 PM, manoj juneja [SMTP:manojkumarjuneja@hotmail.com] wrote: > Hi All, > Can Suggested Label change hop-by-hop (or even dropped at > some transit node) like Label set may change hop-by-hop (or even > dropped at some transit node) ? I think both should have a link by link > significance as in case of label. > > Please clarify. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 17:25:15 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B8F79@ICARIAN> From: Fong Liaw To: 'manoj juneja' , ccamp@ops.ietf.org Subject: RE: Diversity of Routes Doubt Date: Fri, 22 Jun 2001 17:24:30 -0700 MIME-Version: 1.0 Content-Type: text/plain Manoj I am not sure CCAMP is the right email list to discuss OIF UNI specific attributes/object. I will respond here, but we can take it off-line or to oif-signal@oiforum.com if needed. > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Friday, June 22, 2001 4:43 PM > To: ccamp@ops.ietf.org > Subject: Diversity of Routes Doubt > > > Hi All, > The OIF-UNI draft contains diversity sub-object (part of > Generalized UNI Attribute object). There is no such object in GMPLS > drafts. In a typical scenario, where one O-UNI request has to be > converted/translated/mapped to one GMPLS (NNI) request, how to > interpret/translate the diversity TLV/object ? The UNI diversity subobject includes a connection identifier and the diversity requirement, e.g. node, link, etc. The first switch (ONE) should use the connection identifier to find out the path (links and nodes) of the identified connection and then use it to compute ERO that would diverse from the nodes, links, or SRLG. > Is it the responsibility of network manager to offline calculate the > ERO (and pass in the path message from the edge/ingress ONE) which > statisfies the diverstiy of the route desired by the client I don't think this can be done offline, since it changes according to which connection you want to diversify from. But it can be done by either centralized or distributed computation, and precomputation might be possible. > equipment ? Does this mean the usage of strict routes in ERO ? > Should we be having the diversity object in GMPLS drafts also ? Use of strict route in ERO is probably the simplest and common approach in single domain. Using loose route ERO is possible but could be more complicate. This may come into GMPLS/OIF NNI if diversity across multiple domain becomes a requirement. We don't have this requirement yet, so there is no need to introduce it into GMPLS yet. Regards, -Fong > > Please clarify my doubt. > > Regards, > manoj. > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 17:13:23 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Suggested Label Doubt Date: Fri, 22 Jun 2001 17:12:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Can Suggested Label change hop-by-hop (or even dropped at some transit node) like Label set may change hop-by-hop (or even dropped at some transit node) ? I think both should have a link by link significance as in case of label. Please clarify. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 17:03:24 -0700 From: "manoj juneja" To: mvissers@lucent.com, ccamp@ops.ietf.org Bcc: Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Date: Fri, 22 Jun 2001 17:02:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Marteen, Agreed, As per G.707, STM-64 consist of 64 VC-4 signals. I have one doubt here. I want to discuss two cases in where two signals viz. VC-4-3c (contiguously concatenated signals) and VC-4-3v (virtually concatenated signals) have to be allocated to satisfy the two Label Request/Path messages. In case of VC-4-3c, do I have to allocate the contiguous VC-4s (viz. say 4th, 5th and 6th and not 10th, 20th and 30th) ? If I allocate the contiguous signal, does this mean in this case I have to pass only one label corresponding to the multiplexing position of 4th VC-4 (Lowest one) and other VC-4s will be derived by the receiving end from the lowest signal. In case of contiguous concatenation, Can the contiguous VC-4 signals span the AUG-Xc in STM-N [ like STM-64 consist of AUG-64. Say it consist of 4 VC-4-16c. If I have to allocate 20 VC-4s in contiguous concatenation, can I span VC-4s allocation across the AU-4-16cs ? In case of virtual concatenation, Can I allocate non-contiguous signals (viz. 10th, 20th, 30th) ? In this case I have to pass 3 labels corresponding to each VC-4 position in the multiplexing hierarchy. Does this hold true for arbitrary concatenation also ? Please clarify. Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: Eric.Mannie@ebone.com, ccamp@ops.ietf.org >Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt >Date: Wed, 20 Jun 2001 03:46:04 +0200 > >Manoj, > >A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64 >VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of >VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer >to G.707). > >A VC-4-16c signal can be transported in either one of the four AU-4-16c >tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to >7.2.3.4/G.707. > >Regards, > >Maarten > >manoj juneja wrote: > > > > Hi Eric, > > Thanks for the reply. I have one more doubt : > > > > A STM-64 interface consist of 64 STM-1s that are byte interleaved. If > > I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT > > with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0, > > MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to > > allocate contiguous VC-4s in STM-64 link. > > Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link. > > Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal) > > i.e. only one label will be passed in RESV/Label Mapping message. The > > receiving node will drive the subsequent labels from this onwards. > > > > In case of arbitrary or virtual concatenation, Can I allocate non > > -contiguous signals from a link ? The label corresponding to each > > arbitrary or virtually concatenated signal will be passed in > > RESV/Mapping message. > > > > If I have a STM-64 interface configured, and no signal is allocated yet >from > > the link. > > If I have to allocate a signal STM-3c-7v (virtual concatenation of 7 > > STM-3c), Can I allocate the whole signal from this link ? > > > > Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have >to > > pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0}, > > {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ]. > > > > Does this mean that each STS-3c in STM-3c-7v should be contiguous ? > > > > Please tell me if my understanding is correct. > > > > Regards, > > manoj. > > > > Regards, > > manoj. > > > > >From: "Mannie, Eric" > > >To: 'manoj juneja' , ccamp@ops.ietf.org > > >Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > >Date: Tue, 19 Jun 2001 10:02:56 +0200 > > > > > >Hello Manoj, > > > > > >The virtual concatenation is indicated in a separate field (NVC). The > > >reason > > >is to allow to code the virtual concatenation of contiguously >concatenated > > >signals (like the virtual concatenation of several STS-3c's. > > > > > >Kind regards, > > > > > >Eric > > > > > >-----Original Message----- > > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > >Sent: Tuesday, June 19, 2001 3:03 AM > > >To: ccamp@ops.ietf.org > > >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > > > > > > > >Hi, > > > > > > I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : > > > > > > The CCT field can have values no concatenation, standard > > >concatenation, arbitrary, vendor specific. > > >But why can't virtual concatenation ? It was there in original draft. > > >But in the exmaples section for SDH/SONET signals, it is shown that a > > >virtually concatenated signal can be built using NVC field with CCT > > >value as 0. Please clarify the reason in doing so. > > > > > >Regards, > > >manoj. > > > > > >_________________________________________________________________ > > >Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 16:44:27 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Diversity of Routes Doubt Date: Fri, 22 Jun 2001 16:42:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, The OIF-UNI draft contains diversity sub-object (part of Generalized UNI Attribute object). There is no such object in GMPLS drafts. In a typical scenario, where one O-UNI request has to be converted/translated/mapped to one GMPLS (NNI) request, how to interpret/translate the diversity TLV/object ? Is it the responsibility of network manager to offline calculate the ERO (and pass in the path message from the edge/ingress ONE) which statisfies the diverstiy of the route desired by the client equipment ? Does this mean the usage of strict routes in ERO ? Should we be having the diversity object in GMPLS drafts also ? Please clarify my doubt. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 15:21:52 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B8F76@ICARIAN> From: Fong Liaw To: 'manoj juneja' , saurabh@timetra.com, skatukam@cisco.com, ccamp@ops.ietf.org, braja@tellium.com, kireeti@juniper.com Subject: RE: Control Channel Doubt Date: Fri, 22 Jun 2001 15:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain Hi, Manoj > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Friday, June 22, 2001 2:53 PM > To: saurabh@timetra.com; skatukam@cisco.com; ccamp@ops.ietf.org; > braja@tellium.com; kireeti@juniper.com > Subject: RE: Control Channel Doubt > > > Hi, > I think the original purpose of LIH in classical RSVP > was somewhat You are correct here. That's why RSVP_HOP3 object is introduced in oif2000.125.5. > different. The latest draft of O-UNI (oif2000.125.5) has new > RSVP object RSVP_HOP3. This draft reccomends usage of > RSVP_HOP3 object > instead of traditional RSVP_HOP object. This new object has > been added > for the intention of non-associated signalling. The struture of > RSVP_HOP3 is : > > { > IPCC's Next/previous Hop > LIH (control channel's LIH) > TLVs. > } > > The TLVs in the above structure specify the interface for the data > flow. The TLVs can include maxmum of 2 interface Ids (viz. one for > forward direction of data flow and another for reverse direction of > data flow). > But I don't know whether this object will be equally applicable to > GMPLS or not. Whether GMPLS drafts are also going to include the > RSVP_HOP3 object in next revision ? It is the intension to align both OIF and IETF in this aspect. The object actually comes from GMPLS authors. The format is not final yet as noted by OIF2000.125.5. The reason that HOP3 even showed up in OIF2000.125.5 is to address comments on using LIH in SuperComm test/interim agreement. Regards, -Fong > > Authors of OIF draft, Bala, Kireeti etc. : Please clarify whether the > RSVP_HOP3 object has been kept with this intention only or there is > some other reason too. > > Regards, > manoj. > > >From: "Saurabh Shrivastava" > >Reply-To: > >To: "'manoj juneja'" , "Mpls > \(E-mail\)" > > > >Subject: RE: Control Channel Doubt > >Date: Fri, 22 Jun 2001 13:00:03 -0700 > > > >manoj, > >there is something called a LIH (logical interface > >handle) in the HOP Object in the PATH message - this > >shd be copied into the RESV, so that the receiver > >can know on which interface it shd make reservations > >even if it receives RESV on some other interface. > >-saurabh > > > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ > >Saurabh Shrivastava saurabh@timetra.com > > > >TiMetra Networks, Inc. 408.245.8796 (residence) > >http://www.timetra.com/ 650.237.5154 (office) > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ > > > > > ># -----Original Message----- > ># From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On > Behalf Of manoj > ># juneja > ># Sent: Friday, June 22, 2001 12:37 PM > ># To: ccamp@ops.ietf.org; mpls@UU.NET > ># Subject: Control Channel Doubt > ># > ># > ># Hi All, > ># Consider the following scenario : > ># > ># If I have 2 nodes A and B connected by 3 links (viz. OC-3, > ># OC-192 and > ># OC-48). Furthermore, I have a out-of-fiber control > channel running on > ># ethernet between these two nodes. Here, I am considering the > ># case of one > ># control channel for all the three data plane interfaces. When > ># an incoming > ># path message is received, how to identify for which incoming > ># data plane > ># interface this is for ? or Do I have to configure three > ># control channels > ># correspondng to each of the data plane interfaces ? > ># > ># Please clarify my doubt. > ># > ># Regards, > ># manoj. > ># > ># > ># > ># _________________________________________________________________ > ># Get your FREE download of MSN Explorer at http://explorer.msn.com > ># > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 15:05:40 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB6128F@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , eric.gray@sandburst.com, manoj juneja Subject: RE: Control Channel Doubt Date: Sat, 23 Jun 2001 00:05:12 +0200 MIME-Version: 1.0 Content-Type: text/plain GMPLS related discussion is CCAMP Bert > ---------- > From: manoj juneja[SMTP:manojkumarjuneja@hotmail.com] > Sent: Friday, June 22, 2001 11:36 PM > To: ccamp@ops.ietf.org; bwijnen@lucent.com; eric.gray@sandburst.com > Subject: Re: Control Channel Doubt > > Eric, > U are absolutely on track. This is what I was about to post. In > response to my query, some people are copying the response on ccamp and > some on mpls mailing list. Please clarify the procedure. I think we > should have one mailing list. By keeping more mailing lists, we > are confusing the people. Also, there is no clear demarcation of > activities in WGs. Either we should shift whole GMPLS related stuff on > ccamp mailing list otherwise we have to suffer these minor things. > > Regards, > manoj. > > > > > >From: Eric Gray > >To: "Wijnen, Bert (Bert)" > >CC: ccamp-wg , manoj juneja > > > >Subject: Re: Control Channel Doubt > >Date: Fri, 22 Jun 2001 17:12:10 -0400 > > > >Bert, > > > > What would be the general procedure you would recommend for > >a person wishing to post a question that applies to multiple groups? > >What approach do you recommend they use to determine in advance > >whether or not there is a largely overlapping audience? > > > >-- > >Eric Gray > > > >You wrote: > > > > > Please DO NOT cross post to multiple mailing lists with largely > > > overlapping audiences. Choose one list and discuss it there. > > > > > > Thanks, Bert > > > > > > > --- > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 14:54:36 -0700 From: "manoj juneja" To: saurabh@timetra.com, skatukam@cisco.com, ccamp@ops.ietf.org, braja@tellium.com, kireeti@juniper.com Bcc: Subject: RE: Control Channel Doubt Date: Fri, 22 Jun 2001 14:52:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, I think the original purpose of LIH in classical RSVP was somewhat different. The latest draft of O-UNI (oif2000.125.5) has new RSVP object RSVP_HOP3. This draft reccomends usage of RSVP_HOP3 object instead of traditional RSVP_HOP object. This new object has been added for the intention of non-associated signalling. The struture of RSVP_HOP3 is : { IPCC's Next/previous Hop LIH (control channel's LIH) TLVs. } The TLVs in the above structure specify the interface for the data flow. The TLVs can include maxmum of 2 interface Ids (viz. one for forward direction of data flow and another for reverse direction of data flow). But I don't know whether this object will be equally applicable to GMPLS or not. Whether GMPLS drafts are also going to include the RSVP_HOP3 object in next revision ? Authors of OIF draft, Bala, Kireeti etc. : Please clarify whether the RSVP_HOP3 object has been kept with this intention only or there is some other reason too. Regards, manoj. >From: "Saurabh Shrivastava" >Reply-To: >To: "'manoj juneja'" , "Mpls \(E-mail\)" > >Subject: RE: Control Channel Doubt >Date: Fri, 22 Jun 2001 13:00:03 -0700 > >manoj, >there is something called a LIH (logical interface >handle) in the HOP Object in the PATH message - this >shd be copied into the RESV, so that the receiver >can know on which interface it shd make reservations >even if it receives RESV on some other interface. >-saurabh > >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ >Saurabh Shrivastava saurabh@timetra.com > >TiMetra Networks, Inc. 408.245.8796 (residence) >http://www.timetra.com/ 650.237.5154 (office) >~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ > > ># -----Original Message----- ># From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of manoj ># juneja ># Sent: Friday, June 22, 2001 12:37 PM ># To: ccamp@ops.ietf.org; mpls@UU.NET ># Subject: Control Channel Doubt ># ># ># Hi All, ># Consider the following scenario : ># ># If I have 2 nodes A and B connected by 3 links (viz. OC-3, ># OC-192 and ># OC-48). Furthermore, I have a out-of-fiber control channel running on ># ethernet between these two nodes. Here, I am considering the ># case of one ># control channel for all the three data plane interfaces. When ># an incoming ># path message is received, how to identify for which incoming ># data plane ># interface this is for ? or Do I have to configure three ># control channels ># correspondng to each of the data plane interfaces ? ># ># Please clarify my doubt. ># ># Regards, ># manoj. ># ># ># ># _________________________________________________________________ ># Get your FREE download of MSN Explorer at http://explorer.msn.com ># _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 14:49:24 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB6128A@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eric Gray Cc: ccamp-wg , manoj juneja Subject: RE: Control Channel Doubt Date: Fri, 22 Jun 2001 23:49:00 +0200 MIME-Version: 1.0 Content-Type: text/plain I would say that if you have a topic, you choose one mailing list to discuss (and the topic of course should be relevant to the WG itself). That is where you post it and where you do discussion. If you feel that another WG has a different set of people whom you want to be involved, then you do a separate posting to that list and invite the people to join on the first list for discussion. Sorry... but in the CCAMP,. IPO, MPLS set of WG lists, I seem to be getting FAR TOO MANY duplicate postings because of all that cross posting. And it seems to me that MANY people suffer from the same. Bert > ---------- > From: Eric Gray[SMTP:eric.gray@sandburst.com] > Sent: Friday, June 22, 2001 11:12 PM > To: Wijnen, Bert (Bert) > Cc: ccamp-wg; manoj juneja > Subject: Re: Control Channel Doubt > > Bert, > > What would be the general procedure you would recommend for > a person wishing to post a question that applies to multiple groups? > What approach do you recommend they use to determine in advance > whether or not there is a largely overlapping audience? > > -- > Eric Gray > > You wrote: > > > Please DO NOT cross post to multiple mailing lists with largely > > overlapping audiences. Choose one list and discuss it there. > > > > Thanks, Bert > > > > > --- > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 14:47:09 -0700 Message-ID: <3B33BCCE.BF0274F6@lucent.com> Date: Fri, 22 Jun 2001 17:46:54 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org, bwijnen@lucent.com, eric.gray@sandburst.com Subject: Re: Control Channel Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, The question you ask is clearly in the scope of CCAMP only. Regards, Yangguang manoj juneja wrote: > > Eric, > U are absolutely on track. This is what I was about to post. In > response to my query, some people are copying the response on ccamp and > some on mpls mailing list. Please clarify the procedure. I think we > should have one mailing list. By keeping more mailing lists, we > are confusing the people. Also, there is no clear demarcation of > activities in WGs. Either we should shift whole GMPLS related stuff on > ccamp mailing list otherwise we have to suffer these minor things. > > Regards, > manoj. > > >From: Eric Gray > >To: "Wijnen, Bert (Bert)" > >CC: ccamp-wg , manoj juneja > > > >Subject: Re: Control Channel Doubt > >Date: Fri, 22 Jun 2001 17:12:10 -0400 > > > >Bert, > > > > What would be the general procedure you would recommend for > >a person wishing to post a question that applies to multiple groups? > >What approach do you recommend they use to determine in advance > >whether or not there is a largely overlapping audience? > > > >-- > >Eric Gray > > > >You wrote: > > > > > Please DO NOT cross post to multiple mailing lists with largely > > > overlapping audiences. Choose one list and discuss it there. > > > > > > Thanks, Bert > > > > > > > --- > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 14:37:25 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org, bwijnen@lucent.com, eric.gray@sandburst.com Bcc: Subject: Re: Control Channel Doubt Date: Fri, 22 Jun 2001 14:36:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Eric, U are absolutely on track. This is what I was about to post. In response to my query, some people are copying the response on ccamp and some on mpls mailing list. Please clarify the procedure. I think we should have one mailing list. By keeping more mailing lists, we are confusing the people. Also, there is no clear demarcation of activities in WGs. Either we should shift whole GMPLS related stuff on ccamp mailing list otherwise we have to suffer these minor things. Regards, manoj. >From: Eric Gray >To: "Wijnen, Bert (Bert)" >CC: ccamp-wg , manoj juneja > >Subject: Re: Control Channel Doubt >Date: Fri, 22 Jun 2001 17:12:10 -0400 > >Bert, > > What would be the general procedure you would recommend for >a person wishing to post a question that applies to multiple groups? >What approach do you recommend they use to determine in advance >whether or not there is a largely overlapping audience? > >-- >Eric Gray > >You wrote: > > > Please DO NOT cross post to multiple mailing lists with largely > > overlapping audiences. Choose one list and discuss it there. > > > > Thanks, Bert > > > > > --- > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 14:14:36 -0700 Message-ID: <3B33B4AA.4E616501@sandburst.com> Date: Fri, 22 Jun 2001 17:12:10 -0400 From: Eric Gray MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: ccamp-wg , manoj juneja Subject: Re: Control Channel Doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bert, What would be the general procedure you would recommend for a person wishing to post a question that applies to multiple groups? What approach do you recommend they use to determine in advance whether or not there is a largely overlapping audience? -- Eric Gray You wrote: > Please DO NOT cross post to multiple mailing lists with largely > overlapping audiences. Choose one list and discuss it there. > > Thanks, Bert > > > --- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 13:40:21 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB6127C@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , manoj juneja Subject: RE: Control Channel Doubt Date: Fri, 22 Jun 2001 22:35:55 +0200 MIME-Version: 1.0 Content-Type: text/plain Please DO NOT cross post to multiple mailing lists with largely overlapping audiences. Choose one list and discuss it there. Thanks, Bert > ---------- > From: manoj juneja[SMTP:manojkumarjuneja@hotmail.com] > Sent: Friday, June 22, 2001 9:37 PM > To: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Control Channel Doubt > > Hi All, > Consider the following scenario : > > If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and > OC-48). Furthermore, I have a out-of-fiber control channel running on > ethernet between these two nodes. Here, I am considering the case of one > control channel for all the three data plane interfaces. When an incoming > path message is received, how to identify for which incoming data plane > interface this is for ? or Do I have to configure three control channels > correspondng to each of the data plane interfaces ? > > Please clarify my doubt. > > Regards, > manoj. > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 12:42:04 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org, mpls@UU.NET Bcc: Subject: Control Channel Doubt Date: Fri, 22 Jun 2001 12:37:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Consider the following scenario : If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and OC-48). Furthermore, I have a out-of-fiber control channel running on ethernet between these two nodes. Here, I am considering the case of one control channel for all the three data plane interfaces. When an incoming path message is received, how to identify for which incoming data plane interface this is for ? or Do I have to configure three control channels correspondng to each of the data plane interfaces ? Please clarify my doubt. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 22 Jun 2001 10:57:14 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: GMPLS Doubt Date: Fri, 22 Jun 2001 10:49:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In the draft draft-ietf-mpls-generalized-signalling-04.txt, different values of LSP encoding type are defined. What all values of LSP encoding type are currently supported by GMPLS ? The GMPLS draft does not specify the Label formats for ANSI/ETSI PDH etc. I think the only supported values of LSP encoding type are : SDH ITU-T G.707 1996 SONET ANSI T1.105-1995 SDH ITU-T G.707 2000 SONET ANSI T1.105-2000 Fiber Lambda Packet [ classical MPLS : IP Labels/FR Labels/ATM Labels ] Please comment. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Jun 2001 21:47:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: To: ccamp-approval@psg.com From: owner-ccamp@ops.ietf.org Subject: BOUNCE ccamp@ops.ietf.org: Header line too long (>128) Date: Thu, 21 Jun 2001 17:03:55 -0700 >From owner-mpls@UU.NET Thu Jun 21 17:03:54 2001 Message-ID: <46f301c0faae$bebd1490$0e03ca0a@cp98suwbm02> Date: Thu, 21 Jun 2001 17:03:19 -0700 Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 To: Cc: , , , , , Sender: Precedence: bulk Bala, Thanks for your reply. Sorry it took so long to reply back. Please see in-line. Thanks, Ananth bala>> > 1) Type of legacy equipment needing NSAP addresses bala>> > (also, is bala>> > this optical network element or client equipment?) bala>> > 2) Rough estimate of number of UNI ports needing NSAP address bala>> > (2002, 2005, and 2010) bala>> > 3) Description of application in which this legacy equipment bala>> > will use UNI bala>> > signaling bala>I don't recall seeing any response. furthermore, the NSAP bala>requirement was not unanimously endorsed by all carriers (at bala>the OIF). >From our OIF representatives, although it was not unanimously endorsed, there was a significant demand for NSAP support. Well, NSAP is the main non-IP type of addressing that is required. The general requirement is to be able to support non-IP addresses (probably have an address translation from non-IP addresses to routable addresses). bala>It would also be nice if you can give some insight on bala>the timeline in which you need various features, and whether bala>the current GMPLS developments are inadequate within bala>that timeline. (We can always have a progression of features). NSAP support will be needed always (e.g. support for legacy DCC that uses NSAP). So the timeframe requirement is now. Ananth>2) GMPLS is being defined based on assumptions about proprietary Ananth>transmission planes without those assumptions being specified. How can Ananth>we be sure that the control plane support is correct? How can we be Ananth>sure that it can be combined with other features? Assumptions Ananth>regarding the transmission plane that can affect the control plane must Ananth>be clearly documented. This creates the additional related problem that Ananth>there is not a clear inter-working defined for interaction between Ananth>standard/proprietary control planes/transmission planes. bala>BR: I get the feeling you're referring to the concatenation/transperency bala>issues discussed recently. While the debate has been hot, there's bala>no show stopper here. Several suggestions are being considered for bala>clarifying standard/non-standard features supported. The concatenation/transparency issues are a concern. In addition, management features such as manual protection switching, protection switching configuration, billing support (e.g. usage collection) etc need to be supported too. Ananth>3) Assuring separation of the control plane from the data plane Ananth>continues to arise.. When the control plane fails it should not affect Ananth> existing connections. Also if connections in progress are affected Ananth>then they should not leave partially setup connections - they should Ananth>fail gracefully informing the initiator. The GMPLS architecture Ananth>document mentions this separation, but it's not clear how the GMPLS Ananth>signaling specifications reflect the implications of this decoupling. bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS bala>based, as you know), and solutions in the RSVP/LDP space have been bala>proposed (some drafts may be written). bala>This is also not a show stopper by any means. Don't understand how the OIF UNI addresses this. Our concerns are more with respect to the NNI (internal separation of control and data). If this is not addressed, it is definitely a showstopper. According to our OIF representatives, the OIF is looking at the IETF to specify these protocols. To be specific, existing connections shouldn't be impacted when the control plane fails. Ananth>4) Support for NSAP addresses and in general support such that control Ananth>plane addressing is independent of clients and vice versa. Also Ananth>scalable naming/addressing scheme such as proposed in OIF. bala>BR: NSAP, see my initial comments. The OIF is not dealing with bala>names/resolution, etc. This has been decided to be out of the bala>scope of UNI signaling, and considered as a separate function. Address translation of some form (for e.g. NSAP address translation) should be supported. See comment at the beginning of the email. Ananth>5) Since the control plane may be supported via multiple protocols, Ananth>clear statement of what is - and isn't - covered in the GMPLS Signaling Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed. bala>BR: Don't understand this, but doesn't look like a major issue from bala>your phrasing. Recommend the development of applicability statements to cover this (otherwise, it is difficult to understand how the different pieces join together to form a coherent picture). Ananth>6) Terminology is an issue (e.g., waveband switching, link) bala>BR: Any inconsistencies can be taken care of easily. Like your comment. Hope it is as easy as it sounds :-) Mapping of terminology between standards bodies and also between different drafts in the IETF can be painful. Agreed however, that this is not a show-stopper. Ananth>7) Transaction support for connection set-up and release is needed for Ananth>connection oriented networks (e.g. crankback capability). bala>BR: Internet drafts have already been written on crankback. I suggest bala>that you please consider writing some drafts if there is something bala>missing. Aware of the "iwata-draft". Are there others? Ananth>8) Reliable message transfer bala>BR: Very much a part of signaling. the OIF work has considered this bala>aspect also. 'soft-state' signaling protocols may not be acceptable for the optical control plane. Live channels must not be dropped as a result of signaling message delivery failures (e.g. timer refresh failures) Ananth>9) Security concerns have not been fully addressed, particularly at the Ananth> architectural level. The use of separate control network may Ananth>necessitate the need for 24 hour staff to protect against 'Denial of Ananth>Service' attacks as currently happens for IP router networks. In Ananth>general, admission control issues need to be addressed. bala>BR: Please elaborate on these, specifically, what's new in the bala>context of GMPLS. e.g. in the case of ATM UNI, if a user or users attempt too many call setups simultaneously the switch control processor can become overloaded. So, some form of call pacing/overload handling is needed. Is there something similar in the GMPLS context for optical devices? Ananth>10) The definition of transparency may be overly simplified. See Ananth>comments by Ben Mack-Crane: Ananth>I think the debate on transparency indicates that the issue is not as Ananth>clear Ananth>as we might think. The OIF document you cite defines forms of Ananth>transparency Ananth>that are very straightforward (flags 1,2) not the more complex forms in Ananth>the current GMPLS drafts (flags 3..10). Also, these are easily Ananth>provided in Ananth>O-E-O or O-O-O networks operating at the lambda level, but there is no Ananth>standard for providing these over TDM multiplexed SONET/SDH links. bala>BR: This is an ongoing topic of discussion. Doesn't break down bala>the rest of the proposal. Agreed. Ananth>If two vendors implement the same signaling but different TDM Ananth>multiplexing, that Ananth>doesn't achieve interoperability. Is there any way in the drafts to Ananth>determine the scope Ananth>of application of the various signaling elements (that is, whether they Ananth>apply to UNI or NNI, whether they apply to specific network Ananth>layers/technologies)? Ananth>11) One summary of additional items with issues includes: Ananth>- SDH/SONET transparency. Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation. Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities. Ananth>- All kinds of end-to-end protection/restoration for any layer, except Ananth>the IP layer. bala>BR: Restoration is not actually covered in the current set of drafts. bala>An earlier thread discussed this, and my suggestion is that this bala>feature be dealt with separately. Potential show-stopper for deployment if restoration is not covered. Would agree that it could be addressed separately, though. Ananth>- The label set object (only used for lambda issues). Ananth>- LSP encoding type, bandwidth encoding and GPID have to be simplified Ananth>accordingly. Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is not yet Ananth>defined). bala>BR: A draft is forthcoming on this. Have been made aware of this. Thanks. Ananth>12) Support for paths across SONET/SDH gateways bala>BR: Please clarify the issues/write drafts. Quoting from Siegfried Giebl's email regarding "If I understand this document correctly, then you are completely separating SONET and SDH signal types from each other, thus making it difficult to deal with paths across SONET/SDH gateways. As an alternative, I suggest you work only with entities of level STS-1 (STM-0) and higher. On the other hand why don't you go the full way and also add 64 kb/s channels ?" Ananth> 13) Compatibility is required/desired with legacy SDH/SONET equipment Ananth>[and also legacy DWDM] bala>BR: Same as above. NSAP issue identified above. Elements within a link may not communicate using the signaling, i.e., legacy SDH/SONET equipment that does not participate in signaling (participate only in connectivity) Thanks, Ananth Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Jun 2001 13:50:26 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: LSP Encoding Type Doubt Date: Thu, 21 Jun 2001 13:48:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, On a Sonet/SDH link, Can I support LSP encoding type as ANSI/ETSI PDH by mapping the E1/E3 or DS1/DS3 to SDH/SONET signals ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 21 Jun 2001 13:50:12 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bandwidth Encoding Type Doubt ..... Date: Thu, 21 Jun 2001 13:47:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can someone please tell me the reason for bandwidth encoding parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated will be drived from the signal type field. How the bandwidth encoding type will be interpreted in case of other LSP encoding types ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Jun 2001 18:12:41 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bandwidth Encoding Type Doubt ..... Date: Wed, 20 Jun 2001 18:11:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, Can someone please tell me the reason for bandwidth encoding parameter in GMPLS drafts ? In SDH/SONET, the bandwidth allocated will be drived from the signal type field. How the bandwidth encoding type will be interpreted in case of other LSP encoding types ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Jun 2001 15:06:14 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: LSP Encoding Type Doubt Date: Wed, 20 Jun 2001 15:02:45 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, On a Sonet/SDH link, Can I support LSP encoding type as ANSI/ETSI PDH by mapping the E1/E3 or DS1/DS3 to SDH/SONET signals ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Jun 2001 12:29:51 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F041A0188@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: ccamp@ops.ietf.org Subject: RE: OLI requirements Date: Wed, 20 Jun 2001 15:27:55 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F9BF.1B24CC00" 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_01C0F9BF.1B24CC00 Content-Type: text/plain; charset="iso-8859-1" I obviously agree with the requirements (as yet another author). However, I believe the OLI has more to do with transport. As a result, I am also working with others in the ITU where there already exists a significant body of knowledge in this area. Regards; Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, ON, Canada K1Y - 4H7 Tel: 613-763-5827 e.mail: osama@nortelnetworks.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, June 18, 2001 9:22 PM To: ccamp@ops.ietf.org Subject: OLI requirements Hi All, A document on Optical Link Interface Requirements has been submitted (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) Please review the draft and comment (to _this_ list) on the following: 1) Are the requirements stated useful? 2) Are there useful requirements that are missing? 3) Do you think that this document should be a CCAMP WG document? a) as it stands today? b) only if it changed? c) no, no matter what surgery is done on it? d) yawn ... Extra points for terse, technical and temperate comments. We'd like to judge the sentiment towards this draft in a week or two, so if you'd like your comments to be acted upon, send them soon. Thanks, Kireeti & Vijay. ------_=_NextPart_001_01C0F9BF.1B24CC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: OLI requirements

I obviously agree with the requirements (as yet = another author). However, I believe the OLI has more to do with = transport. As a result, I am also working with others in the ITU where = there already exists a significant body of knowledge in this = area.

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Kireeti Kompella [mailto:kireeti@juniper.net] =
Sent:   Monday, June 18, 2001 9:22 = PM
To:     = ccamp@ops.ietf.org
Subject:        = OLI requirements

Hi All,

A document on Optical Link Interface Requirements has = been submitted
(URL: http://search.ietf.org/internet-drafts/draft-many-oli-= reqts-00.txt )

Please review the draft and comment (to _this_ list) = on the following:
1) Are the requirements stated useful?
2) Are there useful requirements that are = missing?
3) Do you think that this document should be a CCAMP = WG document?
   a) as it stands today?
   b) only if it changed?
   c) no, no matter what surgery is done = on it?
   d) yawn ...

Extra points for terse, technical and temperate = comments.

We'd like to judge the sentiment towards this draft = in a week or two,
so if you'd like your comments to be acted upon, = send them soon.

Thanks,
Kireeti & Vijay.

------_=_NextPart_001_01C0F9BF.1B24CC00-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Jun 2001 09:09:31 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: ccamp@ops.ietf.org Subject: I-D ACTION:draft-cheng-gmpls-dynamic-trunking-00.txt Message-Id: Date: Wed, 20 Jun 2001 09:08:59 -0700 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS Extensions for Dynamic Trunking Author(s) : D. Cheng Filename : draft-cheng-gmpls-dynamic-trunking-00.txt Pages : 15 Date : 19-Jun-01 Currently the GMPLS signaling requires to include a 'LSP Encoding Type' in the Generalized Label Request ([GMPLS-SIG]), which indicates the encoding of the LSP being requested. Upon receiving a RSVP PATH message or CR-LDP REQUEST message that contains a Generalized Label Request, a LSR must verify if the receiving and transmitting interface can support the LSP. In particular on the transmitting side, the node either finds an interface that has the same switching class, among other requirements, or it may use a FA-LSP, i.e., another class of switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cheng-gmpls-dynamic-trunking-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010619113157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-gmpls-dynamic-trunking-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cheng-gmpls-dynamic-trunking-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010619113157.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 20 Jun 2001 03:30:47 -0700 From: "Diego Caviglia" To: dimitri.papadimitriou@alcatel.be cc: ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com, "Giovanni Fiaschi" Message-ID: <80256A71.00397DD1.00@marconicomms.com> Date: Wed, 20 Jun 2001 12:28:00 +0200 Subject: draft-many-optical-restoration-00 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dimitri, a comment on the draft in the subject, is not completely clear to me why is needed to know if there are lambda converter in OXC. OXC as stated in the previous chapter are OEO devices and thus are always able to perform lambda conversion. The architecture I have in mind for OXC is: |\ /|--|------|--|\ | | | |--| |--| | | |---------------| |--| OXC |--| |------//-------- | | | |--| |--| | |/ \|--|------|--|/ A B C D Here DWDM B performs: Demultiplexing of the received channels OEO conversion with transponder At this point usually the signal is grey the optical matrix perform cross connection. DWDM D receives grey signal on its interfaces and then using transponder puts the grey signal on the right lambda. So is always possible to convert an incoming let's say green lambda in an outgoing blue lambda by the means of OEO performed by DWDM transponder. Another thing that is not very clear to me is the use of tunable lasers. Could you please clarify better this point? Best regards. Diego. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 23:07:47 -0700 Message-ID: <3B303D43.E4280BCD@utfors.se> Date: Wed, 20 Jun 2001 08:05:55 +0200 From: Loa Andersson MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: OLI requirements Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Kireeti and Vijay, in the capacity of a non-co-author :-) and operator, please see comments inline. Kireeti Kompella wrote: > > A document on Optical Link Interface Requirements has been submitted > (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) > > Please review the draft and comment (to _this_ list) on the following: > 1) Are the requirements stated useful? yes > 2) Are there useful requirements that are missing? nothing that meets the eye or would stop progressing the document > 3) Do you think that this document should be a CCAMP WG document? > a) as it stands today? > b) only if it changed? > c) no, no matter what surgery is done on it? > d) yawn ... a > > Extra points for terse, technical and temperate comments. > > We'd like to judge the sentiment towards this draft in a week or two, > so if you'd like your comments to be acted upon, send them soon. Good, I think this is a typical case there it is extremely more useful to have something (and possible improve later if necessary) than not have anything. Please progress this a fast as possible. /Loa > > Thanks, > Kireeti & Vijay. -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 19:15:58 -0700 Cc: Kireeti Kompella , ccamp@ops.ietf.org Message-ID: <3B3006F5.7D31C720@lucent.com> Date: Wed, 20 Jun 2001 04:14:13 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Yong Xue Original-CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: OLI requirements Content-Type: multipart/mixed; boundary="------------DA3B633851B655C4947A7F11" This is a multi-part message in MIME format. --------------DA3B633851B655C4947A7F11 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The OLI work is in parallel to the work in ITU-T SG15 on OTM-LF (Line-fabric) interface. This OTM-LF interface is essentially a "virtual backplane" interface, and has to support the applications that are typically supported on a backplane in e.g. a SDH/SONET cross connect system, plus the specific OTN applications (for the moment transport of OCh Overhead). "[from WD43, Q.14/15 meeting June 2001] The OTM-LF interface is a multi-fiber parallel interface; it includes all fibers between OLS and OXC used for traffic transport and the additional "funiculus" (umbilical cord) or "Optical Supervisory Interface (OSI)" interface (either on fiber or copper). This funiculus/OSI carries all necessary information as required by the applications between OLS and OXC; e.g. OAM, status information and comms channels. It is a kind of supervisory channel, but now between the trib interface side of the OLS and the OXC (instead of between the line interface side of an OLS and the next OLS); see Figure 3." Note - "OSI"/"funiculus" are alternative names for "OLI". The OSI/funiculus has to interconnect one or more optical line systems with one or more optical fabrics and/or with one or more client equipment. I.e. a multi-point to multi-point configuration. Up to so far, 10 applications are identified that may have to be supported by a OTM-LF interface (text copied from WD43, Q.14/15 meeting June 2001 http://ties.itu.int/u/tsg15/sg15/wp3/q14/0106/wd43-otmlf02.doc ): 4.1 Application 1: Connection Status For the case OLS equipment contains ports with monitoring capabilities (i.e. 3R points/transponders) it can detect the status of the individual link connections while service is provided by the link connections. The status of a link connection can be expressed by means of the signal fail and signal degrade (SF, SD) condition determined by the appropriate atomic function monitoring the link connection. The use of port models based on ITU-T G.806, G.705, G.783 and draft G.798 most likely allows re-using existing specifications. See section 11. For the case of (link) connections not yet carrying service, the status can be determined also using a scanner in optical fabrics which connects cyclically a test generator and test monitor device/circuit to these (link) connections. Coordination is of course required between the optical fabric with the test generator and the one with the test monitor. 4.2 Application 2: Port Management Ports in an OLS may need to be managed as part of the connection creation, release and modification actions (valid for both permanent connections (setup by management plane) and for switched connections (setup by control plane). Port management is required for he case the port includes: = - a monitoring or termination function (e.g. section termination, tandem connection termination, path termination or non-intrusive monitor); tandem connection monitor function may need to be activated/de-activated and one or more MI_XXX (refer to G.806, G.705, G.783, G.798) signals of termination and monitor functions may need a value to be assigned. - a protection switch function; values may need to be assigned to protection switching specific MI_XXX signals like bridge type (broadcast/selective/permanent), protection architecture type (1+1, 1:1, 1:n, m:n, (1:1)n, with/without extra traffic), protection switching type (uni-directional, bi-directional), protection operation type (revertive, non-revertive), WTR timer, HO timer, SF and SD priority. [Note - this functionality is most likely not part of initial OLS equipment.] Although the equipment recommendations (ITU-T G.806, G.705, G.783, draft G.798, ETSI EN 300 417-x-1 x=3D1..6) list all MI_XXX signals and the equipment management function recommendations (ITU-T G.784, ETSI EN 300 417-7-1, ITU-T draft G.cemr, draft G.874) list the associated pre-/post-processing for those MI_XXX signals, there is a need to tie those signals to their applications and identify the subset of applications that are to be controlled via the funiculus/OSI. In addition, ports on the OLS needs management to suppress tributary signal LOS alarms caused by an open matrix connection in the optical fabric (and no light is output). 4.3 Application 3: OLS Discovery The OLS equipment port (and its associated tributary slot (i.e. wavelength) in the WDM line signal), which is physically adjacent to a port on the optical fabric equipment should be automatically discovered by the optical fabric equipment. As multiple OLS equipment will be surrounding the optical fabric equipment, the discovery is about relating the port X on the fabric to line port (i.e. OLS) Y and tributary slot Z (Port X =F3 LinePort Y/TribSlot Z). Note - not part of this application is the discovery of the adjacent switch (optical fabric equipment) and link in between this switch and the adjacent switch. This is part of the general control plane functionality and addressed in that activity (ITU-T G.ason, G.disc). 4.4 Application 4: Status monitoring of funiculus/OSI interface and of communications over it The status of the funiculus/OSI interface and the communications over it should be monitored. As this has similarities with EMS-NE communications in management plane, most likely we can re-use existing requirements and specifications from e.g. SDH/SONET networks. Q.14/15 experts may provide further input here. 4.5 Application 5: Control Plane Communication This application encompasses multiple control plane applications. Of particular interest here are those applications which have their application endpoints in the optical fabric equipment and the physically adjacent OLSs. Note - other control plane applications with application endpoints in this and the next optical fabric equipment will be listed (non-exhaustive) only, and will not be subject of this work item. It is already part of control plane specifications (G.ason, G.dcm, G.disc, =85)= =2E The optical fabric equipment <=3D> physical adjacent OLS equipment contro= l plane applications are: - to be added=85 4.6 Application 6: Management Plane Communication The Management Plane is supported by a Data Communication Network (DCN). This DCN may use in-band Data Communication Channels (DCC) to interconnect network elements at the management level without the need for external communication means. The funiculus/OSI should support such DCC, to be able continue this DCN in-band from OTM-n.m OSC via OLS via optical fabric equipment via OLS to OTM-n.m OSC. 4.7 Application 7: OCh Overhead In an all optical OTN network application (i.e. for case of an OLS trib port without 3R point (transponder)), non-associated OCh overhead (currently: OCh-FDI, OCh-OCI) must be transported between OLS and optical fabric equipment. The funiculus/OSI should support the transport of these OCh non-associated overhead signals. 4.8 Application 8: Protection Switch Endpoint Coordination For the case the optical fabric equipment includes protection switch functions supporting bi-directional switching, the optical fabric equipment with the bridge and with the selector functions must coordinate their protection switching actions via the Automatic Protection Switch (APS) co-ordination communication channel. The funiculus/OSI should support the transport of these APS signals. 4.9 Application 9: Protection Switch Functional Model Emulation For the case an OMS, OCh or ODUk protection implementation does not comply with its protection switch functional model (see annex B, which is copied from http://ties.itu.int/u/tsg15/sg15/wp3/q9/0106/cd/gen-lin-prot-v07.doc ), BDI and BEI information should be communicated to and from the optical fabric equipment via the funiculus/OSI. The optical fabric equipment will select the BDI/BEI information from the "active" interface port and forward this to both upstream "working" and "protection" interface ports. This implements BDI/BEI equivalent to the "RDI/REI X-coupling" indicated in figures B-3 and B-4. 4.10 Application 10: Auxiliary Communication Depending on the specific requirements for OrderWire (OW) and Operator Specific (OpSp) signals, there may be a need to continue those signals beyond a single line system (OLS - OLS). In such case, the OW and/or OpSp information should be transported via the funiculus/OSI. Q.12/15 indicated that the work on this OTM-LF interface requires detailed models of the interface ports at each end of the interface to be available. Without such models, it will not be possible to complete the specification; applications will most likely be overlooked and/or only partly supported otherwise. This equally applies to the OLI work; without accurate descriptions of the transport functionality at each end of the interface supported by the OLI, an incomplete specification will be the result. Up to so far... Regards, Maarten --------------DA3B633851B655C4947A7F11 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 --------------DA3B633851B655C4947A7F11-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 18:50:36 -0700 Cc: Eric.Mannie@ebone.com, ccamp@ops.ietf.org Message-ID: <3B30005C.7517A2DF@lucent.com> Date: Wed, 20 Jun 2001 03:46:04 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: Eric.Mannie@ebone.com, ccamp@ops.ietf.org Subject: Re: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------5C8E7B2A46D33A8AF6DE1AEB" This is a multi-part message in MIME format. --------------5C8E7B2A46D33A8AF6DE1AEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, A STM-64 doesn't consist of 64 STM-1s. Instead, a STM-64 may carry 64 VC-4 signals. Instead of 64 VC-4 signals, a sTM-64 may carry a mix of VC-3, VC-4, VC-4-4c, VC-4-16c signals or a single VC-4-64c signal (refer to G.707). A VC-4-16c signal can be transported in either one of the four AU-4-16c tributary slots: (1,0,0,0), (2,0,0,0), (3,0,0,0) or (4,0,0,0); refer to 7.2.3.4/G.707. Regards, Maarten manoj juneja wrote: > > Hi Eric, > Thanks for the reply. I have one more doubt : > > A STM-64 interface consist of 64 STM-1s that are byte interleaved. If > I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT > with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0, > MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to > allocate contiguous VC-4s in STM-64 link. > Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link. > Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal) > i.e. only one label will be passed in RESV/Label Mapping message. The > receiving node will drive the subsequent labels from this onwards. > > In case of arbitrary or virtual concatenation, Can I allocate non > -contiguous signals from a link ? The label corresponding to each > arbitrary or virtually concatenated signal will be passed in > RESV/Mapping message. > > If I have a STM-64 interface configured, and no signal is allocated yet from > the link. > If I have to allocate a signal STM-3c-7v (virtual concatenation of 7 > STM-3c), Can I allocate the whole signal from this link ? > > Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have to > pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0}, > {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ]. > > Does this mean that each STS-3c in STM-3c-7v should be contiguous ? > > Please tell me if my understanding is correct. > > Regards, > manoj. > > Regards, > manoj. > > >From: "Mannie, Eric" > >To: 'manoj juneja' , ccamp@ops.ietf.org > >Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > >Date: Tue, 19 Jun 2001 10:02:56 +0200 > > > >Hello Manoj, > > > >The virtual concatenation is indicated in a separate field (NVC). The > >reason > >is to allow to code the virtual concatenation of contiguously concatenated > >signals (like the virtual concatenation of several STS-3c's. > > > >Kind regards, > > > >Eric > > > >-----Original Message----- > >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > >Sent: Tuesday, June 19, 2001 3:03 AM > >To: ccamp@ops.ietf.org > >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > > > > >Hi, > > > > I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : > > > > The CCT field can have values no concatenation, standard > >concatenation, arbitrary, vendor specific. > >But why can't virtual concatenation ? It was there in original draft. > >But in the exmaples section for SDH/SONET signals, it is shown that a > >virtually concatenated signal can be built using NVC field with CCT > >value as 0. Please clarify the reason in doing so. > > > >Regards, > >manoj. > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com --------------5C8E7B2A46D33A8AF6DE1AEB 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 --------------5C8E7B2A46D33A8AF6DE1AEB-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 18:07:22 -0700 Date: Tue, 19 Jun 2001 21:05:19 -0400 (EDT) From: Scott Bradner Message-Id: <200106200105.VAA03216@newdev.harvard.edu> To: ccamp@ops.ietf.org, kireeti@juniper.net Subject: Re: draft-ietf-mpls-lmp-02.txt > Having said that, I'll leave it to the ADs to really answer your > question :-) it would be redundant - you already did > Note that this is "rough consensus"; this is not a vote, nor is > each response necessarily "yes" or "no". Also, 3 "votes" for and > none against might mean that we're wasting time on something of > little interest. a bit of expansion though - "rough consensus" does not mean 51% vs 49% it means the WG (or at least the responders) generally agree - so the number of responses is not an issue (unless its not many as Kireeti already pointedd out) but the balance - 10 people saying "yes" and 8 saying "no" will not cut it Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 17:33:56 -0700 Date: Tue, 19 Jun 2001 17:33:01 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106200033.RAA11363@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lmp-02.txt Irfan, > How many response are required before it is deemed consensus? Excellent question! Note that this is "rough consensus"; this is not a vote, nor is each response necessarily "yes" or "no". Also, 3 "votes" for and none against might mean that we're wasting time on something of little interest. Having said that, I'll leave it to the ADs to really answer your question :-) As for conserving bandwidth, that's very net-worthy, but I'd prefer that people sent short messages rather than not sending any, so that we can gauge interest level as well as sentiment. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 17:18:05 -0700 From: "Irfan Lateef" To: kireeti@juniper.net, ccamp@ops.ietf.org Bcc: Subject: Re: draft-ietf-mpls-lmp-02.txt Date: Tue, 19 Jun 2001 20:15:45 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Kireeti, How many response are required before it is deemed consensus? Apologize if it is documented in some RFC. But I am asking because in future if I see "N" responses I will not send mine if it is the same and conserve some bandwidth. Belated, but I also think it should be in CCAMP. Irfan Lateef >From: Kireeti Kompella >To: ccamp@ops.ietf.org >Subject: draft-ietf-mpls-lmp-02.txt >Date: Mon, 18 Jun 2001 19:04:12 -0700 (PDT) > >Hi All, > >Once upon a time, there was consensus to make the above document >(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) >an MPLS WG document. > >It now falls under the purvey of CCAMP. Question: do you think this >document should be a CCAMP WG document? (You know the drill ....) > >Kireeti & Vijay. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 14:29:03 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB60632@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Subject: WG Last Call on GMPLS documents Date: Tue, 19 Jun 2001 23:28:06 +0200 MIME-Version: 1.0 Content-Type: text/plain When flooded with the many postings/comments, I sometimes hate it when people are giving so much comments. But at the other hand, it also shows that we do get feedback from the community. The WG Last Call was a joint call between MPLS and CCAMP WGs. This was done because the 4 documents were in transit from MPLS to CCAMP WG. As a result we saw a lot of (too much!) cross posting. > - from now on we want discussion on CCAMP mailing list. Pls do not > copy MPLS and IPO mailing lists... if you want to participate, pls > join CCAMP mailing list. > - BUT... before you send more comments... pls hold off for a bit. > There are some 1000 or so postings to the WG Last Call. > I have asked the CCAMP WG chairs to try and make a summary of > the issues. Once they have done that, they will post them and try to > find out how many people agree/disagree with each issue. > I.e. they will try to find out if there is WG consensus on what the > issues are. > - I believe there were some suggested "fixes" to address some issues > as well. The WG chairs will also try to summarize these and again > then try to find out how much WG support there is for these "fixes". > - Then we will take it from there. > Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 13:42:30 -0700 Message-Id: <5.1.0.14.0.20010619163311.0422b9b0@neserve0.uu.net> Date: Tue, 19 Jun 2001 16:35:09 -0400 To: Kireeti Kompella , ccamp@ops.ietf.org From: Yong Xue Subject: Re: OLI requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed As a carrier and one of the co-author .. At 06:21 PM 6/18/01 -0700, Kireeti Kompella wrote: >Hi All, > >A document on Optical Link Interface Requirements has been submitted >(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) > >Please review the draft and comment (to _this_ list) on the following: >1) Are the requirements stated useful? Yes. >2) Are there useful requirements that are missing? So far so good >3) Do you think that this document should be a CCAMP WG document? > a) as it stands today? > b) only if it changed? > c) no, no matter what surgery is done on it? > d) yawn ... a) >Extra points for terse, technical and temperate comments. > >We'd like to judge the sentiment towards this draft in a week or two, >so if you'd like your comments to be acted upon, send them soon. > >Thanks, >Kireeti & Vijay. Yong Xue, Distinguished Technical Member NG IP Technology and Architecture UUNET/WorldCom Ashburn, Virginia (703)-886-5358 yxue@uu.net Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 12:14:30 -0700 Message-ID: <3B2FA452.1F495706@nayna.com> Date: Tue, 19 Jun 2001 12:13:22 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: OLI requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit At the capacity of one of the co-authors.... Kireeti Kompella wrote: > Hi All, > > A document on Optical Link Interface Requirements has been submitted > (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) > > Please review the draft and comment (to _this_ list) on the following: > 1) Are the requirements stated useful? Yes. > > 2) Are there useful requirements that are missing? Will revise if we find any missing. > > 3) Do you think that this document should be a CCAMP WG document? > a) as it stands today? > b) only if it changed? > c) no, no matter what surgery is done on it? > d) yawn ... > a > > Extra points for terse, technical and temperate comments. > > We'd like to judge the sentiment towards this draft in a week or two, > so if you'd like your comments to be acted upon, send them soon. > > Thanks, > Kireeti & Vijay. - sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 12:08:50 -0700 Message-ID: From: "Mannie, Eric" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: draft-ietf-mpls-lmp-02.txt Date: Tue, 19 Jun 2001 21:07:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dear Kireeti, Yes I think that this draft should become a CCAMP WG document, it is an important part of the GMPLS architecture and it is a good document. Kind regards, Eric -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Tuesday, June 19, 2001 4:04 AM To: ccamp@ops.ietf.org Subject: draft-ietf-mpls-lmp-02.txt Hi All, Once upon a time, there was consensus to make the above document (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) an MPLS WG document. It now falls under the purvey of CCAMP. Question: do you think this document should be a CCAMP WG document? (You know the drill ....) Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 11:35:50 -0700 Message-ID: From: Ayan Banerjee To: ccamp@ops.ietf.org Subject: RE: OLI requirements Date: Tue, 19 Jun 2001 11:29:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I beleive that this should be CCAMP WG document. Thanks, Ayan -----Original Message----- From: Andre Fredette [mailto:fredette@photonex.com] Sent: Tuesday, June 19, 2001 10:47 AM To: ccamp@ops.ietf.org Subject: Re: OLI requirements I may be a bit biased given that I'm one of the authors, but here are my opinions: At 06:21 PM 6/18/2001 -0700, Kireeti Kompella wrote: >Hi All, > >A document on Optical Link Interface Requirements has been submitted >(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) > >Please review the draft and comment (to _this_ list) on the following: >1) Are the requirements stated useful? Yes. >2) Are there useful requirements that are missing? Possibly. >3) Do you think that this document should be a CCAMP WG document? > a) as it stands today? > b) only if it changed? > c) no, no matter what surgery is done on it? > d) yawn ... a) >Extra points for terse, technical and temperate comments. > >We'd like to judge the sentiment towards this draft in a week or two, >so if you'd like your comments to be acted upon, send them soon. > >Thanks, >Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 11:13:58 -0700 Message-ID: <3B2F961B.50F2D825@alcatel.be> Date: Tue, 19 Jun 2001 20:12:43 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG MIME-Version: 1.0 To: Fong Liaw CC: ccamp@ops.ietf.org Subject: Re: draft-fontana-gmpls-control-g709-00.txt Content-Type: multipart/mixed; boundary="------------5E3A5F798662A309F6C5EE5C" This is a multi-part message in MIME format. --------------5E3A5F798662A309F6C5EE5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Fong, To respond to your question about the TSpec: since this version was published prior to the decision made during the last Minneapolis meeting it doesn't comply to it. The next version to be presented during the London Meeting will be aligned with the "Technology Specific extensions". Regards, Dimitri. Fong Liaw wrote: > > Yes, this draft is useful and a good start. > > One quick comment. > > Why did this draft not use Sender-Tspec to encode the > signal type, transparency, OOS field. I believe > this is the agreed approach to do technology > specific extensions. > > I also think it would be good to change the > code point of digital wrapper and lambda as > suggested by this draft in the GMPLS-SIG. > Or take the code point out of GMPLS-SIG > LSP encoding type code point, and define it here. > The latter is better, given that this draft just > come out. > > Regards, > -Fong --------------5E3A5F798662A309F6C5EE5C 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 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 --------------5E3A5F798662A309F6C5EE5C-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 11:05:55 -0700 From: "manoj juneja" To: Eric.Mannie@ebone.com, ccamp@ops.ietf.org Bcc: Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Date: Tue, 19 Jun 2001 11:00:18 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric, Thanks for the reply. I have one more doubt : A STM-64 interface consist of 64 STM-1s that are byte interleaved. If I have to allocate a signal VC-4-16c (unstructured VC-4s) means CCT with value 1 (standard contiguous concatenation), NCC as 16, NVC as 0, MT as 1, T as 0 to a VC-4 elementry signal. Does this mean, I have to allocate contiguous VC-4s in STM-64 link. Say if I allocate 16 VC-4s as 10th VC4 --> 25th VC-4 on STM-64 link. Then the {SUKLM} would be {s=10, U=1, K=1, L=0, M=0} (lowest signal) i.e. only one label will be passed in RESV/Label Mapping message. The receiving node will drive the subsequent labels from this onwards. In case of arbitrary or virtual concatenation, Can I allocate non -contiguous signals from a link ? The label corresponding to each arbitrary or virtually concatenated signal will be passed in RESV/Mapping message. If I have a STM-64 interface configured, and no signal is allocated yet from the link. If I have to allocate a signal STM-3c-7v (virtual concatenation of 7 STM-3c), Can I allocate the whole signal from this link ? Does this mean I have to allocate 21 STM-1s out of 64 STM-1s and I have to pass 7 labels in RESV/Mapping message [ {1,0,0,0,0}, {4,0,0,0,0}, {7,0,0,0,0}, {10,0,0,0,0}, {13,0,0,0,0}, {16,0,0,0,0}, {19,0,0,0,0} ]. Does this mean that each STS-3c in STM-3c-7v should be contiguous ? Please tell me if my understanding is correct. Regards, manoj. Regards, manoj. >From: "Mannie, Eric" >To: 'manoj juneja' , ccamp@ops.ietf.org >Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt >Date: Tue, 19 Jun 2001 10:02:56 +0200 > >Hello Manoj, > >The virtual concatenation is indicated in a separate field (NVC). The >reason >is to allow to code the virtual concatenation of contiguously concatenated >signals (like the virtual concatenation of several STS-3c's. > >Kind regards, > >Eric > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Tuesday, June 19, 2001 3:03 AM >To: ccamp@ops.ietf.org >Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt > > >Hi, > > I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : > > The CCT field can have values no concatenation, standard >concatenation, arbitrary, vendor specific. >But why can't virtual concatenation ? It was there in original draft. >But in the exmaples section for SDH/SONET signals, it is shown that a >virtually concatenated signal can be built using NVC field with CCT >value as 0. Please clarify the reason in doing so. > >Regards, >manoj. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 11:05:54 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6622B8F65@ICARIAN> From: Fong Liaw To: "'dimitri.papadimitriou@alcatel.be'" Cc: ccamp@ops.ietf.org Subject: draft-fontana-gmpls-control-g709-00.txt Date: Tue, 19 Jun 2001 11:00:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Yes, this draft is useful and a good start. One quick comment. Why did this draft not use Sender-Tspec to encode the signal type, transparency, OOS field. I believe this is the agreed approach to do technology specific extensions. I also think it would be good to change the code point of digital wrapper and lambda as suggested by this draft in the GMPLS-SIG. Or take the code point out of GMPLS-SIG LSP encoding type code point, and define it here. The latter is better, given that this draft just come out. Regards, -Fong Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:48:54 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010619134519.028abe18@mailbox> Date: Tue, 19 Jun 2001 13:46:57 -0400 Subject: Re: OLI requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I may be a bit biased given that I'm one of the authors, but here are my opinions: At 06:21 PM 6/18/2001 -0700, Kireeti Kompella wrote: >Hi All, > >A document on Optical Link Interface Requirements has been submitted >(URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) > >Please review the draft and comment (to _this_ list) on the following: >1) Are the requirements stated useful? Yes. >2) Are there useful requirements that are missing? Possibly. >3) Do you think that this document should be a CCAMP WG document? > a) as it stands today? > b) only if it changed? > c) no, no matter what surgery is done on it? > d) yawn ... a) >Extra points for terse, technical and temperate comments. > >We'd like to judge the sentiment towards this draft in a week or two, >so if you'd like your comments to be acted upon, send them soon. > >Thanks, >Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:48:21 -0700 Message-ID: <3B2F8F45.B5722D3C@lucent.com> Date: Tue, 19 Jun 2001 13:43:33 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: draft-fontana-gmpls-control-g709-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is definitely useful work. I would consider this parallel document to the SONET/SDH document within the GMPLS umbrella. Zhi Kireeti Kompella wrote: > > Hi All, > > There is a draft on signaling for G.709 networks, URL: > http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt > > Please send comments to the CCAMP mailing list on whether you > think that this draft should be made a CCAMP WG document or not, > and why: > a) yes, this draft is pretty good as it stands; > b) yes, this draft needs some work, but is okay; > c) no, this draft is all wrong, but signaling in G.709 networks > is something that the IETF should be working on; > d) no, this is not a subject that the IETF should touch. > > (Just to make it clear: this proposal is not an architecture, or even > a re-architecture of G.709 -- that work belongs in the ITU.) > > Thanks, > Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:44:56 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010619133243.0286eb80@mailbox> Date: Tue, 19 Jun 2001 13:42:43 -0400 Subject: Re: draft-ietf-mpls-lmp-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I agree that LMP should become a CCAMP WG document. LMP performs some very useful functions for the "Common Control" protocols the working group is chartered to specify. Andre At 07:04 PM 6/18/2001 -0700, Kireeti Kompella wrote: >Hi All, > >Once upon a time, there was consensus to make the above document >(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) >an MPLS WG document. > >It now falls under the purvey of CCAMP. Question: do you think this >document should be a CCAMP WG document? (You know the drill ....) > >Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:32:36 -0700 Message-ID: <3B2F8C78.DB704B09@alcatel.be> Date: Tue, 19 Jun 2001 19:31:36 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lmp-02.txt Content-Type: multipart/mixed; boundary="------------D248CC99160284176E859AB4" This is a multi-part message in MIME format. --------------D248CC99160284176E859AB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, Yes, it should be a CCAMP WG document. - Dimitri. Kireeti Kompella wrote: > > Hi All, > > Once upon a time, there was consensus to make the above document > (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) > an MPLS WG document. > > It now falls under the purvey of CCAMP. Question: do you think this > document should be a CCAMP WG document? (You know the drill ....) > > Kireeti & Vijay. --------------D248CC99160284176E859AB4 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 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 --------------D248CC99160284176E859AB4-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:11:26 -0700 Message-ID: From: Jimmy Gendron To: "'ccamp@ops.ietf.org'" Subject: OIF UNI - Link verification Date: Tue, 19 Jun 2001 13:10:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, When you're doing link verification (following the UNI 1.0 specs), you can send Test messages over these transport mechanisms: J0 OH, Section/line DCC OH or POS. How is the Test messages are sent over POS? Thank you, Jimmy Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 10:01:06 -0700 Message-Id: <200106191658.MAA07975@telescope.cisco.com> To: Yong Xue cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lmp-02.txt Date: Tue, 19 Jun 2001 12:58:49 -0400 From: George Swallow Yes, clearly this document has some consensus behind it. ,,,George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 09:42:39 -0700 Message-ID: <89E067900D3FA84A97495C71556140E41B6297@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: draft-ietf-mpls-lmp-02.txt Date: Tue, 19 Jun 2001 12:39:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I also agree that LMP should be a CCAMP document and would also like to see it explicitly added to CCAMP charter. Martin -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, June 18, 2001 10:04 PM To: ccamp@ops.ietf.org Subject: draft-ietf-mpls-lmp-02.txt Hi All, Once upon a time, there was consensus to make the above document (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) an MPLS WG document. It now falls under the purvey of CCAMP. Question: do you think this document should be a CCAMP WG document? (You know the drill ....) Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 09:12:13 -0700 Date: Tue, 19 Jun 2001 12:09:59 -0400 (EDT) From: Yong Xue To: "Thomas D. Nadeau" cc: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lmp-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think lmp should be a ccamp wg document, at the same time second Tom's suggestion to add lmp into the charter. /Yong On Tue, 19 Jun 2001, Thomas D. Nadeau wrote: > > >Once upon a time, there was consensus to make the above document > >(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) > >an MPLS WG document. > > > >It now falls under the purvey of CCAMP. Question: do you think this > >document should be a CCAMP WG document? (You know the drill ....) > > Yes, I think that it should be a CCAMP wg document. > However, in leu of the recent discussions regarding > whether drafts are in or out of charter, I suggest that > we explicitly add LMP to the charter to put to rest > any doubts of its applicability to ccamp. > > --Tom > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 07:51:52 -0700 Message-ID: From: "Dawkins, Spencer" To: ccamp@ops.ietf.org Subject: RE: draft-ietf-mpls-lmp-02.txt Date: Tue, 19 Jun 2001 09:45:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" I would say yes, a workgroup document, and this draft looks pretty good as it stands. Spencer -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, June 18, 2001 9:04 PM To: ccamp@ops.ietf.org Subject: draft-ietf-mpls-lmp-02.txt Hi All, Once upon a time, there was consensus to make the above document (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) an MPLS WG document. It now falls under the purvey of CCAMP. Question: do you think this document should be a CCAMP WG document? (You know the drill ....) Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 07:46:59 -0700 From: ananth.nagarajan@mail.sprint.com Date: Tue, 19 Jun 2001 09:41:59 -0500 Message-Id: Subject: RE: draft-ietf-mpls-lmp-02.txt MIME-Version: 1.0 TO: ccamp@ops.ietf.org, kireeti@juniper.net Content-Type: multipart/mixed; boundary="openmail-part-42085a2b-00000001" --openmail-part-42085a2b-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 19 Jun 2001 09:41:59 -0500" Content-Transfer-Encoding: 7bit Yes. this should be a WG document. Ananth -----Original Message----- From: kireeti [mailto:kireeti@juniper.net] Sent: Monday, June 18, 2001 9:04 PM To: ccamp Cc: kireeti Subject: draft-ietf-mpls-lmp-02.txt Hi All, Once upon a time, there was consensus to make the above document (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) an MPLS WG document. It now falls under the purvey of CCAMP. Question: do you think this document should be a CCAMP WG document? (You know the drill ....) Kireeti & Vijay. --openmail-part-42085a2b-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 07:31:59 -0700 From: ananth.nagarajan@mail.sprint.com Date: Tue, 19 Jun 2001 09:23:37 -0500 Message-Id: Subject: RE: draft-fontana-gmpls-control-g709-00.txt MIME-Version: 1.0 TO: ccamp@ops.ietf.org, kireeti@juniper.net Content-Type: multipart/mixed; boundary="openmail-part-42074c60-00000001" --openmail-part-42074c60-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 19 Jun 2001 09:23:37 -0500" Content-Transfer-Encoding: 7bit This is definitely useful work, and a good start. This should be made a WG document. Thanks, Ananth -----Original Message----- From: kireeti [mailto:kireeti@juniper.net] Sent: Monday, June 18, 2001 9:00 PM To: ccamp Cc: kireeti Subject: draft-fontana-gmpls-control-g709-00.txt Hi All, There is a draft on signaling for G.709 networks, URL: http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt Please send comments to the CCAMP mailing list on whether you think that this draft should be made a CCAMP WG document or not, and why: a) yes, this draft is pretty good as it stands; b) yes, this draft needs some work, but is okay; c) no, this draft is all wrong, but signaling in G.709 networks is something that the IETF should be working on; d) no, this is not a subject that the IETF should touch. (Just to make it clear: this proposal is not an architecture, or even a re-architecture of G.709 -- that work belongs in the ITU.) Thanks, Kireeti & Vijay. --openmail-part-42074c60-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 06:41:15 -0700 Message-ID: <3B2F55F8.EC0A927F@lucent.com> Date: Tue, 19 Jun 2001 09:39:04 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lmp-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think so, Yangguang Kireeti Kompella wrote: > > Hi All, > > Once upon a time, there was consensus to make the above document > (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) > an MPLS WG document. > > It now falls under the purvey of CCAMP. Question: do you think this > document should be a CCAMP WG document? (You know the drill ....) > > Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 05:27:46 -0700 Message-Id: <4.3.2.7.2.20010619082140.019da6b0@bucket.cisco.com> Date: Tue, 19 Jun 2001 08:27:43 -0400 To: Kireeti Kompella , ccamp@ops.ietf.org From: "Thomas D. Nadeau" Subject: Re: draft-ietf-mpls-lmp-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Once upon a time, there was consensus to make the above document >(URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) >an MPLS WG document. > >It now falls under the purvey of CCAMP. Question: do you think this >document should be a CCAMP WG document? (You know the drill ....) Yes, I think that it should be a CCAMP wg document. However, in leu of the recent discussions regarding whether drafts are in or out of charter, I suggest that we explicitly add LMP to the charter to put to rest any doubts of its applicability to ccamp. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 19 Jun 2001 01:06:21 -0700 Message-ID: From: "Mannie, Eric" To: 'manoj juneja' , ccamp@ops.ietf.org Subject: RE: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Date: Tue, 19 Jun 2001 10:02:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Manoj, The virtual concatenation is indicated in a separate field (NVC). The reason is to allow to code the virtual concatenation of contiguously concatenated signals (like the virtual concatenation of several STS-3c's. Kind regards, Eric -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Tuesday, June 19, 2001 3:03 AM To: ccamp@ops.ietf.org Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Hi, I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : The CCT field can have values no concatenation, standard concatenation, arbitrary, vendor specific. But why can't virtual concatenation ? It was there in original draft. But in the exmaples section for SDH/SONET signals, it is shown that a virtually concatenated signal can be built using NVC field with CCT value as 0. Please clarify the reason in doing so. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Jun 2001 19:05:16 -0700 Date: Mon, 18 Jun 2001 19:04:12 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106190204.TAA06764@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: draft-ietf-mpls-lmp-02.txt Hi All, Once upon a time, there was consensus to make the above document (URL: http://search.ietf.org/internet-drafts/draft-lang-mpls-lmp-02.txt ) an MPLS WG document. It now falls under the purvey of CCAMP. Question: do you think this document should be a CCAMP WG document? (You know the drill ....) Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Jun 2001 19:00:36 -0700 Date: Mon, 18 Jun 2001 18:59:48 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106190159.SAA06745@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: draft-fontana-gmpls-control-g709-00.txt Hi All, There is a draft on signaling for G.709 networks, URL: http://search.ietf.org/internet-drafts/draft-fontana-gmpls-control-g709-00.txt Please send comments to the CCAMP mailing list on whether you think that this draft should be made a CCAMP WG document or not, and why: a) yes, this draft is pretty good as it stands; b) yes, this draft needs some work, but is okay; c) no, this draft is all wrong, but signaling in G.709 networks is something that the IETF should be working on; d) no, this is not a subject that the IETF should touch. (Just to make it clear: this proposal is not an architecture, or even a re-architecture of G.709 -- that work belongs in the ITU.) Thanks, Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Jun 2001 18:22:27 -0700 Date: Mon, 18 Jun 2001 18:21:33 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106190121.SAA06372@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: OLI requirements Hi All, A document on Optical Link Interface Requirements has been submitted (URL: http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt ) Please review the draft and comment (to _this_ list) on the following: 1) Are the requirements stated useful? 2) Are there useful requirements that are missing? 3) Do you think that this document should be a CCAMP WG document? a) as it stands today? b) only if it changed? c) no, no matter what surgery is done on it? d) yawn ... Extra points for terse, technical and temperate comments. We'd like to judge the sentiment towards this draft in a week or two, so if you'd like your comments to be acted upon, send them soon. Thanks, Kireeti & Vijay. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 18 Jun 2001 18:05:37 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubt in draft ccamp-gmpls-sonet-sdh-00.txt Date: Mon, 18 Jun 2001 18:03:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, I have a doubt in draft ietf-ccamp-gmpls-sonet-sdh-00.txt : The CCT field can have values no concatenation, standard concatenation, arbitrary, vendor specific. But why can't virtual concatenation ? It was there in original draft. But in the exmaples section for SDH/SONET signals, it is shown that a virtually concatenated signal can be built using NVC field with CCT value as 0. Please clarify the reason in doing so. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Jun 2001 08:23:37 -0700 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F406C9D8A8@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Mannie, Eric'" , "'ananth.nagarajan@mail.sprint.com'" , BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Thu, 14 Jun 2001 11:20:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I beg to disagree with some of the contents. There will be an optical address (which could be in the IP format) At the higher layer there will be an IP address for devices or an NSAP address for ATM devices. Otherwise I agree with the main point - there is separate control at each layer. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Thursday, June 14, 2001 4:12 AM To: 'ananth.nagarajan@mail.sprint.com'; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Ananth, >The requirement is to support non-IP addresses at the edge (this may include NSAP) and >translate/encapsulate to a routable IP address in the core (a la in a >VPN scenario, where non-unique, non-IP addresses may be supported). >i.e, support just IP-based routing in the optical control plane. One can support whatever you like at the edge/host. A layer above any GMPLS controlled layer may use its own addressing, routing and signaling independently. For instance, if you want to use ATM with PNNI and NSAP addresses above a photonic layer controlled by GMPLS that's fine. That should not have any impact on GMPLS (layer independencies). An end-system will have two addresses, one at the ATM layer and one at the IP layer for the GMPLS driver of the photonic layer. In the same way an IP router has IP addresses at the IP layer and ATM addresses associated with ATM drivers. The address translation (from a "logical X address" to "physical IP address") issue can be solved in many ways (DNS, static, via an address resolution protocol (many were already designed), via routing integration, etc). I don't believe that this should be embedded in the signaling protocol used to open and maintain circuits. Too many non-related features in the same protocol makes it more complex. So again, no impact on GMPLS. Kind regards, Eric -----Original Message----- From: ananth.nagarajan@mail.sprint.com [mailto:ananth.nagarajan@mail.sprint.com] Sent: Wednesday, June 13, 2001 9:07 PM To: BRaja@tellium.com; Mannie, Eric Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Eric and others, I think the NSAP support issue is being misunderstood. The requirement is to support non-IP addresses at the edge (this may include NSAP) and translate/encapsulate to a routable IP address in the core (a la in a VPN scenario, where non-unique, non-IP addresses may be supported). i.e, support just IP-based routing in the optical control plane. hope this helps clarify. Ananth -----Original Message----- From: Eric.Mannie [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 5:32 AM To: Nagarajan, Ananth; BRaja Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir, Lynn Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Ananth, >bala>> > 1) Type of legacy equipment needing NSAP addresses >bala>> > (also, is >bala>> > this optical network element or client equipment?) >bala>> > 2) Rough estimate of number of UNI ports needing NSAP address >bala>> > (2002, 2005, and 2010) >bala>> > 3) Description of application in which this legacy equipment >bala>> > will use UNI >bala>> > signaling >bala>I don't recall seeing any response. furthermore, the NSAP >bala>requirement was not unanimously endorsed by all carriers (at >bala>the OIF). > >From our OIF representatives, although it was not unanimously endorsed, >there was a significant demand for NSAP support. Well, NSAP is the main >non-IP type of addressing that is required. The general requirement is >to be able to support non-IP addresses (probably have an address >translation from non-IP addresses to routable addresses). >NSAP support will be needed always (e.g. support for legacy DCC that >uses NSAP). So the timeframe requirement is now. Could you clarify the relationship between GMPLS and NSAP addresses ? You can run several protocol stacks in parallel over the same control channel. For instance, if your control channel is Ethernet, you can have an IP stack and any other kind of stack using any other kind of addresses. The two runs in parallel. The different stacks run in parallel in a "ship in the night" mode. The fact that you have for instance a TMN stack using NSAP addresses is completely orthogonal with a GMPLS stack. Speaking about my DCN: we have one DCN for both our transmission network and our IP network. The ADM's are managed using TMN only, DWDM equipment's are managed using SNMP and TMN, IP routers are managed using SNMP only. Everything uses the same DCN. For the TMN only equipment's we route CLNS using IS-IS and we don't use IP at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM Ethernet interfaces) into the NSAP addresses. You could put an IP address inside the NSAP address if you have a dual stack running on the box, that will even be simpler. For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and I have to check what we do for the TMN stack. I think that it is transported over IP, maybe using RFC1006. If I remember correctly we only configure an IP address on the DWDM box. In that case, I presume that TSAP's are build using this IP address. For the IP routers that we want to manage we use SNMP (full IP stack), and it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the routing in the DCN. The small Cisco routers in the DCN forward and route both CLNS and IP. Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and their operations are independent of the nodes that we want to manage/control - of course. It works fine! Anyway, in a real DCN you will have new and old equipment's and you will need to support both. This is completely independent of the GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the DCN, do I have to use NSAP addresses in my VoIP stack because there is some TMN application that runs there as well ? No, of course. For instance, you run OSPF-TE between two new core ION backbone switches over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS RSVP-TE messages are encapsulated over IP and these IP packets are transported over the IP DCN using any kind of tunnelling scheme (IP in IP, GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. So the GMPLS control plane runs completely independently of all the other stacks that are already running. Where is the issue ? Why do we need NSAP addresses in GMPLS ? Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 14 Jun 2001 01:14:22 -0700 Message-ID: From: "Mannie, Eric" To: "'ananth.nagarajan@mail.sprint.com'" , BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Thu, 14 Jun 2001 10:11:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Ananth, >The requirement is to support non-IP addresses at the edge (this may include NSAP) and >translate/encapsulate to a routable IP address in the core (a la in a >VPN scenario, where non-unique, non-IP addresses may be supported). >i.e, support just IP-based routing in the optical control plane. One can support whatever you like at the edge/host. A layer above any GMPLS controlled layer may use its own addressing, routing and signaling independently. For instance, if you want to use ATM with PNNI and NSAP addresses above a photonic layer controlled by GMPLS that's fine. That should not have any impact on GMPLS (layer independencies). An end-system will have two addresses, one at the ATM layer and one at the IP layer for the GMPLS driver of the photonic layer. In the same way an IP router has IP addresses at the IP layer and ATM addresses associated with ATM drivers. The address translation (from a "logical X address" to "physical IP address") issue can be solved in many ways (DNS, static, via an address resolution protocol (many were already designed), via routing integration, etc). I don't believe that this should be embedded in the signaling protocol used to open and maintain circuits. Too many non-related features in the same protocol makes it more complex. So again, no impact on GMPLS. Kind regards, Eric -----Original Message----- From: ananth.nagarajan@mail.sprint.com [mailto:ananth.nagarajan@mail.sprint.com] Sent: Wednesday, June 13, 2001 9:07 PM To: BRaja@tellium.com; Mannie, Eric Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Eric and others, I think the NSAP support issue is being misunderstood. The requirement is to support non-IP addresses at the edge (this may include NSAP) and translate/encapsulate to a routable IP address in the core (a la in a VPN scenario, where non-unique, non-IP addresses may be supported). i.e, support just IP-based routing in the optical control plane. hope this helps clarify. Ananth -----Original Message----- From: Eric.Mannie [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 5:32 AM To: Nagarajan, Ananth; BRaja Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir, Lynn Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Ananth, >bala>> > 1) Type of legacy equipment needing NSAP addresses >bala>> > (also, is >bala>> > this optical network element or client equipment?) >bala>> > 2) Rough estimate of number of UNI ports needing NSAP address >bala>> > (2002, 2005, and 2010) >bala>> > 3) Description of application in which this legacy equipment >bala>> > will use UNI >bala>> > signaling >bala>I don't recall seeing any response. furthermore, the NSAP >bala>requirement was not unanimously endorsed by all carriers (at >bala>the OIF). > >From our OIF representatives, although it was not unanimously endorsed, >there was a significant demand for NSAP support. Well, NSAP is the main >non-IP type of addressing that is required. The general requirement is >to be able to support non-IP addresses (probably have an address >translation from non-IP addresses to routable addresses). >NSAP support will be needed always (e.g. support for legacy DCC that >uses NSAP). So the timeframe requirement is now. Could you clarify the relationship between GMPLS and NSAP addresses ? You can run several protocol stacks in parallel over the same control channel. For instance, if your control channel is Ethernet, you can have an IP stack and any other kind of stack using any other kind of addresses. The two runs in parallel. The different stacks run in parallel in a "ship in the night" mode. The fact that you have for instance a TMN stack using NSAP addresses is completely orthogonal with a GMPLS stack. Speaking about my DCN: we have one DCN for both our transmission network and our IP network. The ADM's are managed using TMN only, DWDM equipment's are managed using SNMP and TMN, IP routers are managed using SNMP only. Everything uses the same DCN. For the TMN only equipment's we route CLNS using IS-IS and we don't use IP at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM Ethernet interfaces) into the NSAP addresses. You could put an IP address inside the NSAP address if you have a dual stack running on the box, that will even be simpler. For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and I have to check what we do for the TMN stack. I think that it is transported over IP, maybe using RFC1006. If I remember correctly we only configure an IP address on the DWDM box. In that case, I presume that TSAP's are build using this IP address. For the IP routers that we want to manage we use SNMP (full IP stack), and it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the routing in the DCN. The small Cisco routers in the DCN forward and route both CLNS and IP. Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and their operations are independent of the nodes that we want to manage/control - of course. It works fine! Anyway, in a real DCN you will have new and old equipment's and you will need to support both. This is completely independent of the GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the DCN, do I have to use NSAP addresses in my VoIP stack because there is some TMN application that runs there as well ? No, of course. For instance, you run OSPF-TE between two new core ION backbone switches over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS RSVP-TE messages are encapsulated over IP and these IP packets are transported over the IP DCN using any kind of tunnelling scheme (IP in IP, GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. So the GMPLS control plane runs completely independently of all the other stacks that are already running. Where is the issue ? Why do we need NSAP addresses in GMPLS ? Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 17:18:21 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , John Drake , Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 17:12:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Comments in line -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, June 13, 2001 3:41 PM To: jdrake@calient.net; Eric.Mannie@ebone.com; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hi John, You observed 13 June 2001 16:20 > > Niel, > > I think that the point that Eric was trying to make is that > the IETF isn't > the correct venue > for a PNNI based solution, although a PNNI based solution might be a > perfectly fine thing. NH=> Many thanks for acknowledging this.......and as both a signalling expert and co-author of the PNNI specification your view should carry some weight. JD: Um, I was just trying to be nice. I don't have any idea of it could actually work, and it is, shall we say, a stabilized protocol. > > From a technical perspective, unless things have changed in > the past several > years, the issues > with using PNNI are its lack of support for > pre-emption/priority and make > before break, and that > its bandwidth advertisements are tightly coupled to ATM > service categories. NH=> But PNNI seems as though it can more easily adapted to the required job. JD: This sounds suspiciously like an assertion. It has certain features that make it quite attractive like: - mature/tested, already deployed and understood - proven carrier-strength JD: I think the whole point of GMPLS is that the same could be said of the IP suite of protocols. - multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI JD: What are E-NNI and I-NNI? Also, at least when I looked at AINI, it had lots of problems with looping behavior and I don't know if they were fixed. - separate link and signalling protocols, eg SSCOP keepalives separate from signalling, allows more physical interfaces not just connections per interface JD: The same is provided by LMP wrt routing and signalling protocols, and link bundling provides better scalability wrt more physical interfaces than PNNI which doesn't have a similar concept. - supports crankback.....something now slated to be addded to RSVP/CR-LDP I assume? - supports static routed interfaces (AINI)....seems essential for inter-operator case; JD: GMPLS has this. - support for address translation JD: Not clear what you're referring to. - supports S-PVC-type service JD: GMPLS has this. - Logical Group Node concept provides powerful features, eg hides interior behaviour, allows centralised signalling and/or path computation, border nodes not burdened with higher layers, supports any topology, each peer group can have a different internal behaviour, etc; JD: I think you're referring to peer groups. In practice they were pretty nasty to configure properly, and I don't think they have all of the attributes you've given them. - good for phased migration (this is an importnat issue for operators); JD: Given that ATM, like IP, is a service, I don't see why there would be any reason to prefer PNNI over GMPLS. - centralised route computation may be better for OTNs.....this would be allowed; JD: PNNI doesn't have this intrinsically and GMPLS would support it just as easily. - separate signalling and routing means just signalling part can be used JD: I think that PNNI signalling and routing are much more tightly coupled than their GMPLS counterparts. Further, Eric Mannie designed in specific support in GMPLS for signalling only deployments. - etc It would, however, need some minor additional work to adapt it for SDH/OTN as you note......like BW advertisements. JD: It's only minor until you actually start to work out the details. BTW- we have significant experience of trying to run multiple pre-emption schemes and found it not so useful. So this is one aspect we would want, and if it was present we would want to be able to turn it off. JD: GMPLS has only a single pre-emption scheme. Regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 17:14:14 -0700 Message-ID: From: "Don Fedyk" To: neil.2.harrison@bt.com, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 20:13:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F466.C699BEA0" 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_01C0F466.C699BEA0 Content-Type: text/plain; charset="iso-8859-1" Neil You have made some pretty far reaching arguments. We also evaluated these schemes when we started GMPLS. It is my opinion we chose the route because we thought the IP-MPLS synergy in routing was strong. We run OSPF or IS-IS + BGP and we kill the overhead of having two routing systems with all the ills that go with it. There was also as John Drake mentioned more flexibility in adoption of capabilities. We tried once to put these in ATM and were shut down. Only after several years crank back solutions were introduced with still with some inflexible resistance. Next we looked at the signaling protocols and we fought hard to get flexibility and a connection oriented behavior. It is my opinion that CR-LDP was the best suited for this and we still use this model but we have conceded at present to talking to most of the routers with RSVP-TE. The signaling protocol is really not most of the work it is the flexibility we were striving for and with the exception of refresh the two protocols stay closely in synch. As far as addressing everyone seem to agree that we can add external addresses that have nothing to do with the core addressing so this is not about addressing. It is my opinion the best place to do this work has been the IETF over the last few years and here we use IP protocols. It has been the most responsive to the work to date. I don't see this suddenly changing and while you are right about it will look a lot like ATM when we get through that is because it is a connection oriented problem. Don ------_=_NextPart_001_01C0F466.C699BEA0 Content-Type: text/html; charset="iso-8859-1" RE: GMPLS issues (was - GMPLS Last Calls)

Neil

You have made some pretty far reaching arguments. We also evaluated
these schemes when we started GMPLS. It is my opinion we chose the
route because we thought the IP-MPLS synergy in routing was strong.
We run OSPF or IS-IS + BGP and we kill the overhead of having two
routing systems with all the ills that go with it. There was also
as John Drake mentioned more flexibility in adoption of capabilities.
We tried once to put these in ATM and were shut down. Only after
several years crank back solutions were introduced with still with
some inflexible resistance.

Next we looked at the signaling protocols and we fought hard to get
flexibility and a connection oriented behavior. It is my opinion that
CR-LDP was the best suited for this and we still use this model
but we have conceded at present to talking to most of the routers
with RSVP-TE. The signaling protocol is really not most of the
work it is the flexibility we were striving for and with the
exception of refresh the two protocols stay closely in synch.

As far as addressing everyone seem to agree that we can add
external addresses that have nothing to do with the core addressing
so this is not about addressing.

It is my opinion the best place to do this work has been the IETF
over the last few years and here we use IP protocols. It has been
the most responsive to the work to date. I don't see this suddenly
changing and while you are right about it will look a lot like ATM
when we get through that is because it is a connection oriented problem.

Don

------_=_NextPart_001_01C0F466.C699BEA0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 15:42:39 -0700 Message-ID: From: neil.2.harrison@bt.com To: jdrake@calient.net, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:48 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hi John.....You could do this, but I don't believe this is pertinent to what I was discussing. See my response to Eric. Regards, Neil > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 13 June 2001 15:59 > To: 'Mannie, Eric'; 'neil.2.harrison@bt.com'; > ananth.nagarajan@mail.sprint.com; BRaja@tellium.com > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com > Subject: RE: GMPLS issues (was - GMPLS Last Calls) > > > Also, an ATM service using NSAP addresses for customer ports > could be built > on top of a GMPLS core using IP addresses internally. The ATM service > delivery switches could use the GMPLS core to provison > lighpaths between > themselves and then run > PNNI as an overlay network for purposes of exchanging NSAP > reachability > information. > > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Wednesday, June 13, 2001 7:33 AM > To: 'neil.2.harrison@bt.com'; ananth.nagarajan@mail.sprint.com; > BRaja@tellium.com > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com > Subject: RE: GMPLS issues (was - GMPLS Last Calls) > > > Hello Neil, > > >Given that the layers have to be decoupled in the general case (for > >commercial as well as technical reasons - see the BT 'Freeland' > requirements > >draft to 12/00 mtg) then there seems to be no reason why an > operator could > >not use NSAPs for the access points of SDH or OTNs if he so > wished. And, > >given this choice, that operator might also prefer to use PNNI as the > >signalling/routing solution too. So, the issue seems not one of > >'necesssity' but simply choice......though there may be > certain technical > >benefits of choosing 1 solution over another. I don't > believe there is > >anything technically wrong with saying this and giving > operators/vendors a > >choice here is there?.....if there is please point out the problems. > > If somebody wants to use PNNI, it is not our business. The > choice between a > GMPLS control plane and a PNNI control plane is not in our > scope. We are > here working on GMPLS at the IETF, not on PNNI at the ATM > Forum and not on > G.ASON at the ITU-T. > > GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with > NSAP addresses. > I don't think that somebody will choose a control plane only > because it uses > IP or NSAP addresses, this doesn't make sense to me. There > are much more > important distinctions between the two control planes than > the format of the > addresses. > > Technically I don't see arguments to adapt GMPLS to NSAP > addresses, or to > AppleTalk addresses or to any kind of addresses that some people could > prefer, or that could come from another standardization body. > > If technically there is a clear benefit of using NSAP > addresses instead of > IP addresses in GMPLS that should be demonstrated by > somebody. Up to now > nobody made it (I think that when somebody wants to modify an > existing work > in a standardization body this has to be justified with > technical reasons, > not just by a personal preference). So I presume that there > is today no > technical argument to use NSAP addresses in GMPLS. > > Even if any benefit is demonstrated, that should be balanced with the > disadvantages of supporting it and finaly the IETF should > decide if they > want to adapt their protocols to other addressing schemes. > Personally, I > don't think that this make sense. > > Moreover, GMPLS is IP centric and this is one of its driving > forces. I don't > see the interest of transforming an IP centric control plane > in a less IP > centric control plane. This is going in the opposite > direction of what we > are trying to do. > > Kind regards, > > Eric > > Eric Mannie > EBONE (GTS) > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 15:42:37 -0700 Message-ID: From: neil.2.harrison@bt.com To: yakov@juniper.net Cc: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com, wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:51 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hello Yakov..... > > Please note that there is a way to carry NSAPs in IPv6 addresses, > although it does not support all types of NSAPs. (see rfc1888 for > more details). Please also note that GMPLS supports IPv6 (as well > as IPv4). Finally, please note that a "perfect" solution (the one > that addresses all the requirements of everyone) is a *non* goal > for GMPLS. NH=> That is a fair point. Indeed, it is looking at a best fit from our perspective that is driving us......and I feel sure our position would be reflected by many large/established carriers. But you need to talk to the right people in those carriers to get the true view.......I suspect these people will not be tracking any of this discussion nor have looked at the issues in depth yet. > > > And, > > given this choice, that operator might also prefer to use > PNNI as the > > signalling/routing solution too. So, the issue seems not one of > > 'necesssity' but simply choice......though there may be > certain technical > > benefits of choosing 1 solution over another. I don't > believe there is > > anything technically wrong with saying this and giving > operators/vendors a > > choice here is there?.....if there is please point out the problems. > > Few points: > > 1. Providing multiple choices for performing essentially the same > thing, especially if these choices have similar characteristics, > doesn't help to develop multi-vendor interoperable solutions. NH=> Agreed. But who calls the shots here? > > 2. The fact that in the IETF there are not one, but two link-state > IGPs (OSPF and ISIS) is a bug, and not a feature. > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP). > > 4. Suggesting yet another routing/signalling protocol, in addition > to GMPLS, is adding yet another bug (not a feature). NH=> Some bugs are better than others I guess. > > 5. I understand that BT submitted a contribution to the ITU > suggesting PNNI as (yet another) routing/signalling for optical > cross connects. NH=> Better bug? regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 15:42:36 -0700 Message-ID: From: neil.2.harrison@bt.com To: jdrake@calient.net, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:50 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hi John, You observed 13 June 2001 16:20 > > Niel, > > I think that the point that Eric was trying to make is that > the IETF isn't > the correct venue > for a PNNI based solution, although a PNNI based solution might be a > perfectly fine thing. NH=> Many thanks for acknowledging this.......and as both a signalling expert and co-author of the PNNI specification your view should carry some weight. > > From a technical perspective, unless things have changed in > the past several > years, the issues > with using PNNI are its lack of support for > pre-emption/priority and make > before break, and that > its bandwidth advertisements are tightly coupled to ATM > service categories. NH=> But PNNI seems as though it can more easily adapted to the required job. It has certain features that make it quite attractive like: - mature/tested, already deployed and understood - proven carrier-strength - multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI - separate link and signalling protocols, eg SSCOP keepalives separate from signalling, allows more physical interfaces not just connections per interface - supports crankback.....something now slated to be addded to RSVP/CR-LDP I assume? - supports static routed interfaces (AINI)....seems essential for inter-operator case; - support for address translation - supports S-PVC-type service - Logical Group Node concept provides powerful features, eg hides interior behaviour, allows centralised signalling and/or path computation, border nodes not burdened with higher layers, supports any topology, each peer group can have a different internal behaviour, etc; - good for phased migration (this is an importnat issue for operators); - centralised route computation may be better for OTNs.....this would be allowed; - separate signalling and routing means just signalling part can be used - etc It would, however, need some minor additional work to adapt it for SDH/OTN as you note......like BW advertisements. BTW- we have significant experience of trying to run multiple pre-emption schemes and found it not so useful. So this is one aspect we would want, and if it was present we would want to be able to turn it off. Regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 15:42:33 -0700 Message-ID: From: neil.2.harrison@bt.com To: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:46 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hi Eric.....many thanks for your comments....couple of observations: > > If somebody wants to use PNNI, it is not our business. The > choice between a > GMPLS control plane and a PNNI control plane is not in our > scope. We are > here working on GMPLS at the IETF, not on PNNI at the ATM > Forum and not on > G.ASON at the ITU-T. NH=>We have to consider that the control-plane is composed of 3 principlly independent facets (ie addressing, signalling and routing) and it unfair to group them under a generic banner or forum heading. We really should be striving for best current practice here. > > GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with > NSAP addresses. > I don't think that somebody will choose a control plane only > because it uses > IP or NSAP addresses, this doesn't make sense to me. There > are much more > important distinctions between the two control planes than > the format of the > addresses. NH=> The addressing is almost an irrelevance......the addressing used can be anything provided it meets the requirements specified in the Freeland draft. Clearly we would re-use an existing addressing scheme, and v6 and NSAPs look good. v4 does not look so good. > > Technically I don't see arguments to adapt GMPLS to NSAP > addresses, or to > AppleTalk addresses or to any kind of addresses that some people could > prefer, or that could come from another standardization body. NH=> I don't want to do this either. > > If technically there is a clear benefit of using NSAP > addresses instead of > IP addresses in GMPLS that should be demonstrated by > somebody. Up to now > nobody made it (I think that when somebody wants to modify an > existing work > in a standardization body this has to be justified with > technical reasons, > not just by a personal preference). So I presume that there > is today no > technical argument to use NSAP addresses in GMPLS. NH=> Focusing on addressing here is a distraction......the attributes of an address that are required are that (i) it should be large enough for any possible growth, (ii) able to be properly structured to follow topology (for sensible hierarchical and aggregation reasons....so some 'wasted' space is not a bad thing) and (ii) that addresses are decoupled wrt cross-layer allocation (server layer trails = client layer links.....it can't be put more direct/obvious than that I think). > > Even if any benefit is demonstrated, that should be balanced with the > disadvantages of supporting it and finaly the IETF should > decide if they > want to adapt their protocols to other addressing schemes. > Personally, I > don't think that this make sense. NH=> I really think the addressing aspect is a bit of a distraction.......the key issues are all about the choice of signalling protocol and how the routing aspects are used. I cannot believe that a signalling protocol like RSVP whose orgins are from a Rx-controlled, multicast, IP, soft-state, etc environment is better fit than PNNI. This is not an attack of RSVP per se, it is all about re-using best available protocols for a given job. As Jon Crowcroft said at the NSIS BOF at the last mtg: "Don't fix signaling protocols via new requirements, but give a new direction in signaling requirements. PNNI specifications are excellently written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing RSVP until you have read all these protocols. We should not reinvent the wheel and waste the time of the IETF. [See ref: http://www.ietf.org/proceedings/01mar/index.html NSIS BOF] It is my opinion that all you will end up doing is re-inventing PNNI, eg recent crankback drafts. Sure you can do this but why waste the time of the IETF on this? > > Moreover, GMPLS is IP centric and this is one of its driving > forces. I don't > see the interest of transforming an IP centric control plane > in a less IP > centric control plane. This is going in the opposite > direction of what we > are trying to do. NH=> I don't really want to get into this area, so I will be as brief as possible....there is no IP in the SDH or OTN user-plane and, for us at least, the client and SDH/OTN networks must be decoupled. Sure you can force an IP oriented solution but that is by choice....it is certainly not forced by any technical or commercial necessity. Please also note that a significant (around 50% in some cases) of our SDH traffic demands actually come from 'native' managed BW customers.....so these are not even client networks (ie neither IP nor something else) that are under our management domain. These observations lead us to the conclusion that if a control-plane is to be introduced (and please note this is not a sure-fire certainty for SDH in any case for us....and I would urge operators to look at their billing, OSS and current operational practices before reaching any conclusions here) it should be chosen on best current practice principles. Further, we cannot see any good business case for SVCs in either SDH or OTNs....S-PVCs maybe. Has anyone really talked to operators about this....offering SVCs at SDH/OTN trail levels I mean? I would be amazed if valid business cases could be constructed......so if any operators out there know how to do this, we would be very keen to understand the arguments. So....observing that we are dealing with CO/cct-sw networks it would seem to make sense to us to use a signalling protocol that was designed to control such a fabric...and all I am saying here is that PNNI appears to be a better fit than RSVP (provided it is coupled with the right OSS/service environment, eg S-PVC like services 1st). regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 12:08:19 -0700 From: ananth.nagarajan@mail.sprint.com Date: Wed, 13 Jun 2001 14:07:09 -0500 Message-Id: Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 TO: BRaja@tellium.com, Eric.Mannie@ebone.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4186299a-00000001" --openmail-part-4186299a-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 13 Jun 2001 14:07:09 -0500" Content-Transfer-Encoding: 7bit Eric and others, I think the NSAP support issue is being misunderstood. The requirement is to support non-IP addresses at the edge (this may include NSAP) and translate/encapsulate to a routable IP address in the core (a la in a VPN scenario, where non-unique, non-IP addresses may be supported). i.e, support just IP-based routing in the optical control plane. hope this helps clarify. Ananth -----Original Message----- From: Eric.Mannie [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 5:32 AM To: Nagarajan, Ananth; BRaja Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir, Lynn Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Ananth, >bala>> > 1) Type of legacy equipment needing NSAP addresses >bala>> > (also, is >bala>> > this optical network element or client equipment?) >bala>> > 2) Rough estimate of number of UNI ports needing NSAP address >bala>> > (2002, 2005, and 2010) >bala>> > 3) Description of application in which this legacy equipment >bala>> > will use UNI >bala>> > signaling >bala>I don't recall seeing any response. furthermore, the NSAP >bala>requirement was not unanimously endorsed by all carriers (at >bala>the OIF). > >From our OIF representatives, although it was not unanimously endorsed, >there was a significant demand for NSAP support. Well, NSAP is the main >non-IP type of addressing that is required. The general requirement is >to be able to support non-IP addresses (probably have an address >translation from non-IP addresses to routable addresses). >NSAP support will be needed always (e.g. support for legacy DCC that >uses NSAP). So the timeframe requirement is now. Could you clarify the relationship between GMPLS and NSAP addresses ? You can run several protocol stacks in parallel over the same control channel. For instance, if your control channel is Ethernet, you can have an IP stack and any other kind of stack using any other kind of addresses. The two runs in parallel. The different stacks run in parallel in a "ship in the night" mode. The fact that you have for instance a TMN stack using NSAP addresses is completely orthogonal with a GMPLS stack. Speaking about my DCN: we have one DCN for both our transmission network and our IP network. The ADM's are managed using TMN only, DWDM equipment's are managed using SNMP and TMN, IP routers are managed using SNMP only. Everything uses the same DCN. For the TMN only equipment's we route CLNS using IS-IS and we don't use IP at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM Ethernet interfaces) into the NSAP addresses. You could put an IP address inside the NSAP address if you have a dual stack running on the box, that will even be simpler. For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and I have to check what we do for the TMN stack. I think that it is transported over IP, maybe using RFC1006. If I remember correctly we only configure an IP address on the DWDM box. In that case, I presume that TSAP's are build using this IP address. For the IP routers that we want to manage we use SNMP (full IP stack), and it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the routing in the DCN. The small Cisco routers in the DCN forward and route both CLNS and IP. Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and their operations are independent of the nodes that we want to manage/control - of course. It works fine! Anyway, in a real DCN you will have new and old equipment's and you will need to support both. This is completely independent of the GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the DCN, do I have to use NSAP addresses in my VoIP stack because there is some TMN application that runs there as well ? No, of course. For instance, you run OSPF-TE between two new core ION backbone switches over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS RSVP-TE messages are encapsulated over IP and these IP packets are transported over the IP DCN using any kind of tunnelling scheme (IP in IP, GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. So the GMPLS control plane runs completely independently of all the other stacks that are already running. Where is the issue ? Why do we need NSAP addresses in GMPLS ? Kind regards, Eric --openmail-part-4186299a-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 10:08:44 -0700 From: "manoj juneja" To: Eric.Mannie@ebone.com, ccamp@ops.ietf.org Bcc: Subject: RE: Signal Type doubt in GMPLS Date: Wed, 13 Jun 2001 10:06:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Eric, Thanks for the reply. But I have still one thing not clear. When we request AUG-16, does this mean the whole STM-16 without transparency ? Similarly, In case of sonet, if signal type is one of STS-1 SPE, STS Group-3, STS Group-12, means whole STS-X without transparency. But if the requested signal type is one of STS-1 STS-3, STS-12 means with transparency ? Regards, manoj. >From: "Mannie, Eric" >To: 'manoj juneja' , ccamp@ops.ietf.org >Subject: RE: Signal Type doubt in GMPLS >Date: Wed, 13 Jun 2001 10:04:40 +0200 > >Hello Manoj, > > >Also, for signal types STM-1, STM-4 etc. it is written in braces > >that "only when requesting transparency". What does this exactly mean ? > >When you request some transparency it means transparency in the SOH, so you >don't just request some payload, you request something related to the frame >itself. Some part of the SOH has to be delivered at the other end of the >LSP >untouched. This can be achieved in several ways, e.g. simply forwarded >untouched (and this doesn't require any new standard, e.g. you keep the DCC >untouched and you forward it :-) by the intermediate nodes in the network, >or tunnelled in some overhead bytes. > >We didn't want to use a VC type of signal with transparency because the SOH >is not part of this VC, we used STM-N. This is much cleaner. > > >What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs. > >An AUG-X signal type means the space taken by the AUG-X, it is like a TUG >or >VTG signal. That allows to open a circuit without specifying its content, >your SDH framer will recognise the content automatically. > >For instance, I am a customer and I don't care about transparency. I am >connected to a switch with an STM-4 interface. I want to open a circuit >with >the bandwidth equivalent of an STM-1 whose content can change, e.g. first I >structure it as 3 x VC-3's, later on I want one VC-4. I request an AUG-1 >circuit. > >Kind regards, > >Eric > >-----Original Message----- >From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] >Sent: Tuesday, June 12, 2001 9:31 PM >To: ccamp@ops.ietf.org >Subject: Signal Type doubt in GMPLS > > >Hi, > I have certain doubts regarding signal type field in sonet-sdh 00.txt >draft. > >What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs. > >When signal type is AUG-256, what does this exatly mean ? > >Also, for signal types STM-1, STM-4 etc. it is written in braces >that "only when requesting transparency". What does this exactly mean ? > >Please help. > >Regards, >manoj. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 10:03:05 -0700 Message-ID: From: "Bernstein, Greg" To: 'Maarten Vissers' Cc: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Date: Wed, 13 Jun 2001 10:01:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten, et. al., some comments in line. I'm kinda curious that this very fundamental topic (layering and GMPLS) isn't generating more reponses than "flexible arbitrary unconstrained unrestricted universal concatenation" but then again I'm not sure I want a repeat of the last debate :-). I've cut some of the text where Maarten indicated that we were aligned. See the ... comments below. Greg B. *********************************** Dr. Greg M. Bernstein Senior Scientist, Ciena Corporation -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Wednesday, June 13, 2001 3:01 AM To: Bernstein, Greg Cc: Diego Caviglia; Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Greg, See my notes inline. Regards, Maarten "Bernstein, Greg" wrote: > Now if a vendor chooses to integrate STS-1 and VT1.5 > switching in the same box its up to them whether they choose to separate > these signaling control entities or combine them into one entity. Partly aligned here... Within one vendor's subnetwork I agree that a vendor may choose to do this. But when the other switch is outside that vendor's subnetwork, the signaling protocol would have to meet the standard interface specification, which for ASON will have separate signalling control entities. I was thinking of a fine grained VT1.5 switch that could also do some STS-Nc level switching. And hence the call processing entity (internal) may be combined for both layers. And also the entities may have the same IP address to the outside world. The signaling interface specification would have to be met. But, what do you mean by separate signalling control entities? Do you want to be able to monitor the signaling activities for each layer separately? Do you want to be able perform certain signaling management activities on a single layer, e.g., say you've got a "signaling storm" at a layer and want to shut down and then slowly bring back up the entities at that layer. Is this type of measurement and control of signaling somewhat orthogonal to say using a GMPLS signaling protocol or a Q.2931 based protocol? > The logical layer model still stands. I didn't assume any particular > mechanism for the signaling transport (except IP) since different > layers/technologies may have different mechanisms available, e.g., > SONET's DCC. I also didn't want to dictate where the network > engineering function resides, i.e., where in the above example > you'd figure out the best place to put the STS-1 paths given > locations of VT1.5 switches, traffic trends, SONET line capacities > etc. Is this what you are calling a LNTC? Yes, this is what I intend torefer to by LNTC. Note - LNTC is a new term that came to my mind when creating the previous reply. During the Q.12/15 meeting last week people indicated that we need alternative terms for "traffic engineering" and "network engineering" in the way I was using those. My "network engineering" is controlling to some extend the layer network topology; of course it isn't capable to add extra hardware or software to the network, but it can modify the topology by adding/removing/increasing/shrinking links (G.805 terminology)). If you can think of a better term for this, let me know. I am looking for a better term for "traffic engineering" (in my definition) process. Perhaps this should be split into two "controllers"; one concerned with distributing reachability/topology information and link state information, and another concerned with the actual route finding and connection setup/release. Any suggestions? I think we are getting somewhere with these clarifications. > > (2) Routing for each layer -- Here things are a little less obvious to me. > Yes, I can run a separate instance of a route protocol for each layer but > can I keep things simpler and would it be truly simpler. Back to the SONET > example. For setting up STS-1 (or STS-Nc) connections I would want to know > about SONET line layer topology (via a link state route protocol). You need to know the fabrics and the links between those fabrics. It is irrelevant if those links are provided by SONET lines or something else. > For setting up the VT1.5 connections I would want to know about the > SONET STS-1 layer connectivity between the VT1.5 layer switches. You need to know the fabrics and the links between those fabrics. It is irrelevant if those links are provided by SONET STS-1s or something else. E.g. a VC-4, sub-STM-0 or sub-STS-1 interfaces, ATM (some operators use ATM VCs to carry VT/LOVC signals) or MPLS (see ongoing SONEt/SDH over MPLS work). > If one had a network with switches with combined (multi-layer) > switching capability then I could see some advantages in combining > these. At a minimum I can see that the network engineering > function for the VT1.5 layer switches (the thing that > needs to set up the bandwidth between the VT1.5 layer switches) would want > to know about both layers (it must know about the SONET line layer). I have to disagree here. The network engineering function for the VT1.5 layer switches needs to know only - the set of VT1.5 layer network "S_LN" ports (refer to WD08 section 5, figure 38) or "class D" ports (WD20, section 2.3, figure 3) that are present in the VT1.5 switches - the reachability information per (group of) port(s). The network engineering function (or LNTC) decides on the available information between which two VT1.5 switches a VT1.5 link is to be added or extended. Once this is decided, the LNTC has to determine if this can be realised by menas of a direct link (single hop) or if a multi-hop link is the only possibility; in the latter case the two ports to be interconnected can not reach each other directly. Then, the VT1.5 LNTC requests the new VT1.5 link (or links) to be created by its server layer(s) between the specific ports (or port groups). There is no need to know anything about the SONET line layer here. Furthermore, you should consider that the network must perform its tasks independent of the physical grouping of functions. I.e. the behaviour of the network must be the same independent of the fact of VT1.5 fabrics and STS fabrics are in separate equipment, or in the same equipment, or a mix of both is present. You should not base your design on only one of the possible cases. Let's see if we can bring this back together. In my example I assumed VT1.5 switches interconnected via STS-1 paths over SONET lines. I want to do a few things when I set up additional (or any) STS-1 paths connecting these switches: (a) meet current demands for VT1.5 carriage over the STS-1 layer network. (b) make efficient usage of STS-1 layer resources. (c) make efficient usage of STS-1 layer resources in the future. Hence I've got a current demand matrix to be satisfied, some growth trends that I may know about and SONET line layer connectivity (well as you say really STS-1 link capacity but I'm trying to be specific for clarity). Now for the trending information I figured various snap shots over time of the VT1.5 layer connectivity (via a link state protocol) would be used. Hence why I figured upper layer information is useful. Does this clarify my intent? > This > is what motivates integrating multiple layers into a single instance of a > routing protocol. But what about more than two layers? How would a knowing > the DS0 connectivity/traffic trends be of use to the network engineering > function for STS-1 paths between VT1.5 switches? I don't think so since we > see this via the VT1.5 trends anyhow. Similarly the properties of layers > below the SONET line layer should be already summarized via SRLG info so I'm > not sure that knowing the exact topology down at the waveband level is all > that helpful. I have the feeling that you are almost coming to the same conclusion as I am in the lines above. I.e. if you can do a good job at DS0 level without having knowledge of underlying STS, line and below layers why would one need to have line level knowledge when being at VT1.5 level? If you don't need it at one place, you can apply the same mechanism at other places and you don't need it at those places either. I guess I see most lower layer knowledge being abstracted via the use of SRLGs and this would propagate upwards if desired. My WDM systems know lots of things but only a few are useful for the upper layers. > Kireeti (or Yakov) the forwarding adjacency concept was > introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was > for MPLS within MPLS now we are talking multiplex hierarchies where the > entities at the different layers are very much different from each other. Allow me a side step here... from a transport perspective MPLS is having some unique characteristics: "one technology, infinite number of layer networks, infinite number of connection monitoring levels (potential iff MPLS OAM is introduced)". E.g. as MPLS is connection oriented, I can use transport layer terminology to describe the MPLS network architecture: - the outer MPLS layer network connects to (non-MPLS) client layer networks via adaptation functions - adaptation functions to client layer networks can be of the 1:1 type (1 client signal into 1 MPLS signal) or of the n:1 type (n client signals multipelxed into 1 MPLS signal) - a client layer signal is as such adapted to become an MPLS signal before it is transported. Assume that MPLS OAM is available, such MPLS OAM can be added to the signal to provide more extensive transport monitoring capabilities to the signal transport. At this point, end-to-end trail monitoring is established. - Traversing the MPLS layer network, the signal may pass through third party subnetworks. Each of these subnetworks may need to monitor the quality of service of the transport fo the signal through their network, and these networks can now add a new level of MPLS OAM to the signal (i.e. tandem connection monitoring). - Contrary to CBR techniques, MPLS doesn't have to steal overhead bandwidht from the original signal. Instead it can simply add such OAM to the signal. At the same time, it can add another MPLS header to the signal and associate this with the new OAM that is added (improvement over ATM's segment monitoring capability). This makes the signal transport in one subnetwork domain realy independent of its transport in previous domains (true independence is obtained). - let me now focus on the multi-layer aspect of MPLS. If you multiplex several MPLS signals into an MPLS aggregate signal, you have created essentially a second MPLS layer network supporting the first MPLS layer network. The trails in this second MPLS layer network support thus first MPLS layer network links. - From a routing perspective links are static elements in the layer network, and you can now operate the MPLS network as a bunch of independent layer networks, with client/server relationships within the MPLS network itself. On one technology you can now operate a number of logical layers; e.g. an MPLS access layer, a MPLS metro layer and a MPLS core layer. Each will have their specific characteristics (e.g. typical bandwidth of the MPLS signal; small for access, medium for metro, large for core). - the nice thing here is that you can mix and match these logical MPLS layer networks in equipment without the need to install different fabrics. As each logical MPLS layer network can be run with its own control plane instance, you will not run into scalability issues or unwanted access/metro/core interactions. So, all the good stuff from CBR networks without their restrictions. :-) > > Maarten, are we converging here (except for terminology of course)? I have the feeling that we are converging. Let's see if the above notes bring us even closer. Up to so far. Regards, Maarten > > Greg B. > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, June 12, 2001 1:19 AM > To: Bernstein, Greg > Cc: Diego Caviglia; Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; > ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Greg, > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer > protocol > > instances than network layers. > > I am not sure I understand the meaning of the last sentence... does it > refer to: > a common Signalling Communication Network (SCN) over which all > signalling messages are transported for all layer networks? > > The ASON model under definition shows per switched layer network a > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. > Subnetworks may be nested, and the lowest level subnetwork is a Fabric. > These SCs communicate with each other over the SCN. LOVC-SCs communicate > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs > communicate with other ODU1-SCs, etc to exchange link state/topology > information (case of I-NNI), reachability information (case of E-NNI, > UNI) and routing information (connection setup). This is at the moment > also referred to as "intra-layer" information exchange. > > For the case we decide that a Network Engineering agent is included in > an SC, we will get also "inter-layer" information exchange. E.g. > HOVC-SCs may also communicate with LOVC-SCs to provide reachability > information for ports (e.g. STS1 and VC4 access groups) within the LOVC > layer network. For the case we decide that Network Engineering agents > are not part of the SC (but in a separate "layer network topology > controller" (LNTC)), "inter-layer" information exchange will be between > an SC and a LNTC. This latter model has a preference at the moment, > while the two processes (SC: routing, LNTC: network topology) have a > different scope. > > Note - LNTC within one layer network have to communicate with each other > also to build up an understanding of potential topology capabilities > present in the layer network (or layer network partition the LNTC is > responsible for). > > Separate of the above, the ASON recommendations will specify the signal > flow over inter domain interfaces where > - a customer interconnects with an operator > - two operators interconnect > - two vendors interconnect. > > Over these inter domain interfaces you have to comply to the signal > (message) structure. For ASON networks this will be based on the layer > network structure. Within one domain the same layer network structured > approach may be used, or one may decide to create a "spaghetti mountain" > in which the layer network structure is not adhered to. That's up to the > individual vendor. > > Regards, > > Maarten > > "Bernstein, Greg" wrote: > > > > Hi Maarten, Diego, et. al. > > what's interesting here is the question of what do we mean by "its own > > instance of a control plane"? Obviously if we are setting up a LOVC (in > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling > to > > those switches that are LOVC capable. Other switches need not be > involved. > > If it turns out that the LOVC capable switches are not interconnected by a > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > > appropriate HOVC interconnecting the LOVC needs to be setup first. In > GMPLS > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > > switches before we set up the LOVC LSPs. > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer > protocol > > instances than network layers. Well actually as Maarten wrote in a recent > > ITU document that we would be primarily interested in those layers > involved > > in dynamic switching/multiplexing. Note that we've started to bring in > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > > (the WDM--SONET example I always give). > > > > With the signaling protocol things are really separated by who is involved > > in the signaling transaction. In the routing case things are less clear, > > i.e., who wants/needs to know information about other layers and what > burden > > does this present to the NEs and scalability. Which layers can benefit by > > integration... I'll be updating the Optical inter-domain route > requirements > > draft soon (with others) and will be exploring some of these items in more > > depth. > > > > (Terminology: LOVC := Lower order virtual container, SDH term that > includes > > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps > in > > the SDH hierarchy). > > > > Greg B. > > *********************************** > > Dr. Greg M. Bernstein > > Senior Scientist, Ciena Corporation > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, June 11, 2001 7:46 AM > > To: Diego Caviglia > > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: Re: GMPLS Sonet extensions > > > > Diego, > > > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > > and OCh) will have its own (instance of) control plane. > > > > Each switched layer network runs a copy of the generic routing protocol; > > it does so within the boundaries of the switched layer network. > > > > Within each switched layer network you will find UNI, E-NNI and I-NNI > > interfaces due to partitioning of a switched layer network. Topology > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > > the other hand only provide reachability information. > > > > For the case an MPLS router is from a different organisation than the > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > > the interface will be an MPLS-I-NNI. > > For the server layers within the MPLS router (e.g. HOVC and STM-N > > section layers) the interface relation is to be determined independent > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > > as at the HOVC layer entwork only reachability information is available > > in the MPLS router (HOVC-E-NNI). > > > > The MPLS router should not be concerned at all about the routing of the > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > > link between is needed between MPLS router A and MPLS router B, router A > > needs to have knowledge of router B's address/name only to request a > > VC-4-16c/STS-48c connection through the transport network. The switched > > HOVC (transport) network will take care of the connection setup. > > > > And even if two diverse routed connections are required (e.g. to support > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > > needs to request only the creation of 2 VC-4-16c connections with the > > constraint of being diversely routed. The switched HOVC network will be > > able to provide these two connections diversely routed between A and B > > routers. > > > > At the moment, I recognise two connection types in a layer network: > > - native connections and > > - client connections. > > Example: within a HOVC layer network a STS1 or VC-4 connection is a > > native connection, and a DS3 connection or a LOVC link is a client > > connection. A client connection is supported by the HOVC layer network > > after adapting it to the layer network signal type (i.e. STS1 (to > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > > can have a > > - 1:1, > > - 1:n, > > - n:1 > > relationship with the underlying layer network signal. > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > > relationship. > > > > With client connections, an I-NNI is almost per definition not possible > > (you go outside the layer network). Nevertheless, some people consider > > the special 1:1 case as an area where an I-NNI could be deployed; of > > course not for the case of DS3 -> STS1, but for the case of > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > > HOVC layer network and a client signal to the OCh and ODU1 layer > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > > wavelenght it is easy to think to be within one and the same layer > > network. Personally, I believe that such very special case looks much > > brighter than it is in the long term. I.e. don't declare very special > > cases to be the common ones; keep those as very special cases, best even > > keep those as regular cases obeying to the generic rules. > > > > Client connections as such have UNI or E-NNI interface relationships > > over which reachability information is offered at best. This is the case > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > > layer entwork) as well as "vertical client connections" (e.g. a LOVC > > link over a HOVC/STS layer network). > > > > Regards, > > > > Maarten > > > > Diego Caviglia wrote: > > > > > > Maarten, > > > I agree in principle with you but this means it > would > > be > > > necessary to have a routing protocol for each layer doesn't it? > > > > > > One of the initial reasons for (G)MPLS is to unify the control > > plane, your > > > layered view of the network implies again the separation of the control > > planes. > > > > > > The Transport Network is very different from a flat IP network and > > layering in > > > TN is implicit. > > > > > > If I understood your model correctly the MPLS Router only views, > Access > > Groups > > > and links to other MPLS Routers. If there are free resources between > > the two > > > routers the TE process calculates, accordingly to some rules, the best > > path. > > > > Agree. > > > > > If > > > there are no resources a call to the Network Engineering agent is > > performed, the > > > NE makes a call to the TE of the SONET layer in order to provide a > trail > > to the > > > MPLS layer (this procedure is repeated until available resources are > > created for > > > the MPLS router connection). This trail modifies the topology at the > MPLS > > layer. > > > > Agree. One note however, operators have indicated that they would like > > to deploy policies in the NE agent which may include some thresholds, > > before it decides to change the topology of the layer network. E.g. > > topology is not extended unless X calls failed. On the other hand, the > > NE agent may have scheduled topology changes; e.g. at the begin of busy > > hour extra links are added or bandwidth of existing link is extended, > > and at the end of busy hour the reverse is happening. > > > > > > > > If my understanding is correct and we want to implement an automated > TN > > a sort > > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > > > UNI or E-NNI. > > > > > > > > Maybe this will create some problems, on the other hand, as Maarten > > pointed out, > > > flat networks won't work due the huge amount of routing information > > that they > > > have to carry. > > > > > > Regards > > > > > > Diego > > > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > > , ccamp@ops.ietf.org(bcc: > > > Diego Caviglia/MAIN/MC1) > > > > > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > Sharma, > > > > > > "flat" set up is the route to disaster... simply consider a switched > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > > would get information of all these levels... an absolute disaster in a > > > world wide switched transport network would be the result. > > > > > > Therefore, there is this layering in which a server layer network > > > provides bandwidth to its client layer entworks. the client layer > > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > > can route their signals. > > > > > > A separate entity (I called it "network engineering") is looking over > > > the shoulder of the call setup process to see if more bandwidth is > > > needed and when it would be needed or not longer required. But today, > > > this separate entity is not part of the control plane; it is in the > > > management plane. > > > > > > Regards, > > > > > > Maarten > > > > > > Susumu Yoneda wrote: > > > > > > > > Sharma, > > > > > > > > Thank you for letting me know your presentation material which looks > > very > > > > interesting. It seems to me that a layered setup would make a sense. > > > > However, users may want to have a "flat" setup. Therefore, lower > setups > > > > would not be seen by users? > > > > > > > > -----Original Message----- > > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > > Sent: Saturday, June 09, 2001 11:06 AM > > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > > Subject: RE: GMPLS Sonet extensions > > > > > > > > Jimmy, Susumu, > > > > > > > > Your idea (assuming a peer model) is basically correct. Since all > nodes > > > > have the same view of the network, you could compute an ERO at the > > > > ingress router and have the PATH message follow the hop-by-hop route > > > > to the egress router. > > > > (Note, however, that the PATH message will travel > > > > on the out-of-band IP control network; therefore, it would be > > non-associated > > > > signaling.) > > > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > > in fact, have to be shared by all nodes, since that is precisely what > > > > the "peer model" implies. > > > > > > > > But you do have to be careful about what "LSP" you are requesting, > since > > the > > > > characteristics of the requested LSP are not interpreted in the same > way > > by > > > > the > > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > > different > > > > way of defining a circuit than an IP router or an OXC.) > > > > Therefore, one possibility would be to do a "layered setup", where an > > LSP > > > > at the lower layer is setup before the PATH message at the higher > layer > > > > is tunnelled over it or allowed to propagate further. > > > > > > > > For example, when the PATH message for the packet > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > > a corresponding SONET circuit between themselves, and then either > tunnel > > > > the PATH message for the packet LSP over this circuit, or (assuming > your > > > > out-of-band network), at that time, allow the PATH message for the > > packet > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > > channel, likewise, would be a recursive process, with the OXC first > > setting > > > > up an optical lightpath between themselves, and tunneling the request > to > > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > > > A more detailed discussion of this subject, with corresponding > > animations > > > > and figures, that you may also find helpful is available in a talk I > > gave at > > > > MPLSCon'01, and can be found at: > > > > http://www.mplscon.com/missing_presentations.htm > > > > (Dynamic path establishment in MPLS-controlled multi-service > networks.) > > > > > > > > -Vishal > > > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > > [SMTP:yone@japan-telecom.co.jp] > > > > wrote: > > > > > Hi, > > > > > > > > > > I also assume that there would be an out-of-band signalling network > > based > > > > on > > > > > a suite of GMPLS protocols including LMP. I think there will be > issues > > to > > > > > address whether all messages will be shared by all nodes, i.e > router, > > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > > ------------------------------- > > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > > Japan Telecom fax +81 3 5540 8485 > > > > > Information & Communication Labs. > > > > > e-mail yone@japan-telecom.co.jp > > > > > ------------------------------- > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf > > > > Of > > > > > Jimmy Gendron > > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > > To: 'ccamp@ops.ietf.org' > > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > understand > > > > > most of the architecture, but I still have a question since the > > beginning; > > > > > as an unified control plane, how do the routing/signaling protocols > > > > exchange > > > > > informations on a configuration like this: > > > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > > (Ingress) > > > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > > understand > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > > the > > > > two > > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > > (Assuming > > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > > > My guess is that the PATH message will leave the ingress router with > a > > > > PATH > > > > > message with a calculated ERO. It assumes that the network is in > > respect > > > > > with the peer model...everyone have the same routing table and know > > the > > > > > actual network topology. So, my PATH message will follow the CSPF > > (ERO) > > > > and > > > > > go to the egress router. Am I right? > > > > > > > > > > Best regards, > > > > > > > > > > Jimmy Gendron > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 08:40:50 -0700 Message-Id: <200106131538.IAA00319@red.juniper.net> To: neil.2.harrison@bt.com cc: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com, wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: Re: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17180.992446693.1@juniper.net> Date: Wed, 13 Jun 2001 08:38:13 -0700 From: Yakov Rekhter Neil, > Eric, I understand your points on the 'management network'......that is, the > addressing of it's user-plane is a separate network to the user-plane > offered for cutsomer connections. So let me concentrate on the 'external' > user-plane here in an attempt to answer your question. > > Seems we have some choices in GMPLS at the moment: > Addressing - v4 or v6 > Signalling - RSVP or CR-LDP > Routing - OSPF or IS-IS (but exterior is BGP only) > > All these facets are, in principle, independent choices. And, in > particular, since 'server layer trails = client layer links' then addressing > cannot be from the same space at a server and client layer. The addressing > might have exactly the same format, but it comes from a different space, ie > address X at layer M is not = address X at layer M. > > Given that the layers have to be decoupled in the general case (for > commercial as well as technical reasons - see the BT 'Freeland' requirements > draft to 12/00 mtg) then there seems to be no reason why an operator could > not use NSAPs for the access points of SDH or OTNs if he so wished. Please note that there is a way to carry NSAPs in IPv6 addresses, although it does not support all types of NSAPs. (see rfc1888 for more details). Please also note that GMPLS supports IPv6 (as well as IPv4). Finally, please note that a "perfect" solution (the one that addresses all the requirements of everyone) is a *non* goal for GMPLS. > And, > given this choice, that operator might also prefer to use PNNI as the > signalling/routing solution too. So, the issue seems not one of > 'necesssity' but simply choice......though there may be certain technical > benefits of choosing 1 solution over another. I don't believe there is > anything technically wrong with saying this and giving operators/vendors a > choice here is there?.....if there is please point out the problems. Few points: 1. Providing multiple choices for performing essentially the same thing, especially if these choices have similar characteristics, doesn't help to develop multi-vendor interoperable solutions. 2. The fact that in the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is a bug, and not a feature. 3. The same applies for MPLS signalling (CR-LDP vs RSVP). 4. Suggesting yet another routing/signalling protocol, in addition to GMPLS, is adding yet another bug (not a feature). 5. I understand that BT submitted a contribution to the ITU suggesting PNNI as (yet another) routing/signalling for optical cross connects. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 08:29:21 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 08:20:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Niel, I think that the point that Eric was trying to make is that the IETF isn't the correct venue for a PNNI based solution, although a PNNI based solution might be a perfectly fine thing. >From a technical perspective, unless things have changed in the past several years, the issues with using PNNI are its lack of support for pre-emption/priority and make before break, and that its bandwidth advertisements are tightly coupled to ATM service categories. Thanks, John -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, June 13, 2001 6:09 AM To: Eric.Mannie@ebone.com; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) > Where is the issue ? Why do we need NSAP addresses in GMPLS ? > > Kind regards, > > Eric > Eric, I understand your points on the 'management network'......that is, the addressing of it's user-plane is a separate network to the user-plane offered for cutsomer connections. So let me concentrate on the 'external' user-plane here in an attempt to answer your question. Seems we have some choices in GMPLS at the moment: Addressing - v4 or v6 Signalling - RSVP or CR-LDP Routing - OSPF or IS-IS (but exterior is BGP only) All these facets are, in principle, independent choices. And, in particular, since 'server layer trails = client layer links' then addressing cannot be from the same space at a server and client layer. The addressing might have exactly the same format, but it comes from a different space, ie address X at layer M is not = address X at layer M. Given that the layers have to be decoupled in the general case (for commercial as well as technical reasons - see the BT 'Freeland' requirements draft to 12/00 mtg) then there seems to be no reason why an operator could not use NSAPs for the access points of SDH or OTNs if he so wished. And, given this choice, that operator might also prefer to use PNNI as the signalling/routing solution too. So, the issue seems not one of 'necesssity' but simply choice......though there may be certain technical benefits of choosing 1 solution over another. I don't believe there is anything technically wrong with saying this and giving operators/vendors a choice here is there?.....if there is please point out the problems. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 08:06:34 -0700 Message-ID: From: John Drake To: "'Mannie, Eric'" , "'neil.2.harrison@bt.com'" , ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 07:59:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Also, an ATM service using NSAP addresses for customer ports could be built on top of a GMPLS core using IP addresses internally. The ATM service delivery switches could use the GMPLS core to provison lighpaths between themselves and then run PNNI as an overlay network for purposes of exchanging NSAP reachability information. -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 7:33 AM To: 'neil.2.harrison@bt.com'; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Neil, >Given that the layers have to be decoupled in the general case (for >commercial as well as technical reasons - see the BT 'Freeland' requirements >draft to 12/00 mtg) then there seems to be no reason why an operator could >not use NSAPs for the access points of SDH or OTNs if he so wished. And, >given this choice, that operator might also prefer to use PNNI as the >signalling/routing solution too. So, the issue seems not one of >'necesssity' but simply choice......though there may be certain technical >benefits of choosing 1 solution over another. I don't believe there is >anything technically wrong with saying this and giving operators/vendors a >choice here is there?.....if there is please point out the problems. If somebody wants to use PNNI, it is not our business. The choice between a GMPLS control plane and a PNNI control plane is not in our scope. We are here working on GMPLS at the IETF, not on PNNI at the ATM Forum and not on G.ASON at the ITU-T. GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with NSAP addresses. I don't think that somebody will choose a control plane only because it uses IP or NSAP addresses, this doesn't make sense to me. There are much more important distinctions between the two control planes than the format of the addresses. Technically I don't see arguments to adapt GMPLS to NSAP addresses, or to AppleTalk addresses or to any kind of addresses that some people could prefer, or that could come from another standardization body. If technically there is a clear benefit of using NSAP addresses instead of IP addresses in GMPLS that should be demonstrated by somebody. Up to now nobody made it (I think that when somebody wants to modify an existing work in a standardization body this has to be justified with technical reasons, not just by a personal preference). So I presume that there is today no technical argument to use NSAP addresses in GMPLS. Even if any benefit is demonstrated, that should be balanced with the disadvantages of supporting it and finaly the IETF should decide if they want to adapt their protocols to other addressing schemes. Personally, I don't think that this make sense. Moreover, GMPLS is IP centric and this is one of its driving forces. I don't see the interest of transforming an IP centric control plane in a less IP centric control plane. This is going in the opposite direction of what we are trying to do. Kind regards, Eric Eric Mannie EBONE (GTS) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 07:34:07 -0700 Message-ID: From: "Mannie, Eric" To: "'neil.2.harrison@bt.com'" , ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 16:32:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Neil, >Given that the layers have to be decoupled in the general case (for >commercial as well as technical reasons - see the BT 'Freeland' requirements >draft to 12/00 mtg) then there seems to be no reason why an operator could >not use NSAPs for the access points of SDH or OTNs if he so wished. And, >given this choice, that operator might also prefer to use PNNI as the >signalling/routing solution too. So, the issue seems not one of >'necesssity' but simply choice......though there may be certain technical >benefits of choosing 1 solution over another. I don't believe there is >anything technically wrong with saying this and giving operators/vendors a >choice here is there?.....if there is please point out the problems. If somebody wants to use PNNI, it is not our business. The choice between a GMPLS control plane and a PNNI control plane is not in our scope. We are here working on GMPLS at the IETF, not on PNNI at the ATM Forum and not on G.ASON at the ITU-T. GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with NSAP addresses. I don't think that somebody will choose a control plane only because it uses IP or NSAP addresses, this doesn't make sense to me. There are much more important distinctions between the two control planes than the format of the addresses. Technically I don't see arguments to adapt GMPLS to NSAP addresses, or to AppleTalk addresses or to any kind of addresses that some people could prefer, or that could come from another standardization body. If technically there is a clear benefit of using NSAP addresses instead of IP addresses in GMPLS that should be demonstrated by somebody. Up to now nobody made it (I think that when somebody wants to modify an existing work in a standardization body this has to be justified with technical reasons, not just by a personal preference). So I presume that there is today no technical argument to use NSAP addresses in GMPLS. Even if any benefit is demonstrated, that should be balanced with the disadvantages of supporting it and finaly the IETF should decide if they want to adapt their protocols to other addressing schemes. Personally, I don't think that this make sense. Moreover, GMPLS is IP centric and this is one of its driving forces. I don't see the interest of transforming an IP centric control plane in a less IP centric control plane. This is going in the opposite direction of what we are trying to do. Kind regards, Eric Eric Mannie EBONE (GTS) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 06:54:25 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Message-Id: <5.1.0.14.2.20010613095126.023aff88@mailbox> Date: Wed, 13 Jun 2001 09:52:09 -0400 Subject: Fwd: I-D ACTION:draft-many-oli-reqts-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed FYI... Andre >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-many-oli-reqts-00.txt >Date: Wed, 13 Jun 2001 07:09:56 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Optical Link Interface Requirements > Author(s) : A. Fredette et al. > Filename : draft-many-oli-reqts-00.txt > Pages : 15 > Date : 12-Jun-01 > >The emergence of transparent optical switches, together with a >movement towards more dynamic, multi-vendor networks, has introduced >a need for information sharing between optical line systems and >client devices. The information that needs to be shared includes >link status and link properties. We call this interface the Optical >Link Interface (OLI). In this document, we provide high-level >requirements for the OLI. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-many-oli-reqts-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-many-oli-reqts-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <20010612113733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-many-oli-reqts-00.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 06:11:05 -0700 Message-ID: From: neil.2.harrison@bt.com To: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 14:08:47 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" > Where is the issue ? Why do we need NSAP addresses in GMPLS ? > > Kind regards, > > Eric > Eric, I understand your points on the 'management network'......that is, the addressing of it's user-plane is a separate network to the user-plane offered for cutsomer connections. So let me concentrate on the 'external' user-plane here in an attempt to answer your question. Seems we have some choices in GMPLS at the moment: Addressing - v4 or v6 Signalling - RSVP or CR-LDP Routing - OSPF or IS-IS (but exterior is BGP only) All these facets are, in principle, independent choices. And, in particular, since 'server layer trails = client layer links' then addressing cannot be from the same space at a server and client layer. The addressing might have exactly the same format, but it comes from a different space, ie address X at layer M is not = address X at layer M. Given that the layers have to be decoupled in the general case (for commercial as well as technical reasons - see the BT 'Freeland' requirements draft to 12/00 mtg) then there seems to be no reason why an operator could not use NSAPs for the access points of SDH or OTNs if he so wished. And, given this choice, that operator might also prefer to use PNNI as the signalling/routing solution too. So, the issue seems not one of 'necesssity' but simply choice......though there may be certain technical benefits of choosing 1 solution over another. I don't believe there is anything technically wrong with saying this and giving operators/vendors a choice here is there?.....if there is please point out the problems. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 03:32:30 -0700 Message-ID: From: "Mannie, Eric" To: "'ananth.nagarajan@mail.sprint.com'" , BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 12:31:37 +0200 MIME-Version: 1.0 Content-Type: text/plain Hello Ananth, >bala>> > 1) Type of legacy equipment needing NSAP addresses >bala>> > (also, is >bala>> > this optical network element or client equipment?) >bala>> > 2) Rough estimate of number of UNI ports needing NSAP address >bala>> > (2002, 2005, and 2010) >bala>> > 3) Description of application in which this legacy equipment >bala>> > will use UNI >bala>> > signaling >bala>I don't recall seeing any response. furthermore, the NSAP >bala>requirement was not unanimously endorsed by all carriers (at >bala>the OIF). > >From our OIF representatives, although it was not unanimously endorsed, >there was a significant demand for NSAP support. Well, NSAP is the main >non-IP type of addressing that is required. The general requirement is >to be able to support non-IP addresses (probably have an address >translation from non-IP addresses to routable addresses). >NSAP support will be needed always (e.g. support for legacy DCC that >uses NSAP). So the timeframe requirement is now. Could you clarify the relationship between GMPLS and NSAP addresses ? You can run several protocol stacks in parallel over the same control channel. For instance, if your control channel is Ethernet, you can have an IP stack and any other kind of stack using any other kind of addresses. The two runs in parallel. The different stacks run in parallel in a "ship in the night" mode. The fact that you have for instance a TMN stack using NSAP addresses is completely orthogonal with a GMPLS stack. Speaking about my DCN: we have one DCN for both our transmission network and our IP network. The ADM's are managed using TMN only, DWDM equipment's are managed using SNMP and TMN, IP routers are managed using SNMP only. Everything uses the same DCN. For the TMN only equipment's we route CLNS using IS-IS and we don't use IP at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM Ethernet interfaces) into the NSAP addresses. You could put an IP address inside the NSAP address if you have a dual stack running on the box, that will even be simpler. For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and I have to check what we do for the TMN stack. I think that it is transported over IP, maybe using RFC1006. If I remember correctly we only configure an IP address on the DWDM box. In that case, I presume that TSAP's are build using this IP address. For the IP routers that we want to manage we use SNMP (full IP stack), and it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the routing in the DCN. The small Cisco routers in the DCN forward and route both CLNS and IP. Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and their operations are independent of the nodes that we want to manage/control - of course. It works fine! Anyway, in a real DCN you will have new and old equipment's and you will need to support both. This is completely independent of the GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the DCN, do I have to use NSAP addresses in my VoIP stack because there is some TMN application that runs there as well ? No, of course. For instance, you run OSPF-TE between two new core ION backbone switches over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS RSVP-TE messages are encapsulated over IP and these IP packets are transported over the IP DCN using any kind of tunnelling scheme (IP in IP, GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. So the GMPLS control plane runs completely independently of all the other stacks that are already running. Where is the issue ? Why do we need NSAP addresses in GMPLS ? Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 03:01:10 -0700 Cc: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <3B2739C9.A517ABC8@lucent.com> Date: Wed, 13 Jun 2001 12:00:41 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Bernstein, Greg" Original-CC: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------768A252F6A467CD4C58CEF3D" This is a multi-part message in MIME format. --------------768A252F6A467CD4C58CEF3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg, See my notes inline. Regards, Maarten PS. ITU-T has created an open area to share information with IETF and T1X1.5. for the moment access is limited via ftp client only. Work is ongoing to provide web access as well. > Host Name: ftp.itu.int > Host Type: Unix (Standard) > Remote Host Name: /tsg15opticaltransport > Log in with your username and password > Username: sg15opticalt > Password: otxchange In this open area you will find now 3 ASTN/ASON architecture document I have created. WD07 ASTN Layer Network Architecture - Multiplicity and interactions of Traffic Engineering and Network Engineering processes WD08 ASTN Layer Network Architecture WD20 ASTN/ASON Layer Network Architecture (view) "Bernstein, Greg" wrote: > > Hi Maarten et. al., I had two cases in mind. You'll have to meet me halfway > on the terminology (I'm using SONET below in my examples). No problem, SONET terminology is well understood by me. :-) > (1) Signaling for each layer -- this can use a "common signaling" protocol > with different "objects" or "information element" particular to that layer. > This protocol would be used between the appropriate entities that control > the switching at that particular layer. For example, say I want to switch > VT1.5s (a container for carrying T1s in SONET) then I would signal between > the VT1.5 switches along the path using this common protocol. If I first > needed to connect some STS-1 paths between these VT1.5 switches then the > signaling protocol (with STS-1 descriptions in it) would be used between > these STS-1 switches. We seem aligned here. > Now if a vendor chooses to integrate STS-1 and VT1.5 > switching in the same box its up to them whether they choose to separate > these signaling control entities or combine them into one entity. Partly aligned here... Within one vendor's subnetwork I agree that a vendor may choose to do this. But when the other switch is outside that vendor's subnetwork, the signaling protocol would have to meet the standard interface specification, which for ASON will have separate signalling control entities. > The logical layer model still stands. I didn't assume any particular > mechanism for the signaling transport (except IP) since different > layers/technologies may have different mechanisms available, e.g., > SONET's DCC. I also didn't want to dictate where the network > engineering function resides, i.e., where in the above example > you'd figure out the best place to put the STS-1 paths given > locations of VT1.5 switches, traffic trends, SONET line capacities > etc. Is this what you are calling a LNTC? Yes, this is what I intend torefer to by LNTC. Note - LNTC is a new term that came to my mind when creating the previous reply. During the Q.12/15 meeting last week people indicated that we need alternative terms for "traffic engineering" and "network engineering" in the way I was using those. My "network engineering" is controlling to some extend the layer network topology; of course it isn't capable to add extra hardware or software to the network, but it can modify the topology by adding/removing/increasing/shrinking links (G.805 terminology)). If you can think of a better term for this, let me know. I am looking for a better term for "traffic engineering" (in my definition) process. Perhaps this should be split into two "controllers"; one concerned with distributing reachability/topology information and link state information, and another concerned with the actual route finding and connection setup/release. Any suggestions? > > (2) Routing for each layer -- Here things are a little less obvious to me. > Yes, I can run a separate instance of a route protocol for each layer but > can I keep things simpler and would it be truly simpler. Back to the SONET > example. For setting up STS-1 (or STS-Nc) connections I would want to know > about SONET line layer topology (via a link state route protocol). You need to know the fabrics and the links between those fabrics. It is irrelevant if those links are provided by SONET lines or something else. > For setting up the VT1.5 connections I would want to know about the > SONET STS-1 layer connectivity between the VT1.5 layer switches. You need to know the fabrics and the links between those fabrics. It is irrelevant if those links are provided by SONET STS-1s or something else. E.g. a VC-4, sub-STM-0 or sub-STS-1 interfaces, ATM (some operators use ATM VCs to carry VT/LOVC signals) or MPLS (see ongoing SONEt/SDH over MPLS work). > If one had a network with switches with combined (multi-layer) > switching capability then I could see some advantages in combining > these. At a minimum I can see that the network engineering > function for the VT1.5 layer switches (the thing that > needs to set up the bandwidth between the VT1.5 layer switches) would want > to know about both layers (it must know about the SONET line layer). I have to disagree here. The network engineering function for the VT1.5 layer switches needs to know only - the set of VT1.5 layer network "S_LN" ports (refer to WD08 section 5, figure 38) or "class D" ports (WD20, section 2.3, figure 3) that are present in the VT1.5 switches - the reachability information per (group of) port(s). The network engineering function (or LNTC) decides on the available information between which two VT1.5 switches a VT1.5 link is to be added or extended. Once this is decided, the LNTC has to determine if this can be realised by menas of a direct link (single hop) or if a multi-hop link is the only possibility; in the latter case the two ports to be interconnected can not reach each other directly. Then, the VT1.5 LNTC requests the new VT1.5 link (or links) to be created by its server layer(s) between the specific ports (or port groups). There is no need to know anything about the SONET line layer here. Furthermore, you should consider that the network must perform its tasks independent of the physical grouping of functions. I.e. the behaviour of the network must be the same independent of the fact of VT1.5 fabrics and STS fabrics are in separate equipment, or in the same equipment, or a mix of both is present. You should not base your design on only one of the possible cases. > This > is what motivates integrating multiple layers into a single instance of a > routing protocol. But what about more than two layers? How would a knowing > the DS0 connectivity/traffic trends be of use to the network engineering > function for STS-1 paths between VT1.5 switches? I don't think so since we > see this via the VT1.5 trends anyhow. Similarly the properties of layers > below the SONET line layer should be already summarized via SRLG info so I'm > not sure that knowing the exact topology down at the waveband level is all > that helpful. I have the feeling that you are almost coming to the same conclusion as I am in the lines above. I.e. if you can do a good job at DS0 level without having knowledge of underlying STS, line and below layers why would one need to have line level knowledge when being at VT1.5 level? If you don't need it at one place, you can apply the same mechanism at other places and you don't need it at those places either. > Kireeti (or Yakov) the forwarding adjacency concept was > introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was > for MPLS within MPLS now we are talking multiplex hierarchies where the > entities at the different layers are very much different from each other. Allow me a side step here... from a transport perspective MPLS is having some unique characteristics: "one technology, infinite number of layer networks, infinite number of connection monitoring levels (potential iff MPLS OAM is introduced)". E.g. as MPLS is connection oriented, I can use transport layer terminology to describe the MPLS network architecture: - the outer MPLS layer network connects to (non-MPLS) client layer networks via adaptation functions - adaptation functions to client layer networks can be of the 1:1 type (1 client signal into 1 MPLS signal) or of the n:1 type (n client signals multipelxed into 1 MPLS signal) - a client layer signal is as such adapted to become an MPLS signal before it is transported. Assume that MPLS OAM is available, such MPLS OAM can be added to the signal to provide more extensive transport monitoring capabilities to the signal transport. At this point, end-to-end trail monitoring is established. - Traversing the MPLS layer network, the signal may pass through third party subnetworks. Each of these subnetworks may need to monitor the quality of service of the transport fo the signal through their network, and these networks can now add a new level of MPLS OAM to the signal (i.e. tandem connection monitoring). - Contrary to CBR techniques, MPLS doesn't have to steal overhead bandwidht from the original signal. Instead it can simply add such OAM to the signal. At the same time, it can add another MPLS header to the signal and associate this with the new OAM that is added (improvement over ATM's segment monitoring capability). This makes the signal transport in one subnetwork domain realy independent of its transport in previous domains (true independence is obtained). - let me now focus on the multi-layer aspect of MPLS. If you multiplex several MPLS signals into an MPLS aggregate signal, you have created essentially a second MPLS layer network supporting the first MPLS layer network. The trails in this second MPLS layer network support thus first MPLS layer network links. - From a routing perspective links are static elements in the layer network, and you can now operate the MPLS network as a bunch of independent layer networks, with client/server relationships within the MPLS network itself. On one technology you can now operate a number of logical layers; e.g. an MPLS access layer, a MPLS metro layer and a MPLS core layer. Each will have their specific characteristics (e.g. typical bandwidth of the MPLS signal; small for access, medium for metro, large for core). - the nice thing here is that you can mix and match these logical MPLS layer networks in equipment without the need to install different fabrics. As each logical MPLS layer network can be run with its own control plane instance, you will not run into scalability issues or unwanted access/metro/core interactions. So, all the good stuff from CBR networks without their restrictions. :-) > > Maarten, are we converging here (except for terminology of course)? I have the feeling that we are converging. Let's see if the above notes bring us even closer. Up to so far. Regards, Maarten > > Greg B. > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Tuesday, June 12, 2001 1:19 AM > To: Bernstein, Greg > Cc: Diego Caviglia; Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; > ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Greg, > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer > protocol > > instances than network layers. > > I am not sure I understand the meaning of the last sentence... does it > refer to: > a common Signalling Communication Network (SCN) over which all > signalling messages are transported for all layer networks? > > The ASON model under definition shows per switched layer network a > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. > Subnetworks may be nested, and the lowest level subnetwork is a Fabric. > These SCs communicate with each other over the SCN. LOVC-SCs communicate > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs > communicate with other ODU1-SCs, etc to exchange link state/topology > information (case of I-NNI), reachability information (case of E-NNI, > UNI) and routing information (connection setup). This is at the moment > also referred to as "intra-layer" information exchange. > > For the case we decide that a Network Engineering agent is included in > an SC, we will get also "inter-layer" information exchange. E.g. > HOVC-SCs may also communicate with LOVC-SCs to provide reachability > information for ports (e.g. STS1 and VC4 access groups) within the LOVC > layer network. For the case we decide that Network Engineering agents > are not part of the SC (but in a separate "layer network topology > controller" (LNTC)), "inter-layer" information exchange will be between > an SC and a LNTC. This latter model has a preference at the moment, > while the two processes (SC: routing, LNTC: network topology) have a > different scope. > > Note - LNTC within one layer network have to communicate with each other > also to build up an understanding of potential topology capabilities > present in the layer network (or layer network partition the LNTC is > responsible for). > > Separate of the above, the ASON recommendations will specify the signal > flow over inter domain interfaces where > - a customer interconnects with an operator > - two operators interconnect > - two vendors interconnect. > > Over these inter domain interfaces you have to comply to the signal > (message) structure. For ASON networks this will be based on the layer > network structure. Within one domain the same layer network structured > approach may be used, or one may decide to create a "spaghetti mountain" > in which the layer network structure is not adhered to. That's up to the > individual vendor. > > Regards, > > Maarten > > "Bernstein, Greg" wrote: > > > > Hi Maarten, Diego, et. al. > > what's interesting here is the question of what do we mean by "its own > > instance of a control plane"? Obviously if we are setting up a LOVC (in > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling > to > > those switches that are LOVC capable. Other switches need not be > involved. > > If it turns out that the LOVC capable switches are not interconnected by a > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > > appropriate HOVC interconnecting the LOVC needs to be setup first. In > GMPLS > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > > switches before we set up the LOVC LSPs. > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer > protocol > > instances than network layers. Well actually as Maarten wrote in a recent > > ITU document that we would be primarily interested in those layers > involved > > in dynamic switching/multiplexing. Note that we've started to bring in > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > > (the WDM--SONET example I always give). > > > > With the signaling protocol things are really separated by who is involved > > in the signaling transaction. In the routing case things are less clear, > > i.e., who wants/needs to know information about other layers and what > burden > > does this present to the NEs and scalability. Which layers can benefit by > > integration... I'll be updating the Optical inter-domain route > requirements > > draft soon (with others) and will be exploring some of these items in more > > depth. > > > > (Terminology: LOVC := Lower order virtual container, SDH term that > includes > > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps > in > > the SDH hierarchy). > > > > Greg B. > > *********************************** > > Dr. Greg M. Bernstein > > Senior Scientist, Ciena Corporation > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, June 11, 2001 7:46 AM > > To: Diego Caviglia > > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: Re: GMPLS Sonet extensions > > > > Diego, > > > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > > and OCh) will have its own (instance of) control plane. > > > > Each switched layer network runs a copy of the generic routing protocol; > > it does so within the boundaries of the switched layer network. > > > > Within each switched layer network you will find UNI, E-NNI and I-NNI > > interfaces due to partitioning of a switched layer network. Topology > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > > the other hand only provide reachability information. > > > > For the case an MPLS router is from a different organisation than the > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > > the interface will be an MPLS-I-NNI. > > For the server layers within the MPLS router (e.g. HOVC and STM-N > > section layers) the interface relation is to be determined independent > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > > as at the HOVC layer entwork only reachability information is available > > in the MPLS router (HOVC-E-NNI). > > > > The MPLS router should not be concerned at all about the routing of the > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > > link between is needed between MPLS router A and MPLS router B, router A > > needs to have knowledge of router B's address/name only to request a > > VC-4-16c/STS-48c connection through the transport network. The switched > > HOVC (transport) network will take care of the connection setup. > > > > And even if two diverse routed connections are required (e.g. to support > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > > needs to request only the creation of 2 VC-4-16c connections with the > > constraint of being diversely routed. The switched HOVC network will be > > able to provide these two connections diversely routed between A and B > > routers. > > > > At the moment, I recognise two connection types in a layer network: > > - native connections and > > - client connections. > > Example: within a HOVC layer network a STS1 or VC-4 connection is a > > native connection, and a DS3 connection or a LOVC link is a client > > connection. A client connection is supported by the HOVC layer network > > after adapting it to the layer network signal type (i.e. STS1 (to > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > > can have a > > - 1:1, > > - 1:n, > > - n:1 > > relationship with the underlying layer network signal. > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > > relationship. > > > > With client connections, an I-NNI is almost per definition not possible > > (you go outside the layer network). Nevertheless, some people consider > > the special 1:1 case as an area where an I-NNI could be deployed; of > > course not for the case of DS3 -> STS1, but for the case of > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > > HOVC layer network and a client signal to the OCh and ODU1 layer > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > > wavelenght it is easy to think to be within one and the same layer > > network. Personally, I believe that such very special case looks much > > brighter than it is in the long term. I.e. don't declare very special > > cases to be the common ones; keep those as very special cases, best even > > keep those as regular cases obeying to the generic rules. > > > > Client connections as such have UNI or E-NNI interface relationships > > over which reachability information is offered at best. This is the case > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > > layer entwork) as well as "vertical client connections" (e.g. a LOVC > > link over a HOVC/STS layer network). > > > > Regards, > > > > Maarten > > > > Diego Caviglia wrote: > > > > > > Maarten, > > > I agree in principle with you but this means it > would > > be > > > necessary to have a routing protocol for each layer doesn't it? > > > > > > One of the initial reasons for (G)MPLS is to unify the control > > plane, your > > > layered view of the network implies again the separation of the control > > planes. > > > > > > The Transport Network is very different from a flat IP network and > > layering in > > > TN is implicit. > > > > > > If I understood your model correctly the MPLS Router only views, > Access > > Groups > > > and links to other MPLS Routers. If there are free resources between > > the two > > > routers the TE process calculates, accordingly to some rules, the best > > path. > > > > Agree. > > > > > If > > > there are no resources a call to the Network Engineering agent is > > performed, the > > > NE makes a call to the TE of the SONET layer in order to provide a > trail > > to the > > > MPLS layer (this procedure is repeated until available resources are > > created for > > > the MPLS router connection). This trail modifies the topology at the > MPLS > > layer. > > > > Agree. One note however, operators have indicated that they would like > > to deploy policies in the NE agent which may include some thresholds, > > before it decides to change the topology of the layer network. E.g. > > topology is not extended unless X calls failed. On the other hand, the > > NE agent may have scheduled topology changes; e.g. at the begin of busy > > hour extra links are added or bandwidth of existing link is extended, > > and at the end of busy hour the reverse is happening. > > > > > > > > If my understanding is correct and we want to implement an automated > TN > > a sort > > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > > > UNI or E-NNI. > > > > > > > > Maybe this will create some problems, on the other hand, as Maarten > > pointed out, > > > flat networks won't work due the huge amount of routing information > > that they > > > have to carry. > > > > > > Regards > > > > > > Diego > > > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > > , ccamp@ops.ietf.org(bcc: > > > Diego Caviglia/MAIN/MC1) > > > > > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > Sharma, > > > > > > "flat" set up is the route to disaster... simply consider a switched > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > > would get information of all these levels... an absolute disaster in a > > > world wide switched transport network would be the result. > > > > > > Therefore, there is this layering in which a server layer network > > > provides bandwidth to its client layer entworks. the client layer > > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > > can route their signals. > > > > > > A separate entity (I called it "network engineering") is looking over > > > the shoulder of the call setup process to see if more bandwidth is > > > needed and when it would be needed or not longer required. But today, > > > this separate entity is not part of the control plane; it is in the > > > management plane. > > > > > > Regards, > > > > > > Maarten > > > > > > Susumu Yoneda wrote: > > > > > > > > Sharma, > > > > > > > > Thank you for letting me know your presentation material which looks > > very > > > > interesting. It seems to me that a layered setup would make a sense. > > > > However, users may want to have a "flat" setup. Therefore, lower > setups > > > > would not be seen by users? > > > > > > > > -----Original Message----- > > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > > Sent: Saturday, June 09, 2001 11:06 AM > > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > > Subject: RE: GMPLS Sonet extensions > > > > > > > > Jimmy, Susumu, > > > > > > > > Your idea (assuming a peer model) is basically correct. Since all > nodes > > > > have the same view of the network, you could compute an ERO at the > > > > ingress router and have the PATH message follow the hop-by-hop route > > > > to the egress router. > > > > (Note, however, that the PATH message will travel > > > > on the out-of-band IP control network; therefore, it would be > > non-associated > > > > signaling.) > > > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > > in fact, have to be shared by all nodes, since that is precisely what > > > > the "peer model" implies. > > > > > > > > But you do have to be careful about what "LSP" you are requesting, > since > > the > > > > characteristics of the requested LSP are not interpreted in the same > way > > by > > > > the > > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > > different > > > > way of defining a circuit than an IP router or an OXC.) > > > > Therefore, one possibility would be to do a "layered setup", where an > > LSP > > > > at the lower layer is setup before the PATH message at the higher > layer > > > > is tunnelled over it or allowed to propagate further. > > > > > > > > For example, when the PATH message for the packet > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > > a corresponding SONET circuit between themselves, and then either > tunnel > > > > the PATH message for the packet LSP over this circuit, or (assuming > your > > > > out-of-band network), at that time, allow the PATH message for the > > packet > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > > channel, likewise, would be a recursive process, with the OXC first > > setting > > > > up an optical lightpath between themselves, and tunneling the request > to > > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > > > A more detailed discussion of this subject, with corresponding > > animations > > > > and figures, that you may also find helpful is available in a talk I > > gave at > > > > MPLSCon'01, and can be found at: > > > > http://www.mplscon.com/missing_presentations.htm > > > > (Dynamic path establishment in MPLS-controlled multi-service > networks.) > > > > > > > > -Vishal > > > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > > [SMTP:yone@japan-telecom.co.jp] > > > > wrote: > > > > > Hi, > > > > > > > > > > I also assume that there would be an out-of-band signalling network > > based > > > > on > > > > > a suite of GMPLS protocols including LMP. I think there will be > issues > > to > > > > > address whether all messages will be shared by all nodes, i.e > router, > > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > > ------------------------------- > > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > > Japan Telecom fax +81 3 5540 8485 > > > > > Information & Communication Labs. > > > > > e-mail yone@japan-telecom.co.jp > > > > > ------------------------------- > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf > > > > Of > > > > > Jimmy Gendron > > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > > To: 'ccamp@ops.ietf.org' > > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > understand > > > > > most of the architecture, but I still have a question since the > > beginning; > > > > > as an unified control plane, how do the routing/signaling protocols > > > > exchange > > > > > informations on a configuration like this: > > > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > > (Ingress) > > > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > > understand > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > > the > > > > two > > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > > (Assuming > > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > > > My guess is that the PATH message will leave the ingress router with > a > > > > PATH > > > > > message with a calculated ERO. It assumes that the network is in > > respect > > > > > with the peer model...everyone have the same routing table and know > > the > > > > > actual network topology. So, my PATH message will follow the CSPF > > (ERO) > > > > and > > > > > go to the egress router. Am I right? > > > > > > > > > > Best regards, > > > > > > > > > > Jimmy Gendron > > > > > --------------768A252F6A467CD4C58CEF3D 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 --------------768A252F6A467CD4C58CEF3D-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 02:56:16 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C9B0460@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , Mina Azad Cc: Scott Bradner Subject: RE: TE-WG Design Team Date: Wed, 13 Jun 2001 11:54:29 +0200 MIME-Version: 1.0 Content-Type: text/plain I thought that in the announcement we explained that we had far too many volunteers. You then have to choose. We consulted with a number of ADs and TAs and the WG chairs, and based on the input we got from the volunteers we came up with the list. We used cirteria like apparent knowledge of the topic, know organization, etc... I don't think it makes sense to go into a detailed discussion here. But instead... we should trust that the DT will come up with a good initial InternetDraft that contains the requirements and that based on that we can have a good technical discussion. Bert > ---------- > From: Mina Azad[SMTP:mazad@nortelnetworks.com] > Sent: Tuesday, June 12, 2001 11:09 PM > To: Wijnen, Bert (Bert); ccamp-wg > Cc: Scott Bradner > Subject: RE: TE-WG Design Team > > You wrote: > "We evaluated the volunteers with the ADs, TAs and TEWG chairs and we > decided to compose the team..." > > May I ask what was your evaluation criteria? > > Mina Azad > ATM/IP OAM Standards Specialist > Nortel Networks > mazad@nortelnetworks.com > 1-613-763-2044 (ESN 393-2044) > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com] > > Sent: Tuesday, June 12, 2001 4:49 PM > > To: ccamp-wg > > Cc: Scott Bradner > > Subject: TE-WG Design Team > > > > > > All, > > > > > We had a great response to our call for volunteers - 27 > > people sent in > > > their names and indicated their readyness to help. As > > noted in RFC 2418 > > > sec 6.5 design teams work best when they are small so we > > could not accept > > > everyone who offered their services. We evaluated the > > volunteers with the > > > ADs, TAs and TEWG chairs and we decided to compose the team > > as follows: > > > > > Ed Kern, ejk@tech.org (chair). > > > Malin Carlzon, malin@sunet.se > > Tim Griffin, griffin@research.att.com > > Tom Reddington, treddington@bell-labs.com > > Chris Liljenstolpe, chris@cw.net > > Wai Sum Lai, wlai@att.com > > Longsong Lin, llin@mmcnet.com > > Dave McDysan, dave.mcdysan@wcom.com > > Rob Coltun, rcoltun@redback.com > > > > > We thank everyone who volunteered for their willingness to > > serve. we also > > > want to remind everyone (including the design team) that, as noted > > > in the same section of RFC 2418, "The output of a design > > team is always > > > subject to approval, rejection or modification by the WG as > > a whole." > > > i.e. being on the design team means that the rest of the WG > > will get to > > > comment on their work without having to put in the original effort. > > > > > > We will be sending out a formal charge to the designe team > > in the next few > > > days and expect that they will produce an Internet Draft > > (well) before > > > the ID cutoff for the London IETF meeting. > > > > > > Bert & Scott > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 13 Jun 2001 01:06:03 -0700 Message-ID: From: "Mannie, Eric" To: 'manoj juneja' , ccamp@ops.ietf.org Subject: RE: Signal Type doubt in GMPLS Date: Wed, 13 Jun 2001 10:04:40 +0200 MIME-Version: 1.0 Content-Type: text/plain Hello Manoj, >Also, for signal types STM-1, STM-4 etc. it is written in braces >that "only when requesting transparency". What does this exactly mean ? When you request some transparency it means transparency in the SOH, so you don't just request some payload, you request something related to the frame itself. Some part of the SOH has to be delivered at the other end of the LSP untouched. This can be achieved in several ways, e.g. simply forwarded untouched (and this doesn't require any new standard, e.g. you keep the DCC untouched and you forward it :-) by the intermediate nodes in the network, or tunnelled in some overhead bytes. We didn't want to use a VC type of signal with transparency because the SOH is not part of this VC, we used STM-N. This is much cleaner. >What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs. An AUG-X signal type means the space taken by the AUG-X, it is like a TUG or VTG signal. That allows to open a circuit without specifying its content, your SDH framer will recognise the content automatically. For instance, I am a customer and I don't care about transparency. I am connected to a switch with an STM-4 interface. I want to open a circuit with the bandwidth equivalent of an STM-1 whose content can change, e.g. first I structure it as 3 x VC-3's, later on I want one VC-4. I request an AUG-1 circuit. Kind regards, Eric -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Tuesday, June 12, 2001 9:31 PM To: ccamp@ops.ietf.org Subject: Signal Type doubt in GMPLS Hi, I have certain doubts regarding signal type field in sonet-sdh 00.txt draft. What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs. When signal type is AUG-256, what does this exatly mean ? Also, for signal types STM-1, STM-4 etc. it is written in braces that "only when requesting transparency". What does this exactly mean ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 16:09:55 -0700 Message-ID: From: "Bernstein, Greg" To: 'Maarten Vissers' Cc: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Date: Tue, 12 Jun 2001 16:06:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten et. al., I had two cases in mind. You'll have to meet me halfway on the terminology (I'm using SONET below in my examples). (1) Signaling for each layer -- this can use a "common signaling" protocol with different "objects" or "information element" particular to that layer. This protocol would be used between the appropriate entities that control the switching at that particular layer. For example, say I want to switch VT1.5s (a container for carrying T1s in SONET) then I would signal between the VT1.5 switches along the path using this common protocol. If I first needed to connect some STS-1 paths between these VT1.5 switches then the signaling protocol (with STS-1 descriptions in it) would be used between these STS-1 switches. Now if a vendor chooses to integrate STS-1 and VT1.5 switching in the same box its up to them whether they choose to separate these signaling control entities or combine them into one entity. The logical layer model still stands. I didn't assume any particular mechanism for the signaling transport (except IP) since different layers/technologies may have different mechanisms available, e.g., SONET's DCC. I also didn't want to dictate where the network engineering function resides, i.e., where in the above example you'd figure out the best place to put the STS-1 paths given locations of VT1.5 switches, traffic trends, SONET line capacities etc. Is this what you are calling a LNTC? (2) Routing for each layer -- Here things are a little less obvious to me. Yes, I can run a separate instance of a route protocol for each layer but can I keep things simpler and would it be truly simpler. Back to the SONET example. For setting up STS-1 (or STS-Nc) connections I would want to know about SONET line layer topology (via a link state route protocol). For setting up the VT1.5 connections I would want to know about the SONET STS-1 layer connectivity between the VT1.5 layer switches. If one had a network with switches with combined (multi-layer) switching capability then I could see some advantages in combining these. At a minimum I can see that the network engineering function for the VT1.5 layer switches (the thing that needs to set up the bandwidth between the VT1.5 layer switches) would want to know about both layers (it must know about the SONET line layer). This is what motivates integrating multiple layers into a single instance of a routing protocol. But what about more than two layers? How would a knowing the DS0 connectivity/traffic trends be of use to the network engineering function for STS-1 paths between VT1.5 switches? I don't think so since we see this via the VT1.5 trends anyhow. Similarly the properties of layers below the SONET line layer should be already summarized via SRLG info so I'm not sure that knowing the exact topology down at the waveband level is all that helpful. Kireeti (or Yakov) the forwarding adjacency concept was introduced for dealing with hierarchy in MPLS and MPLS tunnels, but this was for MPLS within MPLS now we are talking multiplex hierarchies where the entities at the different layers are very much different from each other. Maarten, are we converging here (except for terminology of course)? Greg B. -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Tuesday, June 12, 2001 1:19 AM To: Bernstein, Greg Cc: Diego Caviglia; Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Greg, > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. I am not sure I understand the meaning of the last sentence... does it refer to: a common Signalling Communication Network (SCN) over which all signalling messages are transported for all layer networks? The ASON model under definition shows per switched layer network a hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. Subnetworks may be nested, and the lowest level subnetwork is a Fabric. These SCs communicate with each other over the SCN. LOVC-SCs communicate with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs communicate with other ODU1-SCs, etc to exchange link state/topology information (case of I-NNI), reachability information (case of E-NNI, UNI) and routing information (connection setup). This is at the moment also referred to as "intra-layer" information exchange. For the case we decide that a Network Engineering agent is included in an SC, we will get also "inter-layer" information exchange. E.g. HOVC-SCs may also communicate with LOVC-SCs to provide reachability information for ports (e.g. STS1 and VC4 access groups) within the LOVC layer network. For the case we decide that Network Engineering agents are not part of the SC (but in a separate "layer network topology controller" (LNTC)), "inter-layer" information exchange will be between an SC and a LNTC. This latter model has a preference at the moment, while the two processes (SC: routing, LNTC: network topology) have a different scope. Note - LNTC within one layer network have to communicate with each other also to build up an understanding of potential topology capabilities present in the layer network (or layer network partition the LNTC is responsible for). Separate of the above, the ASON recommendations will specify the signal flow over inter domain interfaces where - a customer interconnects with an operator - two operators interconnect - two vendors interconnect. Over these inter domain interfaces you have to comply to the signal (message) structure. For ASON networks this will be based on the layer network structure. Within one domain the same layer network structured approach may be used, or one may decide to create a "spaghetti mountain" in which the layer network structure is not adhered to. That's up to the individual vendor. Regards, Maarten "Bernstein, Greg" wrote: > > Hi Maarten, Diego, et. al. > what's interesting here is the question of what do we mean by "its own > instance of a control plane"? Obviously if we are setting up a LOVC (in > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to > those switches that are LOVC capable. Other switches need not be involved. > If it turns out that the LOVC capable switches are not interconnected by a > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > switches before we set up the LOVC LSPs. > > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. Well actually as Maarten wrote in a recent > ITU document that we would be primarily interested in those layers involved > in dynamic switching/multiplexing. Note that we've started to bring in > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > (the WDM--SONET example I always give). > > With the signaling protocol things are really separated by who is involved > in the signaling transaction. In the routing case things are less clear, > i.e., who wants/needs to know information about other layers and what burden > does this present to the NEs and scalability. Which layers can benefit by > integration... I'll be updating the Optical inter-domain route requirements > draft soon (with others) and will be exploring some of these items in more > depth. > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > the SDH hierarchy). > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Scientist, Ciena Corporation > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, June 11, 2001 7:46 AM > To: Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Diego, > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > and OCh) will have its own (instance of) control plane. > > Each switched layer network runs a copy of the generic routing protocol; > it does so within the boundaries of the switched layer network. > > Within each switched layer network you will find UNI, E-NNI and I-NNI > interfaces due to partitioning of a switched layer network. Topology > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > the other hand only provide reachability information. > > For the case an MPLS router is from a different organisation than the > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > the interface will be an MPLS-I-NNI. > For the server layers within the MPLS router (e.g. HOVC and STM-N > section layers) the interface relation is to be determined independent > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > as at the HOVC layer entwork only reachability information is available > in the MPLS router (HOVC-E-NNI). > > The MPLS router should not be concerned at all about the routing of the > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > link between is needed between MPLS router A and MPLS router B, router A > needs to have knowledge of router B's address/name only to request a > VC-4-16c/STS-48c connection through the transport network. The switched > HOVC (transport) network will take care of the connection setup. > > And even if two diverse routed connections are required (e.g. to support > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > needs to request only the creation of 2 VC-4-16c connections with the > constraint of being diversely routed. The switched HOVC network will be > able to provide these two connections diversely routed between A and B > routers. > > At the moment, I recognise two connection types in a layer network: > - native connections and > - client connections. > Example: within a HOVC layer network a STS1 or VC-4 connection is a > native connection, and a DS3 connection or a LOVC link is a client > connection. A client connection is supported by the HOVC layer network > after adapting it to the layer network signal type (i.e. STS1 (to > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > can have a > - 1:1, > - 1:n, > - n:1 > relationship with the underlying layer network signal. > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > relationship. > > With client connections, an I-NNI is almost per definition not possible > (you go outside the layer network). Nevertheless, some people consider > the special 1:1 case as an area where an I-NNI could be deployed; of > course not for the case of DS3 -> STS1, but for the case of > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > HOVC layer network and a client signal to the OCh and ODU1 layer > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > wavelenght it is easy to think to be within one and the same layer > network. Personally, I believe that such very special case looks much > brighter than it is in the long term. I.e. don't declare very special > cases to be the common ones; keep those as very special cases, best even > keep those as regular cases obeying to the generic rules. > > Client connections as such have UNI or E-NNI interface relationships > over which reachability information is offered at best. This is the case > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > layer entwork) as well as "vertical client connections" (e.g. a LOVC > link over a HOVC/STS layer network). > > Regards, > > Maarten > > Diego Caviglia wrote: > > > > Maarten, > > I agree in principle with you but this means it would > be > > necessary to have a routing protocol for each layer doesn't it? > > > > One of the initial reasons for (G)MPLS is to unify the control > plane, your > > layered view of the network implies again the separation of the control > planes. > > > > The Transport Network is very different from a flat IP network and > layering in > > TN is implicit. > > > > If I understood your model correctly the MPLS Router only views, Access > Groups > > and links to other MPLS Routers. If there are free resources between > the two > > routers the TE process calculates, accordingly to some rules, the best > path. > > Agree. > > > If > > there are no resources a call to the Network Engineering agent is > performed, the > > NE makes a call to the TE of the SONET layer in order to provide a trail > to the > > MPLS layer (this procedure is repeated until available resources are > created for > > the MPLS router connection). This trail modifies the topology at the MPLS > layer. > > Agree. One note however, operators have indicated that they would like > to deploy policies in the NE agent which may include some thresholds, > before it decides to change the topology of the layer network. E.g. > topology is not extended unless X calls failed. On the other hand, the > NE agent may have scheduled topology changes; e.g. at the begin of busy > hour extra links are added or bandwidth of existing link is extended, > and at the end of busy hour the reverse is happening. > > > > > If my understanding is correct and we want to implement an automated TN > a sort > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > UNI or E-NNI. > > > > > Maybe this will create some problems, on the other hand, as Maarten > pointed out, > > flat networks won't work due the huge amount of routing information > that they > > have to carry. > > > > Regards > > > > Diego > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > , ccamp@ops.ietf.org(bcc: > > Diego Caviglia/MAIN/MC1) > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > Sharma, > > > > "flat" set up is the route to disaster... simply consider a switched > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > would get information of all these levels... an absolute disaster in a > > world wide switched transport network would be the result. > > > > Therefore, there is this layering in which a server layer network > > provides bandwidth to its client layer entworks. the client layer > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > can route their signals. > > > > A separate entity (I called it "network engineering") is looking over > > the shoulder of the call setup process to see if more bandwidth is > > needed and when it would be needed or not longer required. But today, > > this separate entity is not part of the control plane; it is in the > > management plane. > > > > Regards, > > > > Maarten > > > > Susumu Yoneda wrote: > > > > > > Sharma, > > > > > > Thank you for letting me know your presentation material which looks > very > > > interesting. It seems to me that a layered setup would make a sense. > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > would not be seen by users? > > > > > > -----Original Message----- > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > Sent: Saturday, June 09, 2001 11:06 AM > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: RE: GMPLS Sonet extensions > > > > > > Jimmy, Susumu, > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > have the same view of the network, you could compute an ERO at the > > > ingress router and have the PATH message follow the hop-by-hop route > > > to the egress router. > > > (Note, however, that the PATH message will travel > > > on the out-of-band IP control network; therefore, it would be > non-associated > > > signaling.) > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > in fact, have to be shared by all nodes, since that is precisely what > > > the "peer model" implies. > > > > > > But you do have to be careful about what "LSP" you are requesting, since > the > > > characteristics of the requested LSP are not interpreted in the same way > by > > > the > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > different > > > way of defining a circuit than an IP router or an OXC.) > > > Therefore, one possibility would be to do a "layered setup", where an > LSP > > > at the lower layer is setup before the PATH message at the higher layer > > > is tunnelled over it or allowed to propagate further. > > > > > > For example, when the PATH message for the packet > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > a corresponding SONET circuit between themselves, and then either tunnel > > > the PATH message for the packet LSP over this circuit, or (assuming your > > > out-of-band network), at that time, allow the PATH message for the > packet > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > channel, likewise, would be a recursive process, with the OXC first > setting > > > up an optical lightpath between themselves, and tunneling the request to > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > A more detailed discussion of this subject, with corresponding > animations > > > and figures, that you may also find helpful is available in a talk I > gave at > > > MPLSCon'01, and can be found at: > > > http://www.mplscon.com/missing_presentations.htm > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > -Vishal > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > [SMTP:yone@japan-telecom.co.jp] > > > wrote: > > > > Hi, > > > > > > > > I also assume that there would be an out-of-band signalling network > based > > > on > > > > a suite of GMPLS protocols including LMP. I think there will be issues > to > > > > address whether all messages will be shared by all nodes, i.e router, > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > ------------------------------- > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > Japan Telecom fax +81 3 5540 8485 > > > > Information & Communication Labs. > > > > e-mail yone@japan-telecom.co.jp > > > > ------------------------------- > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf > > > Of > > > > Jimmy Gendron > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > To: 'ccamp@ops.ietf.org' > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > Hi, > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > understand > > > > most of the architecture, but I still have a question since the > beginning; > > > > as an unified control plane, how do the routing/signaling protocols > > > exchange > > > > informations on a configuration like this: > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > (Ingress) > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > understand > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > the > > > two > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > (Assuming > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > My guess is that the PATH message will leave the ingress router with a > > > PATH > > > > message with a calculated ERO. It assumes that the network is in > respect > > > > with the peer model...everyone have the same routing table and know > the > > > > actual network topology. So, my PATH message will follow the CSPF > (ERO) > > > and > > > > go to the egress router. Am I right? > > > > > > > > Best regards, > > > > > > > > Jimmy Gendron > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 16:03:54 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Date: Tue, 12 Jun 2001 16:02:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, I am looking for the information regarding the companies who have implemented GMPLS. I want to know whether they support SONET/SDH only or waveband is also supported ? Thanks in advance, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 14:11:23 -0700 Message-ID: <6DDA62170439D31185750000F80826AC065C8AA0@zmerd004.ca.nortel.com> From: "Mina Azad" To: "Wijnen, Bert (Bert)" , ccamp-wg Cc: Scott Bradner Subject: RE: TE-WG Design Team Date: Tue, 12 Jun 2001 17:09:03 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F383.E84DC4D0" 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_01C0F383.E84DC4D0 Content-Type: text/plain; charset="ISO-8859-1" You wrote: "We evaluated the volunteers with the ADs, TAs and TEWG chairs and we decided to compose the team..." May I ask what was your evaluation criteria? > Mina Azad > ATM/IP OAM Standards Specialist > Nortel Networks > mazad@nortelnetworks.com > 1-613-763-2044 (ESN 393-2044) > > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, June 12, 2001 4:49 PM > To: ccamp-wg > Cc: Scott Bradner > Subject: TE-WG Design Team > > > All, > > > We had a great response to our call for volunteers - 27 > people sent in > > their names and indicated their readyness to help. As > noted in RFC 2418 > > sec 6.5 design teams work best when they are small so we > could not accept > > everyone who offered their services. We evaluated the > volunteers with the > > ADs, TAs and TEWG chairs and we decided to compose the team > as follows: > > > Ed Kern, ejk@tech.org (chair). > > Malin Carlzon, malin@sunet.se > Tim Griffin, griffin@research.att.com > Tom Reddington, treddington@bell-labs.com > Chris Liljenstolpe, chris@cw.net > Wai Sum Lai, wlai@att.com > Longsong Lin, llin@mmcnet.com > Dave McDysan, dave.mcdysan@wcom.com > Rob Coltun, rcoltun@redback.com > > > We thank everyone who volunteered for their willingness to > serve. we also > > want to remind everyone (including the design team) that, as noted > > in the same section of RFC 2418, "The output of a design > team is always > > subject to approval, rejection or modification by the WG as > a whole." > > i.e. being on the design team means that the rest of the WG > will get to > > comment on their work without having to put in the original effort. > > > > We will be sending out a formal charge to the designe team > in the next few > > days and expect that they will produce an Internet Draft > (well) before > > the ID cutoff for the London IETF meeting. > > > > Bert & Scott > > > > ------_=_NextPart_001_01C0F383.E84DC4D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: TE-WG Design Team

You wrote:
"We evaluated the volunteers = with the ADs, TAs and TEWG chairs and we decided to compose the = team..."

May I ask what was your evaluation = criteria?   

      Mina = Azad
      ATM/IP OAM Standards Specialist  
      Nortel Networks
      mazad@nortelnetworks.com
      1-613-763-2044 (ESN 393-2044)


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Tuesday, June 12, 2001 = 4:49 PM
> To: ccamp-wg
> Cc: Scott Bradner
> Subject: TE-WG Design = Team
>
>
> All,
>
> > We had a great response to = our call for volunteers - 27
> people sent in
> > their names and indicated = their readyness to help.  As
> noted in RFC 2418
> > sec 6.5 design teams work = best when they are small so we
> could not accept
> > everyone who offered their = services. We evaluated the
> volunteers with the
> > ADs, TAs and TEWG chairs = and we decided to compose the team
> as follows:
> >
>    Ed Kern, = ejk@tech.org  (chair).
> >    Malin = Carlzon, malin@sunet.se
>    Tim Griffin, = griffin@research.att.com
>    Tom = Reddington, treddington@bell-labs.com
>    Chris = Liljenstolpe, chris@cw.net
>    Wai Sum Lai, = wlai@att.com
>    Longsong = Lin,  llin@mmcnet.com
>    Dave McDysan, = dave.mcdysan@wcom.com
>    Rob Coltun, = rcoltun@redback.com
>
> > We thank everyone who = volunteered for their willingness to
> serve.  we also
> > want to remind everyone = (including the design team) that, as noted
> > in the same section of RFC = 2418, "The output of a design
> team is always
> > subject to approval, = rejection or modification by the WG as
> a whole."
> > i.e. being on the design = team means that the rest of the WG
> will get to
> > comment on their work = without having to put in the original effort.
> >
> > We will be sending out a = formal charge to the designe team
> in the next few
> > days and expect that they = will produce an Internet Draft
> (well) before
> > the ID cutoff for the = London IETF meeting.
> >
> > Bert & Scott
> >
>
>

------_=_NextPart_001_01C0F383.E84DC4D0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 13:50:24 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C9B0261@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg Cc: Scott Bradner Subject: TE-WG Design Team Date: Tue, 12 Jun 2001 22:48:45 +0200 MIME-Version: 1.0 Content-Type: text/plain All, > We had a great response to our call for volunteers - 27 people sent in > their names and indicated their readyness to help. As noted in RFC 2418 > sec 6.5 design teams work best when they are small so we could not accept > everyone who offered their services. We evaluated the volunteers with the > ADs, TAs and TEWG chairs and we decided to compose the team as follows: > Ed Kern, ejk@tech.org (chair). > Malin Carlzon, malin@sunet.se Tim Griffin, griffin@research.att.com Tom Reddington, treddington@bell-labs.com Chris Liljenstolpe, chris@cw.net Wai Sum Lai, wlai@att.com Longsong Lin, llin@mmcnet.com Dave McDysan, dave.mcdysan@wcom.com Rob Coltun, rcoltun@redback.com > We thank everyone who volunteered for their willingness to serve. we also > want to remind everyone (including the design team) that, as noted > in the same section of RFC 2418, "The output of a design team is always > subject to approval, rejection or modification by the WG as a whole." > i.e. being on the design team means that the rest of the WG will get to > comment on their work without having to put in the original effort. > > We will be sending out a formal charge to the designe team in the next few > days and expect that they will produce an Internet Draft (well) before > the ID cutoff for the London IETF meeting. > > Bert & Scott > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 13:38:49 -0700 From: ananth.nagarajan@mail.sprint.com Date: Tue, 12 Jun 2001 15:27:31 -0500 Message-Id: Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 TO: BRaja@tellium.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4167abb8-00000001" --openmail-part-4167abb8-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 12 Jun 2001 15:27:31 -0500" Content-Transfer-Encoding: 7bit Bala, Thanks for your reply. Sorry it took so long to reply back. Please see in-line. Thanks, Ananth bala>> > 1) Type of legacy equipment needing NSAP addresses bala>> > (also, is bala>> > this optical network element or client equipment?) bala>> > 2) Rough estimate of number of UNI ports needing NSAP address bala>> > (2002, 2005, and 2010) bala>> > 3) Description of application in which this legacy equipment bala>> > will use UNI bala>> > signaling bala>I don't recall seeing any response. furthermore, the NSAP bala>requirement was not unanimously endorsed by all carriers (at bala>the OIF). >From our OIF representatives, although it was not unanimously endorsed, there was a significant demand for NSAP support. Well, NSAP is the main non-IP type of addressing that is required. The general requirement is to be able to support non-IP addresses (probably have an address translation from non-IP addresses to routable addresses). bala>It would also be nice if you can give some insight on bala>the timeline in which you need various features, and whether bala>the current GMPLS developments are inadequate within bala>that timeline. (We can always have a progression of features). NSAP support will be needed always (e.g. support for legacy DCC that uses NSAP). So the timeframe requirement is now. Ananth>2) GMPLS is being defined based on assumptions about proprietary Ananth>transmission planes without those assumptions being specified. How can Ananth>we be sure that the control plane support is correct? How can we be Ananth>sure that it can be combined with other features? Assumptions Ananth>regarding the transmission plane that can affect the control plane must Ananth>be clearly documented. This creates the additional related problem that Ananth>there is not a clear inter-working defined for interaction between Ananth>standard/proprietary control planes/transmission planes. bala>BR: I get the feeling you're referring to the concatenation/transperency bala>issues discussed recently. While the debate has been hot, there's bala>no show stopper here. Several suggestions are being considered for bala>clarifying standard/non-standard features supported. The concatenation/transparency issues are a concern. In addition, management features such as manual protection switching, protection switching configuration, billing support (e.g. usage collection) etc need to be supported too. Ananth>3) Assuring separation of the control plane from the data plane Ananth>continues to arise.. When the control plane fails it should not affect Ananth> existing connections. Also if connections in progress are affected Ananth>then they should not leave partially setup connections - they should Ananth>fail gracefully informing the initiator. The GMPLS architecture Ananth>document mentions this separation, but it's not clear how the GMPLS Ananth>signaling specifications reflect the implications of this decoupling. bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS bala>based, as you know), and solutions in the RSVP/LDP space have been bala>proposed (some drafts may be written). bala>This is also not a show stopper by any means. Don't understand how the OIF UNI addresses this. Our concerns are more with respect to the NNI (internal separation of control and data). If this is not addressed, it is definitely a showstopper. According to our OIF representatives, the OIF is looking at the IETF to specify these protocols. To be specific, existing connections shouldn't be impacted when the control plane fails. Ananth>4) Support for NSAP addresses and in general support such that control Ananth>plane addressing is independent of clients and vice versa. Also Ananth>scalable naming/addressing scheme such as proposed in OIF. bala>BR: NSAP, see my initial comments. The OIF is not dealing with bala>names/resolution, etc. This has been decided to be out of the bala>scope of UNI signaling, and considered as a separate function. Address translation of some form (for e.g. NSAP address translation) should be supported. See comment at the beginning of the email. Ananth>5) Since the control plane may be supported via multiple protocols, Ananth>clear statement of what is - and isn't - covered in the GMPLS Signaling Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed. bala>BR: Don't understand this, but doesn't look like a major issue from bala>your phrasing. Recommend the development of applicability statements to cover this (otherwise, it is difficult to understand how the different pieces join together to form a coherent picture). Ananth>6) Terminology is an issue (e.g., waveband switching, link) bala>BR: Any inconsistencies can be taken care of easily. Like your comment. Hope it is as easy as it sounds :-) Mapping of terminology between standards bodies and also between different drafts in the IETF can be painful. Agreed however, that this is not a show-stopper. Ananth>7) Transaction support for connection set-up and release is needed for Ananth>connection oriented networks (e.g. crankback capability). bala>BR: Internet drafts have already been written on crankback. I suggest bala>that you please consider writing some drafts if there is something bala>missing. Aware of the "iwata-draft". Are there others? Ananth>8) Reliable message transfer bala>BR: Very much a part of signaling. the OIF work has considered this bala>aspect also. 'soft-state' signaling protocols may not be acceptable for the optical control plane. Live channels must not be dropped as a result of signaling message delivery failures (e.g. timer refresh failures) Ananth>9) Security concerns have not been fully addressed, particularly at the Ananth> architectural level. The use of separate control network may Ananth>necessitate the need for 24 hour staff to protect against 'Denial of Ananth>Service' attacks as currently happens for IP router networks. In Ananth>general, admission control issues need to be addressed. bala>BR: Please elaborate on these, specifically, what's new in the bala>context of GMPLS. e.g. in the case of ATM UNI, if a user or users attempt too many call setups simultaneously the switch control processor can become overloaded. So, some form of call pacing/overload handling is needed. Is there something similar in the GMPLS context for optical devices? Ananth>10) The definition of transparency may be overly simplified. See Ananth>comments by Ben Mack-Crane: Ananth>I think the debate on transparency indicates that the issue is not as Ananth>clear Ananth>as we might think. The OIF document you cite defines forms of Ananth>transparency Ananth>that are very straightforward (flags 1,2) not the more complex forms in Ananth>the current GMPLS drafts (flags 3..10). Also, these are easily Ananth>provided in Ananth>O-E-O or O-O-O networks operating at the lambda level, but there is no Ananth>standard for providing these over TDM multiplexed SONET/SDH links. bala>BR: This is an ongoing topic of discussion. Doesn't break down bala>the rest of the proposal. Agreed. Ananth>If two vendors implement the same signaling but different TDM Ananth>multiplexing, that Ananth>doesn't achieve interoperability. Is there any way in the drafts to Ananth>determine the scope Ananth>of application of the various signaling elements (that is, whether they Ananth>apply to UNI or NNI, whether they apply to specific network Ananth>layers/technologies)? Ananth>11) One summary of additional items with issues includes: Ananth>- SDH/SONET transparency. Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation. Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities. Ananth>- All kinds of end-to-end protection/restoration for any layer, except Ananth>the IP layer. bala>BR: Restoration is not actually covered in the current set of drafts. bala>An earlier thread discussed this, and my suggestion is that this bala>feature be dealt with separately. Potential show-stopper for deployment if restoration is not covered. Would agree that it could be addressed separately, though. Ananth>- The label set object (only used for lambda issues). Ananth>- LSP encoding type, bandwidth encoding and GPID have to be simplified Ananth>accordingly. Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is not yet Ananth>defined). bala>BR: A draft is forthcoming on this. Have been made aware of this. Thanks. Ananth>12) Support for paths across SONET/SDH gateways bala>BR: Please clarify the issues/write drafts. Quoting from Siegfried Giebl's email regarding "If I understand this document correctly, then you are completely separating SONET and SDH signal types from each other, thus making it difficult to deal with paths across SONET/SDH gateways. As an alternative, I suggest you work only with entities of level STS-1 (STM-0) and higher. On the other hand why don't you go the full way and also add 64 kb/s channels ?" Ananth> 13) Compatibility is required/desired with legacy SDH/SONET equipment Ananth>[and also legacy DWDM] bala>BR: Same as above. NSAP issue identified above. Elements within a link may not communicate using the signaling, i.e., legacy SDH/SONET equipment that does not participate in signaling (participate only in connectivity) Thanks, Ananth --openmail-part-4167abb8-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 12:33:14 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Signal Type doubt in GMPLS Date: Tue, 12 Jun 2001 12:31:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, I have certain doubts regarding signal type field in sonet-sdh 00.txt draft. What does AUG-1/AUG-16 means ? STM-1 has 1 AUG and STM-N has N AUGs. When signal type is AUG-256, what does this exatly mean ? Also, for signal types STM-1, STM-4 etc. it is written in braces that "only when requesting transparency". What does this exactly mean ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 07:48:16 -0700 Cc: "'Diego Caviglia'" , "Bernstein, Greg" , Susumu Yoneda , Jimmy Gendron , "ccamp@ops.ietf.org" Message-ID: <3B262B34.CE0F698A@lucent.com> Date: Tue, 12 Jun 2001 16:46:12 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "v.sharma@ieee.org" Original-CC: "'Diego Caviglia'" , "Bernstein, Greg" , Susumu Yoneda , Jimmy Gendron , "ccamp@ops.ietf.org" Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------1FCC5DEAD6811498CA279252" This is a multi-part message in MIME format. --------------1FCC5DEAD6811498CA279252 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vishal, Comments inline. Regards, Maarten Vishal Sharma wrote: > > Diego, > > Comments inline. > > -Vishal > On Tuesday, June 12, 2001 2:51 AM, Diego Caviglia > [SMTP:Diego.Caviglia@marconi.com] wrote: > > > > > > Maaeten, > > > > In my understanding Greg's sentence (but of course the last > > word > > on the matter of his sentence is up to him) refers to the possibility > > of > > aggregating information from different layers in order to have less > > protocol > > instances than layers. > > > > If we consider all the possible layers inside the TN we have: > > > > 1. LOVC > > > > 2. HOVC > > > > 3. ODU1 > > > > 4. ODU2 > > > > 5. ODU3 > > > > 6. Lambda > > Exactly right. > > > Moreover we have to take into account for Lambda switching purpose the type > > of > > the fiber (I mean if the fiber is G.655, G.653, G.652 and maybe the vendor > > of > > the fiber) and for diversity routing purpose the duct layer. > > > > Do we need to aggregate information from these layers? If so how could > > we > > aggregate layers? > > Good question. I believe it is this aggregation that Greg was alluding to > in his email, but we'll wait to hear what he has to say. > > > Is OSPF/IS-IS with extension the right choice in this layered environment or > > do > > we have to move to another routing protocol? > > > > The routing protocol(s) have to cope with lots of constraints and with lots > > of > > problems that were not in the "flat" IP networks for which they were > > designed. > > Exactly the point! This is indeed what needs to be looked at carefully. > Of course, this does not mean abandoning the layered network approach > (Maarten would certainly think that will collapse the global transport network > :-)). Correct :-). It is all based on domain engineering principles. Proper decomposition will "reduce" the complexity of the item and support graceful operation. > But... it does mean a thorough examination of the available protocols, > in the light of what is needed, to see if they can be made to fit the bill, and > yet be made scalable, or if something new entirely might be needed. > > > e.g. can a LOVC request trigger a HOVC trail creation? Repeating the process > > it > > could be possible that a LOVC request triggers a Lambda trail that from > > an > > operator perspective, which I suppose is not desirable. > > Technically, in a layered network under a common control plane this could > certainly happen. However, when a request crosses the "layers" in a layered > network in this manner, I believe it would have to have some interaction with > the EMS/NMS or a policy engine somewhere that would need to determine > what kind of HOVC or lambda trail needs to be setup to accommodate this > (and possibly future) requests. Correct. Operators are indicating that topology of a layer network is changed based on policies, which are operator specific (operators will differentiate themselve here from other operators). At the moment this policy engine is located in the management plane (EMS/NMS/operators). > > > Maarten Vissers on 12/06/2001 10.18.38 > > > > > > > > > > > > > > > > > > > > > > > > > > > To: "Bernstein, Greg" > > > > cc: Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda > > , v.sharma@ieee.org, > > Jimmy Gendron , > > ccamp@ops.ietf.org > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > > > > > > > > > > Greg, > > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > > (b) understand the topology at each layer, to me this sounds like an > > > instance of a control plane at each layer. > > > However, it doesn't necessarily tell me whether I'd want to (or not) > > > integrate multiple layer information into a protocol and run fewer protocol > > > instances than network layers. > > > > I am not sure I understand the meaning of the last sentence... does it > > refer to: > > a common Signalling Communication Network (SCN) over which all > > signalling messages are transported for all layer networks? > > > > The ASON model under definition shows per switched layer network a > > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. > > Subnetworks may be nested, and the lowest level subnetwork is a Fabric. > > These SCs communicate with each other over the SCN. LOVC-SCs communicate > > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs > > communicate with other ODU1-SCs, etc to exchange link state/topology > > information (case of I-NNI), reachability information (case of E-NNI, > > UNI) and routing information (connection setup). This is at the moment > > also referred to as "intra-layer" information exchange. > > > > For the case we decide that a Network Engineering agent is included in > > an SC, we will get also "inter-layer" information exchange. E.g. > > HOVC-SCs may also communicate with LOVC-SCs to provide reachability > > information for ports (e.g. STS1 and VC4 access groups) within the LOVC > > layer network. For the case we decide that Network Engineering agents > > are not part of the SC (but in a separate "layer network topology > > controller" (LNTC)), "inter-layer" information exchange will be between > > an SC and a LNTC. This latter model has a preference at the moment, > > while the two processes (SC: routing, LNTC: network topology) have a > > different scope. > > > > Note - LNTC within one layer network have to communicate with each other > > also to build up an understanding of potential topology capabilities > > present in the layer network (or layer network partition the LNTC is > > responsible for). > > > > > > > > Separate of the above, the ASON recommendations will specify the signal > > flow over inter domain interfaces where > > - a customer interconnects with an operator > > - two operators interconnect > > - two vendors interconnect. > > > > Over these inter domain interfaces you have to comply to the signal > > (message) structure. For ASON networks this will be based on the layer > > network structure. Within one domain the same layer network structured > > approach may be used, or one may decide to create a "spaghetti mountain" > > in which the layer network structure is not adhered to. That's up to the > > individual vendor. > > > > Regards, > > > > Maarten > > > > > > > > > > "Bernstein, Greg" wrote: > > > > > > Hi Maarten, Diego, et. al. > > > what's interesting here is the question of what do we mean by "its own > > > instance of a control plane"? Obviously if we are setting up a LOVC (in > > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling > > > to > > > those switches that are LOVC capable. Other switches need not be involved. > > > If it turns out that the LOVC capable switches are not interconnected by a > > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > > > appropriate HOVC interconnecting the LOVC needs to be setup first. In > > > GMPLS > > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > > > switches before we set up the LOVC LSPs. > > > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > > (b) understand the topology at each layer, to me this sounds like an > > > instance of a control plane at each layer. > > > However, it doesn't necessarily tell me whether I'd want to (or not) > > > integrate multiple layer information into a protocol and run fewer protocol > > > instances than network layers. Well actually as Maarten wrote in a recent > > > ITU document that we would be primarily interested in those layers involved > > > in dynamic switching/multiplexing. Note that we've started to bring in > > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > > > (the WDM--SONET example I always give). > > > > > > With the signaling protocol things are really separated by who is involved > > > in the signaling transaction. In the routing case things are less clear, > > > i.e., who wants/needs to know information about other layers and what > > > burden > > > does this present to the NEs and scalability. Which layers can benefit by > > > integration... I'll be updating the Optical inter-domain route > > > requirements > > > draft soon (with others) and will be exploring some of these items in more > > > depth. > > > > > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > > > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > > > the SDH hierarchy). > > > > > > Greg B. > > > *********************************** > > > Dr. Greg M. Bernstein > > > Senior Scientist, Ciena Corporation > > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Monday, June 11, 2001 7:46 AM > > > To: Diego Caviglia > > > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: Re: GMPLS Sonet extensions > > > > > > Diego, > > > > > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > > > and OCh) will have its own (instance of) control plane. > > > > > > Each switched layer network runs a copy of the generic routing protocol; > > > it does so within the boundaries of the switched layer network. > > > > > > Within each switched layer network you will find UNI, E-NNI and I-NNI > > > interfaces due to partitioning of a switched layer network. Topology > > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > > > the other hand only provide reachability information. > > > > > > For the case an MPLS router is from a different organisation than the > > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > > > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > > > the interface will be an MPLS-I-NNI. > > > For the server layers within the MPLS router (e.g. HOVC and STM-N > > > section layers) the interface relation is to be determined independent > > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > > > as at the HOVC layer entwork only reachability information is available > > > in the MPLS router (HOVC-E-NNI). > > > > > > The MPLS router should not be concerned at all about the routing of the > > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > > > link between is needed between MPLS router A and MPLS router B, router A > > > needs to have knowledge of router B's address/name only to request a > > > VC-4-16c/STS-48c connection through the transport network. The switched > > > HOVC (transport) network will take care of the connection setup. > > > > > > And even if two diverse routed connections are required (e.g. to support > > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > > > needs to request only the creation of 2 VC-4-16c connections with the > > > constraint of being diversely routed. The switched HOVC network will be > > > able to provide these two connections diversely routed between A and B > > > routers. > > > > > > At the moment, I recognise two connection types in a layer network: > > > - native connections and > > > - client connections. > > > Example: within a HOVC layer network a STS1 or VC-4 connection is a > > > native connection, and a DS3 connection or a LOVC link is a client > > > connection. A client connection is supported by the HOVC layer network > > > after adapting it to the layer network signal type (i.e. STS1 (to > > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > > > can have a > > > - 1:1, > > > - 1:n, > > > - n:1 > > > relationship with the underlying layer network signal. > > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > > > relationship. > > > > > > With client connections, an I-NNI is almost per definition not possible > > > (you go outside the layer network). Nevertheless, some people consider > > > the special 1:1 case as an area where an I-NNI could be deployed; of > > > course not for the case of DS3 -> STS1, but for the case of > > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > > > HOVC layer network and a client signal to the OCh and ODU1 layer > > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > > > wavelenght it is easy to think to be within one and the same layer > > > network. Personally, I believe that such very special case looks much > > > brighter than it is in the long term. I.e. don't declare very special > > > cases to be the common ones; keep those as very special cases, best even > > > keep those as regular cases obeying to the generic rules. > > > > > > Client connections as such have UNI or E-NNI interface relationships > > > over which reachability information is offered at best. This is the case > > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > > > layer entwork) as well as "vertical client connections" (e.g. a LOVC > > > link over a HOVC/STS layer network). > > > > > > Regards, > > > > > > Maarten > > > > > > Diego Caviglia wrote: > > > > > > > > Maarten, > > > > I agree in principle with you but this means it would > > > be > > > > necessary to have a routing protocol for each layer doesn't it? > > > > > > > > One of the initial reasons for (G)MPLS is to unify the control > > > plane, your > > > > layered view of the network implies again the separation of the control > > > planes. > > > > > > > > The Transport Network is very different from a flat IP network and > > > layering in > > > > TN is implicit. > > > > > > > > If I understood your model correctly the MPLS Router only views, Access > > > Groups > > > > and links to other MPLS Routers. If there are free resources between > > > the two > > > > routers the TE process calculates, accordingly to some rules, the best > > > path. > > > > > > Agree. > > > > > > > If > > > > there are no resources a call to the Network Engineering agent is > > > performed, the > > > > NE makes a call to the TE of the SONET layer in order to provide a trail > > > to the > > > > MPLS layer (this procedure is repeated until available resources are > > > created for > > > > the MPLS router connection). This trail modifies the topology at the MPLS > > > layer. > > > > > > Agree. One note however, operators have indicated that they would like > > > to deploy policies in the NE agent which may include some thresholds, > > > before it decides to change the topology of the layer network. E.g. > > > topology is not extended unless X calls failed. On the other hand, the > > > NE agent may have scheduled topology changes; e.g. at the begin of busy > > > hour extra links are added or bandwidth of existing link is extended, > > > and at the end of busy hour the reverse is happening. > > > > > > > > > > > If my understanding is correct and we want to implement an automated TN > > > a sort > > > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > > > > > UNI or E-NNI. > > > > > > > > > > > Maybe this will create some problems, on the other hand, as Maarten > > > pointed out, > > > > flat networks won't work due the huge amount of routing information > > > that they > > > > have to carry. > > > > > > > > Regards > > > > > > > > Diego > > > > > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > > > , ccamp@ops.ietf.org(bcc: > > > > Diego Caviglia/MAIN/MC1) > > > > > > > > > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > > > > Sharma, > > > > > > > > "flat" set up is the route to disaster... simply consider a switched > > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > > > would get information of all these levels... an absolute disaster in a > > > > world wide switched transport network would be the result. > > > > > > > > Therefore, there is this layering in which a server layer network > > > > provides bandwidth to its client layer entworks. the client layer > > > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > > > can route their signals. > > > > > > > > A separate entity (I called it "network engineering") is looking over > > > > the shoulder of the call setup process to see if more bandwidth is > > > > needed and when it would be needed or not longer required. But today, > > > > this separate entity is not part of the control plane; it is in the > > > > management plane. > > > > > > > > Regards, > > > > > > > > Maarten > > > > > > > > Susumu Yoneda wrote: > > > > > > > > > > Sharma, > > > > > > > > > > Thank you for letting me know your presentation material which looks > > > very > > > > > interesting. It seems to me that a layered setup would make a sense. > > > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > > > would not be seen by users? > > > > > > > > > > -----Original Message----- > > > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > > > Sent: Saturday, June 09, 2001 11:06 AM > > > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > > > Subject: RE: GMPLS Sonet extensions > > > > > > > > > > Jimmy, Susumu, > > > > > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > > > have the same view of the network, you could compute an ERO at the > > > > > ingress router and have the PATH message follow the hop-by-hop route > > > > > to the egress router. > > > > > (Note, however, that the PATH message will travel > > > > > on the out-of-band IP control network; therefore, it would be > > > non-associated > > > > > signaling.) > > > > > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > > > in fact, have to be shared by all nodes, since that is precisely what > > > > > the "peer model" implies. > > > > > > > > > > But you do have to be careful about what "LSP" you are requesting, > > > > > since > > > the > > > > > characteristics of the requested LSP are not interpreted in the same > > > > > way > > > by > > > > > the > > > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > > > different > > > > > way of defining a circuit than an IP router or an OXC.) > > > > > Therefore, one possibility would be to do a "layered setup", where an > > > LSP > > > > > at the lower layer is setup before the PATH message at the higher layer > > > > > is tunnelled over it or allowed to propagate further. > > > > > > > > > > For example, when the PATH message for the packet > > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > > > a corresponding SONET circuit between themselves, and then either > > > > > tunnel > > > > > the PATH message for the packet LSP over this circuit, or (assuming > > > > > your > > > > > out-of-band network), at that time, allow the PATH message for the > > > packet > > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > > > channel, likewise, would be a recursive process, with the OXC first > > > setting > > > > > up an optical lightpath between themselves, and tunneling the request > > > > > to > > > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > > > > > A more detailed discussion of this subject, with corresponding > > > animations > > > > > and figures, that you may also find helpful is available in a talk I > > > gave at > > > > > MPLSCon'01, and can be found at: > > > > > http://www.mplscon.com/missing_presentations.htm > > > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > > > > > -Vishal > > > > > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > > > [SMTP:yone@japan-telecom.co.jp] > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I also assume that there would be an out-of-band signalling network > > > based > > > > > on > > > > > > a suite of GMPLS protocols including LMP. I think there will be > > > > > > issues > > > to > > > > > > address whether all messages will be shared by all nodes, i.e router, > > > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > > > ------------------------------- > > > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > > > Japan Telecom fax +81 3 5540 8485 > > > > > > Information & Communication Labs. > > > > > > e-mail yone@japan-telecom.co.jp > > > > > > ------------------------------- > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf > > > > > Of > > > > > > Jimmy Gendron > > > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > > > To: 'ccamp@ops.ietf.org' > > > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > > understand > > > > > > most of the architecture, but I still have a question since the > > > beginning; > > > > > > as an unified control plane, how do the routing/signaling protocols > > > > > exchange > > > > > > informations on a configuration like this: > > > > > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > > > (Ingress) > > > > > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > > > understand > > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > > > the > > > > > two > > > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > > > (Assuming > > > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > > > > > My guess is that the PATH message will leave the ingress router with > > > > > > a > > > > > PATH > > > > > > message with a calculated ERO. It assumes that the network is in > > > respect > > > > > > with the peer model...everyone have the same routing table and know > > > the > > > > > > actual network topology. So, my PATH message will follow the CSPF > > > (ERO) > > > > > and > > > > > > go to the egress router. Am I right? > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Jimmy Gendron > > > > > > > > << File: mvissers.vcf >> --------------1FCC5DEAD6811498CA279252 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 --------------1FCC5DEAD6811498CA279252-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 05:56:07 -0700 Cc: "Bernstein, Greg" , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <3B261119.18BEFDDE@lucent.com> Date: Tue, 12 Jun 2001 14:54:49 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Diego Caviglia Original-CC: "Bernstein, Greg" , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------659DBFFCE48B83F81DD81695" This is a multi-part message in MIME format. --------------659DBFFCE48B83F81DD81695 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diego, If we assume that e.g. LOVC-SCs communicate with other LOVC-SCs and that HOVC-SCs communicate with other HOVC-SCs, then it seems not possible to me (might be wrong) to aggregate LOVC information exchanged between LOVC-SCs with HOVC information exchanged between HOVC-SCs in one and the same message. Aggregation can be realised in this case by multiplexing both information flows onto the same SCN only. The SCN is a data network in which LOVC-SCs, HOVC-SCs, ODU1-SCs, etc are endpoints. If this network is build up with e.g. MPLS connections we may multiplex LOVC information flows with HOVC information flows over the same MPLS connection (e.g. between A and B) if e.g. LOVC-SC and HOVC-SC within network element A need to communicate with LOVC-SC and HOVC-SC in network element B. But logically, there are a LOVC-SC-A to LOVC-SC-B MPLS connection, a HOVC-SC-A to HOVC-SC-B MPLS connection and an NE-A to NE-B MPLS aggregate connection. Regards, Maarten Diego Caviglia wrote: > > Maaeten, > > In my understanding Greg's sentence (but of course the last word > on the matter of his sentence is up to him) refers to the possibility of > aggregating information from different layers in order to have less protocol > instances than layers. > > If we consider all the possible layers inside the TN we have: > > 1. LOVC > > 2. HOVC > > 3. ODU1 > > 4. ODU2 > > 5. ODU3 > > 6. Lambda I prefer to refer to the latter one as "OCh" (optical channel). A "Lambda" is a representation of a tributary (i.e. frequency) slot in an aggregate signal. Thus a Lambda is not a signal. "Lambda switching" is as such also impossible; instead the "optical channel signal" (transported over a "lambda") is switched from a lambda in the incoming aggregate signal to a lambda in the outgoing aggregate signal (or to a single channel outgoing signal without lambda). > > Moreover we have to take into account for Lambda switching purpose the type of > the fiber (I mean if the fiber is G.655, G.653, G.652 and maybe the vendor of > the fiber) and for diversity routing purpose the duct layer. > > Do we need to aggregate information from these layers? If so how could we > aggregate layers? > > Is OSPF/IS-IS with extension the right choice in this layered environment or do > we have to move to another routing protocol? > > The routing protocol(s) have to cope with lots of constraints and with lots of > problems that were not in the "flat" IP networks for which they were designed. > e.g. can a LOVC request trigger a HOVC trail creation? Repeating the process it > could be possible that a LOVC request triggers a Lambda trail that from an > operator perspective, which I suppose is not desirable. Correct. My example is a DS1 (1.5M) connection request creating a 40G ODU3 trail; see ftp://ftp.t1.org/T1X1/X1.5/1x151260.doc Regards, Maarten > > Best regards. > > Diego > > Maarten Vissers on 12/06/2001 10.18.38 > > > > > > > > To: "Bernstein, Greg" > > cc: Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda > , v.sharma@ieee.org, > Jimmy Gendron , > ccamp@ops.ietf.org > > > > Subject: Re: GMPLS Sonet extensions > > > Greg, > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer protocol > > instances than network layers. > > I am not sure I understand the meaning of the last sentence... does it > refer to: > a common Signalling Communication Network (SCN) over which all > signalling messages are transported for all layer networks? > > The ASON model under definition shows per switched layer network a > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. > Subnetworks may be nested, and the lowest level subnetwork is a Fabric. > These SCs communicate with each other over the SCN. LOVC-SCs communicate > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs > communicate with other ODU1-SCs, etc to exchange link state/topology > information (case of I-NNI), reachability information (case of E-NNI, > UNI) and routing information (connection setup). This is at the moment > also referred to as "intra-layer" information exchange. > > For the case we decide that a Network Engineering agent is included in > an SC, we will get also "inter-layer" information exchange. E.g. > HOVC-SCs may also communicate with LOVC-SCs to provide reachability > information for ports (e.g. STS1 and VC4 access groups) within the LOVC > layer network. For the case we decide that Network Engineering agents > are not part of the SC (but in a separate "layer network topology > controller" (LNTC)), "inter-layer" information exchange will be between > an SC and a LNTC. This latter model has a preference at the moment, > while the two processes (SC: routing, LNTC: network topology) have a > different scope. > > Note - LNTC within one layer network have to communicate with each other > also to build up an understanding of potential topology capabilities > present in the layer network (or layer network partition the LNTC is > responsible for). > > Separate of the above, the ASON recommendations will specify the signal > flow over inter domain interfaces where > - a customer interconnects with an operator > - two operators interconnect > - two vendors interconnect. > > Over these inter domain interfaces you have to comply to the signal > (message) structure. For ASON networks this will be based on the layer > network structure. Within one domain the same layer network structured > approach may be used, or one may decide to create a "spaghetti mountain" > in which the layer network structure is not adhered to. That's up to the > individual vendor. > > Regards, > > Maarten > > "Bernstein, Greg" wrote: > > > > Hi Maarten, Diego, et. al. > > what's interesting here is the question of what do we mean by "its own > > instance of a control plane"? Obviously if we are setting up a LOVC (in > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to > > those switches that are LOVC capable. Other switches need not be involved. > > If it turns out that the LOVC capable switches are not interconnected by a > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > > appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > > switches before we set up the LOVC LSPs. > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer protocol > > instances than network layers. Well actually as Maarten wrote in a recent > > ITU document that we would be primarily interested in those layers involved > > in dynamic switching/multiplexing. Note that we've started to bring in > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > > (the WDM--SONET example I always give). > > > > With the signaling protocol things are really separated by who is involved > > in the signaling transaction. In the routing case things are less clear, > > i.e., who wants/needs to know information about other layers and what burden > > does this present to the NEs and scalability. Which layers can benefit by > > integration... I'll be updating the Optical inter-domain route requirements > > draft soon (with others) and will be exploring some of these items in more > > depth. > > > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > > the SDH hierarchy). > > > > Greg B. > > *********************************** > > Dr. Greg M. Bernstein > > Senior Scientist, Ciena Corporation > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, June 11, 2001 7:46 AM > > To: Diego Caviglia > > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: Re: GMPLS Sonet extensions > > > > Diego, > > > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > > and OCh) will have its own (instance of) control plane. > > > > Each switched layer network runs a copy of the generic routing protocol; > > it does so within the boundaries of the switched layer network. > > > > Within each switched layer network you will find UNI, E-NNI and I-NNI > > interfaces due to partitioning of a switched layer network. Topology > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > > the other hand only provide reachability information. > > > > For the case an MPLS router is from a different organisation than the > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > > the interface will be an MPLS-I-NNI. > > For the server layers within the MPLS router (e.g. HOVC and STM-N > > section layers) the interface relation is to be determined independent > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > > as at the HOVC layer entwork only reachability information is available > > in the MPLS router (HOVC-E-NNI). > > > > The MPLS router should not be concerned at all about the routing of the > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > > link between is needed between MPLS router A and MPLS router B, router A > > needs to have knowledge of router B's address/name only to request a > > VC-4-16c/STS-48c connection through the transport network. The switched > > HOVC (transport) network will take care of the connection setup. > > > > And even if two diverse routed connections are required (e.g. to support > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > > needs to request only the creation of 2 VC-4-16c connections with the > > constraint of being diversely routed. The switched HOVC network will be > > able to provide these two connections diversely routed between A and B > > routers. > > > > At the moment, I recognise two connection types in a layer network: > > - native connections and > > - client connections. > > Example: within a HOVC layer network a STS1 or VC-4 connection is a > > native connection, and a DS3 connection or a LOVC link is a client > > connection. A client connection is supported by the HOVC layer network > > after adapting it to the layer network signal type (i.e. STS1 (to > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > > can have a > > - 1:1, > > - 1:n, > > - n:1 > > relationship with the underlying layer network signal. > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > > relationship. > > > > With client connections, an I-NNI is almost per definition not possible > > (you go outside the layer network). Nevertheless, some people consider > > the special 1:1 case as an area where an I-NNI could be deployed; of > > course not for the case of DS3 -> STS1, but for the case of > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > > HOVC layer network and a client signal to the OCh and ODU1 layer > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > > wavelenght it is easy to think to be within one and the same layer > > network. Personally, I believe that such very special case looks much > > brighter than it is in the long term. I.e. don't declare very special > > cases to be the common ones; keep those as very special cases, best even > > keep those as regular cases obeying to the generic rules. > > > > Client connections as such have UNI or E-NNI interface relationships > > over which reachability information is offered at best. This is the case > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > > layer entwork) as well as "vertical client connections" (e.g. a LOVC > > link over a HOVC/STS layer network). > > > > Regards, > > > > Maarten > > > > Diego Caviglia wrote: > > > > > > Maarten, > > > I agree in principle with you but this means it would > > be > > > necessary to have a routing protocol for each layer doesn't it? > > > > > > One of the initial reasons for (G)MPLS is to unify the control > > plane, your > > > layered view of the network implies again the separation of the control > > planes. > > > > > > The Transport Network is very different from a flat IP network and > > layering in > > > TN is implicit. > > > > > > If I understood your model correctly the MPLS Router only views, Access > > Groups > > > and links to other MPLS Routers. If there are free resources between > > the two > > > routers the TE process calculates, accordingly to some rules, the best > > path. > > > > Agree. > > > > > If > > > there are no resources a call to the Network Engineering agent is > > performed, the > > > NE makes a call to the TE of the SONET layer in order to provide a trail > > to the > > > MPLS layer (this procedure is repeated until available resources are > > created for > > > the MPLS router connection). This trail modifies the topology at the MPLS > > layer. > > > > Agree. One note however, operators have indicated that they would like > > to deploy policies in the NE agent which may include some thresholds, > > before it decides to change the topology of the layer network. E.g. > > topology is not extended unless X calls failed. On the other hand, the > > NE agent may have scheduled topology changes; e.g. at the begin of busy > > hour extra links are added or bandwidth of existing link is extended, > > and at the end of busy hour the reverse is happening. > > > > > > > > If my understanding is correct and we want to implement an automated TN > > a sort > > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > > > UNI or E-NNI. > > > > > > > > Maybe this will create some problems, on the other hand, as Maarten > > pointed out, > > > flat networks won't work due the huge amount of routing information > > that they > > > have to carry. > > > > > > Regards > > > > > > Diego > > > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > > , ccamp@ops.ietf.org(bcc: > > > Diego Caviglia/MAIN/MC1) > > > > > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > Sharma, > > > > > > "flat" set up is the route to disaster... simply consider a switched > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > > would get information of all these levels... an absolute disaster in a > > > world wide switched transport network would be the result. > > > > > > Therefore, there is this layering in which a server layer network > > > provides bandwidth to its client layer entworks. the client layer > > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > > can route their signals. > > > > > > A separate entity (I called it "network engineering") is looking over > > > the shoulder of the call setup process to see if more bandwidth is > > > needed and when it would be needed or not longer required. But today, > > > this separate entity is not part of the control plane; it is in the > > > management plane. > > > > > > Regards, > > > > > > Maarten > > > > > > Susumu Yoneda wrote: > > > > > > > > Sharma, > > > > > > > > Thank you for letting me know your presentation material which looks > > very > > > > interesting. It seems to me that a layered setup would make a sense. > > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > > would not be seen by users? > > > > > > > > -----Original Message----- > > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > > Sent: Saturday, June 09, 2001 11:06 AM > > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > > Subject: RE: GMPLS Sonet extensions > > > > > > > > Jimmy, Susumu, > > > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > > have the same view of the network, you could compute an ERO at the > > > > ingress router and have the PATH message follow the hop-by-hop route > > > > to the egress router. > > > > (Note, however, that the PATH message will travel > > > > on the out-of-band IP control network; therefore, it would be > > non-associated > > > > signaling.) > > > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > > in fact, have to be shared by all nodes, since that is precisely what > > > > the "peer model" implies. > > > > > > > > But you do have to be careful about what "LSP" you are requesting, since > > the > > > > characteristics of the requested LSP are not interpreted in the same way > > by > > > > the > > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > > different > > > > way of defining a circuit than an IP router or an OXC.) > > > > Therefore, one possibility would be to do a "layered setup", where an > > LSP > > > > at the lower layer is setup before the PATH message at the higher layer > > > > is tunnelled over it or allowed to propagate further. > > > > > > > > For example, when the PATH message for the packet > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > > a corresponding SONET circuit between themselves, and then either tunnel > > > > the PATH message for the packet LSP over this circuit, or (assuming your > > > > out-of-band network), at that time, allow the PATH message for the > > packet > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > > channel, likewise, would be a recursive process, with the OXC first > > setting > > > > up an optical lightpath between themselves, and tunneling the request to > > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > > > A more detailed discussion of this subject, with corresponding > > animations > > > > and figures, that you may also find helpful is available in a talk I > > gave at > > > > MPLSCon'01, and can be found at: > > > > http://www.mplscon.com/missing_presentations.htm > > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > > > -Vishal > > > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > > [SMTP:yone@japan-telecom.co.jp] > > > > wrote: > > > > > Hi, > > > > > > > > > > I also assume that there would be an out-of-band signalling network > > based > > > > on > > > > > a suite of GMPLS protocols including LMP. I think there will be issues > > to > > > > > address whether all messages will be shared by all nodes, i.e router, > > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > > ------------------------------- > > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > > Japan Telecom fax +81 3 5540 8485 > > > > > Information & Communication Labs. > > > > > e-mail yone@japan-telecom.co.jp > > > > > ------------------------------- > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf > > > > Of > > > > > Jimmy Gendron > > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > > To: 'ccamp@ops.ietf.org' > > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > understand > > > > > most of the architecture, but I still have a question since the > > beginning; > > > > > as an unified control plane, how do the routing/signaling protocols > > > > exchange > > > > > informations on a configuration like this: > > > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > > (Ingress) > > > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > > understand > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > > the > > > > two > > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > > (Assuming > > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > > > My guess is that the PATH message will leave the ingress router with a > > > > PATH > > > > > message with a calculated ERO. It assumes that the network is in > > respect > > > > > with the peer model...everyone have the same routing table and know > > the > > > > > actual network topology. So, my PATH message will follow the CSPF > > (ERO) > > > > and > > > > > go to the egress router. Am I right? > > > > > > > > > > Best regards, > > > > > > > > > > Jimmy Gendron > > > > > --------------659DBFFCE48B83F81DD81695 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 --------------659DBFFCE48B83F81DD81695-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 03:51:39 -0700 Message-ID: <01C0F2F3.2871DF60.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'Diego Caviglia'" , Maarten Vissers Cc: "Bernstein, Greg" , Susumu Yoneda , "v.sharma@ieee.org" , Jimmy Gendron , "ccamp@ops.ietf.org" Subject: RE: GMPLS Sonet extensions Date: Tue, 12 Jun 2001 03:52:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Diego, Comments inline. -Vishal On Tuesday, June 12, 2001 2:51 AM, Diego Caviglia [SMTP:Diego.Caviglia@marconi.com] wrote: > > > Maaeten, > > In my understanding Greg's sentence (but of course the last > word > on the matter of his sentence is up to him) refers to the possibility > of > aggregating information from different layers in order to have less > protocol > instances than layers. > > If we consider all the possible layers inside the TN we have: > > 1. LOVC > > 2. HOVC > > 3. ODU1 > > 4. ODU2 > > 5. ODU3 > > 6. Lambda Exactly right. > Moreover we have to take into account for Lambda switching purpose the type > of > the fiber (I mean if the fiber is G.655, G.653, G.652 and maybe the vendor > of > the fiber) and for diversity routing purpose the duct layer. > > Do we need to aggregate information from these layers? If so how could > we > aggregate layers? Good question. I believe it is this aggregation that Greg was alluding to in his email, but we'll wait to hear what he has to say. > Is OSPF/IS-IS with extension the right choice in this layered environment or > do > we have to move to another routing protocol? > > The routing protocol(s) have to cope with lots of constraints and with lots > of > problems that were not in the "flat" IP networks for which they were > designed. Exactly the point! This is indeed what needs to be looked at carefully. Of course, this does not mean abandoning the layered network approach (Maarten would certainly think that will collapse the global transport network :-)). But... it does mean a thorough examination of the available protocols, in the light of what is needed, to see if they can be made to fit the bill, and yet be made scalable, or if something new entirely might be needed. > e.g. can a LOVC request trigger a HOVC trail creation? Repeating the process > it > could be possible that a LOVC request triggers a Lambda trail that from > an > operator perspective, which I suppose is not desirable. Technically, in a layered network under a common control plane this could certainly happen. However, when a request crosses the "layers" in a layered network in this manner, I believe it would have to have some interaction with the EMS/NMS or a policy engine somewhere that would need to determine what kind of HOVC or lambda trail needs to be setup to accommodate this (and possibly future) requests. > Maarten Vissers on 12/06/2001 10.18.38 > > > > > > > > > > > > To: "Bernstein, Greg" > > cc: Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda > , v.sharma@ieee.org, > Jimmy Gendron , > ccamp@ops.ietf.org > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > Greg, > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer protocol > > instances than network layers. > > I am not sure I understand the meaning of the last sentence... does it > refer to: > a common Signalling Communication Network (SCN) over which all > signalling messages are transported for all layer networks? > > The ASON model under definition shows per switched layer network a > hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. > Subnetworks may be nested, and the lowest level subnetwork is a Fabric. > These SCs communicate with each other over the SCN. LOVC-SCs communicate > with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs > communicate with other ODU1-SCs, etc to exchange link state/topology > information (case of I-NNI), reachability information (case of E-NNI, > UNI) and routing information (connection setup). This is at the moment > also referred to as "intra-layer" information exchange. > > For the case we decide that a Network Engineering agent is included in > an SC, we will get also "inter-layer" information exchange. E.g. > HOVC-SCs may also communicate with LOVC-SCs to provide reachability > information for ports (e.g. STS1 and VC4 access groups) within the LOVC > layer network. For the case we decide that Network Engineering agents > are not part of the SC (but in a separate "layer network topology > controller" (LNTC)), "inter-layer" information exchange will be between > an SC and a LNTC. This latter model has a preference at the moment, > while the two processes (SC: routing, LNTC: network topology) have a > different scope. > > Note - LNTC within one layer network have to communicate with each other > also to build up an understanding of potential topology capabilities > present in the layer network (or layer network partition the LNTC is > responsible for). > > > > Separate of the above, the ASON recommendations will specify the signal > flow over inter domain interfaces where > - a customer interconnects with an operator > - two operators interconnect > - two vendors interconnect. > > Over these inter domain interfaces you have to comply to the signal > (message) structure. For ASON networks this will be based on the layer > network structure. Within one domain the same layer network structured > approach may be used, or one may decide to create a "spaghetti mountain" > in which the layer network structure is not adhered to. That's up to the > individual vendor. > > Regards, > > Maarten > > > > > "Bernstein, Greg" wrote: > > > > Hi Maarten, Diego, et. al. > > what's interesting here is the question of what do we mean by "its own > > instance of a control plane"? Obviously if we are setting up a LOVC (in > > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling > > to > > those switches that are LOVC capable. Other switches need not be involved. > > If it turns out that the LOVC capable switches are not interconnected by a > > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > > appropriate HOVC interconnecting the LOVC needs to be setup first. In > > GMPLS > > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > > switches before we set up the LOVC LSPs. > > > > Since we have to (a) be able to set up connects at the appropriate layers, > > (b) understand the topology at each layer, to me this sounds like an > > instance of a control plane at each layer. > > However, it doesn't necessarily tell me whether I'd want to (or not) > > integrate multiple layer information into a protocol and run fewer protocol > > instances than network layers. Well actually as Maarten wrote in a recent > > ITU document that we would be primarily interested in those layers involved > > in dynamic switching/multiplexing. Note that we've started to bring in > > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > > (the WDM--SONET example I always give). > > > > With the signaling protocol things are really separated by who is involved > > in the signaling transaction. In the routing case things are less clear, > > i.e., who wants/needs to know information about other layers and what > > burden > > does this present to the NEs and scalability. Which layers can benefit by > > integration... I'll be updating the Optical inter-domain route > > requirements > > draft soon (with others) and will be exploring some of these items in more > > depth. > > > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > > the SDH hierarchy). > > > > Greg B. > > *********************************** > > Dr. Greg M. Bernstein > > Senior Scientist, Ciena Corporation > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, June 11, 2001 7:46 AM > > To: Diego Caviglia > > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: Re: GMPLS Sonet extensions > > > > Diego, > > > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > > and OCh) will have its own (instance of) control plane. > > > > Each switched layer network runs a copy of the generic routing protocol; > > it does so within the boundaries of the switched layer network. > > > > Within each switched layer network you will find UNI, E-NNI and I-NNI > > interfaces due to partitioning of a switched layer network. Topology > > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > > the other hand only provide reachability information. > > > > For the case an MPLS router is from a different organisation than the > > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > > the interface will be an MPLS-I-NNI. > > For the server layers within the MPLS router (e.g. HOVC and STM-N > > section layers) the interface relation is to be determined independent > > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > > as at the HOVC layer entwork only reachability information is available > > in the MPLS router (HOVC-E-NNI). > > > > The MPLS router should not be concerned at all about the routing of the > > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > > link between is needed between MPLS router A and MPLS router B, router A > > needs to have knowledge of router B's address/name only to request a > > VC-4-16c/STS-48c connection through the transport network. The switched > > HOVC (transport) network will take care of the connection setup. > > > > And even if two diverse routed connections are required (e.g. to support > > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > > needs to request only the creation of 2 VC-4-16c connections with the > > constraint of being diversely routed. The switched HOVC network will be > > able to provide these two connections diversely routed between A and B > > routers. > > > > At the moment, I recognise two connection types in a layer network: > > - native connections and > > - client connections. > > Example: within a HOVC layer network a STS1 or VC-4 connection is a > > native connection, and a DS3 connection or a LOVC link is a client > > connection. A client connection is supported by the HOVC layer network > > after adapting it to the layer network signal type (i.e. STS1 (to > > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > > can have a > > - 1:1, > > - 1:n, > > - n:1 > > relationship with the underlying layer network signal. > > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > > relationship. > > > > With client connections, an I-NNI is almost per definition not possible > > (you go outside the layer network). Nevertheless, some people consider > > the special 1:1 case as an area where an I-NNI could be deployed; of > > course not for the case of DS3 -> STS1, but for the case of > > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > > HOVC layer network and a client signal to the OCh and ODU1 layer > > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > > wavelenght it is easy to think to be within one and the same layer > > network. Personally, I believe that such very special case looks much > > brighter than it is in the long term. I.e. don't declare very special > > cases to be the common ones; keep those as very special cases, best even > > keep those as regular cases obeying to the generic rules. > > > > Client connections as such have UNI or E-NNI interface relationships > > over which reachability information is offered at best. This is the case > > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > > layer entwork) as well as "vertical client connections" (e.g. a LOVC > > link over a HOVC/STS layer network). > > > > Regards, > > > > Maarten > > > > Diego Caviglia wrote: > > > > > > Maarten, > > > I agree in principle with you but this means it would > > be > > > necessary to have a routing protocol for each layer doesn't it? > > > > > > One of the initial reasons for (G)MPLS is to unify the control > > plane, your > > > layered view of the network implies again the separation of the control > > planes. > > > > > > The Transport Network is very different from a flat IP network and > > layering in > > > TN is implicit. > > > > > > If I understood your model correctly the MPLS Router only views, Access > > Groups > > > and links to other MPLS Routers. If there are free resources between > > the two > > > routers the TE process calculates, accordingly to some rules, the best > > path. > > > > Agree. > > > > > If > > > there are no resources a call to the Network Engineering agent is > > performed, the > > > NE makes a call to the TE of the SONET layer in order to provide a trail > > to the > > > MPLS layer (this procedure is repeated until available resources are > > created for > > > the MPLS router connection). This trail modifies the topology at the MPLS > > layer. > > > > Agree. One note however, operators have indicated that they would like > > to deploy policies in the NE agent which may include some thresholds, > > before it decides to change the topology of the layer network. E.g. > > topology is not extended unless X calls failed. On the other hand, the > > NE agent may have scheduled topology changes; e.g. at the begin of busy > > hour extra links are added or bandwidth of existing link is extended, > > and at the end of busy hour the reverse is happening. > > > > > > > > If my understanding is correct and we want to implement an automated TN > > a sort > > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > > > UNI or E-NNI. > > > > > > > > Maybe this will create some problems, on the other hand, as Maarten > > pointed out, > > > flat networks won't work due the huge amount of routing information > > that they > > > have to carry. > > > > > > Regards > > > > > > Diego > > > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > > , ccamp@ops.ietf.org(bcc: > > > Diego Caviglia/MAIN/MC1) > > > > > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > > > > Sharma, > > > > > > "flat" set up is the route to disaster... simply consider a switched > > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > > would get information of all these levels... an absolute disaster in a > > > world wide switched transport network would be the result. > > > > > > Therefore, there is this layering in which a server layer network > > > provides bandwidth to its client layer entworks. the client layer > > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > > can route their signals. > > > > > > A separate entity (I called it "network engineering") is looking over > > > the shoulder of the call setup process to see if more bandwidth is > > > needed and when it would be needed or not longer required. But today, > > > this separate entity is not part of the control plane; it is in the > > > management plane. > > > > > > Regards, > > > > > > Maarten > > > > > > Susumu Yoneda wrote: > > > > > > > > Sharma, > > > > > > > > Thank you for letting me know your presentation material which looks > > very > > > > interesting. It seems to me that a layered setup would make a sense. > > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > > would not be seen by users? > > > > > > > > -----Original Message----- > > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > > Sent: Saturday, June 09, 2001 11:06 AM > > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > > Subject: RE: GMPLS Sonet extensions > > > > > > > > Jimmy, Susumu, > > > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > > have the same view of the network, you could compute an ERO at the > > > > ingress router and have the PATH message follow the hop-by-hop route > > > > to the egress router. > > > > (Note, however, that the PATH message will travel > > > > on the out-of-band IP control network; therefore, it would be > > non-associated > > > > signaling.) > > > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > > in fact, have to be shared by all nodes, since that is precisely what > > > > the "peer model" implies. > > > > > > > > But you do have to be careful about what "LSP" you are requesting, > > > > since > > the > > > > characteristics of the requested LSP are not interpreted in the same > > > > way > > by > > > > the > > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > > different > > > > way of defining a circuit than an IP router or an OXC.) > > > > Therefore, one possibility would be to do a "layered setup", where an > > LSP > > > > at the lower layer is setup before the PATH message at the higher layer > > > > is tunnelled over it or allowed to propagate further. > > > > > > > > For example, when the PATH message for the packet > > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > > a corresponding SONET circuit between themselves, and then either > > > > tunnel > > > > the PATH message for the packet LSP over this circuit, or (assuming > > > > your > > > > out-of-band network), at that time, allow the PATH message for the > > packet > > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > > channel, likewise, would be a recursive process, with the OXC first > > setting > > > > up an optical lightpath between themselves, and tunneling the request > > > > to > > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > > > A more detailed discussion of this subject, with corresponding > > animations > > > > and figures, that you may also find helpful is available in a talk I > > gave at > > > > MPLSCon'01, and can be found at: > > > > http://www.mplscon.com/missing_presentations.htm > > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > > > -Vishal > > > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > > [SMTP:yone@japan-telecom.co.jp] > > > > wrote: > > > > > Hi, > > > > > > > > > > I also assume that there would be an out-of-band signalling network > > based > > > > on > > > > > a suite of GMPLS protocols including LMP. I think there will be > > > > > issues > > to > > > > > address whether all messages will be shared by all nodes, i.e router, > > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > > ------------------------------- > > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > > Japan Telecom fax +81 3 5540 8485 > > > > > Information & Communication Labs. > > > > > e-mail yone@japan-telecom.co.jp > > > > > ------------------------------- > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf > > > > Of > > > > > Jimmy Gendron > > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > > To: 'ccamp@ops.ietf.org' > > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > understand > > > > > most of the architecture, but I still have a question since the > > beginning; > > > > > as an unified control plane, how do the routing/signaling protocols > > > > exchange > > > > > informations on a configuration like this: > > > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > > (Ingress) > > > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > > understand > > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > > the > > > > two > > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > > (Assuming > > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > > > My guess is that the PATH message will leave the ingress router with > > > > > a > > > > PATH > > > > > message with a calculated ERO. It assumes that the network is in > > respect > > > > > with the peer model...everyone have the same routing table and know > > the > > > > > actual network topology. So, my PATH message will follow the CSPF > > (ERO) > > > > and > > > > > go to the egress router. Am I right? > > > > > > > > > > Best regards, > > > > > > > > > > Jimmy Gendron > > > > > > << File: mvissers.vcf >> Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 03:19:24 -0700 From: "Diego Caviglia" To: Maarten Vissers cc: "Bernstein, Greg" , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <80256A69.003621B9.00@marconicomms.com> Date: Tue, 12 Jun 2001 11:51:14 +0200 Subject: Re: GMPLS Sonet extensions Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5" Content-Disposition: inline --0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Maaeten, In my understanding Greg's sentence (but of course the last word on the matter of his sentence is up to him) refers to the possibility of aggregating information from different layers in order to have less protocol instances than layers. If we consider all the possible layers inside the TN we have: 1. LOVC 2. HOVC 3. ODU1 4. ODU2 5. ODU3 6. Lambda Moreover we have to take into account for Lambda switching purpose the type of the fiber (I mean if the fiber is G.655, G.653, G.652 and maybe the vendor of the fiber) and for diversity routing purpose the duct layer. Do we need to aggregate information from these layers? If so how could we aggregate layers? Is OSPF/IS-IS with extension the right choice in this layered environment or do we have to move to another routing protocol? The routing protocol(s) have to cope with lots of constraints and with lots of problems that were not in the "flat" IP networks for which they were designed. e.g. can a LOVC request trigger a HOVC trail creation? Repeating the process it could be possible that a LOVC request triggers a Lambda trail that from an operator perspective, which I suppose is not desirable. Best regards. Diego Maarten Vissers on 12/06/2001 10.18.38 To: "Bernstein, Greg" cc: Diego Caviglia/MAIN/MC1@MCMAIN, Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Greg, > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. I am not sure I understand the meaning of the last sentence... does it refer to: a common Signalling Communication Network (SCN) over which all signalling messages are transported for all layer networks? The ASON model under definition shows per switched layer network a hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. Subnetworks may be nested, and the lowest level subnetwork is a Fabric. These SCs communicate with each other over the SCN. LOVC-SCs communicate with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs communicate with other ODU1-SCs, etc to exchange link state/topology information (case of I-NNI), reachability information (case of E-NNI, UNI) and routing information (connection setup). This is at the moment also referred to as "intra-layer" information exchange. For the case we decide that a Network Engineering agent is included in an SC, we will get also "inter-layer" information exchange. E.g. HOVC-SCs may also communicate with LOVC-SCs to provide reachability information for ports (e.g. STS1 and VC4 access groups) within the LOVC layer network. For the case we decide that Network Engineering agents are not part of the SC (but in a separate "layer network topology controller" (LNTC)), "inter-layer" information exchange will be between an SC and a LNTC. This latter model has a preference at the moment, while the two processes (SC: routing, LNTC: network topology) have a different scope. Note - LNTC within one layer network have to communicate with each other also to build up an understanding of potential topology capabilities present in the layer network (or layer network partition the LNTC is responsible for). Separate of the above, the ASON recommendations will specify the signal flow over inter domain interfaces where - a customer interconnects with an operator - two operators interconnect - two vendors interconnect. Over these inter domain interfaces you have to comply to the signal (message) structure. For ASON networks this will be based on the layer network structure. Within one domain the same layer network structured approach may be used, or one may decide to create a "spaghetti mountain" in which the layer network structure is not adhered to. That's up to the individual vendor. Regards, Maarten "Bernstein, Greg" wrote: > > Hi Maarten, Diego, et. al. > what's interesting here is the question of what do we mean by "its own > instance of a control plane"? Obviously if we are setting up a LOVC (in > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to > those switches that are LOVC capable. Other switches need not be involved. > If it turns out that the LOVC capable switches are not interconnected by a > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > switches before we set up the LOVC LSPs. > > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. Well actually as Maarten wrote in a recent > ITU document that we would be primarily interested in those layers involved > in dynamic switching/multiplexing. Note that we've started to bring in > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > (the WDM--SONET example I always give). > > With the signaling protocol things are really separated by who is involved > in the signaling transaction. In the routing case things are less clear, > i.e., who wants/needs to know information about other layers and what burden > does this present to the NEs and scalability. Which layers can benefit by > integration... I'll be updating the Optical inter-domain route requirements > draft soon (with others) and will be exploring some of these items in more > depth. > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > the SDH hierarchy). > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Scientist, Ciena Corporation > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, June 11, 2001 7:46 AM > To: Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Diego, > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > and OCh) will have its own (instance of) control plane. > > Each switched layer network runs a copy of the generic routing protocol; > it does so within the boundaries of the switched layer network. > > Within each switched layer network you will find UNI, E-NNI and I-NNI > interfaces due to partitioning of a switched layer network. Topology > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > the other hand only provide reachability information. > > For the case an MPLS router is from a different organisation than the > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > the interface will be an MPLS-I-NNI. > For the server layers within the MPLS router (e.g. HOVC and STM-N > section layers) the interface relation is to be determined independent > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > as at the HOVC layer entwork only reachability information is available > in the MPLS router (HOVC-E-NNI). > > The MPLS router should not be concerned at all about the routing of the > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > link between is needed between MPLS router A and MPLS router B, router A > needs to have knowledge of router B's address/name only to request a > VC-4-16c/STS-48c connection through the transport network. The switched > HOVC (transport) network will take care of the connection setup. > > And even if two diverse routed connections are required (e.g. to support > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > needs to request only the creation of 2 VC-4-16c connections with the > constraint of being diversely routed. The switched HOVC network will be > able to provide these two connections diversely routed between A and B > routers. > > At the moment, I recognise two connection types in a layer network: > - native connections and > - client connections. > Example: within a HOVC layer network a STS1 or VC-4 connection is a > native connection, and a DS3 connection or a LOVC link is a client > connection. A client connection is supported by the HOVC layer network > after adapting it to the layer network signal type (i.e. STS1 (to > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > can have a > - 1:1, > - 1:n, > - n:1 > relationship with the underlying layer network signal. > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > relationship. > > With client connections, an I-NNI is almost per definition not possible > (you go outside the layer network). Nevertheless, some people consider > the special 1:1 case as an area where an I-NNI could be deployed; of > course not for the case of DS3 -> STS1, but for the case of > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > HOVC layer network and a client signal to the OCh and ODU1 layer > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > wavelenght it is easy to think to be within one and the same layer > network. Personally, I believe that such very special case looks much > brighter than it is in the long term. I.e. don't declare very special > cases to be the common ones; keep those as very special cases, best even > keep those as regular cases obeying to the generic rules. > > Client connections as such have UNI or E-NNI interface relationships > over which reachability information is offered at best. This is the case > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > layer entwork) as well as "vertical client connections" (e.g. a LOVC > link over a HOVC/STS layer network). > > Regards, > > Maarten > > Diego Caviglia wrote: > > > > Maarten, > > I agree in principle with you but this means it would > be > > necessary to have a routing protocol for each layer doesn't it? > > > > One of the initial reasons for (G)MPLS is to unify the control > plane, your > > layered view of the network implies again the separation of the control > planes. > > > > The Transport Network is very different from a flat IP network and > layering in > > TN is implicit. > > > > If I understood your model correctly the MPLS Router only views, Access > Groups > > and links to other MPLS Routers. If there are free resources between > the two > > routers the TE process calculates, accordingly to some rules, the best > path. > > Agree. > > > If > > there are no resources a call to the Network Engineering agent is > performed, the > > NE makes a call to the TE of the SONET layer in order to provide a trail > to the > > MPLS layer (this procedure is repeated until available resources are > created for > > the MPLS router connection). This trail modifies the topology at the MPLS > layer. > > Agree. One note however, operators have indicated that they would like > to deploy policies in the NE agent which may include some thresholds, > before it decides to change the topology of the layer network. E.g. > topology is not extended unless X calls failed. On the other hand, the > NE agent may have scheduled topology changes; e.g. at the begin of busy > hour extra links are added or bandwidth of existing link is extended, > and at the end of busy hour the reverse is happening. > > > > > If my understanding is correct and we want to implement an automated TN > a sort > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > UNI or E-NNI. > > > > > Maybe this will create some problems, on the other hand, as Maarten > pointed out, > > flat networks won't work due the huge amount of routing information > that they > > have to carry. > > > > Regards > > > > Diego > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > , ccamp@ops.ietf.org(bcc: > > Diego Caviglia/MAIN/MC1) > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > Sharma, > > > > "flat" set up is the route to disaster... simply consider a switched > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > would get information of all these levels... an absolute disaster in a > > world wide switched transport network would be the result. > > > > Therefore, there is this layering in which a server layer network > > provides bandwidth to its client layer entworks. the client layer > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > can route their signals. > > > > A separate entity (I called it "network engineering") is looking over > > the shoulder of the call setup process to see if more bandwidth is > > needed and when it would be needed or not longer required. But today, > > this separate entity is not part of the control plane; it is in the > > management plane. > > > > Regards, > > > > Maarten > > > > Susumu Yoneda wrote: > > > > > > Sharma, > > > > > > Thank you for letting me know your presentation material which looks > very > > > interesting. It seems to me that a layered setup would make a sense. > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > would not be seen by users? > > > > > > -----Original Message----- > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > Sent: Saturday, June 09, 2001 11:06 AM > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: RE: GMPLS Sonet extensions > > > > > > Jimmy, Susumu, > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > have the same view of the network, you could compute an ERO at the > > > ingress router and have the PATH message follow the hop-by-hop route > > > to the egress router. > > > (Note, however, that the PATH message will travel > > > on the out-of-band IP control network; therefore, it would be > non-associated > > > signaling.) > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > in fact, have to be shared by all nodes, since that is precisely what > > > the "peer model" implies. > > > > > > But you do have to be careful about what "LSP" you are requesting, since > the > > > characteristics of the requested LSP are not interpreted in the same way > by > > > the > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > different > > > way of defining a circuit than an IP router or an OXC.) > > > Therefore, one possibility would be to do a "layered setup", where an > LSP > > > at the lower layer is setup before the PATH message at the higher layer > > > is tunnelled over it or allowed to propagate further. > > > > > > For example, when the PATH message for the packet > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > a corresponding SONET circuit between themselves, and then either tunnel > > > the PATH message for the packet LSP over this circuit, or (assuming your > > > out-of-band network), at that time, allow the PATH message for the > packet > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > channel, likewise, would be a recursive process, with the OXC first > setting > > > up an optical lightpath between themselves, and tunneling the request to > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > A more detailed discussion of this subject, with corresponding > animations > > > and figures, that you may also find helpful is available in a talk I > gave at > > > MPLSCon'01, and can be found at: > > > http://www.mplscon.com/missing_presentations.htm > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > -Vishal > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > [SMTP:yone@japan-telecom.co.jp] > > > wrote: > > > > Hi, > > > > > > > > I also assume that there would be an out-of-band signalling network > based > > > on > > > > a suite of GMPLS protocols including LMP. I think there will be issues > to > > > > address whether all messages will be shared by all nodes, i.e router, > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > ------------------------------- > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > Japan Telecom fax +81 3 5540 8485 > > > > Information & Communication Labs. > > > > e-mail yone@japan-telecom.co.jp > > > > ------------------------------- > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf > > > Of > > > > Jimmy Gendron > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > To: 'ccamp@ops.ietf.org' > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > Hi, > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > understand > > > > most of the architecture, but I still have a question since the > beginning; > > > > as an unified control plane, how do the routing/signaling protocols > > > exchange > > > > informations on a configuration like this: > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > (Ingress) > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > understand > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > the > > > two > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > (Assuming > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > My guess is that the PATH message will leave the ingress router with a > > > PATH > > > > message with a calculated ERO. It assumes that the network is in > respect > > > > with the peer model...everyone have the same routing table and know > the > > > > actual network topology. So, my PATH message will follow the CSPF > (ERO) > > > and > > > > go to the egress router. Am I right? > > > > > > > > Best regards, > > > > > > > > Jimmy Gendron > > > > --0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5 Content-type: application/octet-stream; name="mvissers.vcf" Content-Disposition: attachment; filename="mvissers.vcf" Content-transfer-encoding: base64 YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1 DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7 d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K --0__=yIcwcDoHuhk9JZD6ipZGkb6W40yIUQv0J9oo2GqtasvbACkD5uy4PxZ5-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 12 Jun 2001 01:21:41 -0700 Cc: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <3B25D05E.354B0F17@lucent.com> Date: Tue, 12 Jun 2001 10:18:38 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Bernstein, Greg" Original-CC: Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------0A9E3D8D94ED6A15EFAB5D30" This is a multi-part message in MIME format. --------------0A9E3D8D94ED6A15EFAB5D30 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg, > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. I am not sure I understand the meaning of the last sentence... does it refer to: a common Signalling Communication Network (SCN) over which all signalling messages are transported for all layer networks? The ASON model under definition shows per switched layer network a hierarchy of Subnetwork Controllers (SC) each controlling a subnetwork. Subnetworks may be nested, and the lowest level subnetwork is a Fabric. These SCs communicate with each other over the SCN. LOVC-SCs communicate with other LOVC-SCs, HOVC-SCs communicate with other HOVC-SCs, ODU1-SCs communicate with other ODU1-SCs, etc to exchange link state/topology information (case of I-NNI), reachability information (case of E-NNI, UNI) and routing information (connection setup). This is at the moment also referred to as "intra-layer" information exchange. For the case we decide that a Network Engineering agent is included in an SC, we will get also "inter-layer" information exchange. E.g. HOVC-SCs may also communicate with LOVC-SCs to provide reachability information for ports (e.g. STS1 and VC4 access groups) within the LOVC layer network. For the case we decide that Network Engineering agents are not part of the SC (but in a separate "layer network topology controller" (LNTC)), "inter-layer" information exchange will be between an SC and a LNTC. This latter model has a preference at the moment, while the two processes (SC: routing, LNTC: network topology) have a different scope. Note - LNTC within one layer network have to communicate with each other also to build up an understanding of potential topology capabilities present in the layer network (or layer network partition the LNTC is responsible for). Separate of the above, the ASON recommendations will specify the signal flow over inter domain interfaces where - a customer interconnects with an operator - two operators interconnect - two vendors interconnect. Over these inter domain interfaces you have to comply to the signal (message) structure. For ASON networks this will be based on the layer network structure. Within one domain the same layer network structured approach may be used, or one may decide to create a "spaghetti mountain" in which the layer network structure is not adhered to. That's up to the individual vendor. Regards, Maarten "Bernstein, Greg" wrote: > > Hi Maarten, Diego, et. al. > what's interesting here is the question of what do we mean by "its own > instance of a control plane"? Obviously if we are setting up a LOVC (in > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to > those switches that are LOVC capable. Other switches need not be involved. > If it turns out that the LOVC capable switches are not interconnected by a > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > switches before we set up the LOVC LSPs. > > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. Well actually as Maarten wrote in a recent > ITU document that we would be primarily interested in those layers involved > in dynamic switching/multiplexing. Note that we've started to bring in > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > (the WDM--SONET example I always give). > > With the signaling protocol things are really separated by who is involved > in the signaling transaction. In the routing case things are less clear, > i.e., who wants/needs to know information about other layers and what burden > does this present to the NEs and scalability. Which layers can benefit by > integration... I'll be updating the Optical inter-domain route requirements > draft soon (with others) and will be exploring some of these items in more > depth. > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > the SDH hierarchy). > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Scientist, Ciena Corporation > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, June 11, 2001 7:46 AM > To: Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Diego, > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > and OCh) will have its own (instance of) control plane. > > Each switched layer network runs a copy of the generic routing protocol; > it does so within the boundaries of the switched layer network. > > Within each switched layer network you will find UNI, E-NNI and I-NNI > interfaces due to partitioning of a switched layer network. Topology > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > the other hand only provide reachability information. > > For the case an MPLS router is from a different organisation than the > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > the interface will be an MPLS-I-NNI. > For the server layers within the MPLS router (e.g. HOVC and STM-N > section layers) the interface relation is to be determined independent > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > as at the HOVC layer entwork only reachability information is available > in the MPLS router (HOVC-E-NNI). > > The MPLS router should not be concerned at all about the routing of the > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > link between is needed between MPLS router A and MPLS router B, router A > needs to have knowledge of router B's address/name only to request a > VC-4-16c/STS-48c connection through the transport network. The switched > HOVC (transport) network will take care of the connection setup. > > And even if two diverse routed connections are required (e.g. to support > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > needs to request only the creation of 2 VC-4-16c connections with the > constraint of being diversely routed. The switched HOVC network will be > able to provide these two connections diversely routed between A and B > routers. > > At the moment, I recognise two connection types in a layer network: > - native connections and > - client connections. > Example: within a HOVC layer network a STS1 or VC-4 connection is a > native connection, and a DS3 connection or a LOVC link is a client > connection. A client connection is supported by the HOVC layer network > after adapting it to the layer network signal type (i.e. STS1 (to > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > can have a > - 1:1, > - 1:n, > - n:1 > relationship with the underlying layer network signal. > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > relationship. > > With client connections, an I-NNI is almost per definition not possible > (you go outside the layer network). Nevertheless, some people consider > the special 1:1 case as an area where an I-NNI could be deployed; of > course not for the case of DS3 -> STS1, but for the case of > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > HOVC layer network and a client signal to the OCh and ODU1 layer > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > wavelenght it is easy to think to be within one and the same layer > network. Personally, I believe that such very special case looks much > brighter than it is in the long term. I.e. don't declare very special > cases to be the common ones; keep those as very special cases, best even > keep those as regular cases obeying to the generic rules. > > Client connections as such have UNI or E-NNI interface relationships > over which reachability information is offered at best. This is the case > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > layer entwork) as well as "vertical client connections" (e.g. a LOVC > link over a HOVC/STS layer network). > > Regards, > > Maarten > > Diego Caviglia wrote: > > > > Maarten, > > I agree in principle with you but this means it would > be > > necessary to have a routing protocol for each layer doesn't it? > > > > One of the initial reasons for (G)MPLS is to unify the control > plane, your > > layered view of the network implies again the separation of the control > planes. > > > > The Transport Network is very different from a flat IP network and > layering in > > TN is implicit. > > > > If I understood your model correctly the MPLS Router only views, Access > Groups > > and links to other MPLS Routers. If there are free resources between > the two > > routers the TE process calculates, accordingly to some rules, the best > path. > > Agree. > > > If > > there are no resources a call to the Network Engineering agent is > performed, the > > NE makes a call to the TE of the SONET layer in order to provide a trail > to the > > MPLS layer (this procedure is repeated until available resources are > created for > > the MPLS router connection). This trail modifies the topology at the MPLS > layer. > > Agree. One note however, operators have indicated that they would like > to deploy policies in the NE agent which may include some thresholds, > before it decides to change the topology of the layer network. E.g. > topology is not extended unless X calls failed. On the other hand, the > NE agent may have scheduled topology changes; e.g. at the begin of busy > hour extra links are added or bandwidth of existing link is extended, > and at the end of busy hour the reverse is happening. > > > > > If my understanding is correct and we want to implement an automated TN > a sort > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > UNI or E-NNI. > > > > > Maybe this will create some problems, on the other hand, as Maarten > pointed out, > > flat networks won't work due the huge amount of routing information > that they > > have to carry. > > > > Regards > > > > Diego > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > , ccamp@ops.ietf.org(bcc: > > Diego Caviglia/MAIN/MC1) > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > Sharma, > > > > "flat" set up is the route to disaster... simply consider a switched > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > would get information of all these levels... an absolute disaster in a > > world wide switched transport network would be the result. > > > > Therefore, there is this layering in which a server layer network > > provides bandwidth to its client layer entworks. the client layer > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > can route their signals. > > > > A separate entity (I called it "network engineering") is looking over > > the shoulder of the call setup process to see if more bandwidth is > > needed and when it would be needed or not longer required. But today, > > this separate entity is not part of the control plane; it is in the > > management plane. > > > > Regards, > > > > Maarten > > > > Susumu Yoneda wrote: > > > > > > Sharma, > > > > > > Thank you for letting me know your presentation material which looks > very > > > interesting. It seems to me that a layered setup would make a sense. > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > would not be seen by users? > > > > > > -----Original Message----- > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > Sent: Saturday, June 09, 2001 11:06 AM > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: RE: GMPLS Sonet extensions > > > > > > Jimmy, Susumu, > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > have the same view of the network, you could compute an ERO at the > > > ingress router and have the PATH message follow the hop-by-hop route > > > to the egress router. > > > (Note, however, that the PATH message will travel > > > on the out-of-band IP control network; therefore, it would be > non-associated > > > signaling.) > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > in fact, have to be shared by all nodes, since that is precisely what > > > the "peer model" implies. > > > > > > But you do have to be careful about what "LSP" you are requesting, since > the > > > characteristics of the requested LSP are not interpreted in the same way > by > > > the > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > different > > > way of defining a circuit than an IP router or an OXC.) > > > Therefore, one possibility would be to do a "layered setup", where an > LSP > > > at the lower layer is setup before the PATH message at the higher layer > > > is tunnelled over it or allowed to propagate further. > > > > > > For example, when the PATH message for the packet > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > a corresponding SONET circuit between themselves, and then either tunnel > > > the PATH message for the packet LSP over this circuit, or (assuming your > > > out-of-band network), at that time, allow the PATH message for the > packet > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > channel, likewise, would be a recursive process, with the OXC first > setting > > > up an optical lightpath between themselves, and tunneling the request to > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > A more detailed discussion of this subject, with corresponding > animations > > > and figures, that you may also find helpful is available in a talk I > gave at > > > MPLSCon'01, and can be found at: > > > http://www.mplscon.com/missing_presentations.htm > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > -Vishal > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > [SMTP:yone@japan-telecom.co.jp] > > > wrote: > > > > Hi, > > > > > > > > I also assume that there would be an out-of-band signalling network > based > > > on > > > > a suite of GMPLS protocols including LMP. I think there will be issues > to > > > > address whether all messages will be shared by all nodes, i.e router, > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > ------------------------------- > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > Japan Telecom fax +81 3 5540 8485 > > > > Information & Communication Labs. > > > > e-mail yone@japan-telecom.co.jp > > > > ------------------------------- > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf > > > Of > > > > Jimmy Gendron > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > To: 'ccamp@ops.ietf.org' > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > Hi, > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > understand > > > > most of the architecture, but I still have a question since the > beginning; > > > > as an unified control plane, how do the routing/signaling protocols > > > exchange > > > > informations on a configuration like this: > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > (Ingress) > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > understand > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > the > > > two > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > (Assuming > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > My guess is that the PATH message will leave the ingress router with a > > > PATH > > > > message with a calculated ERO. It assumes that the network is in > respect > > > > with the peer model...everyone have the same routing table and know > the > > > > actual network topology. So, my PATH message will follow the CSPF > (ERO) > > > and > > > > go to the egress router. Am I right? > > > > > > > > Best regards, > > > > > > > > Jimmy Gendron > > > > --------------0A9E3D8D94ED6A15EFAB5D30 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 --------------0A9E3D8D94ED6A15EFAB5D30-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 15:38:36 -0700 From: "Raju Venkatraman" To: ccamp@ops.ietf.org Bcc: Subject: Fwd: GMPLS Questions, Doubts Date: Mon, 11 Jun 2001 22:36:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: >From: "Raju Venkatraman" >To: ccamp@ops.ietf.org >Subject: GMPLS Questions, Doubts >Date: Sat, 09 Jun 2001 21:09:39 -0000 > >Hi, > >I was just going through GMPLS drafts and I've some questions. Actually not >able to understand few things. Any help would be greatly appreciated. > >* Should the signalling module (control plane) be aware of all the data >channels/links under its control? In GMPLS, as it would be used in optical >networks and a no. of interfaces would be present [not all carrying the >signalling information] between GMPLS-enabled optical nodes, I don't feel >it's required. The association of signalling link/channel(s) to data >links/channels could be mainatained outside the sigannling module. > >* Where one would like to maintain the diffserv related intelligence while >setting up L-LSP and E-LSPs - would it would be assumed to be with routing >module or signalling module? > >I know, these things vary from implementation to implmentation, but just >wanted to hear your thoughts in this regard. > >Thanks in advance. >Raju > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 13:35:00 -0700 Message-ID: <01C0F27B.5A445220.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'Maarten Vissers'" , Susumu Yoneda , "'Diego Caviglia'" Cc: "v.sharma@ieee.org" , Jimmy Gendron , "ccamp@ops.ietf.org" Subject: RE: GMPLS Sonet extensions Date: Mon, 11 Jun 2001 13:35:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Maarten, Thanks for your note and clarification. Just to clarify, however, I was not proposing that route setup be done in a "flat" way. I was merely outlining how signaling could work in a multi-layer network. The issue of whether the network is "flat" or not is mainly a routing issue (how many instances of the route protocol, how those instances may interact, etc.), with signaling coming in when one wants a UNI (which would be needed in a non-flat network, as Diego already pointed out in one of his recent emails.) So I am not a proponet of any particular routing approach. In fact, quite a bit of prior work on the SDH/SONET signaling that I've been involved with has alluded to the layered nature of the transport network, and to the fact that routing would have to be appropriately designed for multi-layer circuit setup to work. Thanks, -Vishal On Monday, June 11, 2001 4:17 AM, Maarten Vissers [SMTP:mvissers@lucent.com] wrote: > Sharma, > > "flat" set up is the route to disaster... simply consider a switched > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > would get information of all these levels... an absolute disaster in a > world wide switched transport network would be the result. > > Therefore, there is this layering in which a server layer network > provides bandwidth to its client layer entworks. the client layer > networks see this bandwidth as kind of "fixed" bandwidth over which they > can route their signals. > > A separate entity (I called it "network engineering") is looking over > the shoulder of the call setup process to see if more bandwidth is > needed and when it would be needed or not longer required. But today, > this separate entity is not part of the control plane; it is in the > management plane. > > Regards, > > Maarten > > Susumu Yoneda wrote: > > > > Sharma, > > > > Thank you for letting me know your presentation material which looks very > > interesting. It seems to me that a layered setup would make a sense. > > However, users may want to have a "flat" setup. Therefore, lower setups > > would not be seen by users? > > > > -----Original Message----- > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > Sent: Saturday, June 09, 2001 11:06 AM > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: RE: GMPLS Sonet extensions > > > > Jimmy, Susumu, > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > have the same view of the network, you could compute an ERO at the > > ingress router and have the PATH message follow the hop-by-hop route > > to the egress router. > > (Note, however, that the PATH message will travel > > on the out-of-band IP control network; therefore, it would be non- > > associated > > signaling.) > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > in fact, have to be shared by all nodes, since that is precisely what > > the "peer model" implies. > > > > But you do have to be careful about what "LSP" you are requesting, since > > the > > characteristics of the requested LSP are not interpreted in the same way by > > the > > various pieces of equipment in your figure. (A SONET ADM requires a > > different > > way of defining a circuit than an IP router or an OXC.) > > Therefore, one possibility would be to do a "layered setup", where an LSP > > at the lower layer is setup before the PATH message at the higher layer > > is tunnelled over it or allowed to propagate further. > > > > For example, when the PATH message for the packet > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > a corresponding SONET circuit between themselves, and then either tunnel > > the PATH message for the packet LSP over this circuit, or (assuming your > > out-of-band network), at that time, allow the PATH message for the packet > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > channel, likewise, would be a recursive process, with the OXC first setting > > up an optical lightpath between themselves, and tunneling the request to > > set up the SONET channel over it, once that lightpath is setup.) > > > > A more detailed discussion of this subject, with corresponding animations > > and figures, that you may also find helpful is available in a talk I gave > > at > > MPLSCon'01, and can be found at: > > http://www.mplscon.com/missing_presentations.htm > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > -Vishal > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > [SMTP:yone@japan-telecom.co.jp] > > wrote: > > > Hi, > > > > > > I also assume that there would be an out-of-band signalling network based > > on > > > a suite of GMPLS protocols including LMP. I think there will be issues to > > > address whether all messages will be shared by all nodes, i.e router, > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > ------------------------------- > > > Susumu Yoneda tel +81 3 5540 8493 > > > Japan Telecom fax +81 3 5540 8485 > > > Information & Communication Labs. > > > e-mail yone@japan-telecom.co.jp > > > ------------------------------- > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > > Of > > > Jimmy Gendron > > > Sent: Friday, June 08, 2001 10:01 PM > > > To: 'ccamp@ops.ietf.org' > > > Subject: GMPLS Sonet extensions > > > > > > > > > Hi, > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > > > understand > > > most of the architecture, but I still have a question since the beginning; > > > > > > as an unified control plane, how do the routing/signaling protocols > > exchange > > > informations on a configuration like this: > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > (Ingress) > > > > > > Its a basic point to point configuration, but it will allow me to > > understand > > > the basic features of GMPLS. If I want to create an MPLS LSP between the > > two > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > (Assuming > > > that we have an out-of-band IP control network running LMP) > > > > > > My guess is that the PATH message will leave the ingress router with a > > PATH > > > message with a calculated ERO. It assumes that the network is in respect > > > with the peer model...everyone have the same routing table and know the > > > actual network topology. So, my PATH message will follow the CSPF (ERO) > > and > > > go to the egress router. Am I right? > > > > > > Best regards, > > > > > > Jimmy Gendron > > > << File: mvissers.vcf >> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 13:31:43 -0700 Message-ID: <36EF020032CFD411B7B400508B55E59016657A@MILAN> From: Wenjing Chu To: "'Bernstein, Greg'" , 'Maarten Vissers' , Diego Caviglia Cc: Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Date: Mon, 11 Jun 2001 12:41:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > > With the signaling protocol things are really separated by > who is involved > in the signaling transaction. In the routing case things are > less clear, > i.e., who wants/needs to know information about other layers > and what burden > does this present to the NEs and scalability. Which layers > can benefit by > integration... I'll be updating the Optical inter-domain > route requirements > draft soon (with others) and will be exploring some of these > items in more > depth. > Very much to the point. Routing integration is the interesting part. Whether and how much to integrate different layers become critical in maintaining scalability and bringing about the benefit of layer integration. Flexibility is needed in various trade-off points between "overlay" and "peer". Wenjing Turin Networks Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 11:59:44 -0700 Message-ID: From: neil.2.harrison@bt.com To: GregB@ciena.com, mvissers@lucent.com, Diego.Caviglia@marconi.com Cc: yone@japan-telecom.co.jp, v.sharma@ieee.org, jgendron@hyperchip.com, ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Date: Mon, 11 Jun 2001 19:58:12 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hi Greg.....you might find re-visting the 'Freeland' draft BT submitted to the 12/00 San Diego mtg helpful when reviewing the OTN inter-domain routing work you mentioned below. Some other observations on this discussion are: - there is vertical layering between technologies and horizontal partitioning within/per (single technology) layer networks. The latter is a very important aspect, since it is usually associated with commercial management domains (and can also involve different vendor interworking). So we can have a single management domain at technology/layer N served by several different disjoint/tandemmed commercial domains at layer N-1......clearly these relationships can recurse. - as we get closer to the duct layer network (yes it is a real layer network) the trail holding times must increase for stability.....so the need for SVC-like services decreases as we move to the duct. - I find it hard to understand how any operator will be able to make a valid business case for large BW L1 SVC services; SVCs need a 'law of large numbers' environment such that any single instance of a demand is almost unoticable on the network....so as we get closer to the duct:- S-PVCs yes, SVCs no; so we really don't need UNIs, but we do need NNIs (and different interior and exterior NNIs); - unless one has total control of all layer networks to the duct then one cannot even contemplate an accurate view of resources (including resilience design.....since disjoint connectivity in all client layers is defined/inherited from the duct layer). The immediate corrolary of this is that if any operator wishes to serve a global customer base then: (i) that operator must accept peering with other operators and virtualisation of server layers......and note that in such a relationship each peering operator will demand isolation of what is/is-not allowed to be advertised/controlled across that (exterior) NNI....which usually means this reduces to simple reachability; OR (ii) that operator must build out (to the duct) globally. Guess which model has more chance of obtaining acceptance with operators (especially their finance people!)? - SDH will be a client of the OTN......and there will be several client layers of SDH. These layer networks are commercially important to operators and cannot be discounted. It is also an interesting exercise to find out just what a sizeable business peer (or as Maarten calls them 'native') managed BW demands are on the L1 networks.....probably bigger than most non-operators realise. - we (I am speaking as BT here) can set-up L1 trails in SDH very fast now using management tools....introducing a control-plane is not going to speed up the process by any significant degree unless it can also dig trenches, lay ducts, install equipment and do order processing, link to billing (and all our other OSS), etc! As I said, the Freeland draft from BT has additional pointers as to what we, as at least one operator, need for the L1 networks if a control-plane is introduced. But as to the choice of the the most *appropriate* control-plane facets, that is a different question ;-). But one thing is for sure......there will have to be hard decoupling between client layers and the SDH/OTN server layers. This is not really a technical issue for argument, it is commercial necessity. regards, Neil > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: 11 June 2001 17:14 > To: 'Maarten Vissers'; Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; > ccamp@ops.ietf.org > Subject: RE: GMPLS Sonet extensions > > > Hi Maarten, Diego, et. al. > what's interesting here is the question of what do we mean by "its own > instance of a control plane"? Obviously if we are setting up > a LOVC (in > SONET, say a VT1.5 capable of carrying a DS1 signal) we will > be signaling to > those switches that are LOVC capable. Other switches need > not be involved. > If it turns out that the LOVC capable switches are not > interconnected by a > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > appropriate HOVC interconnecting the LOVC needs to be setup > first. In GMPLS > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > switches before we set up the LOVC LSPs. > > Since we have to (a) be able to set up connects at the > appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run > fewer protocol > instances than network layers. Well actually as Maarten > wrote in a recent > ITU document that we would be primarily interested in those > layers involved > in dynamic switching/multiplexing. Note that we've started > to bring in > non-dynamic layer information via other mechanisms, e.g., the > SRLG concept > (the WDM--SONET example I always give). > > With the signaling protocol things are really separated by > who is involved > in the signaling transaction. In the routing case things are > less clear, > i.e., who wants/needs to know information about other layers > and what burden > does this present to the NEs and scalability. Which layers > can benefit by > integration... I'll be updating the Optical inter-domain > route requirements > draft soon (with others) and will be exploring some of these > items in more > depth. > > (Terminology: LOVC := Lower order virtual container, SDH term > that includes > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := > Higher order > virtual container, SDH terms that includes signals between > 50Mbps-40Gbps in > the SDH hierarchy). > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Scientist, Ciena Corporation > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, June 11, 2001 7:46 AM > To: Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; > ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > > Diego, > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > and OCh) will have its own (instance of) control plane. > > Each switched layer network runs a copy of the generic > routing protocol; > it does so within the boundaries of the switched layer network. > > Within each switched layer network you will find UNI, E-NNI and I-NNI > interfaces due to partitioning of a switched layer network. Topology > information is exchanged only via I-NNI interfaces. E-NNI > interfaces on > the other hand only provide reachability information. > > For the case an MPLS router is from a different organisation than the > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > the interface will be an MPLS-I-NNI. > For the server layers within the MPLS router (e.g. HOVC and STM-N > section layers) the interface relation is to be determined independent > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it > migth be that > at MPLS level full topology information is exchanged > (MPLS-I-NNI), where > as at the HOVC layer entwork only reachability information is > available > in the MPLS router (HOVC-E-NNI). > > The MPLS router should not be concerned at all about the > routing of the > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > between two adjacent MPLS routers. For the case an additional > 2.5G MPLS > link between is needed between MPLS router A and MPLS router > B, router A > needs to have knowledge of router B's address/name only to request a > VC-4-16c/STS-48c connection through the transport network. > The switched > HOVC (transport) network will take care of the connection setup. > > And even if two diverse routed connections are required (e.g. > to support > VC-4-16c SNC protection within the A and B MPLS routers), > MPLS router A > needs to request only the creation of 2 VC-4-16c connections with the > constraint of being diversely routed. The switched HOVC > network will be > able to provide these two connections diversely routed between A and B > routers. > > > > At the moment, I recognise two connection types in a layer network: > - native connections and > - client connections. > Example: within a HOVC layer network a STS1 or VC-4 connection is a > native connection, and a DS3 connection or a LOVC link is a client > connection. A client connection is supported by the HOVC layer network > after adapting it to the layer network signal type (i.e. STS1 (to > support DS3), STS1 or VC4 (to support LOVC link)). The client > connection > can have a > - 1:1, > - 1:n, > - n:1 > relationship with the underlying layer network signal. > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > relationship. > > With client connections, an I-NNI is almost per definition > not possible > (you go outside the layer network). Nevertheless, some people consider > the special 1:1 case as an area where an I-NNI could be deployed; of > course not for the case of DS3 -> STS1, but for the case of > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and > STS-192c/VC-4-64c > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > HOVC layer network and a client signal to the OCh and ODU1 layer > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > wavelenght it is easy to think to be within one and the same layer > network. Personally, I believe that such very special case looks much > brighter than it is in the long term. I.e. don't declare very special > cases to be the common ones; keep those as very special > cases, best even > keep those as regular cases obeying to the generic rules. > > Client connections as such have UNI or E-NNI interface relationships > over which reachability information is offered at best. This > is the case > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > layer entwork) as well as "vertical client connections" (e.g. a LOVC > link over a HOVC/STS layer network). > > Regards, > > Maarten > > > Diego Caviglia wrote: > > > > Maarten, > > I agree in principle with you but this > means it would > be > > necessary to have a routing protocol for each layer doesn't it? > > > > One of the initial reasons for (G)MPLS is to unify the control > plane, your > > layered view of the network implies again the separation of > the control > planes. > > > > The Transport Network is very different from a flat IP network and > layering in > > TN is implicit. > > > > If I understood your model correctly the MPLS Router only > views, Access > Groups > > and links to other MPLS Routers. If there are free > resources between > the two > > routers the TE process calculates, accordingly to some > rules, the best > path. > > Agree. > > > If > > there are no resources a call to the Network Engineering agent is > performed, the > > NE makes a call to the TE of the SONET layer in order to > provide a trail > to the > > MPLS layer (this procedure is repeated until available resources are > created for > > the MPLS router connection). This trail modifies the > topology at the MPLS > layer. > > Agree. One note however, operators have indicated that they would like > to deploy policies in the NE agent which may include some thresholds, > before it decides to change the topology of the layer network. E.g. > topology is not extended unless X calls failed. On the other hand, the > NE agent may have scheduled topology changes; e.g. at the > begin of busy > hour extra links are added or bandwidth of existing link is extended, > and at the end of busy hour the reverse is happening. > > > > > If my understanding is correct and we want to implement > an automated TN > a sort > > of UNI has to be put between the NE at layer N and the TE > at layer N-1. > > UNI or E-NNI. > > > > > Maybe this will create some problems, on the other hand, as Maarten > pointed out, > > flat networks won't work due the huge amount of routing > information > that they > > have to carry. > > > > Regards > > > > Diego > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > , ccamp@ops.ietf.org(bcc: > > Diego Caviglia/MAIN/MC1) > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > Sharma, > > > > "flat" set up is the route to disaster... simply consider a switched > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and > perhaps also DS0, > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > would get information of all these levels... an absolute > disaster in a > > world wide switched transport network would be the result. > > > > Therefore, there is this layering in which a server layer network > > provides bandwidth to its client layer entworks. the client layer > > networks see this bandwidth as kind of "fixed" bandwidth > over which they > > can route their signals. > > > > A separate entity (I called it "network engineering") is > looking over > > the shoulder of the call setup process to see if more bandwidth is > > needed and when it would be needed or not longer required. > But today, > > this separate entity is not part of the control plane; it is in the > > management plane. > > > > Regards, > > > > Maarten > > > > Susumu Yoneda wrote: > > > > > > Sharma, > > > > > > Thank you for letting me know your presentation material > which looks > very > > > interesting. It seems to me that a layered setup would > make a sense. > > > However, users may want to have a "flat" setup. > Therefore, lower setups > > > would not be seen by users? > > > > > > -----Original Message----- > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > Sent: Saturday, June 09, 2001 11:06 AM > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: RE: GMPLS Sonet extensions > > > > > > Jimmy, Susumu, > > > > > > Your idea (assuming a peer model) is basically correct. > Since all nodes > > > have the same view of the network, you could compute an ERO at the > > > ingress router and have the PATH message follow the > hop-by-hop route > > > to the egress router. > > > (Note, however, that the PATH message will travel > > > on the out-of-band IP control network; therefore, it would be > non-associated > > > signaling.) > > > > > > Also, Susumu, if the peer model is in effect, then all > messges will, > > > in fact, have to be shared by all nodes, since that is > precisely what > > > the "peer model" implies. > > > > > > But you do have to be careful about what "LSP" you are > requesting, since > the > > > characteristics of the requested LSP are not interpreted > in the same way > by > > > the > > > various pieces of equipment in your figure. (A SONET ADM > requires a > > > different > > > way of defining a circuit than an IP router or an OXC.) > > > Therefore, one possibility would be to do a "layered > setup", where an > LSP > > > at the lower layer is setup before the PATH message at > the higher layer > > > is tunnelled over it or allowed to propagate further. > > > > > > For example, when the PATH message for the packet > > > LSP arrives at the SONET ADM, the peer SONET ADMs would > have to setup > > > a corresponding SONET circuit between themselves, and > then either tunnel > > > the PATH message for the packet LSP over this circuit, or > (assuming your > > > out-of-band network), at that time, allow the PATH message for the > packet > > > LSP to propagate to the next MPLS router. (The setting up > of the SONET > > > channel, likewise, would be a recursive process, with the > OXC first > setting > > > up an optical lightpath between themselves, and tunneling > the request to > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > A more detailed discussion of this subject, with corresponding > animations > > > and figures, that you may also find helpful is available > in a talk I > gave at > > > MPLSCon'01, and can be found at: > > > http://www.mplscon.com/missing_presentations.htm > > > (Dynamic path establishment in MPLS-controlled > multi-service networks.) > > > > > > -Vishal > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > [SMTP:yone@japan-telecom.co.jp] > > > wrote: > > > > Hi, > > > > > > > > I also assume that there would be an out-of-band > signalling network > based > > > on > > > > a suite of GMPLS protocols including LMP. I think there > will be issues > to > > > > address whether all messages will be shared by all > nodes, i.e router, > > > > SDH/SONET, and OXC or not. This will be a part of > security issues. > > > > ------------------------------- > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > Japan Telecom fax +81 3 5540 8485 > > > > Information & Communication Labs. > > > > e-mail yone@japan-telecom.co.jp > > > > ------------------------------- > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On > Behalf > > > Of > > > > Jimmy Gendron > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > To: 'ccamp@ops.ietf.org' > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > Hi, > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > understand > > > > most of the architecture, but I still have a question since the > beginning; > > > > as an unified control plane, how do the > routing/signaling protocols > > > exchange > > > > informations on a configuration like this: > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM > ----------- WDM > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > (Ingress) > > > > > > > > Its a basic point to point configuration, but it will > allow me to > > > understand > > > > the basic features of GMPLS. If I want to create an > MPLS LSP between > the > > > two > > > > MPLS routers, how do the RSVP PATH message is sent to > the network? > > > (Assuming > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > My guess is that the PATH message will leave the > ingress router with a > > > PATH > > > > message with a calculated ERO. It assumes that the network is in > respect > > > > with the peer model...everyone have the same routing > table and know > the > > > > actual network topology. So, my PATH message will > follow the CSPF > (ERO) > > > and > > > > go to the egress router. Am I right? > > > > > > > > Best regards, > > > > > > > > Jimmy Gendron > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 11:10:37 -0700 Message-ID: <3B250954.71F3B0AC@lucent.com> Date: Mon, 11 Jun 2001 14:09:24 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies MIME-Version: 1.0 To: "Bernstein, Greg" CC: "'Maarten Vissers'" , Diego Caviglia , Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I think there are multiple ways that control plane can be realized: * single control plane for all layers (single protocol, single process) * single control plane for each layer (single protocol, single process, multiple databases for each layer) * multiple control plane for each layer (single protocol, multiple processes) * multiple control plane for each layer (multiple protocol, multiple processes) I think it's an implementation issue which one is chosen. The standards, both GMPLS and ASTN, allows for any combinations. Of course, each implementation will have it's own domain of use where it is better than other implementations... But I think that architecturally/functionally speaking, these can be viewed as separate control planes controlling separate layers. Or am I mistaken? Zhi "Bernstein, Greg" wrote: > > Hi Maarten, Diego, et. al. > what's interesting here is the question of what do we mean by "its own > instance of a control plane"? Obviously if we are setting up a LOVC (in > SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to > those switches that are LOVC capable. Other switches need not be involved. > If it turns out that the LOVC capable switches are not interconnected by a > HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the > appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS > speak we first setup the HOVC LSP tunnel(s) between the LOVC capable > switches before we set up the LOVC LSPs. > > Since we have to (a) be able to set up connects at the appropriate layers, > (b) understand the topology at each layer, to me this sounds like an > instance of a control plane at each layer. > However, it doesn't necessarily tell me whether I'd want to (or not) > integrate multiple layer information into a protocol and run fewer protocol > instances than network layers. Well actually as Maarten wrote in a recent > ITU document that we would be primarily interested in those layers involved > in dynamic switching/multiplexing. Note that we've started to bring in > non-dynamic layer information via other mechanisms, e.g., the SRLG concept > (the WDM--SONET example I always give). > > With the signaling protocol things are really separated by who is involved > in the signaling transaction. In the routing case things are less clear, > i.e., who wants/needs to know information about other layers and what burden > does this present to the NEs and scalability. Which layers can benefit by > integration... I'll be updating the Optical inter-domain route requirements > draft soon (with others) and will be exploring some of these items in more > depth. > > (Terminology: LOVC := Lower order virtual container, SDH term that includes > signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order > virtual container, SDH terms that includes signals between 50Mbps-40Gbps in > the SDH hierarchy). > > Greg B. > *********************************** > Dr. Greg M. Bernstein > Senior Scientist, Ciena Corporation > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, June 11, 2001 7:46 AM > To: Diego Caviglia > Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org > Subject: Re: GMPLS Sonet extensions > > Diego, > > Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 > and OCh) will have its own (instance of) control plane. > > Each switched layer network runs a copy of the generic routing protocol; > it does so within the boundaries of the switched layer network. > > Within each switched layer network you will find UNI, E-NNI and I-NNI > interfaces due to partitioning of a switched layer network. Topology > information is exchanged only via I-NNI interfaces. E-NNI interfaces on > the other hand only provide reachability information. > > For the case an MPLS router is from a different organisation than the > transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI > interface. For the case the MPLS router is at the edge of a MPLS-VPN, > the interface will be an MPLS-I-NNI. > For the server layers within the MPLS router (e.g. HOVC and STM-N > section layers) the interface relation is to be determined independent > of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined > (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that > at MPLS level full topology information is exchanged (MPLS-I-NNI), where > as at the HOVC layer entwork only reachability information is available > in the MPLS router (HOVC-E-NNI). > > The MPLS router should not be concerned at all about the routing of the > HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link > between two adjacent MPLS routers. For the case an additional 2.5G MPLS > link between is needed between MPLS router A and MPLS router B, router A > needs to have knowledge of router B's address/name only to request a > VC-4-16c/STS-48c connection through the transport network. The switched > HOVC (transport) network will take care of the connection setup. > > And even if two diverse routed connections are required (e.g. to support > VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A > needs to request only the creation of 2 VC-4-16c connections with the > constraint of being diversely routed. The switched HOVC network will be > able to provide these two connections diversely routed between A and B > routers. > > At the moment, I recognise two connection types in a layer network: > - native connections and > - client connections. > Example: within a HOVC layer network a STS1 or VC-4 connection is a > native connection, and a DS3 connection or a LOVC link is a client > connection. A client connection is supported by the HOVC layer network > after adapting it to the layer network signal type (i.e. STS1 (to > support DS3), STS1 or VC4 (to support LOVC link)). The client connection > can have a > - 1:1, > - 1:n, > - n:1 > relationship with the underlying layer network signal. > Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 > relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n > relationship. > > With client connections, an I-NNI is almost per definition not possible > (you go outside the layer network). Nevertheless, some people consider > the special 1:1 case as an area where an I-NNI could be deployed; of > course not for the case of DS3 -> STS1, but for the case of > STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c > -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the > HOVC layer network and a client signal to the OCh and ODU1 layer > networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 > wavelenght it is easy to think to be within one and the same layer > network. Personally, I believe that such very special case looks much > brighter than it is in the long term. I.e. don't declare very special > cases to be the common ones; keep those as very special cases, best even > keep those as regular cases obeying to the generic rules. > > Client connections as such have UNI or E-NNI interface relationships > over which reachability information is offered at best. This is the case > for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS > layer entwork) as well as "vertical client connections" (e.g. a LOVC > link over a HOVC/STS layer network). > > Regards, > > Maarten > > Diego Caviglia wrote: > > > > Maarten, > > I agree in principle with you but this means it would > be > > necessary to have a routing protocol for each layer doesn't it? > > > > One of the initial reasons for (G)MPLS is to unify the control > plane, your > > layered view of the network implies again the separation of the control > planes. > > > > The Transport Network is very different from a flat IP network and > layering in > > TN is implicit. > > > > If I understood your model correctly the MPLS Router only views, Access > Groups > > and links to other MPLS Routers. If there are free resources between > the two > > routers the TE process calculates, accordingly to some rules, the best > path. > > Agree. > > > If > > there are no resources a call to the Network Engineering agent is > performed, the > > NE makes a call to the TE of the SONET layer in order to provide a trail > to the > > MPLS layer (this procedure is repeated until available resources are > created for > > the MPLS router connection). This trail modifies the topology at the MPLS > layer. > > Agree. One note however, operators have indicated that they would like > to deploy policies in the NE agent which may include some thresholds, > before it decides to change the topology of the layer network. E.g. > topology is not extended unless X calls failed. On the other hand, the > NE agent may have scheduled topology changes; e.g. at the begin of busy > hour extra links are added or bandwidth of existing link is extended, > and at the end of busy hour the reverse is happening. > > > > > If my understanding is correct and we want to implement an automated TN > a sort > > of UNI has to be put between the NE at layer N and the TE at layer N-1. > > UNI or E-NNI. > > > > > Maybe this will create some problems, on the other hand, as Maarten > pointed out, > > flat networks won't work due the huge amount of routing information > that they > > have to carry. > > > > Regards > > > > Diego > > > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > > > > > > > > > To: Susumu Yoneda > > > > cc: v.sharma@ieee.org, Jimmy Gendron > > , ccamp@ops.ietf.org(bcc: > > Diego Caviglia/MAIN/MC1) > > > > > > > > Subject: Re: GMPLS Sonet extensions > > > > > > Sharma, > > > > "flat" set up is the route to disaster... simply consider a switched > > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > > would get information of all these levels... an absolute disaster in a > > world wide switched transport network would be the result. > > > > Therefore, there is this layering in which a server layer network > > provides bandwidth to its client layer entworks. the client layer > > networks see this bandwidth as kind of "fixed" bandwidth over which they > > can route their signals. > > > > A separate entity (I called it "network engineering") is looking over > > the shoulder of the call setup process to see if more bandwidth is > > needed and when it would be needed or not longer required. But today, > > this separate entity is not part of the control plane; it is in the > > management plane. > > > > Regards, > > > > Maarten > > > > Susumu Yoneda wrote: > > > > > > Sharma, > > > > > > Thank you for letting me know your presentation material which looks > very > > > interesting. It seems to me that a layered setup would make a sense. > > > However, users may want to have a "flat" setup. Therefore, lower setups > > > would not be seen by users? > > > > > > -----Original Message----- > > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > > Sent: Saturday, June 09, 2001 11:06 AM > > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > > Subject: RE: GMPLS Sonet extensions > > > > > > Jimmy, Susumu, > > > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > > have the same view of the network, you could compute an ERO at the > > > ingress router and have the PATH message follow the hop-by-hop route > > > to the egress router. > > > (Note, however, that the PATH message will travel > > > on the out-of-band IP control network; therefore, it would be > non-associated > > > signaling.) > > > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > > in fact, have to be shared by all nodes, since that is precisely what > > > the "peer model" implies. > > > > > > But you do have to be careful about what "LSP" you are requesting, since > the > > > characteristics of the requested LSP are not interpreted in the same way > by > > > the > > > various pieces of equipment in your figure. (A SONET ADM requires a > > > different > > > way of defining a circuit than an IP router or an OXC.) > > > Therefore, one possibility would be to do a "layered setup", where an > LSP > > > at the lower layer is setup before the PATH message at the higher layer > > > is tunnelled over it or allowed to propagate further. > > > > > > For example, when the PATH message for the packet > > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > > a corresponding SONET circuit between themselves, and then either tunnel > > > the PATH message for the packet LSP over this circuit, or (assuming your > > > out-of-band network), at that time, allow the PATH message for the > packet > > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > > channel, likewise, would be a recursive process, with the OXC first > setting > > > up an optical lightpath between themselves, and tunneling the request to > > > set up the SONET channel over it, once that lightpath is setup.) > > > > > > A more detailed discussion of this subject, with corresponding > animations > > > and figures, that you may also find helpful is available in a talk I > gave at > > > MPLSCon'01, and can be found at: > > > http://www.mplscon.com/missing_presentations.htm > > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > > > -Vishal > > > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > > [SMTP:yone@japan-telecom.co.jp] > > > wrote: > > > > Hi, > > > > > > > > I also assume that there would be an out-of-band signalling network > based > > > on > > > > a suite of GMPLS protocols including LMP. I think there will be issues > to > > > > address whether all messages will be shared by all nodes, i.e router, > > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > > ------------------------------- > > > > Susumu Yoneda tel +81 3 5540 8493 > > > > Japan Telecom fax +81 3 5540 8485 > > > > Information & Communication Labs. > > > > e-mail yone@japan-telecom.co.jp > > > > ------------------------------- > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf > > > Of > > > > Jimmy Gendron > > > > Sent: Friday, June 08, 2001 10:01 PM > > > > To: 'ccamp@ops.ietf.org' > > > > Subject: GMPLS Sonet extensions > > > > > > > > > > > > Hi, > > > > > > > > I used to read almost all stuff regarding GMPLS since a week. I > understand > > > > most of the architecture, but I still have a question since the > beginning; > > > > as an unified control plane, how do the routing/signaling protocols > > > exchange > > > > informations on a configuration like this: > > > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > > (Ingress) > > > > > > > > Its a basic point to point configuration, but it will allow me to > > > understand > > > > the basic features of GMPLS. If I want to create an MPLS LSP between > the > > > two > > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > > (Assuming > > > > that we have an out-of-band IP control network running LMP) > > > > > > > > My guess is that the PATH message will leave the ingress router with a > > > PATH > > > > message with a calculated ERO. It assumes that the network is in > respect > > > > with the peer model...everyone have the same routing table and know > the > > > > actual network topology. So, my PATH message will follow the CSPF > (ERO) > > > and > > > > go to the egress router. Am I right? > > > > > > > > Best regards, > > > > > > > > Jimmy Gendron > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 09:15:14 -0700 Message-ID: From: "Bernstein, Greg" To: 'Maarten Vissers' , Diego Caviglia Cc: Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Date: Mon, 11 Jun 2001 09:13:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Maarten, Diego, et. al. what's interesting here is the question of what do we mean by "its own instance of a control plane"? Obviously if we are setting up a LOVC (in SONET, say a VT1.5 capable of carrying a DS1 signal) we will be signaling to those switches that are LOVC capable. Other switches need not be involved. If it turns out that the LOVC capable switches are not interconnected by a HOVC (in SONET an STS-1 that is used to carry multiple VT1.5) then the appropriate HOVC interconnecting the LOVC needs to be setup first. In GMPLS speak we first setup the HOVC LSP tunnel(s) between the LOVC capable switches before we set up the LOVC LSPs. Since we have to (a) be able to set up connects at the appropriate layers, (b) understand the topology at each layer, to me this sounds like an instance of a control plane at each layer. However, it doesn't necessarily tell me whether I'd want to (or not) integrate multiple layer information into a protocol and run fewer protocol instances than network layers. Well actually as Maarten wrote in a recent ITU document that we would be primarily interested in those layers involved in dynamic switching/multiplexing. Note that we've started to bring in non-dynamic layer information via other mechanisms, e.g., the SRLG concept (the WDM--SONET example I always give). With the signaling protocol things are really separated by who is involved in the signaling transaction. In the routing case things are less clear, i.e., who wants/needs to know information about other layers and what burden does this present to the NEs and scalability. Which layers can benefit by integration... I'll be updating the Optical inter-domain route requirements draft soon (with others) and will be exploring some of these items in more depth. (Terminology: LOVC := Lower order virtual container, SDH term that includes signals between 1.5 and 6Mbps in the SDH hierarchy. HOVC := Higher order virtual container, SDH terms that includes signals between 50Mbps-40Gbps in the SDH hierarchy). Greg B. *********************************** Dr. Greg M. Bernstein Senior Scientist, Ciena Corporation -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Monday, June 11, 2001 7:46 AM To: Diego Caviglia Cc: Susumu Yoneda; v.sharma@ieee.org; Jimmy Gendron; ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Diego, Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 and OCh) will have its own (instance of) control plane. Each switched layer network runs a copy of the generic routing protocol; it does so within the boundaries of the switched layer network. Within each switched layer network you will find UNI, E-NNI and I-NNI interfaces due to partitioning of a switched layer network. Topology information is exchanged only via I-NNI interfaces. E-NNI interfaces on the other hand only provide reachability information. For the case an MPLS router is from a different organisation than the transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI interface. For the case the MPLS router is at the edge of a MPLS-VPN, the interface will be an MPLS-I-NNI. For the server layers within the MPLS router (e.g. HOVC and STM-N section layers) the interface relation is to be determined independent of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that at MPLS level full topology information is exchanged (MPLS-I-NNI), where as at the HOVC layer entwork only reachability information is available in the MPLS router (HOVC-E-NNI). The MPLS router should not be concerned at all about the routing of the HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link between two adjacent MPLS routers. For the case an additional 2.5G MPLS link between is needed between MPLS router A and MPLS router B, router A needs to have knowledge of router B's address/name only to request a VC-4-16c/STS-48c connection through the transport network. The switched HOVC (transport) network will take care of the connection setup. And even if two diverse routed connections are required (e.g. to support VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A needs to request only the creation of 2 VC-4-16c connections with the constraint of being diversely routed. The switched HOVC network will be able to provide these two connections diversely routed between A and B routers. At the moment, I recognise two connection types in a layer network: - native connections and - client connections. Example: within a HOVC layer network a STS1 or VC-4 connection is a native connection, and a DS3 connection or a LOVC link is a client connection. A client connection is supported by the HOVC layer network after adapting it to the layer network signal type (i.e. STS1 (to support DS3), STS1 or VC4 (to support LOVC link)). The client connection can have a - 1:1, - 1:n, - n:1 relationship with the underlying layer network signal. Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n relationship. With client connections, an I-NNI is almost per definition not possible (you go outside the layer network). Nevertheless, some people consider the special 1:1 case as an area where an I-NNI could be deployed; of course not for the case of DS3 -> STS1, but for the case of STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the HOVC layer network and a client signal to the OCh and ODU1 layer networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 wavelenght it is easy to think to be within one and the same layer network. Personally, I believe that such very special case looks much brighter than it is in the long term. I.e. don't declare very special cases to be the common ones; keep those as very special cases, best even keep those as regular cases obeying to the generic rules. Client connections as such have UNI or E-NNI interface relationships over which reachability information is offered at best. This is the case for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS layer entwork) as well as "vertical client connections" (e.g. a LOVC link over a HOVC/STS layer network). Regards, Maarten Diego Caviglia wrote: > > Maarten, > I agree in principle with you but this means it would be > necessary to have a routing protocol for each layer doesn't it? > > One of the initial reasons for (G)MPLS is to unify the control plane, your > layered view of the network implies again the separation of the control planes. > > The Transport Network is very different from a flat IP network and layering in > TN is implicit. > > If I understood your model correctly the MPLS Router only views, Access Groups > and links to other MPLS Routers. If there are free resources between the two > routers the TE process calculates, accordingly to some rules, the best path. Agree. > If > there are no resources a call to the Network Engineering agent is performed, the > NE makes a call to the TE of the SONET layer in order to provide a trail to the > MPLS layer (this procedure is repeated until available resources are created for > the MPLS router connection). This trail modifies the topology at the MPLS layer. Agree. One note however, operators have indicated that they would like to deploy policies in the NE agent which may include some thresholds, before it decides to change the topology of the layer network. E.g. topology is not extended unless X calls failed. On the other hand, the NE agent may have scheduled topology changes; e.g. at the begin of busy hour extra links are added or bandwidth of existing link is extended, and at the end of busy hour the reverse is happening. > > If my understanding is correct and we want to implement an automated TN a sort > of UNI has to be put between the NE at layer N and the TE at layer N-1. UNI or E-NNI. > > Maybe this will create some problems, on the other hand, as Maarten pointed out, > flat networks won't work due the huge amount of routing information that they > have to carry. > > Regards > > Diego > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > To: Susumu Yoneda > > cc: v.sharma@ieee.org, Jimmy Gendron > , ccamp@ops.ietf.org(bcc: > Diego Caviglia/MAIN/MC1) > > > > Subject: Re: GMPLS Sonet extensions > > > Sharma, > > "flat" set up is the route to disaster... simply consider a switched > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > would get information of all these levels... an absolute disaster in a > world wide switched transport network would be the result. > > Therefore, there is this layering in which a server layer network > provides bandwidth to its client layer entworks. the client layer > networks see this bandwidth as kind of "fixed" bandwidth over which they > can route their signals. > > A separate entity (I called it "network engineering") is looking over > the shoulder of the call setup process to see if more bandwidth is > needed and when it would be needed or not longer required. But today, > this separate entity is not part of the control plane; it is in the > management plane. > > Regards, > > Maarten > > Susumu Yoneda wrote: > > > > Sharma, > > > > Thank you for letting me know your presentation material which looks very > > interesting. It seems to me that a layered setup would make a sense. > > However, users may want to have a "flat" setup. Therefore, lower setups > > would not be seen by users? > > > > -----Original Message----- > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > Sent: Saturday, June 09, 2001 11:06 AM > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: RE: GMPLS Sonet extensions > > > > Jimmy, Susumu, > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > have the same view of the network, you could compute an ERO at the > > ingress router and have the PATH message follow the hop-by-hop route > > to the egress router. > > (Note, however, that the PATH message will travel > > on the out-of-band IP control network; therefore, it would be non-associated > > signaling.) > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > in fact, have to be shared by all nodes, since that is precisely what > > the "peer model" implies. > > > > But you do have to be careful about what "LSP" you are requesting, since the > > characteristics of the requested LSP are not interpreted in the same way by > > the > > various pieces of equipment in your figure. (A SONET ADM requires a > > different > > way of defining a circuit than an IP router or an OXC.) > > Therefore, one possibility would be to do a "layered setup", where an LSP > > at the lower layer is setup before the PATH message at the higher layer > > is tunnelled over it or allowed to propagate further. > > > > For example, when the PATH message for the packet > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > a corresponding SONET circuit between themselves, and then either tunnel > > the PATH message for the packet LSP over this circuit, or (assuming your > > out-of-band network), at that time, allow the PATH message for the packet > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > channel, likewise, would be a recursive process, with the OXC first setting > > up an optical lightpath between themselves, and tunneling the request to > > set up the SONET channel over it, once that lightpath is setup.) > > > > A more detailed discussion of this subject, with corresponding animations > > and figures, that you may also find helpful is available in a talk I gave at > > MPLSCon'01, and can be found at: > > http://www.mplscon.com/missing_presentations.htm > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > -Vishal > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > [SMTP:yone@japan-telecom.co.jp] > > wrote: > > > Hi, > > > > > > I also assume that there would be an out-of-band signalling network based > > on > > > a suite of GMPLS protocols including LMP. I think there will be issues to > > > address whether all messages will be shared by all nodes, i.e router, > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > ------------------------------- > > > Susumu Yoneda tel +81 3 5540 8493 > > > Japan Telecom fax +81 3 5540 8485 > > > Information & Communication Labs. > > > e-mail yone@japan-telecom.co.jp > > > ------------------------------- > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > > Of > > > Jimmy Gendron > > > Sent: Friday, June 08, 2001 10:01 PM > > > To: 'ccamp@ops.ietf.org' > > > Subject: GMPLS Sonet extensions > > > > > > > > > Hi, > > > > > > I used to read almost all stuff regarding GMPLS since a week. I understand > > > most of the architecture, but I still have a question since the beginning; > > > as an unified control plane, how do the routing/signaling protocols > > exchange > > > informations on a configuration like this: > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > (Ingress) > > > > > > Its a basic point to point configuration, but it will allow me to > > understand > > > the basic features of GMPLS. If I want to create an MPLS LSP between the > > two > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > (Assuming > > > that we have an out-of-band IP control network running LMP) > > > > > > My guess is that the PATH message will leave the ingress router with a > > PATH > > > message with a calculated ERO. It assumes that the network is in respect > > > with the peer model...everyone have the same routing table and know the > > > actual network topology. So, my PATH message will follow the CSPF (ERO) > > and > > > go to the egress router. Am I right? > > > > > > Best regards, > > > > > > Jimmy Gendron > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 07:47:07 -0700 Cc: Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <3B24D9C4.59061D6E@lucent.com> Date: Mon, 11 Jun 2001 16:46:28 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Diego Caviglia Original-CC: Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------3D38327E2429B1C9D7893F5C" This is a multi-part message in MIME format. --------------3D38327E2429B1C9D7893F5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diego, Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3 and OCh) will have its own (instance of) control plane. Each switched layer network runs a copy of the generic routing protocol; it does so within the boundaries of the switched layer network. Within each switched layer network you will find UNI, E-NNI and I-NNI interfaces due to partitioning of a switched layer network. Topology information is exchanged only via I-NNI interfaces. E-NNI interfaces on the other hand only provide reachability information. For the case an MPLS router is from a different organisation than the transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI interface. For the case the MPLS router is at the edge of a MPLS-VPN, the interface will be an MPLS-I-NNI. For the server layers within the MPLS router (e.g. HOVC and STM-N section layers) the interface relation is to be determined independent of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined (on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that at MPLS level full topology information is exchanged (MPLS-I-NNI), where as at the HOVC layer entwork only reachability information is available in the MPLS router (HOVC-E-NNI). The MPLS router should not be concerned at all about the routing of the HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link between two adjacent MPLS routers. For the case an additional 2.5G MPLS link between is needed between MPLS router A and MPLS router B, router A needs to have knowledge of router B's address/name only to request a VC-4-16c/STS-48c connection through the transport network. The switched HOVC (transport) network will take care of the connection setup. And even if two diverse routed connections are required (e.g. to support VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A needs to request only the creation of 2 VC-4-16c connections with the constraint of being diversely routed. The switched HOVC network will be able to provide these two connections diversely routed between A and B routers. At the moment, I recognise two connection types in a layer network: - native connections and - client connections. Example: within a HOVC layer network a STS1 or VC-4 connection is a native connection, and a DS3 connection or a LOVC link is a client connection. A client connection is supported by the HOVC layer network after adapting it to the layer network signal type (i.e. STS1 (to support DS3), STS1 or VC4 (to support LOVC link)). The client connection can have a - 1:1, - 1:n, - n:1 relationship with the underlying layer network signal. Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1 relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n relationship. With client connections, an I-NNI is almost per definition not possible (you go outside the layer network). Nevertheless, some people consider the special 1:1 case as an area where an I-NNI could be deployed; of course not for the case of DS3 -> STS1, but for the case of STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c -> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the HOVC layer network and a client signal to the OCh and ODU1 layer networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5 wavelenght it is easy to think to be within one and the same layer network. Personally, I believe that such very special case looks much brighter than it is in the long term. I.e. don't declare very special cases to be the common ones; keep those as very special cases, best even keep those as regular cases obeying to the generic rules. Client connections as such have UNI or E-NNI interface relationships over which reachability information is offered at best. This is the case for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS layer entwork) as well as "vertical client connections" (e.g. a LOVC link over a HOVC/STS layer network). Regards, Maarten Diego Caviglia wrote: > > Maarten, > I agree in principle with you but this means it would be > necessary to have a routing protocol for each layer doesn't it? > > One of the initial reasons for (G)MPLS is to unify the control plane, your > layered view of the network implies again the separation of the control planes. > > The Transport Network is very different from a flat IP network and layering in > TN is implicit. > > If I understood your model correctly the MPLS Router only views, Access Groups > and links to other MPLS Routers. If there are free resources between the two > routers the TE process calculates, accordingly to some rules, the best path. Agree. > If > there are no resources a call to the Network Engineering agent is performed, the > NE makes a call to the TE of the SONET layer in order to provide a trail to the > MPLS layer (this procedure is repeated until available resources are created for > the MPLS router connection). This trail modifies the topology at the MPLS layer. Agree. One note however, operators have indicated that they would like to deploy policies in the NE agent which may include some thresholds, before it decides to change the topology of the layer network. E.g. topology is not extended unless X calls failed. On the other hand, the NE agent may have scheduled topology changes; e.g. at the begin of busy hour extra links are added or bandwidth of existing link is extended, and at the end of busy hour the reverse is happening. > > If my understanding is correct and we want to implement an automated TN a sort > of UNI has to be put between the NE at layer N and the TE at layer N-1. UNI or E-NNI. > > Maybe this will create some problems, on the other hand, as Maarten pointed out, > flat networks won't work due the huge amount of routing information that they > have to carry. > > Regards > > Diego > > Maarten Vissers on 11/06/2001 13.16.52 > > > > > > > > To: Susumu Yoneda > > cc: v.sharma@ieee.org, Jimmy Gendron > , ccamp@ops.ietf.org(bcc: > Diego Caviglia/MAIN/MC1) > > > > Subject: Re: GMPLS Sonet extensions > > > Sharma, > > "flat" set up is the route to disaster... simply consider a switched > transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, > VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, > MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment > would get information of all these levels... an absolute disaster in a > world wide switched transport network would be the result. > > Therefore, there is this layering in which a server layer network > provides bandwidth to its client layer entworks. the client layer > networks see this bandwidth as kind of "fixed" bandwidth over which they > can route their signals. > > A separate entity (I called it "network engineering") is looking over > the shoulder of the call setup process to see if more bandwidth is > needed and when it would be needed or not longer required. But today, > this separate entity is not part of the control plane; it is in the > management plane. > > Regards, > > Maarten > > Susumu Yoneda wrote: > > > > Sharma, > > > > Thank you for letting me know your presentation material which looks very > > interesting. It seems to me that a layered setup would make a sense. > > However, users may want to have a "flat" setup. Therefore, lower setups > > would not be seen by users? > > > > -----Original Message----- > > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > > Sent: Saturday, June 09, 2001 11:06 AM > > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > > Subject: RE: GMPLS Sonet extensions > > > > Jimmy, Susumu, > > > > Your idea (assuming a peer model) is basically correct. Since all nodes > > have the same view of the network, you could compute an ERO at the > > ingress router and have the PATH message follow the hop-by-hop route > > to the egress router. > > (Note, however, that the PATH message will travel > > on the out-of-band IP control network; therefore, it would be non-associated > > signaling.) > > > > Also, Susumu, if the peer model is in effect, then all messges will, > > in fact, have to be shared by all nodes, since that is precisely what > > the "peer model" implies. > > > > But you do have to be careful about what "LSP" you are requesting, since the > > characteristics of the requested LSP are not interpreted in the same way by > > the > > various pieces of equipment in your figure. (A SONET ADM requires a > > different > > way of defining a circuit than an IP router or an OXC.) > > Therefore, one possibility would be to do a "layered setup", where an LSP > > at the lower layer is setup before the PATH message at the higher layer > > is tunnelled over it or allowed to propagate further. > > > > For example, when the PATH message for the packet > > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > > a corresponding SONET circuit between themselves, and then either tunnel > > the PATH message for the packet LSP over this circuit, or (assuming your > > out-of-band network), at that time, allow the PATH message for the packet > > LSP to propagate to the next MPLS router. (The setting up of the SONET > > channel, likewise, would be a recursive process, with the OXC first setting > > up an optical lightpath between themselves, and tunneling the request to > > set up the SONET channel over it, once that lightpath is setup.) > > > > A more detailed discussion of this subject, with corresponding animations > > and figures, that you may also find helpful is available in a talk I gave at > > MPLSCon'01, and can be found at: > > http://www.mplscon.com/missing_presentations.htm > > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > > > -Vishal > > > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > > [SMTP:yone@japan-telecom.co.jp] > > wrote: > > > Hi, > > > > > > I also assume that there would be an out-of-band signalling network based > > on > > > a suite of GMPLS protocols including LMP. I think there will be issues to > > > address whether all messages will be shared by all nodes, i.e router, > > > SDH/SONET, and OXC or not. This will be a part of security issues. > > > ------------------------------- > > > Susumu Yoneda tel +81 3 5540 8493 > > > Japan Telecom fax +81 3 5540 8485 > > > Information & Communication Labs. > > > e-mail yone@japan-telecom.co.jp > > > ------------------------------- > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > > Of > > > Jimmy Gendron > > > Sent: Friday, June 08, 2001 10:01 PM > > > To: 'ccamp@ops.ietf.org' > > > Subject: GMPLS Sonet extensions > > > > > > > > > Hi, > > > > > > I used to read almost all stuff regarding GMPLS since a week. I understand > > > most of the architecture, but I still have a question since the beginning; > > > as an unified control plane, how do the routing/signaling protocols > > exchange > > > informations on a configuration like this: > > > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > > -------> OXC --------> SONET ADM --------> MPLS Router > > > (Ingress) > > > > > > Its a basic point to point configuration, but it will allow me to > > understand > > > the basic features of GMPLS. If I want to create an MPLS LSP between the > > two > > > MPLS routers, how do the RSVP PATH message is sent to the network? > > (Assuming > > > that we have an out-of-band IP control network running LMP) > > > > > > My guess is that the PATH message will leave the ingress router with a > > PATH > > > message with a calculated ERO. It assumes that the network is in respect > > > with the peer model...everyone have the same routing table and know the > > > actual network topology. So, my PATH message will follow the CSPF (ERO) > > and > > > go to the egress router. Am I right? > > > > > > Best regards, > > > > > > Jimmy Gendron > > > --------------3D38327E2429B1C9D7893F5C 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 --------------3D38327E2429B1C9D7893F5C-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 06:27:11 -0700 Reply-To: From: "Srikanth" To: Cc: Subject: Doubt in mpls-generalized-cr-ldp-03.txt Date: Mon, 11 Jun 2001 18:55:24 +0530 Message-Id: <000f01c0f279$f99aa4c0$3006140a@future.futsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I have a doubt in Explicit Label Control In section 5.1 (Procedures), "........If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label_Set TLV. This Label_Set TLV MUST be included on the corresponding outgoing MAPPING message..........." Topology : LSR X -------------- LSR Y Consider the scenario, LSR X is processing the Label ER-Hop ( LSR X is a part of the ER-Hop preceding the Label ER-Hop in the Hop List ). This label ER-Hop specifies the Label to be assigned by LSR Y ( not in the case of splicing ). To achieve this, LSR X has to construct the Label Set ( with just this label ) and send it to LSR Y. So the MAPPING in section 5.1 should be REQUEST. Please correct if i am wrong. Thanks in advance, Srikanth Narayanan. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 05:59:08 -0700 From: "Diego Caviglia" To: Maarten Vissers cc: Susumu Yoneda , v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <80256A68.0044FA7E.00@marconicomms.com> Date: Mon, 11 Jun 2001 14:29:26 +0200 Subject: Re: GMPLS Sonet extensions Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM" Content-Disposition: inline --0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM Content-type: text/plain; charset=us-ascii Content-Disposition: inline Maarten, I agree in principle with you but this means it would be necessary to have a routing protocol for each layer doesn't it? One of the initial reasons for (G)MPLS is to unify the control plane, your layered view of the network implies again the separation of the control planes. The Transport Network is very different from a flat IP network and layering in TN is implicit. If I understood your model correctly the MPLS Router only views, Access Groups and links to other MPLS Routers. If there are free resources between the two routers the TE process calculates, accordingly to some rules, the best path. If there are no resources a call to the Network Engineering agent is performed, the NE makes a call to the TE of the SONET layer in order to provide a trail to the MPLS layer (this procedure is repeated until available resources are created for the MPLS router connection). This trail modifies the topology at the MPLS layer. If my understanding is correct and we want to implement an automated TN a sort of UNI has to be put between the NE at layer N and the TE at layer N-1. Maybe this will create some problems, on the other hand, as Maarten pointed out, flat networks won't work due the huge amount of routing information that they have to carry. Regards Diego Maarten Vissers on 11/06/2001 13.16.52 To: Susumu Yoneda cc: v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org(bcc: Diego Caviglia/MAIN/MC1) Subject: Re: GMPLS Sonet extensions Sharma, "flat" set up is the route to disaster... simply consider a switched transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment would get information of all these levels... an absolute disaster in a world wide switched transport network would be the result. Therefore, there is this layering in which a server layer network provides bandwidth to its client layer entworks. the client layer networks see this bandwidth as kind of "fixed" bandwidth over which they can route their signals. A separate entity (I called it "network engineering") is looking over the shoulder of the call setup process to see if more bandwidth is needed and when it would be needed or not longer required. But today, this separate entity is not part of the control plane; it is in the management plane. Regards, Maarten Susumu Yoneda wrote: > > Sharma, > > Thank you for letting me know your presentation material which looks very > interesting. It seems to me that a layered setup would make a sense. > However, users may want to have a "flat" setup. Therefore, lower setups > would not be seen by users? > > -----Original Message----- > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > Sent: Saturday, June 09, 2001 11:06 AM > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > Subject: RE: GMPLS Sonet extensions > > Jimmy, Susumu, > > Your idea (assuming a peer model) is basically correct. Since all nodes > have the same view of the network, you could compute an ERO at the > ingress router and have the PATH message follow the hop-by-hop route > to the egress router. > (Note, however, that the PATH message will travel > on the out-of-band IP control network; therefore, it would be non-associated > signaling.) > > Also, Susumu, if the peer model is in effect, then all messges will, > in fact, have to be shared by all nodes, since that is precisely what > the "peer model" implies. > > But you do have to be careful about what "LSP" you are requesting, since the > characteristics of the requested LSP are not interpreted in the same way by > the > various pieces of equipment in your figure. (A SONET ADM requires a > different > way of defining a circuit than an IP router or an OXC.) > Therefore, one possibility would be to do a "layered setup", where an LSP > at the lower layer is setup before the PATH message at the higher layer > is tunnelled over it or allowed to propagate further. > > For example, when the PATH message for the packet > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > a corresponding SONET circuit between themselves, and then either tunnel > the PATH message for the packet LSP over this circuit, or (assuming your > out-of-band network), at that time, allow the PATH message for the packet > LSP to propagate to the next MPLS router. (The setting up of the SONET > channel, likewise, would be a recursive process, with the OXC first setting > up an optical lightpath between themselves, and tunneling the request to > set up the SONET channel over it, once that lightpath is setup.) > > A more detailed discussion of this subject, with corresponding animations > and figures, that you may also find helpful is available in a talk I gave at > MPLSCon'01, and can be found at: > http://www.mplscon.com/missing_presentations.htm > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > -Vishal > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > [SMTP:yone@japan-telecom.co.jp] > wrote: > > Hi, > > > > I also assume that there would be an out-of-band signalling network based > on > > a suite of GMPLS protocols including LMP. I think there will be issues to > > address whether all messages will be shared by all nodes, i.e router, > > SDH/SONET, and OXC or not. This will be a part of security issues. > > ------------------------------- > > Susumu Yoneda tel +81 3 5540 8493 > > Japan Telecom fax +81 3 5540 8485 > > Information & Communication Labs. > > e-mail yone@japan-telecom.co.jp > > ------------------------------- > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > Of > > Jimmy Gendron > > Sent: Friday, June 08, 2001 10:01 PM > > To: 'ccamp@ops.ietf.org' > > Subject: GMPLS Sonet extensions > > > > > > Hi, > > > > I used to read almost all stuff regarding GMPLS since a week. I understand > > most of the architecture, but I still have a question since the beginning; > > as an unified control plane, how do the routing/signaling protocols > exchange > > informations on a configuration like this: > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > -------> OXC --------> SONET ADM --------> MPLS Router > > (Ingress) > > > > Its a basic point to point configuration, but it will allow me to > understand > > the basic features of GMPLS. If I want to create an MPLS LSP between the > two > > MPLS routers, how do the RSVP PATH message is sent to the network? > (Assuming > > that we have an out-of-band IP control network running LMP) > > > > My guess is that the PATH message will leave the ingress router with a > PATH > > message with a calculated ERO. It assumes that the network is in respect > > with the peer model...everyone have the same routing table and know the > > actual network topology. So, my PATH message will follow the CSPF (ERO) > and > > go to the egress router. Am I right? > > > > Best regards, > > > > Jimmy Gendron > > --0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM Content-type: application/octet-stream; name="mvissers.vcf" Content-Disposition: attachment; filename="mvissers.vcf" Content-transfer-encoding: base64 YmVnaW46dmNhcmQgDQpuOlZpc3NlcnM7TWFhcnRlbg0KdGVsO2NlbGw6KzMxIDYyIDA2MSAzOTQ1 DQp0ZWw7ZmF4OiszMSAzNSA2ODcgNTk3Ng0KdGVsO2hvbWU6KzMxIDM1IDUyNiA1NDYzDQp0ZWw7 d29yazorMzEgMzUgNjg3IDQyNzANCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6T3B0aWNhbCBO ZXR3b3JrIEdyb3VwO0x1Y2VudCBUZWNobm9sb2dpZXMgTmVkZXJsYW5kDQp2ZXJzaW9uOjIuMQ0K ZW1haWw7aW50ZXJuZXQ6bXZpc3NlcnNAbHVjZW50LmNvbQ0KdGl0bGU6Q29uc3VsdGluZyBNZW1i ZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQphZHI7cXVvdGVkLXByaW50YWJsZTo7O0JvdHRlcnN0cmFh dCA0NT0wRD0wQT0wRD0wQTsxMjcxIFhMIEh1aXplbjs7O1RoZSBOZXRoZXJsYW5kcw0KZm46TWFh cnRlbiBWaXNzZXJzDQplbmQ6dmNhcmQNCg0K --0__=sAcgXvvsCnuX58kO502vNOpFZsLuEJZRhjDCpQCBas0TbOMY1LeC0VBM-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 04:17:21 -0700 Cc: v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Message-ID: <3B24A8A4.54F68342@lucent.com> Date: Mon, 11 Jun 2001 13:16:52 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Susumu Yoneda Original-CC: v.sharma@ieee.org, Jimmy Gendron , ccamp@ops.ietf.org Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------2ECF57E1524E9CA8E27A523F" This is a multi-part message in MIME format. --------------2ECF57E1524E9CA8E27A523F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sharma, "flat" set up is the route to disaster... simply consider a switched transport network with switching levels at VT1.5, VC-12, VC-3/STS-1, VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0, MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment would get information of all these levels... an absolute disaster in a world wide switched transport network would be the result. Therefore, there is this layering in which a server layer network provides bandwidth to its client layer entworks. the client layer networks see this bandwidth as kind of "fixed" bandwidth over which they can route their signals. A separate entity (I called it "network engineering") is looking over the shoulder of the call setup process to see if more bandwidth is needed and when it would be needed or not longer required. But today, this separate entity is not part of the control plane; it is in the management plane. Regards, Maarten Susumu Yoneda wrote: > > Sharma, > > Thank you for letting me know your presentation material which looks very > interesting. It seems to me that a layered setup would make a sense. > However, users may want to have a "flat" setup. Therefore, lower setups > would not be seen by users? > > -----Original Message----- > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > Sent: Saturday, June 09, 2001 11:06 AM > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > Subject: RE: GMPLS Sonet extensions > > Jimmy, Susumu, > > Your idea (assuming a peer model) is basically correct. Since all nodes > have the same view of the network, you could compute an ERO at the > ingress router and have the PATH message follow the hop-by-hop route > to the egress router. > (Note, however, that the PATH message will travel > on the out-of-band IP control network; therefore, it would be non-associated > signaling.) > > Also, Susumu, if the peer model is in effect, then all messges will, > in fact, have to be shared by all nodes, since that is precisely what > the "peer model" implies. > > But you do have to be careful about what "LSP" you are requesting, since the > characteristics of the requested LSP are not interpreted in the same way by > the > various pieces of equipment in your figure. (A SONET ADM requires a > different > way of defining a circuit than an IP router or an OXC.) > Therefore, one possibility would be to do a "layered setup", where an LSP > at the lower layer is setup before the PATH message at the higher layer > is tunnelled over it or allowed to propagate further. > > For example, when the PATH message for the packet > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > a corresponding SONET circuit between themselves, and then either tunnel > the PATH message for the packet LSP over this circuit, or (assuming your > out-of-band network), at that time, allow the PATH message for the packet > LSP to propagate to the next MPLS router. (The setting up of the SONET > channel, likewise, would be a recursive process, with the OXC first setting > up an optical lightpath between themselves, and tunneling the request to > set up the SONET channel over it, once that lightpath is setup.) > > A more detailed discussion of this subject, with corresponding animations > and figures, that you may also find helpful is available in a talk I gave at > MPLSCon'01, and can be found at: > http://www.mplscon.com/missing_presentations.htm > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > -Vishal > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > [SMTP:yone@japan-telecom.co.jp] > wrote: > > Hi, > > > > I also assume that there would be an out-of-band signalling network based > on > > a suite of GMPLS protocols including LMP. I think there will be issues to > > address whether all messages will be shared by all nodes, i.e router, > > SDH/SONET, and OXC or not. This will be a part of security issues. > > ------------------------------- > > Susumu Yoneda tel +81 3 5540 8493 > > Japan Telecom fax +81 3 5540 8485 > > Information & Communication Labs. > > e-mail yone@japan-telecom.co.jp > > ------------------------------- > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > Of > > Jimmy Gendron > > Sent: Friday, June 08, 2001 10:01 PM > > To: 'ccamp@ops.ietf.org' > > Subject: GMPLS Sonet extensions > > > > > > Hi, > > > > I used to read almost all stuff regarding GMPLS since a week. I understand > > most of the architecture, but I still have a question since the beginning; > > as an unified control plane, how do the routing/signaling protocols > exchange > > informations on a configuration like this: > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > -------> OXC --------> SONET ADM --------> MPLS Router > > (Ingress) > > > > Its a basic point to point configuration, but it will allow me to > understand > > the basic features of GMPLS. If I want to create an MPLS LSP between the > two > > MPLS routers, how do the RSVP PATH message is sent to the network? > (Assuming > > that we have an out-of-band IP control network running LMP) > > > > My guess is that the PATH message will leave the ingress router with a > PATH > > message with a calculated ERO. It assumes that the network is in respect > > with the peer model...everyone have the same routing table and know the > > actual network topology. So, my PATH message will follow the CSPF (ERO) > and > > go to the egress router. Am I right? > > > > Best regards, > > > > Jimmy Gendron > > --------------2ECF57E1524E9CA8E27A523F 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 --------------2ECF57E1524E9CA8E27A523F-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 11 Jun 2001 04:11:32 -0700 Cc: "'v.sharma@ieee.org'" , "'ccamp@ops.ietf.org'" Message-ID: <3B24A6FA.20CB6225@lucent.com> Date: Mon, 11 Jun 2001 13:09:46 +0200 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Jimmy Gendron Original-CC: "'v.sharma@ieee.org'" , "'ccamp@ops.ietf.org'" Subject: Re: GMPLS Sonet extensions Content-Type: multipart/mixed; boundary="------------D446BB46687226DBF93CB3F6" This is a multi-part message in MIME format. --------------D446BB46687226DBF93CB3F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jimmy, Connection set-up is performed on a per layer network basis. For its purpose of setting up a connection, the layer network uses available bandwidth to that layer network. For the case a protected connection is to be set up, it is important to know at what level the protection is required. I.e. this layer network or a server layer network. If it is the former, the layer network has to create two unprotected connections starting/ending at bridge/selector functions; e.g. a 1+1 SNC protected VC-4 connection would be dealt with this way within the HOVC layer entwork. However, if it is the latter (server layer network contains protection), the layer network which sets up the connection doesn't care at all about protection; e.g. case of a VC-4 connection running over a 1+1 MS protected line or over a MS SPring protected ring - the HOVC layer entwork doesn't care about the protection. Regards, Maarten Jimmy Gendron wrote: > > Vishal, > > thank you for the details. How the protection type is managed? Is it the > SONET LSP that set up an optical LSP with, for example, 1+1 protection? > Which entity is responsible to deal with protection at first when we try to > set up an MPLS LSP with 1+1 prot through SONET? > > Thank you, > > Jimmy > > -----Original Message----- > From: Vishal Sharma [mailto:vsharma87@yahoo.com] > Sent: Friday, June 08, 2001 10:06 PM > To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org > Subject: RE: GMPLS Sonet extensions > > Jimmy, Susumu, > > Your idea (assuming a peer model) is basically correct. Since all nodes > have the same view of the network, you could compute an ERO at the > ingress router and have the PATH message follow the hop-by-hop route > to the egress router. > (Note, however, that the PATH message will travel > on the out-of-band IP control network; therefore, it would be non-associated > > signaling.) > > Also, Susumu, if the peer model is in effect, then all messges will, > in fact, have to be shared by all nodes, since that is precisely what > the "peer model" implies. > > But you do have to be careful about what "LSP" you are requesting, since the > characteristics of the requested LSP are not interpreted in the same way by > the > various pieces of equipment in your figure. (A SONET ADM requires a > different > way of defining a circuit than an IP router or an OXC.) > Therefore, one possibility would be to do a "layered setup", where an LSP > at the lower layer is setup before the PATH message at the higher layer > is tunnelled over it or allowed to propagate further. > > For example, when the PATH message for the packet > LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup > a corresponding SONET circuit between themselves, and then either tunnel > the PATH message for the packet LSP over this circuit, or (assuming your > out-of-band network), at that time, allow the PATH message for the packet > LSP to propagate to the next MPLS router. (The setting up of the SONET > channel, likewise, would be a recursive process, with the OXC first setting > up an optical lightpath between themselves, and tunneling the request to > set up the SONET channel over it, once that lightpath is setup.) > > A more detailed discussion of this subject, with corresponding animations > and figures, that you may also find helpful is available in a talk I gave at > MPLSCon'01, and can be found at: > http://www.mplscon.com/missing_presentations.htm > (Dynamic path establishment in MPLS-controlled multi-service networks.) > > -Vishal > > On Friday, June 08, 2001 6:00 PM, Susumu Yoneda > [SMTP:yone@japan-telecom.co.jp] > wrote: > > Hi, > > > > I also assume that there would be an out-of-band signalling network based > on > > a suite of GMPLS protocols including LMP. I think there will be issues to > > address whether all messages will be shared by all nodes, i.e router, > > SDH/SONET, and OXC or not. This will be a part of security issues. > > ------------------------------- > > Susumu Yoneda tel +81 3 5540 8493 > > Japan Telecom fax +81 3 5540 8485 > > Information & Communication Labs. > > e-mail yone@japan-telecom.co.jp > > ------------------------------- > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf > Of > > Jimmy Gendron > > Sent: Friday, June 08, 2001 10:01 PM > > To: 'ccamp@ops.ietf.org' > > Subject: GMPLS Sonet extensions > > > > > > Hi, > > > > I used to read almost all stuff regarding GMPLS since a week. I understand > > most of the architecture, but I still have a question since the beginning; > > as an unified control plane, how do the routing/signaling protocols > exchange > > informations on a configuration like this: > > > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > > -------> OXC --------> SONET ADM --------> MPLS Router > > (Ingress) > > > > Its a basic point to point configuration, but it will allow me to > understand > > the basic features of GMPLS. If I want to create an MPLS LSP between the > two > > MPLS routers, how do the RSVP PATH message is sent to the network? > (Assuming > > that we have an out-of-band IP control network running LMP) > > > > My guess is that the PATH message will leave the ingress router with a > PATH > > message with a calculated ERO. It assumes that the network is in respect > > with the peer model...everyone have the same routing table and know the > > actual network topology. So, my PATH message will follow the CSPF (ERO) > and > > go to the egress router. Am I right? > > > > Best regards, > > > > Jimmy Gendron > > --------------D446BB46687226DBF93CB3F6 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 --------------D446BB46687226DBF93CB3F6-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 09 Jun 2001 17:29:57 -0700 From: "Susumu Yoneda" To: , "Jimmy Gendron" , Subject: RE: GMPLS Sonet extensions Date: Sun, 10 Jun 2001 09:34:01 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sharma, Thank you for letting me know your presentation material which looks very interesting. It seems to me that a layered setup would make a sense. However, users may want to have a "flat" setup. Therefore, lower setups would not be seen by users? -----Original Message----- From: Vishal Sharma [mailto:vsharma87@yahoo.com] Sent: Saturday, June 09, 2001 11:06 AM To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Jimmy, Susumu, Your idea (assuming a peer model) is basically correct. Since all nodes have the same view of the network, you could compute an ERO at the ingress router and have the PATH message follow the hop-by-hop route to the egress router. (Note, however, that the PATH message will travel on the out-of-band IP control network; therefore, it would be non-associated signaling.) Also, Susumu, if the peer model is in effect, then all messges will, in fact, have to be shared by all nodes, since that is precisely what the "peer model" implies. But you do have to be careful about what "LSP" you are requesting, since the characteristics of the requested LSP are not interpreted in the same way by the various pieces of equipment in your figure. (A SONET ADM requires a different way of defining a circuit than an IP router or an OXC.) Therefore, one possibility would be to do a "layered setup", where an LSP at the lower layer is setup before the PATH message at the higher layer is tunnelled over it or allowed to propagate further. For example, when the PATH message for the packet LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup a corresponding SONET circuit between themselves, and then either tunnel the PATH message for the packet LSP over this circuit, or (assuming your out-of-band network), at that time, allow the PATH message for the packet LSP to propagate to the next MPLS router. (The setting up of the SONET channel, likewise, would be a recursive process, with the OXC first setting up an optical lightpath between themselves, and tunneling the request to set up the SONET channel over it, once that lightpath is setup.) A more detailed discussion of this subject, with corresponding animations and figures, that you may also find helpful is available in a talk I gave at MPLSCon'01, and can be found at: http://www.mplscon.com/missing_presentations.htm (Dynamic path establishment in MPLS-controlled multi-service networks.) -Vishal On Friday, June 08, 2001 6:00 PM, Susumu Yoneda [SMTP:yone@japan-telecom.co.jp] wrote: > Hi, > > I also assume that there would be an out-of-band signalling network based on > a suite of GMPLS protocols including LMP. I think there will be issues to > address whether all messages will be shared by all nodes, i.e router, > SDH/SONET, and OXC or not. This will be a part of security issues. > ------------------------------- > Susumu Yoneda tel +81 3 5540 8493 > Japan Telecom fax +81 3 5540 8485 > Information & Communication Labs. > e-mail yone@japan-telecom.co.jp > ------------------------------- > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > Jimmy Gendron > Sent: Friday, June 08, 2001 10:01 PM > To: 'ccamp@ops.ietf.org' > Subject: GMPLS Sonet extensions > > > Hi, > > I used to read almost all stuff regarding GMPLS since a week. I understand > most of the architecture, but I still have a question since the beginning; > as an unified control plane, how do the routing/signaling protocols exchange > informations on a configuration like this: > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > -------> OXC --------> SONET ADM --------> MPLS Router > (Ingress) > > Its a basic point to point configuration, but it will allow me to understand > the basic features of GMPLS. If I want to create an MPLS LSP between the two > MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming > that we have an out-of-band IP control network running LMP) > > My guess is that the PATH message will leave the ingress router with a PATH > message with a calculated ERO. It assumes that the network is in respect > with the peer model...everyone have the same routing table and know the > actual network topology. So, my PATH message will follow the CSPF (ERO) and > go to the egress router. Am I right? > > Best regards, > > Jimmy Gendron > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 09 Jun 2001 14:12:10 -0700 From: "Raju Venkatraman" To: ccamp@ops.ietf.org Bcc: Subject: GMPLS Questions, Doubts Date: Sat, 09 Jun 2001 21:09:39 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, I was just going through GMPLS drafts and I've some questions. Actually not able to understand few things. Any help would be greatly appreciated. * Should the signalling module (control plane) be aware of all the data channels/links under its control? In GMPLS, as it would be used in optical networks and a no. of interfaces would be present [not all carrying the signalling information] between GMPLS-enabled optical nodes, I don't feel it's required. The association of signalling link/channel(s) to data links/channels could be mainatained outside the sigannling module. * Where one would like to maintain the diffserv related intelligence while setting up L-LSP and E-LSPs - would it would be assumed to be with routing module or signalling module? I know, these things vary from implementation to implmentation, but just wanted to hear your thoughts in this regard. Thanks in advance. Raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 09 Jun 2001 07:57:36 -0700 Message-ID: From: Jimmy Gendron To: "'v.sharma@ieee.org'" , "'ccamp@ops.ietf.org'" Subject: RE: GMPLS Sonet extensions Date: Sat, 9 Jun 2001 10:49:47 -0400 MIME-Version: 1.0 Content-Type: text/plain Vishal, thank you for the details. How the protection type is managed? Is it the SONET LSP that set up an optical LSP with, for example, 1+1 protection? Which entity is responsible to deal with protection at first when we try to set up an MPLS LSP with 1+1 prot through SONET? Thank you, Jimmy -----Original Message----- From: Vishal Sharma [mailto:vsharma87@yahoo.com] Sent: Friday, June 08, 2001 10:06 PM To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org Subject: RE: GMPLS Sonet extensions Jimmy, Susumu, Your idea (assuming a peer model) is basically correct. Since all nodes have the same view of the network, you could compute an ERO at the ingress router and have the PATH message follow the hop-by-hop route to the egress router. (Note, however, that the PATH message will travel on the out-of-band IP control network; therefore, it would be non-associated signaling.) Also, Susumu, if the peer model is in effect, then all messges will, in fact, have to be shared by all nodes, since that is precisely what the "peer model" implies. But you do have to be careful about what "LSP" you are requesting, since the characteristics of the requested LSP are not interpreted in the same way by the various pieces of equipment in your figure. (A SONET ADM requires a different way of defining a circuit than an IP router or an OXC.) Therefore, one possibility would be to do a "layered setup", where an LSP at the lower layer is setup before the PATH message at the higher layer is tunnelled over it or allowed to propagate further. For example, when the PATH message for the packet LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup a corresponding SONET circuit between themselves, and then either tunnel the PATH message for the packet LSP over this circuit, or (assuming your out-of-band network), at that time, allow the PATH message for the packet LSP to propagate to the next MPLS router. (The setting up of the SONET channel, likewise, would be a recursive process, with the OXC first setting up an optical lightpath between themselves, and tunneling the request to set up the SONET channel over it, once that lightpath is setup.) A more detailed discussion of this subject, with corresponding animations and figures, that you may also find helpful is available in a talk I gave at MPLSCon'01, and can be found at: http://www.mplscon.com/missing_presentations.htm (Dynamic path establishment in MPLS-controlled multi-service networks.) -Vishal On Friday, June 08, 2001 6:00 PM, Susumu Yoneda [SMTP:yone@japan-telecom.co.jp] wrote: > Hi, > > I also assume that there would be an out-of-band signalling network based on > a suite of GMPLS protocols including LMP. I think there will be issues to > address whether all messages will be shared by all nodes, i.e router, > SDH/SONET, and OXC or not. This will be a part of security issues. > ------------------------------- > Susumu Yoneda tel +81 3 5540 8493 > Japan Telecom fax +81 3 5540 8485 > Information & Communication Labs. > e-mail yone@japan-telecom.co.jp > ------------------------------- > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > Jimmy Gendron > Sent: Friday, June 08, 2001 10:01 PM > To: 'ccamp@ops.ietf.org' > Subject: GMPLS Sonet extensions > > > Hi, > > I used to read almost all stuff regarding GMPLS since a week. I understand > most of the architecture, but I still have a question since the beginning; > as an unified control plane, how do the routing/signaling protocols exchange > informations on a configuration like this: > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > -------> OXC --------> SONET ADM --------> MPLS Router > (Ingress) > > Its a basic point to point configuration, but it will allow me to understand > the basic features of GMPLS. If I want to create an MPLS LSP between the two > MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming > that we have an out-of-band IP control network running LMP) > > My guess is that the PATH message will leave the ingress router with a PATH > message with a calculated ERO. It assumes that the network is in respect > with the peer model...everyone have the same routing table and know the > actual network topology. So, my PATH message will follow the CSPF (ERO) and > go to the egress router. Am I right? > > Best regards, > > Jimmy Gendron > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Jun 2001 19:07:34 -0700 Message-ID: <01C0F04E.0640CFC0.vsharma87@yahoo.com> From: Vishal Sharma Reply-To: "v.sharma@ieee.org" To: "'Susumu Yoneda'" , Jimmy Gendron , "ccamp@ops.ietf.org" Subject: RE: GMPLS Sonet extensions Date: Fri, 8 Jun 2001 19:05:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jimmy, Susumu, Your idea (assuming a peer model) is basically correct. Since all nodes have the same view of the network, you could compute an ERO at the ingress router and have the PATH message follow the hop-by-hop route to the egress router. (Note, however, that the PATH message will travel on the out-of-band IP control network; therefore, it would be non-associated signaling.) Also, Susumu, if the peer model is in effect, then all messges will, in fact, have to be shared by all nodes, since that is precisely what the "peer model" implies. But you do have to be careful about what "LSP" you are requesting, since the characteristics of the requested LSP are not interpreted in the same way by the various pieces of equipment in your figure. (A SONET ADM requires a different way of defining a circuit than an IP router or an OXC.) Therefore, one possibility would be to do a "layered setup", where an LSP at the lower layer is setup before the PATH message at the higher layer is tunnelled over it or allowed to propagate further. For example, when the PATH message for the packet LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup a corresponding SONET circuit between themselves, and then either tunnel the PATH message for the packet LSP over this circuit, or (assuming your out-of-band network), at that time, allow the PATH message for the packet LSP to propagate to the next MPLS router. (The setting up of the SONET channel, likewise, would be a recursive process, with the OXC first setting up an optical lightpath between themselves, and tunneling the request to set up the SONET channel over it, once that lightpath is setup.) A more detailed discussion of this subject, with corresponding animations and figures, that you may also find helpful is available in a talk I gave at MPLSCon'01, and can be found at: http://www.mplscon.com/missing_presentations.htm (Dynamic path establishment in MPLS-controlled multi-service networks.) -Vishal On Friday, June 08, 2001 6:00 PM, Susumu Yoneda [SMTP:yone@japan-telecom.co.jp] wrote: > Hi, > > I also assume that there would be an out-of-band signalling network based on > a suite of GMPLS protocols including LMP. I think there will be issues to > address whether all messages will be shared by all nodes, i.e router, > SDH/SONET, and OXC or not. This will be a part of security issues. > ------------------------------- > Susumu Yoneda tel +81 3 5540 8493 > Japan Telecom fax +81 3 5540 8485 > Information & Communication Labs. > e-mail yone@japan-telecom.co.jp > ------------------------------- > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > Jimmy Gendron > Sent: Friday, June 08, 2001 10:01 PM > To: 'ccamp@ops.ietf.org' > Subject: GMPLS Sonet extensions > > > Hi, > > I used to read almost all stuff regarding GMPLS since a week. I understand > most of the architecture, but I still have a question since the beginning; > as an unified control plane, how do the routing/signaling protocols exchange > informations on a configuration like this: > > MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM > -------> OXC --------> SONET ADM --------> MPLS Router > (Ingress) > > Its a basic point to point configuration, but it will allow me to understand > the basic features of GMPLS. If I want to create an MPLS LSP between the two > MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming > that we have an out-of-band IP control network running LMP) > > My guess is that the PATH message will leave the ingress router with a PATH > message with a calculated ERO. It assumes that the network is in respect > with the peer model...everyone have the same routing table and know the > actual network topology. So, my PATH message will follow the CSPF (ERO) and > go to the egress router. Am I right? > > Best regards, > > Jimmy Gendron > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Jun 2001 17:56:17 -0700 From: "Susumu Yoneda" To: "Jimmy Gendron" , Subject: RE: GMPLS Sonet extensions Date: Sat, 9 Jun 2001 10:00:13 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I also assume that there would be an out-of-band signalling network based on a suite of GMPLS protocols including LMP. I think there will be issues to address whether all messages will be shared by all nodes, i.e router, SDH/SONET, and OXC or not. This will be a part of security issues. ------------------------------- Susumu Yoneda tel +81 3 5540 8493 Japan Telecom fax +81 3 5540 8485 Information & Communication Labs. e-mail yone@japan-telecom.co.jp ------------------------------- -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Jimmy Gendron Sent: Friday, June 08, 2001 10:01 PM To: 'ccamp@ops.ietf.org' Subject: GMPLS Sonet extensions Hi, I used to read almost all stuff regarding GMPLS since a week. I understand most of the architecture, but I still have a question since the beginning; as an unified control plane, how do the routing/signaling protocols exchange informations on a configuration like this: MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM -------> OXC --------> SONET ADM --------> MPLS Router (Ingress) Its a basic point to point configuration, but it will allow me to understand the basic features of GMPLS. If I want to create an MPLS LSP between the two MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming that we have an out-of-band IP control network running LMP) My guess is that the PATH message will leave the ingress router with a PATH message with a calculated ERO. It assumes that the network is in respect with the peer model...everyone have the same routing table and know the actual network topology. So, my PATH message will follow the CSPF (ERO) and go to the egress router. Am I right? Best regards, Jimmy Gendron Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Jun 2001 10:37:18 -0700 Message-ID: From: Jonathan Lang To: 'Jimmy Gendron' , "'ccamp@ops.ietf.org'" Subject: RE: GMPLS recovery and SRLG Date: Fri, 8 Jun 2001 10:32:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jimmy, Yes. The SRLGs are used to determine disjoint paths and are included in the gmpls routing drafts (draft-kompella-ospf-gmpls-extensions-01.txt and draft-ietf-isis-gmpls-extensions-02.txt). The SRLGs are then used for determining routes for backup LSPs and link protection. Thanks, Jonathan > -----Original Message----- > From: Jimmy Gendron [mailto:jgendron@hyperchip.com] > Sent: Thursday, June 07, 2001 10:46 AM > To: 'ccamp@ops.ietf.org' > Subject: GMPLS recovery and SRLG > > > Hi, > > after reading the draft-lang-ccamp-recovery-oo.txt document > related to GMPLS > protection/recovery mechanisms, I would like to know if the proposed > mechanisms supports the SRLG enhancements as proposed before? > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 08 Jun 2001 06:03:37 -0700 Message-ID: From: Jimmy Gendron To: "'ccamp@ops.ietf.org'" Subject: GMPLS Sonet extensions Date: Fri, 8 Jun 2001 09:01:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I used to read almost all stuff regarding GMPLS since a week. I understand most of the architecture, but I still have a question since the beginning; as an unified control plane, how do the routing/signaling protocols exchange informations on a configuration like this: MPLS Router -----> SONET ADM ------> OXC -----> WDM ----------- WDM -------> OXC --------> SONET ADM --------> MPLS Router (Ingress) Its a basic point to point configuration, but it will allow me to understand the basic features of GMPLS. If I want to create an MPLS LSP between the two MPLS routers, how do the RSVP PATH message is sent to the network? (Assuming that we have an out-of-band IP control network running LMP) My guess is that the PATH message will leave the ingress router with a PATH message with a calculated ERO. It assumes that the network is in respect with the peer model...everyone have the same routing table and know the actual network topology. So, my PATH message will follow the CSPF (ERO) and go to the egress router. Am I right? Best regards, Jimmy Gendron Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Jun 2001 18:11:02 -0700 From: "Tissa Senevirathne" To: bwijnen@lucent.com, ccamp@ops.ietf.org Bcc: Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 .tx Date: Fri, 08 Jun 2001 01:09:44 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: The information were emailed to idsummary tody. In addition the I-D has all the requested information included after "Status of This Memo" Thanks Tissa >From: "Wijnen, Bert (Bert)" >To: ccamp-wg , Tissa Senevirathne > >Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 >.tx >Date: Thu, 7 Jun 2001 02:02:48 +0200 > >New I-Ds that are targeted to a WG should be summaried and such >a summary should be send to the idsummary mailing list (as we >asked all existing I-D authors to do a few weeks ago). > >Bert > > > ---------- > > From: Tissa Senevirathne[SMTP:tsenevir@hotmail.com] > > Sent: Wednesday, June 06, 2001 4:54 AM > > To: ccamp@ops.ietf.org > > Subject: Please could you comment on I-D > > draft-tsenevir-l2vpn-pmesh-00.tx > > > > Below is ID that explain use of partial mesh tunnels to achieve >forwarding > > > > behavior of full mesh tunnels. The discussion in the ID is manily >targeted > > > > towards Layer 2 NBVPN. > > > > The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest > > Path > > Algorithm (Dijkstra) to derive required forwarding tunnels. > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt > > > > Please could you comment > > > > Thanks > > > > Tissa > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Jun 2001 10:48:36 -0700 Message-ID: From: Jimmy Gendron To: "'ccamp@ops.ietf.org'" Subject: GMPLS recovery and SRLG Date: Thu, 7 Jun 2001 13:46:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, after reading the draft-lang-ccamp-recovery-oo.txt document related to GMPLS protection/recovery mechanisms, I would like to know if the proposed mechanisms supports the SRLG enhancements as proposed before? Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Jun 2001 09:36:29 -0700 Message-ID: From: neil.2.harrison@bt.com To: dallan@nortelnetworks.com, yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Thu, 7 Jun 2001 17:34:44 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Hi Dave.....I know exactly what you are saying and its something Andy Reid and I have chewed over once or twice when considering a functional architecture description of MPLS. I was certainly not exhaustive nor precise in my description and definitions....I was more interested in trying to emphasise the 'no free lunch' point that making one aspect simpler usually makes some aspect more complex (normal engineering trade-off). I see 2 basic forms of MPLS LSPs: 1 One that is a close adjunct function of the IGP.....this is LDP LSPs, and LDP is required since one cannot easily distribute labels piggy-backed on a link-state routing protocol like OSPF (though you can with BGP). 2 One that is not a close adjunct function of the IGP, and requires to be signalled....this is RSVP-TE and CR-LDP LSPs. The 'no free lunch' bit here means the former gives an operator more headaches when considering fault-management and the definition of SLAs for VPN services for example, whilst potentially getting some gains in scalability......so that's the trade off I was inferring. Its a bit like the polarised CO vs CNLS transfer mode view of the world.....in reality technologies fall some-way between the 2 pure extremes, and its knowing where the compromises should occur for a given (service) case.....since neither alone can yield an optimum solution for all cases. Indeed, one could say this is exactly why we have/need MPLS to augment IP. Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 07 June 2001 16:37 To: neil.2.harrison@bt.com; yakov@juniper.net; mpls@UU.NET; ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Neil, you wrote - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. I'm not sure the existence of merging or QoS is necessarily a criteria for excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for the purposes of MPLS a layer can exist independently of which subset of topological constructs in the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP infrastructre using integrated routing to me would constitute a useful definition of a "layer". It is only when I ruthlessly exclude absolutely everything but the elemental p2p undirectional trail from the discussion that such a hard definition applies, unfortunatley much of the value statements around MPLS disappear at roughly the same time. cheers Dave Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 07 Jun 2001 08:38:37 -0700 Message-ID: <6DDA62170439D31185750000F80826AC064E683F@zmerd004.ca.nortel.com> From: "David Allan" To: neil.2.harrison@bt.com, yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Thu, 7 Jun 2001 11:36:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF67.A7998520" 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_01C0EF67.A7998520 Content-Type: text/plain; charset="ISO-8859-1" Neil, you wrote - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. I'm not sure the existence of merging or QoS is necessarily a criteria for excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for the purposes of MPLS a layer can exist independently of which subset of topological constructs in the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP infrastructre using integrated routing to me would constitute a useful definition of a "layer". It is only when I ruthlessly exclude absolutely everything but the elemental p2p undirectional trail from the discussion that such a hard definition applies, unfortunatley much of the value statements around MPLS disappear at roughly the same time. cheers Dave ------_=_NextPart_001_01C0EF67.A7998520 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: GMPLS Last Calls

Neil, you wrote

-       LDP induced = LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard = QoS problems....like how
does one define availability in a mpt-pt tree?  = [Its the old issue of 'no
free lunch'...if you push down a problem in 1 = dimension (eg scalability), it
creates a problem somewhere else (eg measuing = availability in VPNs say)];
-       Explicitly = routed LSPs on the other hand do form true layer
networks....since they need to be signalled they = exist as true trail objects
in their own right.

I'm not sure the existence of merging or QoS is = necessarily a criteria for excluding LDP "induced" LSPs as a = layer. Intuitively it strikes me that for the purposes of MPLS a layer = can exist independently of which subset of topological constructs in = the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP = infrastructre using integrated routing to me would constitute a useful = definition of a "layer". It is only when I ruthlessly exclude = absolutely everything but the elemental  p2p undirectional trail = from the discussion that such a hard definition applies, unfortunatley = much of the value statements around MPLS disappear at roughly the same = time.

cheers
Dave

------_=_NextPart_001_01C0EF67.A7998520-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Jun 2001 17:06:36 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C8E0725@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , Tissa Senevirathne Subject: RE: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00 .tx Date: Thu, 7 Jun 2001 02:02:48 +0200 MIME-Version: 1.0 Content-Type: text/plain New I-Ds that are targeted to a WG should be summaried and such a summary should be send to the idsummary mailing list (as we asked all existing I-D authors to do a few weeks ago). Bert > ---------- > From: Tissa Senevirathne[SMTP:tsenevir@hotmail.com] > Sent: Wednesday, June 06, 2001 4:54 AM > To: ccamp@ops.ietf.org > Subject: Please could you comment on I-D > draft-tsenevir-l2vpn-pmesh-00.tx > > Below is ID that explain use of partial mesh tunnels to achieve forwarding > > behavior of full mesh tunnels. The discussion in the ID is manily targeted > > towards Layer 2 NBVPN. > > The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest > Path > Algorithm (Dijkstra) to derive required forwarding tunnels. > > http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt > > Please could you comment > > Thanks > > Tissa > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 06 Jun 2001 06:07:36 -0700 From: Andre Fredette To: ccamp@ops.ietf.org Cc: Martin Dubuc , "'Wijnen, Bert (Bert)'" , "Thomas D. Nadeau" , Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" , George Swallow Message-Id: <5.1.0.14.2.20010606085529.0282abc8@mailbox> Date: Wed, 06 Jun 2001 09:02:29 -0400 Subject: Re: Proposed Addition to CCAMP Charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I second George's statement. Also, as Osama mentioned in a previous note, I will be submitting an I-D on requirements for an interface to WDM transmission systems in the next couple of days. This I-D was co-authored by the LMP-WDM and NTIP co-authors, together with a few other individuals who expressed an interest during the last meeting. Andre At 03:19 PM 6/5/2001 -0400, George Swallow wrote: >Martin - > > > Looking back at the minutes, there seems to have been quite a debate during > > the CCAMP session between LMP and NTIP proponents. I do not know how we > move > > forward though. The debate has not been happening on the mailing list. Even > > though Andre has asked a question to NTIP authors to stir the debate to the > > mailing, no response has come back. Otherwise, I have only seen some > > discussions on LMP-WDM vs. funiculus. > >Don't confuse LMP with LMP-WDM. There is no major controversy over >LMP. The debate was how to add some functionality to extract >information from WDMs. One proposal, LMP-WDM, extends LMP to do >this. NTIP proposes a new protocol. Just because there is a debate >over where this new functionality goes, we shouldn't let that affect >the progress of LMP. > >...George > > >================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 20:46:02 -0700 Date: Tue, 5 Jun 2001 20:44:56 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106060344.UAA21560@kummer.juniper.net> To: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com Subject: RE: GMPLS Last Calls Hi Don, > I have followed this thread and think that there is something more > fundamental going on here. The last call for RFC is a milestone for > any draft. The issue is that GMPLS is so large the only way we can > tackle it is to have interim RFCs that begin to point the way to > solving the problem. Actually, GMPLS has been broken up: there are now 3 major sets of docs: the "base" GMPLS docs, GMPLS for SONET/SDH, and the upcoming GMPLS doc for G.709 networks. The base GMPLS docs are in pretty good shape; most of the issues (some would say pseudo-issues) being raised are for the SONET/SDH doc. BTW, another important factor is that the number of folks (from both carriers and vendors) that are interested in GMPLS is very high; CCAMP and IPO have become magnets much the way MPLS was over the past four years (and still is). While this is in general great news, the number of divergent opinions, alternative drafts and proposals, and issues raised has skyrocketed, as well as, sad to say, the degree of, how should I put it, "highly charged non-technical discussion". This means that progress will of necessity be slower, but hopefully, it also means that GMPLS will be more wide-ranging, and meet a broader range of carrier needs. Perhaps this increased number of participants is the "something more fundamental" that's going on. I'll leave it to the IESG to figure it out, and if needed, propose remedies for the "growing pains" which seem concommitant with success. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 19:55:14 -0700 From: "Tissa Senevirathne" To: ccamp@ops.ietf.org Bcc: Subject: Please could you comment on I-D draft-tsenevir-l2vpn-pmesh-00.tx Date: Wed, 06 Jun 2001 02:54:15 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Below is ID that explain use of partial mesh tunnels to achieve forwarding behavior of full mesh tunnels. The discussion in the ID is manily targeted towards Layer 2 NBVPN. The ID discuss use of a Minimum Spanning Tree algorithm and a Shortest Path Algorithm (Dijkstra) to derive required forwarding tunnels. http://search.ietf.org/internet-drafts/draft-tsenevir-l2vpn-pmesh-00.txt Please could you comment Thanks Tissa _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 17:15:39 -0700 Message-ID: From: "Don Fedyk" To: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, kireeti@juniper.net Subject: RE: GMPLS Last Calls Date: Tue, 5 Jun 2001 20:13:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EE1D.8E124C40" 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_01C0EE1D.8E124C40 Content-Type: text/plain; charset="ISO-8859-1" Ananth, Kireeti I have followed this thread and think that there is something more fundamental going on here. The last call for RFC is a milestone for any draft. The issue is that GMPLS is so large the only way we can tackle it is to have interim RFCs that begin to point the way to solving the problem. I don't view them as all encompassing specifications just a step in the right direction towards common mechanisms. One thing that I would have hoped we would achieve with GMPLS was a forward looking architecture that could be extended. The immediate question we must answer is: Have we provided this? The longer term question is: Will we follow through and cover the other aspects? When will the set of GMPLS RFCs become complete? For that we have to stay tuned. Don ------_=_NextPart_001_01C0EE1D.8E124C40 Content-Type: text/html; charset="ISO-8859-1" RE: GMPLS Last Calls

Ananth, Kireeti

I have followed this thread and think that there is something more
fundamental going on here. The last call for RFC is a milestone for
any draft. The issue is that GMPLS is so large the only way we can
tackle it is to have interim RFCs that begin to point the way to
solving the problem. I don't view them as all encompassing
specifications just a step in the right direction towards common
mechanisms.

One thing that I would have hoped we would achieve with GMPLS was a
forward looking architecture that could be extended. The immediate
question we must answer is: Have we provided this?

The longer term question is:
Will we follow through and cover the other aspects? When will the
set of GMPLS RFCs become complete? For that we have to stay tuned.

Don

------_=_NextPart_001_01C0EE1D.8E124C40-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 12:22:21 -0700 Message-Id: <200106051919.PAA06897@telescope.cisco.com> To: Martin Dubuc cc: "'Wijnen, Bert (Bert)'" , ccamp-wg , "Thomas D. Nadeau" , Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" , swallow@cisco.com Subject: Re: Proposed Addition to CCAMP Charter Date: Tue, 05 Jun 2001 15:19:42 -0400 From: George Swallow Martin - > Looking back at the minutes, there seems to have been quite a debate during > the CCAMP session between LMP and NTIP proponents. I do not know how we move > forward though. The debate has not been happening on the mailing list. Even > though Andre has asked a question to NTIP authors to stir the debate to the > mailing, no response has come back. Otherwise, I have only seen some > discussions on LMP-WDM vs. funiculus. Don't confuse LMP with LMP-WDM. There is no major controversy over LMP. The debate was how to add some functionality to extract information from WDMs. One proposal, LMP-WDM, extends LMP to do this. NTIP proposes a new protocol. Just because there is a debate over where this new functionality goes, we shouldn't let that affect the progress of LMP. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 12:18:27 -0700 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F040807E8@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: Martin Dubuc , "'Wijnen, Bert (Bert)'" , ccamp-wg , "Thomas D. Nadeau" Cc: Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 15:15:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EDF3.D7609200" 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_01C0EDF3.D7609200 Content-Type: text/plain; charset="ISO-8859-1" A few clarifications are due. First the debate is between NTIP and LMP-WDM. The debate is NOT between NTIP and LMP. Secondly, people interested in the subject have agreed on a set of requirements for that interface. The requirements have been presented at the last OIF, and are being discussed at an ITU meeting this week. I think Andre have already submitted a draft to IETF on those requirements (or he is in the process of doing so). What I don't understand is why NTIP and LMP-WDM debate has been brought into this discussion? It seems to me that this discussion is related to setting WG charter, and to what extent certain items fit or don't fit into a charter, or IETF in general. It is a wider discussion than just a debate between two proposals. Regards; Osama. -----Original Message----- From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com] Sent: Tuesday, June 05, 2001 2:47 PM To: 'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail) Subject: RE: Proposed Addition to CCAMP Charter Bert, Looking back at the minutes, there seems to have been quite a debate during the CCAMP session between LMP and NTIP proponents. I do not know how we move forward though. The debate has not been happening on the mailing list. Even though Andre has asked a question to NTIP authors to stir the debate to the mailing, no response has come back. Otherwise, I have only seen some discussions on LMP-WDM vs. funiculus. What should be the next step to get LMP on the CCAMP WG charter? Martin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, June 05, 2001 2:01 PM To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail) Subject: RE: Proposed Addition to CCAMP Charter Importance: High Inline > ---------- > From: Martin Dubuc[SMTP:martin.dubuc@edgeflow.com] > Sent: Tuesday, June 05, 2001 6:45 PM > To: 'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > > Bert, > > Can you tell us when you expect to complete evaluation of all I-D > summaries? > Is it a matter of days, weeks, months? > > Who decides whether LMP should be a CCAMP WG charter item? I am quite a > bit > surprised that someone is considering putting G-MPLS and LMP in different > WGs. Is there a rationale for this? Nope no plans for that... but I believe I did see in some WG minutes that your WG chairs were considering to merge the LMP and NTIP proposals. I think it mentioned that requirements would be written down first... and then one would see what the next steps would be... I would need to dig in to archives to find what the exact statement was. In any event, we wanted all I-Ds, also those that were already WG I-Ds to send in a summary. The WG chairs are the first to assess that input. as soon as we hear from them, we'll know more. Bert > Regards, > > Martin > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, June 05, 2001 11:58 AM > To: ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > Importance: High > > > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries > that have been submitted with CCAMP as the target WG. > Once we have gone through those, we will also address the work item > of an LMP MIB (that is if LMP is still also a WG charter item by then). > > Bert > > > ---------- > > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > > Sent: Tuesday, June 05, 2001 5:08 PM > > To: ccamp@ops.ietf.org > > Cc: bwijnen@lucent.com; Scott Bradner; Sudheer Dharanikota > (E-mail); > > Jonathan Lang (E-mail); Evan McGinnis (E-mail) > > Subject: Proposed Addition to CCAMP Charter > > > > > > Hello, > > > > It has been brought to my attention recently > > that despite the WG voting to adopt the LMP-MIB > > during the Minneapolis meeting, that the adoption of > > this document is not possible because there is no mention > > of network management in the CCAMP WG charter. Therefore > > I propose that since the features we are working > > on in the WG are not very useful unless they are > > manageable, that where appropriate, > > marriageability (or at least SNMP MIBs) of things > > developed in CCAMP be added to the charter. > > > > --Tom > > > > > ------_=_NextPart_001_01C0EDF3.D7609200 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Addition to CCAMP Charter

A few clarifications are due. First the debate is = between NTIP and LMP-WDM. The debate is NOT between NTIP and LMP. = Secondly, people interested in the subject have agreed on a set of = requirements for that interface. The requirements have been presented = at the last OIF, and are being discussed at an ITU meeting this week. I = think Andre have already submitted a draft to IETF on those = requirements (or he is in the process of doing so).

What I don't understand is why NTIP and LMP-WDM = debate has been brought into this discussion? It seems to me that this = discussion is related to setting WG charter, and to what extent certain = items fit or don't fit into a charter, or IETF in general. It is a = wider discussion than just a debate between two proposals.

Regards;

Osama.
 -----Original Message-----
From:   Martin Dubuc [mailto:martin.dubuc@edgeflow.c= om]
Sent:   Tuesday, June 05, 2001 2:47 = PM
To:     'Wijnen, Bert (Bert)'; = ccamp-wg; Thomas D. Nadeau
Cc:     Scott Bradner; Sudheer = Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis = (E-mail)
Subject:        = RE: Proposed Addition to CCAMP Charter

Bert,

Looking back at the minutes, there seems to have been = quite a debate during
the CCAMP session between LMP and NTIP proponents. I = do not know how we move
forward though. The debate has not been happening on = the mailing list. Even
though Andre has asked a question to NTIP authors to = stir the debate to the
mailing, no response has come back. Otherwise, I = have only seen some
discussions on LMP-WDM vs. funiculus.

What should be the next step to get LMP on the CCAMP = WG charter?

Martin

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
Sent: Tuesday, June 05, 2001 2:01 PM
To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc
Cc: Scott Bradner; Sudheer Dharanikota (E-mail); = Jonathan Lang (E-mail);
Evan McGinnis (E-mail)
Subject: RE: Proposed Addition to CCAMP = Charter
Importance: High


Inline

> ----------
> From: =         Martin = Dubuc[SMTP:martin.dubuc@edgeflow.com]
> Sent: =         Tuesday, June 05, 2001 6:45 = PM
> To:   'Wijnen, Bert (Bert)'; ccamp-wg; = Thomas D. Nadeau
> Cc:   Scott Bradner; Sudheer Dharanikota = (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject:      RE: Proposed = Addition to CCAMP Charter
>
> Bert,
>
> Can you tell us when you expect to complete = evaluation of all I-D
> summaries?
> Is it a matter of days, weeks, months?
>
> Who decides whether LMP should be a CCAMP WG = charter item? I am quite a
> bit
> surprised that someone is considering putting = G-MPLS and LMP in different
> WGs. Is there a rationale for this?
Nope no plans for that... but I believe I did see in = some WG minutes that
your WG chairs were considering to merge the LMP and = NTIP proposals.
I think it mentioned that requirements would be = written down first... and
then one would see what the next steps would be... I = would need to dig in
to archives to find what the exact statement = was.

In any event, we wanted all I-Ds, also those that = were already WG I-Ds
to send in a summary. The WG chairs are the first to = assess that input.
as soon as we hear from them, we'll know = more.

Bert

> Regards,
>
> Martin
>
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Tuesday, June 05, 2001 11:58 AM
> To: ccamp-wg; Thomas D. Nadeau
> Cc: Scott Bradner; Sudheer Dharanikota = (E-mail); Jonathan Lang (E-mail);
> Evan McGinnis (E-mail)
> Subject: RE: Proposed Addition to CCAMP = Charter
> Importance: High
>
>
> Your WG chairs with the ADs and TAs are = evaluating all the I-D summaries
> that have been submitted with CCAMP as the = target WG.
> Once we have gone through those, we will also = address the work item
> of an LMP MIB (that is if LMP is still also a = WG charter item by then).
>
> Bert
>
> > ----------
> > From:       = Thomas D. Nadeau[SMTP:tnadeau@cisco.com]
> > Sent:       = Tuesday, June 05, 2001 5:08 PM
> > To: =         ccamp@ops.ietf.org
> > Cc: =         bwijnen@lucent.com; Scott = Bradner; Sudheer Dharanikota
> (E-mail);
> > Jonathan Lang (E-mail); Evan McGinnis = (E-mail)
> > Subject:    Proposed Addition to = CCAMP Charter
> >
> >
> >     Hello,
> >
> >     It has been brought to = my attention recently
> > that despite the WG voting to adopt the = LMP-MIB
> > during the Minneapolis meeting, that the = adoption of
> > this document is not possible because = there is no mention
> > of network management in the CCAMP WG = charter. Therefore
> > I propose that since the features we are = working
> > on in the WG are not very useful unless = they are
> > manageable, that where appropriate,
> > marriageability (or at least SNMP MIBs) of = things
> > developed in CCAMP be added to the = charter.
> >
> >     --Tom
> >
> >
>

------_=_NextPart_001_01C0EDF3.D7609200-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 11:48:01 -0700 Message-ID: <89E067900D3FA84A97495C71556140E41B6254@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'Wijnen, Bert (Bert)'" , ccamp-wg , "Thomas D. Nadeau" Cc: Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 14:47:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Looking back at the minutes, there seems to have been quite a debate during the CCAMP session between LMP and NTIP proponents. I do not know how we move forward though. The debate has not been happening on the mailing list. Even though Andre has asked a question to NTIP authors to stir the debate to the mailing, no response has come back. Otherwise, I have only seen some discussions on LMP-WDM vs. funiculus. What should be the next step to get LMP on the CCAMP WG charter? Martin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, June 05, 2001 2:01 PM To: ccamp-wg; Thomas D. Nadeau; Martin Dubuc Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail) Subject: RE: Proposed Addition to CCAMP Charter Importance: High Inline > ---------- > From: Martin Dubuc[SMTP:martin.dubuc@edgeflow.com] > Sent: Tuesday, June 05, 2001 6:45 PM > To: 'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > > Bert, > > Can you tell us when you expect to complete evaluation of all I-D > summaries? > Is it a matter of days, weeks, months? > > Who decides whether LMP should be a CCAMP WG charter item? I am quite a > bit > surprised that someone is considering putting G-MPLS and LMP in different > WGs. Is there a rationale for this? Nope no plans for that... but I believe I did see in some WG minutes that your WG chairs were considering to merge the LMP and NTIP proposals. I think it mentioned that requirements would be written down first... and then one would see what the next steps would be... I would need to dig in to archives to find what the exact statement was. In any event, we wanted all I-Ds, also those that were already WG I-Ds to send in a summary. The WG chairs are the first to assess that input. as soon as we hear from them, we'll know more. Bert > Regards, > > Martin > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, June 05, 2001 11:58 AM > To: ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > Importance: High > > > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries > that have been submitted with CCAMP as the target WG. > Once we have gone through those, we will also address the work item > of an LMP MIB (that is if LMP is still also a WG charter item by then). > > Bert > > > ---------- > > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > > Sent: Tuesday, June 05, 2001 5:08 PM > > To: ccamp@ops.ietf.org > > Cc: bwijnen@lucent.com; Scott Bradner; Sudheer Dharanikota > (E-mail); > > Jonathan Lang (E-mail); Evan McGinnis (E-mail) > > Subject: Proposed Addition to CCAMP Charter > > > > > > Hello, > > > > It has been brought to my attention recently > > that despite the WG voting to adopt the LMP-MIB > > during the Minneapolis meeting, that the adoption of > > this document is not possible because there is no mention > > of network management in the CCAMP WG charter. Therefore > > I propose that since the features we are working > > on in the WG are not very useful unless they are > > manageable, that where appropriate, > > marriageability (or at least SNMP MIBs) of things > > developed in CCAMP be added to the charter. > > > > --Tom > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 11:24:38 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C821CCD@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: George Swallow Cc: ccamp-wg , "Thomas D. Nadeau" , Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 20:22:33 +0200 MIME-Version: 1.0 Content-Type: text/plain George... in principle we want all protocols to also define a MIB such that the protocol is manageable. We DO WANT such an item on the WG charter as a work item though. So... I think things are REAL EASY. Once we decide on the final I-Ds that are in CCAMP, then if LMP is part of it, then it seems logical to also do a MIB. We should then pass that through IESG/IAB as explained by Scott. Bert > ---------- > From: George Swallow[SMTP:swallow@cisco.com] > Sent: Tuesday, June 05, 2001 6:49 PM > To: Wijnen, Bert (Bert) > Cc: ccamp-wg; Thomas D. Nadeau; Scott Bradner; Sudheer Dharanikota > (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail); > swallow@cisco.com > Subject: Re: Proposed Addition to CCAMP Charter > > Bert - > > > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries > > that have been submitted with CCAMP as the target WG. > > Once we have gone through those, we will also address the work item > > of an LMP MIB (that is if LMP is still also a WG charter item by then). > > It is my understanding that the IESG is actively encouraging MIB work > to be done along with (i.e. in the same WG) as the protocols they > manage. In that regard no explicit mention of a MIB for a protocol is > necessary in the charter (just like an applicability statement). Has > that changed? > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 11:03:07 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C821CC6@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , "Thomas D. Nadeau" , Martin Dubuc Cc: Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 20:01:29 +0200 MIME-Version: 1.0 Content-Type: text/plain Inline > ---------- > From: Martin Dubuc[SMTP:martin.dubuc@edgeflow.com] > Sent: Tuesday, June 05, 2001 6:45 PM > To: 'Wijnen, Bert (Bert)'; ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > > Bert, > > Can you tell us when you expect to complete evaluation of all I-D > summaries? > Is it a matter of days, weeks, months? > > Who decides whether LMP should be a CCAMP WG charter item? I am quite a > bit > surprised that someone is considering putting G-MPLS and LMP in different > WGs. Is there a rationale for this? Nope no plans for that... but I believe I did see in some WG minutes that your WG chairs were considering to merge the LMP and NTIP proposals. I think it mentioned that requirements would be written down first... and then one would see what the next steps would be... I would need to dig in to archives to find what the exact statement was. In any event, we wanted all I-Ds, also those that were already WG I-Ds to send in a summary. The WG chairs are the first to assess that input. as soon as we hear from them, we'll know more. Bert > Regards, > > Martin > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, June 05, 2001 11:58 AM > To: ccamp-wg; Thomas D. Nadeau > Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); > Evan McGinnis (E-mail) > Subject: RE: Proposed Addition to CCAMP Charter > Importance: High > > > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries > that have been submitted with CCAMP as the target WG. > Once we have gone through those, we will also address the work item > of an LMP MIB (that is if LMP is still also a WG charter item by then). > > Bert > > > ---------- > > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > > Sent: Tuesday, June 05, 2001 5:08 PM > > To: ccamp@ops.ietf.org > > Cc: bwijnen@lucent.com; Scott Bradner; Sudheer Dharanikota > (E-mail); > > Jonathan Lang (E-mail); Evan McGinnis (E-mail) > > Subject: Proposed Addition to CCAMP Charter > > > > > > Hello, > > > > It has been brought to my attention recently > > that despite the WG voting to adopt the LMP-MIB > > during the Minneapolis meeting, that the adoption of > > this document is not possible because there is no mention > > of network management in the CCAMP WG charter. Therefore > > I propose that since the features we are working > > on in the WG are not very useful unless they are > > manageable, that where appropriate, > > marriageability (or at least SNMP MIBs) of things > > developed in CCAMP be added to the charter. > > > > --Tom > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 10:52:25 -0700 Message-Id: <200106051649.MAA24415@telescope.cisco.com> To: "Wijnen, Bert (Bert)" cc: ccamp-wg , "Thomas D. Nadeau" , Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" , swallow@cisco.com Subject: Re: Proposed Addition to CCAMP Charter Date: Tue, 05 Jun 2001 12:49:10 -0400 From: George Swallow Bert - > Your WG chairs with the ADs and TAs are evaluating all the I-D summaries > that have been submitted with CCAMP as the target WG. > Once we have gone through those, we will also address the work item > of an LMP MIB (that is if LMP is still also a WG charter item by then). It is my understanding that the IESG is actively encouraging MIB work to be done along with (i.e. in the same WG) as the protocols they manage. In that regard no explicit mention of a MIB for a protocol is necessary in the charter (just like an applicability statement). Has that changed? ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 10:43:52 -0700 Date: Tue, 5 Jun 2001 13:42:19 -0400 (EDT) From: Scott Bradner Message-Id: <200106051742.NAA08952@newdev.harvard.edu> To: eric.gray@sandburst.com, sob@harvard.edu Subject: Re: Proposed Addition to CCAMP Charter Cc: bwijnen@lucent.com, ccamp@ops.ietf.org, evan@calient.net, jplang@calient.net, martin.dubuc@edgeflow.com, sudheer@nayna.com, tnadeau@cisco.com > It was rather pointedly implied by Bert's comment in which he > said - "(that is if LMP is still also a WG charter item by then)". > Admittedly, this could mean that the group (also known as 'them'*) > is thinking that LMP would be a charter item in no WG at all. Bert made no mention of any other working group just to be clear nothing in this or any of Bert's messages makes any value judgements about LMP or an LMP MIB - IETF working group charters specify what a working group is to work on - if a topic is not in the charter then it can not be a formal WG task changes to IETF WG charetrs are worked out between teh WG chairs and the ADs (and in this case TA) - if the ADs are convinced then they will take the proposed changes to the IESG. The IESG (with advice from the IAB) must approve all changes to charters. Note that the IESG is generally reluctant to add work to a WG charter until the WG has shown that it can get work done. Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 10:28:44 -0700 Message-ID: <3B1D162C.1B792032@sandburst.com> Date: Tue, 05 Jun 2001 13:26:04 -0400 From: Eric Gray MIME-Version: 1.0 To: Scott Bradner Cc: bwijnen@lucent.com, ccamp@ops.ietf.org, martin.dubuc@edgeflow.com, tnadeau@cisco.com, evan@calient.net, jplang@calient.net, sudheer@nayna.com Subject: Re: Proposed Addition to CCAMP Charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott, It was rather pointedly implied by Bert's comment in which he said - "(that is if LMP is still also a WG charter item by then)". Admittedly, this could mean that the group (also known as 'them'*) is thinking that LMP would be a charter item in no WG at all. * 'they' are composed of WG chairs (which WGs?), Area Directors (presumably you and Bert) and the technical advisors (Rob Coltun and Dave Oran, still?). -- Eric Gray You wrote: > > I am quite a bit > > surprised that someone is considering putting G-MPLS and LMP in different > > > WGs. > > where did you here this? > > Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 09:53:55 -0700 Date: Tue, 5 Jun 2001 12:52:05 -0400 (EDT) From: Scott Bradner Message-Id: <200106051652.MAA08519@newdev.harvard.edu> To: bwijnen@lucent.com, ccamp@ops.ietf.org, martin.dubuc@edgeflow.com, tnadeau@cisco.com Subject: RE: Proposed Addition to CCAMP Charter Cc: evan@calient.net, jplang@calient.net, sob@harvard.edu, sudheer@nayna.com > I am quite a bit > surprised that someone is considering putting G-MPLS and LMP in different > WGs. where did you here this? Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 09:46:39 -0700 Message-ID: <89E067900D3FA84A97495C71556140E41B624F@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'Wijnen, Bert (Bert)'" , ccamp-wg , "Thomas D. Nadeau" Cc: Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 12:45:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, Can you tell us when you expect to complete evaluation of all I-D summaries? Is it a matter of days, weeks, months? Who decides whether LMP should be a CCAMP WG charter item? I am quite a bit surprised that someone is considering putting G-MPLS and LMP in different WGs. Is there a rationale for this? Regards, Martin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, June 05, 2001 11:58 AM To: ccamp-wg; Thomas D. Nadeau Cc: Scott Bradner; Sudheer Dharanikota (E-mail); Jonathan Lang (E-mail); Evan McGinnis (E-mail) Subject: RE: Proposed Addition to CCAMP Charter Importance: High Your WG chairs with the ADs and TAs are evaluating all the I-D summaries that have been submitted with CCAMP as the target WG. Once we have gone through those, we will also address the work item of an LMP MIB (that is if LMP is still also a WG charter item by then). Bert > ---------- > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > Sent: Tuesday, June 05, 2001 5:08 PM > To: ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; Scott Bradner; Sudheer Dharanikota (E-mail); > Jonathan Lang (E-mail); Evan McGinnis (E-mail) > Subject: Proposed Addition to CCAMP Charter > > > Hello, > > It has been brought to my attention recently > that despite the WG voting to adopt the LMP-MIB > during the Minneapolis meeting, that the adoption of > this document is not possible because there is no mention > of network management in the CCAMP WG charter. Therefore > I propose that since the features we are working > on in the WG are not very useful unless they are > manageable, that where appropriate, > marriageability (or at least SNMP MIBs) of things > developed in CCAMP be added to the charter. > > --Tom > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 08:59:17 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C821C76@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , "Thomas D. Nadeau" Cc: Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Subject: RE: Proposed Addition to CCAMP Charter Date: Tue, 5 Jun 2001 17:57:50 +0200 MIME-Version: 1.0 Content-Type: text/plain Your WG chairs with the ADs and TAs are evaluating all the I-D summaries that have been submitted with CCAMP as the target WG. Once we have gone through those, we will also address the work item of an LMP MIB (that is if LMP is still also a WG charter item by then). Bert > ---------- > From: Thomas D. Nadeau[SMTP:tnadeau@cisco.com] > Sent: Tuesday, June 05, 2001 5:08 PM > To: ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; Scott Bradner; Sudheer Dharanikota (E-mail); > Jonathan Lang (E-mail); Evan McGinnis (E-mail) > Subject: Proposed Addition to CCAMP Charter > > > Hello, > > It has been brought to my attention recently > that despite the WG voting to adopt the LMP-MIB > during the Minneapolis meeting, that the adoption of > this document is not possible because there is no mention > of network management in the CCAMP WG charter. Therefore > I propose that since the features we are working > on in the WG are not very useful unless they are > manageable, that where appropriate, > marriageability (or at least SNMP MIBs) of things > developed in CCAMP be added to the charter. > > --Tom > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 08:49:51 -0700 Message-ID: <3B1CFF38.AB0D7E3B@sandburst.com> Date: Tue, 05 Jun 2001 11:48:08 -0400 From: Eric Gray MIME-Version: 1.0 To: "Thomas D. Nadeau" Cc: Common Control and Measurement Protocols Subject: Re: Proposed Addition to CCAMP Charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom, I thought that management work is now an implied part of all working group charters. I agree with you that a specific WG charter should include specific manageability goals. -- Eric Gray You wrote: > Hello, > > It has been brought to my attention recently > that despite the WG voting to adopt the LMP-MIB > during the Minneapolis meeting, that the adoption of > this document is not possible because there is no mention > of network management in the CCAMP WG charter. Therefore > I propose that since the features we are working > on in the WG are not very useful unless they are > manageable, that where appropriate, > marriageability (or at least SNMP MIBs) of things > developed in CCAMP be added to the charter. > > --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 08:49:18 -0700 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C821C60@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ccamp-wg , ipo-wg , v.sharma@ieee.org Cc: Scott Bradner Subject: RE: [IP-Optical] RE: Arbitrary concatenation proposals Date: Tue, 5 Jun 2001 17:47:16 +0200 MIME-Version: 1.0 Content-Type: text/plain > We want their personal input based on their personal experience with > a data network operator or based on direct discussions with people who > work for data network operators. We do not need assertions based > on suppositions or marketing hopes. > > Scott and Bert > > ---------- > > > > If so, I am a little confused about what it means > > to ask for SP input? Are we asking for individual contributors from the > > SP community, and hoping that they will bring in (by osmosis) the > overall > > philosophy > > of their company, or are we asking for companies to specifically send > > their representatives to provide inputs on certain topics that have been > > deemed to require SP input? > > > > ADs, Chairs, any comments or clarifications? > > > > Thanks, > > > > -Vishal > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 05 Jun 2001 08:11:11 -0700 Message-Id: <4.3.2.7.2.20010605110228.03e30e10@bucket.cisco.com> Date: Tue, 05 Jun 2001 11:08:31 -0400 To: ccamp@ops.ietf.org From: "Thomas D. Nadeau" Subject: Proposed Addition to CCAMP Charter Cc: bwijnen@lucent.com, Scott Bradner , "Sudheer Dharanikota (E-mail)" , "Jonathan Lang (E-mail)" , "Evan McGinnis (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, It has been brought to my attention recently that despite the WG voting to adopt the LMP-MIB during the Minneapolis meeting, that the adoption of this document is not possible because there is no mention of network management in the CCAMP WG charter. Therefore I propose that since the features we are working on in the WG are not very useful unless they are manageable, that where appropriate, marriageability (or at least SNMP MIBs) of things developed in CCAMP be added to the charter. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 12:37:52 -0700 From: ananth.nagarajan@mail.sprint.com Date: Mon, 4 Jun 2001 13:42:53 -0500 Message-Id: Subject: RE: Re: GMPLS Last Calls MIME-Version: 1.0 TO: ccamp@ops.ietf.org, kireeti@juniper.net Content-Type: multipart/mixed; boundary="openmail-part-408bcd0a-00000001" --openmail-part-408bcd0a-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 4 Jun 2001 13:42:53 -0500" Content-Transfer-Encoding: 7bit Kireeti, >However, any attempt to say "I work for such-and-and company, hence >you should listen to me", or "I speak for such-and-such company as >a whole" goes in my bitbucket -- in Randy's words, "is irrelevant". >If a suggestion or argument cannot stand on its own, throwing the >weight of one's company's name behind it won't help hold it up. I >am sure that that was not the intent in the email that started this >thread, but invoking company names raises doubts. I don't know if this email was intended for me or for "anonymous". Would like to reiterate that it was not my intention to "throw the weight of my company's name" (as you've correctly pointed out). Unfortunately, the group of individuals that I work with that contributed to my email are not very familiar with the "IETF culture" and would rather see the company name being quoted (as they see in the standards fora that they go to). I am hoping that the innocent misdemeanor of quoting my company's name be ignored (far too much has been said on this already). We're thankful to the few folks who have continued the technical discussion in spite of all the entertainment that's floating around, and will concentrate on addressing those technical comments/questions. Thanks, Ananth --openmail-part-408bcd0a-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 12:00:38 -0700 Message-Id: <200106041859.OAA08870@telescope.cisco.com> To: Kireeti Kompella cc: ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: GMPLS Last Calls Date: Mon, 04 Jun 2001 14:59:22 -0400 From: George Swallow All, and especially anonimous, Since we are an organization of individuals, anyone not revealing their individual identity should be ignored. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 11:09:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Gray Cc: MPLS Mailing List , Common Control and Measurement Protocols Subject: Re: GMPLS Last Calls Message-Id: Date: Mon, 04 Jun 2001 11:07:51 -0700 > Also, in spite of Randy's comments, people DO want to hear from members of > companies. you may be misunderstanding my comment. it is understood that almost all of us still are employed, despite the economy. but the ietf is explicitly, not accidentally, composed of individuals, not companies. and, as we have had unfortunate incidents of attempts at company block pressure for and against some work, many of us have become quite sensitized to this, and try to make the issue clear before entering any slippery slope. please excuse that i am too often overly sensitive to such process issues, and too often insufficiently patient in explaining. randy Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 10:59:28 -0700 Date: Mon, 4 Jun 2001 10:56:10 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106041756.KAA15867@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Re: GMPLS Last Calls Hi Anonymous, > > I agree with you whole heartedly. We must have the inputs from the carriers > > and not from the vendors alone. First off, there is an explicit request for input from *carriers* and *service providers* (same beast, different color), especially for requirements and in requirements-oriented design teams. It's a simple distinction: carriers use the technology; vendors build the technology. Speaking as a contributor to the IETF, I have no desire to build technology (or define protocols) that won't be used; and if carriers don't have input into requirements, they always have the ultimate vote: not to buy/put into production the various new technologies/ features. So, prefacing emails to IETF lists by "I work for a carrier" or "I work for a vendor" (or better yet, "I deploy the technology" or "I build the technology") helps set the context, and is more than acceptable, it is desirable (from my point of view). However, any attempt to say "I work for such-and-and company, hence you should listen to me", or "I speak for such-and-such company as a whole" goes in my bitbucket -- in Randy's words, "is irrelevant". If a suggestion or argument cannot stand on its own, throwing the weight of one's company's name behind it won't help hold it up. I am sure that that was not the intent in the email that started this thread, but invoking company names raises doubts. Please don't interpret Randy's comment as a personal attack, or as an aspersion on the value of carriers' input to the IETF -- remember that Randy is an august member of that very same species. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 08:58:42 -0700 Message-ID: From: neil.2.harrison@bt.com To: yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Mon, 4 Jun 2001 16:56:49 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Yakov Rekhter wrote 04 June 2001 15:48 > > > > Issues that we have found relate to - > > > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 > of Yakov Rekhter's > > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), > Yakov says, " To > > many people, QoS is the driving factor behind MPLS. This > is actually > > something of a misconception......QoS is not a very strong > reason to deploy > > MPLS..." > > The above seems like quoting out of context. To put it in the proper > context here is the full sentence: > > Compared to other factors, such as traffic engineering and Virtual > Private Network support, QoS is not a very strong reason to deploy > MPLS. > > So, what you seem to be missing is that it is *relative* to other > applications, such as TE and VPN, that "QoS is not a very > strong reason > to deploy MPLS". > > And while on the subject of QoS and MPLS, further in the > first section > of Chapter 6 (page 148): > > ..there are some novel QoS capabilities that can be supported across > a provider network using MPLS that, while not being truly > end-to-end, > nevertheless may prove very useful. One of these, > guaranteed bandwidth > LSPs, is discussed in Section 7.5.2. NH=> MPLS has the potential to become very important and have a key role on QoS issues (and it should not be confused with GMPLS see 'note' at end).....but to get there we need to recognise these points: - LDP is to me an IP routing adjunct.....its main role as I see it is to provde address partitioning (or a 'hierachy of routing' as I think you described it in your book Yakov....which, if anyone has not read it, I can strongly recommend); - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. And it was these apsects that our OAM paper tried to address for MPLS....that is, to attack the QoS problem (wrt operational processes and measurements) one needs to first define the defects (and MPLS does have the potential to introduce new ones) and the consequent actions...and from this we can define availability of the LSPs which in turn is a pre-requisite to measuring QoS (since QoS is only relevant to the up-state of the LSP). However.....we have had a 'hard time' from a few on this (maybe there is a silent majority that support this work?)....and this relates to Eric Gray's prior mail on why people don't speak up.....besides the fear of ridicule or abuse, one can only try so many tmes before giving up and going elsewhere. So maybe there is a deep-seated culture problem that needs addressing? Note - MPLS introduces a new user-plane technology....the shim header. By definition, and as noted above, operators need to manage this in an OAM/performance sense. MPLS has the ability to be extended to end systems....I know this is not currently on the agenda of many, but it has that *potential* (ie so that applications could choose a priori the transfer mode, co or cnls). The arguments for a single control-plane across MPLS and IP (or to be more precise the 'addressing facet' of the control-plane) is important if ever MPLS was extended to end systems.....this was the real problem with ATM and IP unification, ie disjoint addressing. GMPLS on the other hand does not introduce a new user-plane. It is about re-using control-plane facets for different layer networks. In principle this is a laudable aim, but its actual embodiment has many technical and commercial implications that are too deep to go into here and we (ie I and colleagues in BT) are addressing these elsewhere. So all I wanted to say here is that one should not compare MPLS and GMPLS like they are same thing. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 08:14:31 -0700 Message-Id: <200106041513.IAA00953@red.juniper.net> To: MPLS Mailing List , Common Control and Measurement Protocols , Eric Gray Subject: Re: GMPLS Last Calls MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81223.991667611.1@juniper.net> Date: Mon, 04 Jun 2001 08:13:31 -0700 From: Yakov Rekhter [minor typo...] > Since you quoted from "MPLS: Technology and Application" before, > I'd like to suggest to look at Section 7.6.2 of this book for the ^^^^^ 7.2.6 > discussion of alledged scalability problem with RSVP, when used in > conjunction with MPLS Constraint-based routing. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 07:48:26 -0700 Message-Id: <200106041447.HAA00384@red.juniper.net> To: MPLS Mailing List , Common Control and Measurement Protocols cc: Eric Gray Subject: Re: GMPLS Last Calls MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77114.991666059.1@juniper.net> Date: Mon, 04 Jun 2001 07:47:39 -0700 From: Yakov Rekhter Anonymous, > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." The above seems like quoting out of context. To put it in the proper context here is the full sentence: Compared to other factors, such as traffic engineering and Virtual Private Network support, QoS is not a very strong reason to deploy MPLS. So, what you seem to be missing is that it is *relative* to other applications, such as TE and VPN, that "QoS is not a very strong reason to deploy MPLS". And while on the subject of QoS and MPLS, further in the first section of Chapter 6 (page 148): ..there are some novel QoS capabilities that can be supported across a provider network using MPLS that, while not being truly end-to-end, nevertheless may prove very useful. One of these, guaranteed bandwidth LSPs, is discussed in Section 7.5.2. > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if > you are interested), At best whether "to do VPN with MPLS with extensions" is "a bad idea" is a matter of opinion. However, since at the beginning of you message you suggested to get inputs from the carriers, you may look at the list of authors of draft-rosen-rfc2547bis-03.txt, as this list may give you a hint of what carriers think about this technology. > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. First of all, there is a difference between "said" and "done". So, while other "have said.. you can easily do TE with a host of network management tools", one could ask whether they actually done this. And if yes, then the next question would be to compare results with TE based on MPLS Constraint-based routing. > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally Since you quoted from "MPLS: Technology and Application" before, I'd like to suggest to look at Section 7.6.2 of this book for the discussion of alledged scalability problem with RSVP, when used in conjunction with MPLS Constraint-based routing. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 07:45:49 -0700 From: ananth.nagarajan@mail.sprint.com Date: Mon, 4 Jun 2001 09:45:11 -0500 Message-Id: Subject: RE: Re: GMPLS Last Calls MIME-Version: 1.0 TO: ccamp@ops.ietf.org, eric.gray@sandburst.com, mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-407f3a21-00000001" --openmail-part-407f3a21-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 4 Jun 2001 09:45:10 -0500" Content-Transfer-Encoding: 7bit This is to the same individual who sent me a private e-mail with similar content as was sent to Eric Gray: Please don't misinterpret my GMPLS concerns as concerns about MPLS as a whole. Please note that I am very supportive of MPLS, and in fact, I like the very aspects of MPLS that you point out as bad things (MPLS for TE, BGP-MPLS and Virtual Router-based VPNs etc.) I also have no problem with GMPLS as the protocol of choice for the optical control plane (In fact i think it is a very logical idea). My e-mail was to point out, what carriers may think as deficiencies with GMPLS for the optical control plane. I welcome comments, like Bala's and others' clarifying the different features that address our concerns. After all, voicing concerns and getting clarifications on a protocol is supposed to be an educational process as well. (Doesn't mean that all the concerns that had been expressed in my e-mail have been resolved, but those will be addressed via a separate e-mail). Cheers, Ananth -----Original Message----- From: eric.gray [mailto:eric.gray@sandburst.com] Sent: Monday, June 04, 2001 9:06 AM To: mpls; ccamp Subject: Re: GMPLS Last Calls Anonymous, Look, I know that these IETF mailing lists are prone to flame wars and that many people prefer to be silent 'lurkers' as a result. But, unless people are willing to come forward with their comments directly, it is not very likely that they will be heard. Also, in spite of Randy's comments, people DO want to hear from members of companies. It is easy to express high sounding, but meaningless, opinions when posting as 'an individual' - especially when posting from an anonymous free E-mail account (as so many people do these days). Understand that - if you come forward with an opinion or idea that you and your colleagues have come up with together - your opinion/idea will have only the weight of an individual opinion. In theory, your opinions and ideas should be considered by IETF participants solely on their merit and not as a result of who you work for (or what your position is in the IETF). Also, in theory, it is understood that your individual opinions and ideas do not reflect the opinions and ideas of your employer. And most of us (wink, wink) believe this too. Personally, I think there is entirely too much censure (read 'flames') going on. If you and your colleagues each individually express the same opinion, you will hear comments like 'well, one company heard from'. On the other hand, if one of you expresses a common opinion, he/she will be censured for not expressing an individual opinion. It may seem like you can't win, but you have to try. And - until some IETF 'king' decides to stoop to literal censure - your opinions will be heard in spite of the flames... :-) -- Eric Gray 'Anonymous' wrote: > Eric, > > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." > > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if you > are interested), > > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. > > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally > > 4. No one addresses the fact that tagging and variable packet sizing enroute > for a packet is extremely high memory and processing hog (hardly acceptable > for the hundreds and thousands of older routers out there) not to mention the > issues of label explosion, TTL, and risk of MTU violation and subsequent > fragmentation and retagging of packets. > > My colleagues and I wonder why no one speaks up. > > (Please feel free to use these items in the thread if you don't use my name. > Thanks.) > > (Anonymous) > > Eric Gray wrote: > > > Randy, > > > > Is this one of your usual insightful comments? Let's see what our > > studio audience has to say - Bzztzzt! Apparently that was a wrong > > answer. :-) > > > > Repeatedly we ask for input from carriers. We get some and we > > hear that we're only interested in hearing from individuals? As Lloyd > > said, interesting... > > > > -- > > Eric Gray > > > > You wrote: > > > > > > These are the collective opinions of me and my colleagues > > > > > > as the ietf is composed of individuals, i have not read your irrelevant > > > message. should you have personal expertise you wish to share, i would > > > be very inteested in hearing it. > > > > > > randy --openmail-part-407f3a21-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 07:07:40 -0700 Message-ID: <3B1B95C5.C88EC9A8@sandburst.com> Date: Mon, 04 Jun 2001 10:05:57 -0400 From: Eric Gray MIME-Version: 1.0 To: MPLS Mailing List , Common Control and Measurement Protocols Subject: Re: GMPLS Last Calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anonymous, Look, I know that these IETF mailing lists are prone to flame wars and that many people prefer to be silent 'lurkers' as a result. But, unless people are willing to come forward with their comments directly, it is not very likely that they will be heard. Also, in spite of Randy's comments, people DO want to hear from members of companies. It is easy to express high sounding, but meaningless, opinions when posting as 'an individual' - especially when posting from an anonymous free E-mail account (as so many people do these days). Understand that - if you come forward with an opinion or idea that you and your colleagues have come up with together - your opinion/idea will have only the weight of an individual opinion. In theory, your opinions and ideas should be considered by IETF participants solely on their merit and not as a result of who you work for (or what your position is in the IETF). Also, in theory, it is understood that your individual opinions and ideas do not reflect the opinions and ideas of your employer. And most of us (wink, wink) believe this too. Personally, I think there is entirely too much censure (read 'flames') going on. If you and your colleagues each individually express the same opinion, you will hear comments like 'well, one company heard from'. On the other hand, if one of you expresses a common opinion, he/she will be censured for not expressing an individual opinion. It may seem like you can't win, but you have to try. And - until some IETF 'king' decides to stoop to literal censure - your opinions will be heard in spite of the flames... :-) -- Eric Gray 'Anonymous' wrote: > Eric, > > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." > > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if you > are interested), > > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. > > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally > > 4. No one addresses the fact that tagging and variable packet sizing enroute > for a packet is extremely high memory and processing hog (hardly acceptable > for the hundreds and thousands of older routers out there) not to mention the > issues of label explosion, TTL, and risk of MTU violation and subsequent > fragmentation and retagging of packets. > > My colleagues and I wonder why no one speaks up. > > (Please feel free to use these items in the thread if you don't use my name. > Thanks.) > > (Anonymous) > > Eric Gray wrote: > > > Randy, > > > > Is this one of your usual insightful comments? Let's see what our > > studio audience has to say - Bzztzzt! Apparently that was a wrong > > answer. :-) > > > > Repeatedly we ask for input from carriers. We get some and we > > hear that we're only interested in hearing from individuals? As Lloyd > > said, interesting... > > > > -- > > Eric Gray > > > > You wrote: > > > > > > These are the collective opinions of me and my colleagues > > > > > > as the ietf is composed of individuals, i have not read your irrelevant > > > message. should you have personal expertise you wish to share, i would > > > be very inteested in hearing it. > > > > > > randy Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 04 Jun 2001 02:44:00 -0700 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A94092DDE59@mbtlipnt01.btlabs.bt.co.uk> From: shehzad.mirza@bt.com To: BRaja@tellium.com, ananth.nagarajan@mail.sprint.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: Re: GMPLS Last Calls Date: Mon, 4 Jun 2001 10:33:10 +0100 MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Bala, I am uncomfortable about talking about emails that were made in a different forum, but I think some clarification to the OIF comments is required. 1. The email that Dan Spears sent to the OIF mailing list made it clear that if there were no responses then the Paris Agreement that ONA Address shall be capable of accommodating either of the IP or NSAP families would still stand. It is wrong to assume that no responses meant that there was no need to support NSAP. 2. It is unreasonable to expect unanimity between carriers given that they have to support a diverse range of services and customers and legacy equipment. Though I'm sure that smart vendors will find ways of accommodating the majority of their carrier customers requirements. I do agree that the work has to continue to ensure that all issues are addressed. regards Shehzad Mirza > -----Original Message----- > From: Bala Rajagopalan [SMTP:BRaja@tellium.com] > Sent: 01 June 2001 22:26 > To: 'ananth.nagarajan@mail.sprint.com' > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com > Subject: RE: Re: GMPLS Last Calls > > Ananth: > > I see that some of the issues you bring up are > not show stoppers. Others need some clarification > from you (please see below). Also, if you > have any suggestions on how to resolve (what you > consider are) the issues, please post them/write > some drafts. This is the most constructive way > going forward. > > With regard to NSAP, Dan Speers posted a note > in the OIF mailing list soliciting response to the following: > > > > 1) Type of legacy equipment needing NSAP addresses > > > (also, is > > > this optical network element or client equipment?) > > > 2) Rough estimate of number of UNI ports needing NSAP address > > > (2002, 2005, and 2010) > > > 3) Description of application in which this legacy equipment > > > will use UNI > > > signaling > > I don't recall seeing any response. furthermore, the NSAP > requirement was not unanimously endorsed by all carriers (at > the OIF). > > It would also be nice if you can give some insight on > the timeline in which you need various features, and whether > the current GMPLS developments are inadequate within > that timeline. (We can always have a progression of features). > > Please see below. On the whole, I believe that there is no > need for alarm or panic now (or even to be "very" concerned :-)). > > > Regards, > > Bala > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > 1) GMPLS is being specified without clear requirements identified > first. As such, there is no way to ensure all needed features have > been provided by the specification. For example, control plane > management requirements have not adequately been identified and there > is concern that the addition of management requirements may cause > modifications to GMPLS functions/protocol. > > BR: Please be more specific about what you need now that's missing, and > how we can address this? > > 2) GMPLS is being defined based on assumptions about proprietary > transmission planes without those assumptions being specified. How can > we be sure that the control plane support is correct? How can we be > sure that it can be combined with other features? Assumptions > regarding the transmission plane that can affect the control plane must > be clearly documented. This creates the additional related problem that > there is not a clear inter-working defined for interaction between > standard/proprietary control planes/transmission planes. > > BR: I get the feeling you're referring to the concatenation/transperency > issues discussed recently. While the debate has been hot, there's > no show stopper here. Several suggestions are being considered for > clarifying standard/non-standard features supported. > > > 3) Assuring separation of the control plane from the data plane > continues to arise.. When the control plane fails it should not affect > existing connections. Also if connections in progress are affected > then they should not leave partially setup connections - they should > fail gracefully informing the initiator. The GMPLS architecture > document mentions this separation, but it's not clear how the GMPLS > signaling specifications reflect the implications of this decoupling. > > BR: This issue has been discussed for the OIF UNI signaling (GMPLS > based, as you know), and solutions in the RSVP/LDP space have been > proposed (some drafts may be written). > This is also not a show stopper by any means. > > > 4) Support for NSAP addresses and in general support such that control > plane addressing is independent of clients and vice versa. Also > scalable naming/addressing scheme such as proposed in OIF. > > BR: NSAP, see my initial comments. The OIF is not dealing with > names/resolution, etc. This has been decided to be out of the > scope of UNI signaling, and considered as a separate function. > > > 5) Since the control plane may be supported via multiple protocols, > clear statement of what is - and isn't - covered in the GMPLS Signaling > Description, RSVP Extensions, LDP Extensions drafts is needed. > > BR: Don't understand this, but doesn't look like a major issue from > your phrasing. > > 6) Terminology is an issue (e.g.waveband switching, link) > > BR: Any inconsistencies can be taken care of easily. > > 7) Transaction support for connection set-up and release is needed for > connection oriented networks (e.g. crankback capability). > > BR: Internet drafts have already been written on crankback. I suggest > that you please consider writing some drafts if there is something > missing. > > 8) Reliable message transfer > > BR: Very much a part of signaling. the OIF work has considered this > aspect also. > > 9) Security concerns have not been fully addressed, particularly at the > architectural level. The use of separate control network may > necessitate the need for 24 hour staff to protect against 'Denial of > Service' attacks as currently happens for IP router networks. In > general, admission control issues need to be addressed. > > BR: Please elaborate on these, specifically, what's new in the > context of GMPLS. > > 10) The definition of transparency may be overly simplified. See > comments by Ben Mack-Crane: > I think the debate on transparency indicates that the issue is not as > clear > as we might think. The OIF document you cite defines forms of > transparency > that are very straightforward (flags 1,2) not the more complex forms in > the current GMPLS drafts (flags 3..10). Also, these are easily > provided in > O-E-O or O-O-O networks operating at the lambda level, but there is no > standard for providing these over TDM multiplexed SONET/SDH links. > > BR: This is an ongoing topic of discussion. Doesn't break down > the rest of the proposal. > > If two vendors implement the same signaling but different TDM > multiplexing, that > doesn't achieve interoperability. Is there any way in the drafts to > determine the scope > of application of the various signaling elements (that is, whether they > apply to UNI or NNI, whether they apply to specific network > layers/technologies)? > 11) One summary of additional items with issues includes: > - SDH/SONET transparency. > - SDH/SONET arbitrary concatenation, flexible concatenation. > - AUG-X, TUG, STS Groups signal types and LSP capabilities. > - All kinds of end-to-end protection/restoration for any layer, except > the IP layer. > > BR: Restoration is not actually covered in the current set of drafts. > An earlier thread discussed this, and my suggestion is that this > feature be dealt with separately. > > - The concept of LSC and FSC layers, i.e. concept of lambda and fiber > switching. > > BR: What are the issues here? > > - The label set object (only used for lambda issues). > - LSP encoding type, bandwidth encoding and GPID have to be simplified > accordingly. > - MPLS extensions to control G.709 (since multiplexing, etc is not yet > defined). > > BR: A draft is forthcoming on this. > > 12) Support for paths across SONET/SDH gateways > > BR: Please clarify the issues/write drafts. > > 13) Compatibility is required/desired with legacy SDH/SONET equipment > [and also legacy DWDM] > > BR: Same as above. > > 14) Just so that we don't stop at 13 :-) > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 02 Jun 2001 17:13:54 -0700 Message-Id: <4.3.2-J.20010602092204.03e3bf00@tea.nwk.cl.nec.co.jp> Date: Sat, 02 Jun 2001 09:28:33 +0900 To: From: Atsushi Iwata Subject: RE: Re: GMPLS Last Calls Cc: Bala Rajagopalan , wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, Gerald (Jerry) Ash , Adrian Farrel , Norihito Fujita Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ananth, As Bala suggested, I wrote the following I-D proposing the crankback routing capability for CR-LDP and RSVP-TE signaling. http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-00.txt Please look at it and if you find any missing pieces for GMPLS signaling, please let me know. I would appreciate any constructive comments. Thank you. At 17:25 01/06/01 -0400, Bala Rajagopalan wrote: >7) Transaction support for connection set-up and release is needed for >connection oriented networks (e.g. crankback capability). > >BR: Internet drafts have already been written on crankback. I suggest >that you please consider writing some drafts if there is something >missing. ---------------------------------------------------------------- Atsushi Iwata, Ph.D. Assistant Manager Network Architecture TG, Networking Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 Internet E-mail: a-iwata@ah.jp.nec.com NEC-internal E-mail: iwata@ccm.CL.nec.co.jp *** Organization has been a bit changed since Apr.2001 *** Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 14:25:59 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D02204040198229D@mail1.tellium.com> From: Bala Rajagopalan To: "'ananth.nagarajan@mail.sprint.com'" Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: Re: GMPLS Last Calls Date: Fri, 1 Jun 2001 17:25:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ananth: I see that some of the issues you bring up are not show stoppers. Others need some clarification from you (please see below). Also, if you have any suggestions on how to resolve (what you consider are) the issues, please post them/write some drafts. This is the most constructive way going forward. With regard to NSAP, Dan Speers posted a note in the OIF mailing list soliciting response to the following: > > 1) Type of legacy equipment needing NSAP addresses > > (also, is > > this optical network element or client equipment?) > > 2) Rough estimate of number of UNI ports needing NSAP address > > (2002, 2005, and 2010) > > 3) Description of application in which this legacy equipment > > will use UNI > > signaling I don't recall seeing any response. furthermore, the NSAP requirement was not unanimously endorsed by all carriers (at the OIF). It would also be nice if you can give some insight on the timeline in which you need various features, and whether the current GMPLS developments are inadequate within that timeline. (We can always have a progression of features). Please see below. On the whole, I believe that there is no need for alarm or panic now (or even to be "very" concerned :-)). Regards, Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- 1) GMPLS is being specified without clear requirements identified first. As such, there is no way to ensure all needed features have been provided by the specification. For example, control plane management requirements have not adequately been identified and there is concern that the addition of management requirements may cause modifications to GMPLS functions/protocol. BR: Please be more specific about what you need now that's missing, and how we can address this? 2) GMPLS is being defined based on assumptions about proprietary transmission planes without those assumptions being specified. How can we be sure that the control plane support is correct? How can we be sure that it can be combined with other features? Assumptions regarding the transmission plane that can affect the control plane must be clearly documented. This creates the additional related problem that there is not a clear inter-working defined for interaction between standard/proprietary control planes/transmission planes. BR: I get the feeling you're referring to the concatenation/transperency issues discussed recently. While the debate has been hot, there's no show stopper here. Several suggestions are being considered for clarifying standard/non-standard features supported. 3) Assuring separation of the control plane from the data plane continues to arise.. When the control plane fails it should not affect existing connections. Also if connections in progress are affected then they should not leave partially setup connections - they should fail gracefully informing the initiator. The GMPLS architecture document mentions this separation, but it's not clear how the GMPLS signaling specifications reflect the implications of this decoupling. BR: This issue has been discussed for the OIF UNI signaling (GMPLS based, as you know), and solutions in the RSVP/LDP space have been proposed (some drafts may be written). This is also not a show stopper by any means. 4) Support for NSAP addresses and in general support such that control plane addressing is independent of clients and vice versa. Also scalable naming/addressing scheme such as proposed in OIF. BR: NSAP, see my initial comments. The OIF is not dealing with names/resolution, etc. This has been decided to be out of the scope of UNI signaling, and considered as a separate function. 5) Since the control plane may be supported via multiple protocols, clear statement of what is - and isn't - covered in the GMPLS Signaling Description, RSVP Extensions, LDP Extensions drafts is needed. BR: Don't understand this, but doesn't look like a major issue from your phrasing. 6) Terminology is an issue (e.g.waveband switching, link) BR: Any inconsistencies can be taken care of easily. 7) Transaction support for connection set-up and release is needed for connection oriented networks (e.g. crankback capability). BR: Internet drafts have already been written on crankback. I suggest that you please consider writing some drafts if there is something missing. 8) Reliable message transfer BR: Very much a part of signaling. the OIF work has considered this aspect also. 9) Security concerns have not been fully addressed, particularly at the architectural level. The use of separate control network may necessitate the need for 24 hour staff to protect against 'Denial of Service' attacks as currently happens for IP router networks. In general, admission control issues need to be addressed. BR: Please elaborate on these, specifically, what's new in the context of GMPLS. 10) The definition of transparency may be overly simplified. See comments by Ben Mack-Crane: I think the debate on transparency indicates that the issue is not as clear as we might think. The OIF document you cite defines forms of transparency that are very straightforward (flags 1,2) not the more complex forms in the current GMPLS drafts (flags 3..10). Also, these are easily provided in O-E-O or O-O-O networks operating at the lambda level, but there is no standard for providing these over TDM multiplexed SONET/SDH links. BR: This is an ongoing topic of discussion. Doesn't break down the rest of the proposal. If two vendors implement the same signaling but different TDM multiplexing, that doesn't achieve interoperability. Is there any way in the drafts to determine the scope of application of the various signaling elements (that is, whether they apply to UNI or NNI, whether they apply to specific network layers/technologies)? 11) One summary of additional items with issues includes: - SDH/SONET transparency. - SDH/SONET arbitrary concatenation, flexible concatenation. - AUG-X, TUG, STS Groups signal types and LSP capabilities. - All kinds of end-to-end protection/restoration for any layer, except the IP layer. BR: Restoration is not actually covered in the current set of drafts. An earlier thread discussed this, and my suggestion is that this feature be dealt with separately. - The concept of LSC and FSC layers, i.e. concept of lambda and fiber switching. BR: What are the issues here? - The label set object (only used for lambda issues). - LSP encoding type, bandwidth encoding and GPID have to be simplified accordingly. - MPLS extensions to control G.709 (since multiplexing, etc is not yet defined). BR: A draft is forthcoming on this. 12) Support for paths across SONET/SDH gateways BR: Please clarify the issues/write drafts. 13) Compatibility is required/desired with legacy SDH/SONET equipment [and also legacy DWDM] BR: Same as above. 14) Just so that we don't stop at 13 :-) Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 13:31:17 -0700 From: ananth.nagarajan@mail.sprint.com Date: Fri, 1 Jun 2001 15:30:34 -0500 Message-Id: Subject: RE: Re: GMPLS Last Calls MIME-Version: 1.0 TO: eric.gray@sandburst.com, randy@psg.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@uu.net, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-406a2320-00000001" --openmail-part-406a2320-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 15:30:34 -0500" Content-Transfer-Encoding: 7bit Eric, Lloyd and other "individuals", Thanks for being so understanding :-) I am sorry this thread is going on in a direction it was not intended to. I apologize for offending "IETF culture". As a group of individuals interested in getting technical responses to our technical concerns, can we re-focus on the technical issues raised collectively by individuals that I work with (I hope this description is acceptable)? Let us get a technical discussion going, please! Ananth -----Original Message----- From: eric.gray [mailto:eric.gray@sandburst.com] Sent: Friday, June 01, 2001 3:19 PM To: randy Cc: eric.gray; Nagarajan, Ananth; ccamp; mpls; Alanqar, Wesam; Ferris, Tammy; Jones, Mark L.; Neir, Lynn Subject: Re: GMPLS Last Calls Randy, Thanks. As an individual, I am interested in hearing from other individuals who can help me to understand what is useful work and what is not. I am so interested in hearing this, that I will go to some lengths to discourage others from censuring them. I believe it is even possible that I am not alone among the many individuals participating in, or listening to, this discussion in feeling this way. But I could be wrong, and you're certainly entitled to express your own opinion. -- Eric Gray You wrote: > > Is this one of your usual insightful comments? > > nope. a statement of ietf culture and policy. > > randy --openmail-part-406a2320-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 13:19:59 -0700 Message-ID: <3B17F8B1.6760CF49@sandburst.com> Date: Fri, 01 Jun 2001 16:18:57 -0400 From: Eric Gray MIME-Version: 1.0 To: Randy Bush Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@uu.net, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, Thanks. As an individual, I am interested in hearing from other individuals who can help me to understand what is useful work and what is not. I am so interested in hearing this, that I will go to some lengths to discourage others from censuring them. I believe it is even possible that I am not alone among the many individuals participating in, or listening to, this discussion in feeling this way. But I could be wrong, and you're certainly entitled to express your own opinion. -- Eric Gray You wrote: > > Is this one of your usual insightful comments? > > nope. a statement of ietf culture and policy. > > randy Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 13:03:30 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Gray Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@uu.net, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls Message-Id: Date: Fri, 01 Jun 2001 13:00:45 -0700 > Is this one of your usual insightful comments? nope. a statement of ietf culture and policy. randy Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 12:28:28 -0700 Message-Id: <200106011926.MAA22179@red.juniper.net> To: Dimitrios Pendarakis cc: "'Jonathan Lang'" , "'Fong Liaw'" , "'suresh Katukam'" , "'Jennifer Yates'" , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last call - RSVP problems MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27332.991423602.1@juniper.net> Date: Fri, 01 Jun 2001 12:26:42 -0700 From: Yakov Rekhter Dimitrios, > The problem with being in meetings is it took me a long > time to respond -:) > > So, I 'll try to provide a summary of the messages exchanged > as well as my understanding of our off-line discussion > on the applicability of RSVP and LMP Hello mechanisms. > > An attempt on terminology clarification first: > Control channel: This is a logical channel over which IP > control packets are transported between two network elements > (for example a UNI-C and UNI-N in the case of the OIF UNI). > A control channel can be realized in multiple ways, for example, > in-fiber using SONET/SDH overhead bytes, out-of-band over an > Ethernet, etc. > A pair of network elements may be connected by multiple control > channels, used either concurrently or in a primary-backup > configuration. Control channel failures can be detected using > link management procedures, such as the LMP Hello mechanism. > > Signaling channel: This is a logical channel over which signaling > messages are exchanged between two peers. The signaling channel > is realized using (potentially multiple) control channels and > it operation relies on processing of signaling messages by the > respective peer signaling entities. > A signaling channel failure is the result of failure of all control > channels, or failure of a signaling entity. Signaling channel > failures can be detected using the RSVP hello mechanism (assuming > of course RSVP is the signaling protocol used!). And then to extend it further we can also talk about routing channel, which is a logical channel over which routing messages (Hellos, Link State Updates) are exchanged between two peers. The routing channel is realized using (potentially multiple) control channels and its operation relies on processing of routing messages by the respective peer routing entities. A routing channel failure is the result of failure of all control channels, or failure of a routing entity. Routing channel failures can be detected using the ISIS/OSPF hello mechanism (assuming ISIS/OSPF is the routing protocol used). Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 12:25:19 -0700 Message-ID: <3B17EBB7.4E5970B6@sandburst.com> Date: Fri, 01 Jun 2001 15:23:35 -0400 From: Eric Gray MIME-Version: 1.0 To: Randy Bush Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@uu.net, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, Is this one of your usual insightful comments? Let's see what our studio audience has to say - Bzztzzt! Apparently that was a wrong answer. :-) Repeatedly we ask for input from carriers. We get some and we hear that we're only interested in hearing from individuals? As Lloyd said, interesting... -- Eric Gray You wrote: > > These are the collective opinions of me and my colleagues > > as the ietf is composed of individuals, i have not read your irrelevant > message. should you have personal expertise you wish to share, i would > be very inteested in hearing it. > > randy Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 10:26:48 -0700 From: ananth.nagarajan@mail.sprint.com Date: Fri, 1 Jun 2001 12:22:55 -0500 Message-Id: Subject: RE: GMPLS Last Calls MIME-Version: 1.0 TO: randy@psg.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@uu.net, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4060ffff-00000001" --openmail-part-4060ffff-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 12:22:54 -0500" Content-Transfer-Encoding: 7bit >as the ietf is composed of individuals, i have not read your irrelevant >message. should you have personal expertise you wish to share, i would >be very inteested in hearing it. In the interest of saving bandwidth, individual expertise has been bundled/aggregated/grouped to have one email instead of several. can't help it if this doesn't appeal to you --openmail-part-4060ffff-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 10:23:54 -0700 To: "Mannie, Eric" , "Stephen Trowbridge" Date: Fri, 01 Jun 2001 10:19:08 -0700 From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 Cc: "'tony.flavin@bt.com'" , jdrake@calient.net, zwlin@lucent.com, rcoltun@redback.com, ccamp@ops.ietf.org Reply-To: lyndon_ong@eudoramail.com Subject: Re: [IP-Optical] Re: Proposed text for the concatenation Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Length: 1083 Content-Transfer-Encoding: 7bit Hi Folks, It seems like the discussion is getting back down to earth a bit :o) I think Eric's point was that arbitrary concatenation is only incidental to GMPLS, as Greg pointed out in one of the early emails it is a feature of newer chips. GMPLS drafts probably have a leaning towards leading edge features because GMPLS itself or optical routing is a sort of leading edge feature. Hopefully people can use GMPLS as a way to route connections to take advantage of the availability of new features in an optical network, so that it opens up possibilities more than it causes problems. BTW, I suspect that virtual concatenation raises more issues for GMPLS than it does for the transport level - suppose that you send component channels along different routes, for example, you would need to be able to correlate multiple signaling messages as being part of the same connection when they are received at the termination point. Cheers, Lyndon Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 09:59:10 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ananth.nagarajan@mail.sprint.com Cc: ccamp@ops.ietf.org, mpls@uu.net, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: RE: GMPLS Last Calls Message-Id: Date: Fri, 01 Jun 2001 09:50:50 -0700 > These are the collective opinions of me and my colleagues as the ietf is composed of individuals, i have not read your irrelevant message. should you have personal expertise you wish to share, i would be very inteested in hearing it. randy Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 09:28:27 -0700 From: ananth.nagarajan@mail.sprint.com Date: Fri, 1 Jun 2001 11:27:49 -0500 Message-Id: Subject: RE: GMPLS Last Calls MIME-Version: 1.0 TO: ccamp@ops.ietf.org, mpls@uu.net CC: wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-405eee36-00000001" --openmail-part-405eee36-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 11:27:49 -0500" Content-Transfer-Encoding: 8bit All, Sprint has remained fairly quiet on the issues regarding the control plane as we have been working to formulate our internal views. We are very concerned about the many issues that have been raised regarding the proposed draft GMPLS standard over the past few weeks. These are the collective opinions of me and my colleagues who are involved/interested in optical control plane issues. Issues raised by others and some added here are of particular concern. In order to move forward, it is recommended that the scope of this version of the standard be re-evaluated and all issues related to that scope of work resolved before standardization. We tried to include here as many items that we could although it is not all inclusive as there were so many issues raised. We believe it is not in the best interest of any of the parties involved to standardize as things stand with so many known issues outstanding. Depending on determined scope (i.e. this list could change depending on scope of GMPLS determined by the group), here are some items that we currently believe must be addressed before final approval: 1) GMPLS is being specified without clear requirements identified first. As such, there is no way to ensure all needed features have been provided by the specification. For example, control plane management requirements have not adequately been identified and there is concern that the addition of management requirements may cause modifications to GMPLS functions/protocol. 2) GMPLS is being defined based on assumptions about proprietary transmission planes without those assumptions being specified. How can we be sure that the control plane support is correct? How can we be sure that it can be combined with other features? Assumptions regarding the transmission plane that can affect the control plane must be clearly documented. This creates the additional related problem that there is not a clear inter-working defined for interaction between standard/proprietary control planes/transmission planes. 3) Assuring separation of the control plane from the data plane continues to arise.. When the control plane fails it should not affect existing connections. Also if connections in progress are affected then they should not leave partially setup connections – they should fail gracefully informing the initiator. The GMPLS architecture document mentions this separation, but it's not clear how the GMPLS signaling specifications reflect the implications of this decoupling. 4) Support for NSAP addresses and in general support such that control plane addressing is independent of clients and vice versa. Also scalable naming/addressing scheme such as proposed in OIF. 5) Since the control plane may be supported via multiple protocols, clear statement of what is - and isn't - covered in the GMPLS Signaling Description, RSVP Extensions, LDP Extensions drafts is needed. 6) Terminology is an issue (e.g.waveband switching, link) 7) Transaction support for connection set-up and release is needed for connection oriented networks (e.g. crankback capability). 8) Reliable message transfer 9) Security concerns have not been fully addressed, particularly at the architectural level. The use of separate control network may necessitate the need for 24 hour staff to protect against 'Denial of Service' attacks as currently happens for IP router networks. In general, admission control issues need to be addressed. 10) The definition of transparency may be overly simplified. See comments by Ben Mack-Crane: I think the debate on transparency indicates that the issue is not as clear as we might think. The OIF document you cite defines forms of transparency that are very straightforward (flags 1,2) not the more complex forms in the current GMPLS drafts (flags 3..10). Also, these are easily provided in O-E-O or O-O-O networks operating at the lambda level, but there is no standard for providing these over TDM multiplexed SONET/SDH links. If two vendors implement the same signaling but different TDM multiplexing, that doesn't achieve interoperability. Is there any way in the drafts to determine the scope of application of the various signaling elements (that is, whether they apply to UNI or NNI, whether they apply to specific network layers/technologies)? 11) One summary of additional items with issues includes: - SDH/SONET transparency. - SDH/SONET arbitrary concatenation, flexible concatenation. - AUG-X, TUG, STS Groups signal types and LSP capabilities. - All kinds of end-to-end protection/restoration for any layer, except the IP layer. - The concept of LSC and FSC layers, i.e. concept of lambda and fiber switching. - The label set object (only used for lambda issues). - LSP encoding type, bandwidth encoding and GPID have to be simplified accordingly. - MPLS extensions to control G.709 (since multiplexing, etc is not yet defined). 12) Support for paths across SONET/SDH gateways 13) Compatibility is required/desired with legacy SDH/SONET equipment [and also legacy DWDM] 14) Just so that we don't stop at 13 :-) Thanks, Ananth --openmail-part-405eee36-00000001-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 08:10:29 -0700 Message-ID: <3B17AF65.482224D1@lucent.com> Date: Fri, 01 Jun 2001 09:06:13 -0600 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'tony.flavin@bt.com'" , jdrake@calient.net, zwlin@lucent.com, rcoltun@redback.com, ccamp@ops.ietf.org Subject: Re: [IP-Optical] Re: Proposed text for the concatenation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Let me try to clarify what I think Tony was saying: - There is a great deal of installed SONET/SDH equipment in todays networks that does not implement the non-standardized forms of concatenation. The standardized forms (contiguous at the agreed multiples of the basic rates and virtual, which involves only the endpoints) are pretty universally available in todays networks. - Arbitrary concatenation is not something that can be easily added to the installed equipment. It generally needs different ASICs. While it may be possible to build new port boards for existing NEs with the different ASICs, this doesn't help you with respect to providing the capability on installed links that are currently providing service. There is no graceful way to replace port boards in service without creating a traffic hit on that existing service. This is not something that can be added to most installed NEs with only a software upgrade. - Many of the operators of these existing networks would like to offer switched SONET/SDH services using GMPLS or some other form of control and signaling. There is a hope and expectation that this can be deployed in existing networks through software upgrades to some existing NEs and perhaps some additional controllers. If a fork lift replacement of every NE in the switching path is needed, I don't think you will see rapid acceptance among established operators. I think it is also expected that this capability can be inserted gradually into existing networks - some NEs may simply provide nailed up pipes between the NEs where the switching functions are actually performed, and those NEs shouldn't require any kind of upgrade. Basing the control plane on currently standardized forms of concationation would provide a much smoother path to incorporate GMPLS capabilities into many existing networks. Let me reiterate the hope that the advocates of arbitrary concatenation will be contributing a precise proposal to the June meeting of T1X1 and the October meeting of ITU-T Study Group 15. We could save a lot of emails if everyone had the same picture about what SONET/SDH really is. Regards, Steve Trowbridge Chairman, ITU-T WP 3/15 "Mannie, Eric" wrote: > > Hello Tony > > >Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This > >is the point I have been trying to make all along. > > To be more precise, arbitrary concatenation won't work over SONET/SDH nodes > that don't implement it, whatever there is a control plane or not. Arbitray > concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's, > TM's, etc... Folks didn't wait for a control plane to implement it. > > Kind regards, > > Eric > > -----Original Message----- > From: tony.flavin@bt.com [mailto:tony.flavin@bt.com] > Sent: Friday, June 01, 2001 9:33 AM > To: jdrake@calient.net; zwlin@lucent.com > Cc: rcoltun@redback.com; ccamp@ops.ietf.org > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > Sorry, > > Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This > is the point I have been trying to make all along. > > Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not. > > Tony > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 30 May 2001 15:45 > To: 'Zhi-Wei Lin'; John Drake > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > I didn't say that, and I don't think that it is true. > > It is my understanding that if there was a set of SONET/SDH pipes between a > pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use > those pipes however they wished as long as they were consistent with > SONET/SDH > transport protocols and the non-GMPLS nodes wouldn't need to understand what > they were doing. > > I think that this is exactly the same situation as virtual concatenation, > where > the endpoints are upgraded without disturbing the intermediate equipment. > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, May 30, 2001 7:32 AM > To: John Drake > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > Hi John, > > Yes I agree. As long as the GMPLS nodes are consistent with the > non-GMPLS cloud, then there is no interop issue. > > As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud > would also need to support this. Then it not only impacts new equipment, > but also require upgrades to embedded equipment as well for this to > work? > > Zhi > > John Drake wrote: > > > > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not > > interacting with the GMPLS > > nodes wrt signalling. This means that the links between the GMPLS nodes > at > > the edges of the non-GMPLS cloud > > are pre-configured SONET/SDH pipes. This also means that as long as what > > the GMPLS nodes are doing > > with those pipes is consistent wrt SONET/SDH transport protocols, e.g., > > arbitrary concat, then there > > is no interoperability issue. > > > > I think that this is the point that Eric has been making, which has tended > > to get lost in the noise. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > > Sent: Wednesday, May 30, 2001 5:54 AM > > To: John Drake > > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > > > Hi John, > > > > I'm not sure it's all new boxes. Would you consider this scenario valid? > > > > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you > > might go over legacy systems. The no-GMPLS area is simply providing a > > "tunnel" between the two GMPLS areas. > > > > Do we consider such examples? > > > > Zhi > > > > John Drake wrote: > > > > > > Rob, > > > > > > It was my understanding that that BGP Capabilities and BGP Multiprotocol > > > extensions include a set of code points called "vendor-specific". > > > > > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for > OSPF), > > > there is the following: > > > > > > Sub-TLV type Length (octets) Name > > > > > > 250-254 Reserved for cisco specific > > > extensions > > > > > > More importantly, what I thought Eric was saying was that the > capabilities > > > under > > > discussion, i.e., transparency and arbitrary concatenation, didn't > require > > > any > > > changes to the SONET/SDH standards. Rather, it would require changes to > > the > > > cross-connects between the SONET/SDH spans. Since these are new boxes, > it > > > doesn't > > > sound like such a big deal. > > > > > > Thanks, > > > > > > John > > > -----Original Message----- > > > From: Rob Coltun [mailto:rcoltun@redback.com] > > > Sent: Friday, May 25, 2001 4:20 PM > > > To: John Drake > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > > > > > Hi John, > > > valid question - I don't think this is true for BGP. There are > > > extensions > > > to BGP that the working group has adopted. > > > Which TE drafts are you referring to? > > > > > > We've said from the beginning that we didn't want to define new "data > > plane" > > > functionality for technologies where the data plane is being defined > > > elsewhere > > > - whereas some of the functions aren't really new, and in cases might be > > > de-facto standard > > > we recognize that certain "data plane" functionality are beyond the > scope > > > of the IETF to define - so this keeps us more in line with (in this > case) > > > the ITU. > > > > > > Note that IETF has defined the > > > MPLS data plane - if some other body were to define new functionality > > > for the MPLS data plane it would certainly cause confusion in the > > industry. > > > This standard stuff is certainly not easy. > > > > > > Is it really that big an issue to just keep them in a separate RFC? > > > > > > thanks, > > > ---rob > > > > > > John Drake wrote: > > > > > > > Rob, > > > > > > > > Why isn't the proposed disclaimer sufficient? If you look in the base > > TE > > > > drafts, for example, there are codepoints defined for use by specific, > > > > named, vendors. I think the same is also true for BGP. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > -----Original Message----- > > > > From: Rob Coltun [mailto:rcoltun@redback.com] > > > > Sent: Thursday, May 24, 2001 6:54 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > > > > > > > All, > > > > despite the heated arguments I think the discussion is important > to > > > > have. > > > > > > > > I suggest that instead of tagging non/pre-standard items in the > current > > > > drafts > > > > that they be put into a separate Informational document - this is the > > > > cleanest thing to do. > > > > We (the IETF) do have a tradition of publishing company proprietary > > > > protocols > > > > but not as standard track documents. > > > > > > > > thanks, > > > > ---rob Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 08:08:01 -0700 Message-ID: From: tony.flavin@bt.com To: Eric.Mannie@ebone.com, tony.flavin@bt.com, jdrake@calient.net, zwlin@lucent.com Cc: rcoltun@redback.com, ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Date: Fri, 1 Jun 2001 15:54:07 +0100 MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Eric, Could we halt the circular arguments. Arbitrary concatenation is not a part of SDH/SONET as defined in ITU, ETSI, or as far as I'm aware ANSI. It has not yet been introduced to ITU. It is being talked about in the same breath as GMPLS etc, so I associate GMPLS as wishing to introduce the feature. Regardless of whether this is correct or nor, arbitrary concatenation is not standardised and will not be transported by existing SDH/SONET networks. Therefore people who are proposing the use of it should be made aware that it will not work over existing networks, but there are alternatives that will. regards Tony -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: 01 June 2001 09:19 To: 'tony.flavin@bt.com'; jdrake@calient.net; zwlin@lucent.com Cc: rcoltun@redback.com; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Hello Tony >Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This >is the point I have been trying to make all along. To be more precise, arbitrary concatenation won't work over SONET/SDH nodes that don't implement it, whatever there is a control plane or not. Arbitray concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's, TM's, etc... Folks didn't wait for a control plane to implement it. Kind regards, Eric -----Original Message----- From: tony.flavin@bt.com [mailto:tony.flavin@bt.com] Sent: Friday, June 01, 2001 9:33 AM To: jdrake@calient.net; zwlin@lucent.com Cc: rcoltun@redback.com; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Sorry, Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This is the point I have been trying to make all along. Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not. Tony -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 30 May 2001 15:45 To: 'Zhi-Wei Lin'; John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation I didn't say that, and I don't think that it is true. It is my understanding that if there was a set of SONET/SDH pipes between a pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use those pipes however they wished as long as they were consistent with SONET/SDH transport protocols and the non-GMPLS nodes wouldn't need to understand what they were doing. I think that this is exactly the same situation as virtual concatenation, where the endpoints are upgraded without disturbing the intermediate equipment. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, May 30, 2001 7:32 AM To: John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: Re: [IP-Optical] Re: Proposed text for the concatenation Hi John, Yes I agree. As long as the GMPLS nodes are consistent with the non-GMPLS cloud, then there is no interop issue. As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud would also need to support this. Then it not only impacts new equipment, but also require upgrades to embedded equipment as well for this to work? Zhi John Drake wrote: > > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not > interacting with the GMPLS > nodes wrt signalling. This means that the links between the GMPLS nodes at > the edges of the non-GMPLS cloud > are pre-configured SONET/SDH pipes. This also means that as long as what > the GMPLS nodes are doing > with those pipes is consistent wrt SONET/SDH transport protocols, e.g., > arbitrary concat, then there > is no interoperability issue. > > I think that this is the point that Eric has been making, which has tended > to get lost in the noise. > > Thanks, > > John > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, May 30, 2001 5:54 AM > To: John Drake > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > Hi John, > > I'm not sure it's all new boxes. Would you consider this scenario valid? > > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you > might go over legacy systems. The no-GMPLS area is simply providing a > "tunnel" between the two GMPLS areas. > > Do we consider such examples? > > Zhi > > John Drake wrote: > > > > Rob, > > > > It was my understanding that that BGP Capabilities and BGP Multiprotocol > > extensions include a set of code points called "vendor-specific". > > > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF), > > there is the following: > > > > Sub-TLV type Length (octets) Name > > > > 250-254 Reserved for cisco specific > > extensions > > > > More importantly, what I thought Eric was saying was that the capabilities > > under > > discussion, i.e., transparency and arbitrary concatenation, didn't require > > any > > changes to the SONET/SDH standards. Rather, it would require changes to > the > > cross-connects between the SONET/SDH spans. Since these are new boxes, it > > doesn't > > sound like such a big deal. > > > > Thanks, > > > > John > > -----Original Message----- > > From: Rob Coltun [mailto:rcoltun@redback.com] > > Sent: Friday, May 25, 2001 4:20 PM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > > > Hi John, > > valid question - I don't think this is true for BGP. There are > > extensions > > to BGP that the working group has adopted. > > Which TE drafts are you referring to? > > > > We've said from the beginning that we didn't want to define new "data > plane" > > functionality for technologies where the data plane is being defined > > elsewhere > > - whereas some of the functions aren't really new, and in cases might be > > de-facto standard > > we recognize that certain "data plane" functionality are beyond the scope > > of the IETF to define - so this keeps us more in line with (in this case) > > the ITU. > > > > Note that IETF has defined the > > MPLS data plane - if some other body were to define new functionality > > for the MPLS data plane it would certainly cause confusion in the > industry. > > This standard stuff is certainly not easy. > > > > Is it really that big an issue to just keep them in a separate RFC? > > > > thanks, > > ---rob > > > > John Drake wrote: > > > > > Rob, > > > > > > Why isn't the proposed disclaimer sufficient? If you look in the base > TE > > > drafts, for example, there are codepoints defined for use by specific, > > > named, vendors. I think the same is also true for BGP. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Rob Coltun [mailto:rcoltun@redback.com] > > > Sent: Thursday, May 24, 2001 6:54 PM > > > To: ccamp@ops.ietf.org > > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > > > > > All, > > > despite the heated arguments I think the discussion is important to > > > have. > > > > > > I suggest that instead of tagging non/pre-standard items in the current > > > drafts > > > that they be put into a separate Informational document - this is the > > > cleanest thing to do. > > > We (the IETF) do have a tradition of publishing company proprietary > > > protocols > > > but not as standard track documents. > > > > > > thanks, > > > ---rob Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 08:04:02 -0700 Message-ID: <0CD7D73C734BD411AEE100B0D0220404019F6904@mail1.tellium.com> From: Dimitrios Pendarakis To: "'Jonathan Lang'" , "'Fong Liaw'" , "'suresh Katukam'" Cc: "'Jennifer Yates'" , mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last call - RSVP problems Date: Fri, 1 Jun 2001 10:57:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, The problem with being in meetings is it took me a long time to respond -:) So, I 'll try to provide a summary of the messages exchanged as well as my understanding of our off-line discussion on the applicability of RSVP and LMP Hello mechanisms. An attempt on terminology clarification first: Control channel: This is a logical channel over which IP control packets are transported between two network elements (for example a UNI-C and UNI-N in the case of the OIF UNI). A control channel can be realized in multiple ways, for example, in-fiber using SONET/SDH overhead bytes, out-of-band over an Ethernet, etc. A pair of network elements may be connected by multiple control channels, used either concurrently or in a primary-backup configuration. Control channel failures can be detected using link management procedures, such as the LMP Hello mechanism. Signaling channel: This is a logical channel over which signaling messages are exchanged between two peers. The signaling channel is realized using (potentially multiple) control channels and it operation relies on processing of signaling messages by the respective peer signaling entities. A signaling channel failure is the result of failure of all control channels, or failure of a signaling entity. Signaling channel failures can be detected using the RSVP hello mechanism (assuming of course RSVP is the signaling protocol used!). Hope this helps, Dimitrios > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Wednesday, May 30, 2001 2:08 PM > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; > 'suresh Katukam' > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last call - RSVP problems > > > Dimitrios, > The luxury of being in meetings all morning is that I had > the chance to > read your email as well as the responses from David, Lyndon, > and Eric before > I respond. Since I agree with their response, I will try to be brief. > Using RSVP Hellos to detect RSVP module failures is in my > mind the correct > usage for them. Control channel failures should be detected > by mechanisms > designed to detect them (e.g., LMP Hellos). One scenario > that carriers are > interested in supporting is the notion of having parallel > redundant control > channels for signaling purposes. We will need to support > other mechanisms > for detecting control channel failures in this case. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > Sent: Wednesday, May 30, 2001 7:24 AM > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam' > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > Subject: RE: Last call - RSVP problems > > > > > > Jonathan, > > > > Could you please clarify why you think RSVP Hello doesn't work for > > parallel (redundant) control channels? Control channel redundancy > > is obviously important; however I don't think it relates to the > > usefulness of the RSVP hello mechanism, at least in the context of > > this discussion. > > > > The whole issue is one of layering: LMP hello allows you to detect > > individual link (or control channel) failures; RSVP Hello allows > > you to detect that you 've lost contact with your signaling peer > > for whatever reason (failure of all redundant control channels, > > failure of the RSVP daemon, etc.). Since they operate at different > > levels they are to some extend complementary; once RSVP Hello tells > > you that your peer is not reachable, you could use LMP Hello's to > > try to pinpoint where the problem occurred. > > > > For clarification, the "control channel failure" mentioned in > > Fong's mail that started this discussion refers to a failure of the > > signaling channel, i.e., inability to communicate with your > signaling > > peer, not failure of specific (individual) control > channels. As such, > > I still believe RSVP Hello is a more accurate detection mechanism. > > > > Please see some additional comments inline. > > > > Thanks, > > Dimitris > > > > > > > If you're using the RSVP Hello to detect the failure of the > > > RSVP module > > > only, then this is fine. If you're using the RSVP Hello to > > detect (or > > > rather, infer) control channel failures, I have a problem. > > > For starters, I > > > don't think it works for parallel (redundant) control > > > channels; if control > > > channel redundancy is *not* important for SPs, then it's not > > > as much of an > > > issue, however, I think you're overloading the semantics of > > > the RSVP Hello. > > > > > > See additional comments inline. > > > > > > Thanks, > > > Jonathan > > > > > > > > > > > Hi Jonathan, > > > > > > > > What needs to be detected here is the inability to send and > > > > receive signaling messages to and from your RSVP peer. In this > > > > respect, using RSVP Hello is a more accurate mechanism for > > > > detecting failures since it is part of the RSVP protocol and > > > > independent of the link layer used to realize the control > > > > channel. As you point out, if you prefer redundant control > > > > channels for resiliency, and want to rely on LMP only, you have > > > > to correlate all LMP detected failures in order to declare a > > > > control channel failure. > > > This is not correct. LMP allows you to detect individual > > > control channel > > > failures, even when there are multiple (redundant) control > > > channels. The > > > RSVP Hello cannot do this. > > > > > > > Sure, as I pointed above, RSVP Hello is not intended to detect > > individual link failures. At the risk of sounding repetitive, the > > point here is that these are different mechanisms that serve > > different purpose. For example, if you have 3 (redundant) > IP control > > channels and rely on LMP Hello only, in order to infer > failure of the > > signaling channel with your peer, you would have to correlate LMP > > failures in all three channels. > > > > > > With RSVP Hello you would rely on a > > > > single set of event(s) to detect the failure. > > > To be clear, the failure of the RSVP module. > > > > Or simultaneous failure of all IP control channels... > > > > > > > > > To go even further, what if all your control channels > are working > > > > fine, but your RSVP daemon has crashed, for whatever reason. > > > > LMP hellos will keep going across but RSVP messages will not... > > > This is where the RSVP Hello has its place. > > > > > > > > > > > All this points to the (certainly non-trivial) problem > of failure > > > > detection and correlation at different layers. I am not > trying to > > > > say that RSVP Hello is the perfect or only mechanism we > > should rely > > > > on, but it certainly has a place in addressing the problem. > > > agreed. see above comment. > > > > > > > > > > > Thanks, > > > > Dimitris > > > > > > > > PS. Hopefully we are not too far apart so we might not have > > > > to keep the discussion going for too long :-) > > > > In any case I believe it has some relevance here as well. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: Friday, May 25, 2001 6:56 PM > > > > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong > Liaw'; 'suresh > > > > > Katukam'; v.sharma@ieee.org > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > Dimitris, > > > > > The RSVP Hello Extension is intended to detect node > > > > failures and not > > > > > necessarily link (control channel) failures. In particular, > > > > > the tunnel > > > > > draft says, "It should be noted that node failure detection > > > > > is not the same > > > > > as a link failure detection mechanism, particularly in the > > > > > case of multiple > > > > > parallel unnumbered links." What happens if you want > > > > > redundant control > > > > > channels for control-channel resiliency? I believe you would > > > > > still want a > > > > > mechanism to detect control channel (link-layer) failures. > > > > > > > > > > In LMP, you can have multiple active control channels > > > > > between a pair of > > > > > nodes. You can configure control channels over shared > > > > > Ethernet and over > > > > > SONET/SDH overhead, etc. You send keep-alive Hellos over > > > > each control > > > > > channel. If you so desire, you can send all signaling > > > > > messages over the > > > > > Ethernet control channels. You can also choose to send all > > > > > remaining LMP > > > > > messages over the SONET/SDH-based control channels. Keeping > > > > > RSVP Hellos as > > > > > "optional" would be fine. Making them mandatory doesn't seem > > > > > like the right > > > > > solution. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > P.S. Should we move this discussion on the OIF list?? > > > > > > > > > > > -----Original Message----- > > > > > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > > > > > Sent: Friday, May 25, 2001 3:16 PM > > > > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; > > > > > v.sharma@ieee.org > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > One point to consider is that the signaling control > > > > > > channel might be realized over a different link layer > > > > > > than LMP. For example, LMP might be running in-fiber > > > > > > over SONET/SDH overhead bytes, while RSVP is running > > > > > > over an out-of-band network such a shared Ethernet. > > > > > > RSVP Hello allows independent detection of signaling > > > > > > channel failure, so it's a useful option to keep. > > > > > > > > > > > > Thanks, > > > > > > Dimitris > > > > > > > > > > > > Dimitris Pendarakis > > > > > > Tellium, Inc. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > > > Sent: Friday, May 25, 2001 5:30 PM > > > > > > > To: 'Fong Liaw'; 'suresh Katukam'; v.sharma@ieee.org > > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > > > > Fong, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Same as (2), any proposals that remove the refresh > > > mechanism > > > > > > > > is going to be difficult to prove that all cases > > > are covered. > > > > > > > > > > > > > > > > Instead, we (will) recommend the following in OIF UNI > > > > document: > > > > > > > > > > > > > > > > Use RSVP Hello to detect control channel failure. > > > > > > > Why wouldn't you use the LMP Hello to detect > > control channel > > > > > > > failure? This > > > > > > > is exactly what it is designed for. From > > > > > > > draft-ietf-mpls-lsp-tunnel-08.txt, > > > > > > > > > > > > > > "This (RSVP Hello) mechanism is intended to be > used when > > > > > > > notification of > > > > > > > link layer > > > > > > > failures is not available and unnumbered links are not > > > > > > > used, or when > > > > > > > the failure detection mechanisms provided by the link > > > > > > layer are not > > > > > > > sufficient for timely node failure detection." > > > > > > > > > > > > > > > If a control channel failure is detected, > LSPs states > > > > > > > > are maintained as if a node continues to receive > > > > > > > > RSVP refresh message from the failed control channel. > > > > > > > > The recommended Hello timer will be in second range, > > > > > > > > instead of ms range specified in RSVP-TE draft. > > > > > > > > > > > > > > > > If a control channel failed permanently, manual > > > > intervention > > > > > > > > may be required. This is to be studied. > > > > > > > > > > > > > > > > p.s The text is currently being drafted as we type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 01:27:31 -0700 Message-ID: From: "Mannie, Eric" To: "'tony.flavin@bt.com'" , jdrake@calient.net, zwlin@lucent.com Cc: rcoltun@redback.com, ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Date: Fri, 1 Jun 2001 10:18:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Tony >Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This >is the point I have been trying to make all along. To be more precise, arbitrary concatenation won't work over SONET/SDH nodes that don't implement it, whatever there is a control plane or not. Arbitray concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's, TM's, etc... Folks didn't wait for a control plane to implement it. Kind regards, Eric -----Original Message----- From: tony.flavin@bt.com [mailto:tony.flavin@bt.com] Sent: Friday, June 01, 2001 9:33 AM To: jdrake@calient.net; zwlin@lucent.com Cc: rcoltun@redback.com; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Sorry, Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This is the point I have been trying to make all along. Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not. Tony -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 30 May 2001 15:45 To: 'Zhi-Wei Lin'; John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation I didn't say that, and I don't think that it is true. It is my understanding that if there was a set of SONET/SDH pipes between a pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use those pipes however they wished as long as they were consistent with SONET/SDH transport protocols and the non-GMPLS nodes wouldn't need to understand what they were doing. I think that this is exactly the same situation as virtual concatenation, where the endpoints are upgraded without disturbing the intermediate equipment. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, May 30, 2001 7:32 AM To: John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: Re: [IP-Optical] Re: Proposed text for the concatenation Hi John, Yes I agree. As long as the GMPLS nodes are consistent with the non-GMPLS cloud, then there is no interop issue. As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud would also need to support this. Then it not only impacts new equipment, but also require upgrades to embedded equipment as well for this to work? Zhi John Drake wrote: > > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not > interacting with the GMPLS > nodes wrt signalling. This means that the links between the GMPLS nodes at > the edges of the non-GMPLS cloud > are pre-configured SONET/SDH pipes. This also means that as long as what > the GMPLS nodes are doing > with those pipes is consistent wrt SONET/SDH transport protocols, e.g., > arbitrary concat, then there > is no interoperability issue. > > I think that this is the point that Eric has been making, which has tended > to get lost in the noise. > > Thanks, > > John > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, May 30, 2001 5:54 AM > To: John Drake > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > Hi John, > > I'm not sure it's all new boxes. Would you consider this scenario valid? > > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you > might go over legacy systems. The no-GMPLS area is simply providing a > "tunnel" between the two GMPLS areas. > > Do we consider such examples? > > Zhi > > John Drake wrote: > > > > Rob, > > > > It was my understanding that that BGP Capabilities and BGP Multiprotocol > > extensions include a set of code points called "vendor-specific". > > > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF), > > there is the following: > > > > Sub-TLV type Length (octets) Name > > > > 250-254 Reserved for cisco specific > > extensions > > > > More importantly, what I thought Eric was saying was that the capabilities > > under > > discussion, i.e., transparency and arbitrary concatenation, didn't require > > any > > changes to the SONET/SDH standards. Rather, it would require changes to > the > > cross-connects between the SONET/SDH spans. Since these are new boxes, it > > doesn't > > sound like such a big deal. > > > > Thanks, > > > > John > > -----Original Message----- > > From: Rob Coltun [mailto:rcoltun@redback.com] > > Sent: Friday, May 25, 2001 4:20 PM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > > > Hi John, > > valid question - I don't think this is true for BGP. There are > > extensions > > to BGP that the working group has adopted. > > Which TE drafts are you referring to? > > > > We've said from the beginning that we didn't want to define new "data > plane" > > functionality for technologies where the data plane is being defined > > elsewhere > > - whereas some of the functions aren't really new, and in cases might be > > de-facto standard > > we recognize that certain "data plane" functionality are beyond the scope > > of the IETF to define - so this keeps us more in line with (in this case) > > the ITU. > > > > Note that IETF has defined the > > MPLS data plane - if some other body were to define new functionality > > for the MPLS data plane it would certainly cause confusion in the > industry. > > This standard stuff is certainly not easy. > > > > Is it really that big an issue to just keep them in a separate RFC? > > > > thanks, > > ---rob > > > > John Drake wrote: > > > > > Rob, > > > > > > Why isn't the proposed disclaimer sufficient? If you look in the base > TE > > > drafts, for example, there are codepoints defined for use by specific, > > > named, vendors. I think the same is also true for BGP. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Rob Coltun [mailto:rcoltun@redback.com] > > > Sent: Thursday, May 24, 2001 6:54 PM > > > To: ccamp@ops.ietf.org > > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > > > > > All, > > > despite the heated arguments I think the discussion is important to > > > have. > > > > > > I suggest that instead of tagging non/pre-standard items in the current > > > drafts > > > that they be put into a separate Informational document - this is the > > > cleanest thing to do. > > > We (the IETF) do have a tradition of publishing company proprietary > > > protocols > > > but not as standard track documents. > > > > > > thanks, > > > ---rob Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 01 Jun 2001 00:44:01 -0700 Message-ID: From: tony.flavin@bt.com To: jdrake@calient.net, zwlin@lucent.com Cc: rcoltun@redback.com, ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation Date: Fri, 1 Jun 2001 08:32:44 +0100 MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sorry, Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This is the point I have been trying to make all along. Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not. Tony -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 30 May 2001 15:45 To: 'Zhi-Wei Lin'; John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: RE: [IP-Optical] Re: Proposed text for the concatenation I didn't say that, and I don't think that it is true. It is my understanding that if there was a set of SONET/SDH pipes between a pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use those pipes however they wished as long as they were consistent with SONET/SDH transport protocols and the non-GMPLS nodes wouldn't need to understand what they were doing. I think that this is exactly the same situation as virtual concatenation, where the endpoints are upgraded without disturbing the intermediate equipment. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: Wednesday, May 30, 2001 7:32 AM To: John Drake Cc: 'Rob Coltun'; ccamp@ops.ietf.org Subject: Re: [IP-Optical] Re: Proposed text for the concatenation Hi John, Yes I agree. As long as the GMPLS nodes are consistent with the non-GMPLS cloud, then there is no interop issue. As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud would also need to support this. Then it not only impacts new equipment, but also require upgrades to embedded equipment as well for this to work? Zhi John Drake wrote: > > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not > interacting with the GMPLS > nodes wrt signalling. This means that the links between the GMPLS nodes at > the edges of the non-GMPLS cloud > are pre-configured SONET/SDH pipes. This also means that as long as what > the GMPLS nodes are doing > with those pipes is consistent wrt SONET/SDH transport protocols, e.g., > arbitrary concat, then there > is no interoperability issue. > > I think that this is the point that Eric has been making, which has tended > to get lost in the noise. > > Thanks, > > John > > -----Original Message----- > From: Zhi-Wei Lin [mailto:zwlin@lucent.com] > Sent: Wednesday, May 30, 2001 5:54 AM > To: John Drake > Cc: 'Rob Coltun'; ccamp@ops.ietf.org > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > Hi John, > > I'm not sure it's all new boxes. Would you consider this scenario valid? > > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you > might go over legacy systems. The no-GMPLS area is simply providing a > "tunnel" between the two GMPLS areas. > > Do we consider such examples? > > Zhi > > John Drake wrote: > > > > Rob, > > > > It was my understanding that that BGP Capabilities and BGP Multiprotocol > > extensions include a set of code points called "vendor-specific". > > > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF), > > there is the following: > > > > Sub-TLV type Length (octets) Name > > > > 250-254 Reserved for cisco specific > > extensions > > > > More importantly, what I thought Eric was saying was that the capabilities > > under > > discussion, i.e., transparency and arbitrary concatenation, didn't require > > any > > changes to the SONET/SDH standards. Rather, it would require changes to > the > > cross-connects between the SONET/SDH spans. Since these are new boxes, it > > doesn't > > sound like such a big deal. > > > > Thanks, > > > > John > > -----Original Message----- > > From: Rob Coltun [mailto:rcoltun@redback.com] > > Sent: Friday, May 25, 2001 4:20 PM > > To: John Drake > > Cc: ccamp@ops.ietf.org > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation > > > > Hi John, > > valid question - I don't think this is true for BGP. There are > > extensions > > to BGP that the working group has adopted. > > Which TE drafts are you referring to? > > > > We've said from the beginning that we didn't want to define new "data > plane" > > functionality for technologies where the data plane is being defined > > elsewhere > > - whereas some of the functions aren't really new, and in cases might be > > de-facto standard > > we recognize that certain "data plane" functionality are beyond the scope > > of the IETF to define - so this keeps us more in line with (in this case) > > the ITU. > > > > Note that IETF has defined the > > MPLS data plane - if some other body were to define new functionality > > for the MPLS data plane it would certainly cause confusion in the > industry. > > This standard stuff is certainly not easy. > > > > Is it really that big an issue to just keep them in a separate RFC? > > > > thanks, > > ---rob > > > > John Drake wrote: > > > > > Rob, > > > > > > Why isn't the proposed disclaimer sufficient? If you look in the base > TE > > > drafts, for example, there are codepoints defined for use by specific, > > > named, vendors. I think the same is also true for BGP. > > > > > > Thanks, > > > > > > John > > > > > > -----Original Message----- > > > From: Rob Coltun [mailto:rcoltun@redback.com] > > > Sent: Thursday, May 24, 2001 6:54 PM > > > To: ccamp@ops.ietf.org > > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation > > > > > > All, > > > despite the heated arguments I think the discussion is important to > > > have. > > > > > > I suggest that instead of tagging non/pre-standard items in the current > > > drafts > > > that they be put into a separate Informational document - this is the > > > cleanest thing to do. > > > We (the IETF) do have a tradition of publishing company proprietary > > > protocols > > > but not as standard track documents. > > > > > > thanks, > > > ---rob