Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 30 Jun 2002 21:18:48 -0700 Date: Mon, 1 Jul 2002 09:39:48 +0530 (IST) From: Chaya To: Subject: Doubt in LMP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, When is the evdcDown event generated in data link FSM. Is it when the channel status mesg arrive, but is it not the channel status message is used when the data link is allocated? thanks, Chaya Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Jun 2002 16:08:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Manral, Vishwas" To: 'Jeff Parker' , "'mpls@UU.NET'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: Control vs Client Links in IS-IS TE Date: Fri, 28 Jun 2002 14:09:54 -0400 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi Jeff, I guess in Section 4.0 of draft http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt it is stated that If a link is advertised with the maximum link metric (2^24 - 1), this link should not be considered during the normal SPF computation. So if we want to preclude a link from normal SPF and yet use it for MPLS LSP's we can set the metric to the value 2^24 - 1. Thanks, Vishwas -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Friday, June 28, 2002 10:57 PM To: 'mpls@UU.NET' Cc: 'ccamp@ops.ietf.org' Subject: Control vs Client Links in IS-IS TE Consider a service provider who wishes to distinguish his control traffic from the network he provides subscribers, by distinguishing his control links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that only run customer traffic. Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP to router B. How can IS-IS distinguish the two types of links if it is using wide metrics? In OSPF, we can send an Opaque LSA with info about an LSP. This will not be used for the IGP's SPF. However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus looks like a normal link from A to B when the router is using Wide Metrics in the SPF. If B also has an LSP to A, other routers will have no way to distinguish an MPLS LSP link intended for CSPF and those to be used in the IGP's SPF. I could imagine using a field such as Switch Capability, to decide if a link should be included in SPF or not, but haven't seen this suggested anywhere. - jeff parker - axiowave networks Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Jun 2002 10:36:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Jeff Parker To: "'mpls@UU.NET'" Cc: "'ccamp@ops.ietf.org'" Subject: Control vs Client Links in IS-IS TE Date: Fri, 28 Jun 2002 13:27:08 -0400 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Consider a service provider who wishes to distinguish his control traffic from the network he provides subscribers, by distinguishing his control links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that only run customer traffic. Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP to router B. How can IS-IS distinguish the two types of links if it is using wide metrics? In OSPF, we can send an Opaque LSA with info about an LSP. This will not be used for the IGP's SPF. However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus looks like a normal link from A to B when the router is using Wide Metrics in the SPF. If B also has an LSP to A, other routers will have no way to distinguish an MPLS LSP link intended for CSPF and those to be used in the IGP's SPF. I could imagine using a field such as Switch Capability, to decide if a link should be included in SPF or not, but haven't seen this suggested anywhere. - jeff parker - axiowave networks Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Jun 2002 03:40:35 -0700 Message-Id: <200206281035.GAA17219@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-kim-ccamp-gmpls-nsid-00.txt Date: Fri, 28 Jun 2002 06:35:42 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Requirement of the Network State Information Database for Traffic Engineering Over GMPLS Author(s) : D. Kim Filename : draft-kim-ccamp-gmpls-nsid-00.txt Pages : 17 Date : 27-Jun-02 This document presents a set of requirements of the Network State Information Database (NSID) for Traffic Engineering over Generalized Multiprotocol Label Switching (GMPLS). The Network State Information Database is required to implement the network architecture for network models that introduce the control element of IP and to optimize the utilization of network resource. And this document includes discussion about the considerations and necessity of the several attributes to construct NSID for Traffic Engineering over GMPLS that are extended from the requirement for Traffic Engineering over MPLS [4]. These attributes can be used to maximize the utilization of network resources and to enhance resource oriented Traffic Engineering techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kim-ccamp-gmpls-nsid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kim-ccamp-gmpls-nsid-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-kim-ccamp-gmpls-nsid-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: <20020627132915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kim-ccamp-gmpls-nsid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kim-ccamp-gmpls-nsid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627132915.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Jun 2002 02:22:58 -0700 Message-Id: <4.3.2.7.2.20020628111537.0419b690@paris.cisco.com> Date: Fri, 28 Jun 2002 11:18:19 +0200 To: mpls@uu.net From: Jean Philippe Vasseur Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt Cc: ccamp@ops.ietf.org, acharny@cisco.com, flefauch@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Sorry for the confusion ... I meant: "Although, this draft fits in MPLS WG, I'm copying CCAMP as some aspects are related to the ongoing protection/restoration work done in CCAMP". And we're still interested by your comments, thanks. JP. >Date: Thu, 27 Jun 2002 17:34:22 +0200 >To: mpls@uu.net >From: Jean Philippe Vasseur >Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt >Cc: ccamp@ops.ietf.org > >Hi, > >This draft proposes a model for the backup tunnel computation to provide >bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the >capability to provide not only a fast convergence but also bandwidth >guaranties while making an efficient backup bandwidth usage. > >Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be >related to the ongoing protection/restoration work done in CCAMP. > >Any comment is of course very welcome. > >Thanks. > >JP. > >>To: IETF-Announce:; >>CC: mpls@UU.NET >>From: Internet-Drafts@ietf.org >>Reply-to: Internet-Drafts@ietf.org >>Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt >>Date: Thu, 27 Jun 2002 06:39:03 -0400 >>Sender: owner-mpls@UU.NET >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : MPLS Traffic Engineering Fast reroute: backup >> tunnel >> path computation for bandwidth protection >> Author(s) : J. Vasseur et al. >> Filename : draft-vasseur-mpls-backup-computation-00.txt >> Pages : 43 >> Date : 26-Jun-02 >> >>This draft proposes an efficient model called ''Facility based >>computation model'' for computing bypass tunnels paths in the context of >>the MPLS TE Fast Reroute, while allowing bandwidth sharing between >>backup tunnel protecting independent resources. Both a centralized and >>a distributed path computation scenarios are described. The required >>signaling extensions are also addressed in the draft. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body of the message. >> >>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-vasseur-mpls-backup-computation-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-vasseur-mpls-backup-computation-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: <20020626134733.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Jun 2002 08:37:54 -0700 Message-Id: <4.3.2.7.2.20020627154020.0753e260@paris.cisco.com> Date: Thu, 27 Jun 2002 17:34:22 +0200 To: mpls@uu.net From: Jean Philippe Vasseur Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, This draft proposes a model for the backup tunnel computation to provide bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the capability to provide not only a fast convergence but also bandwidth guaranties while making an efficient backup bandwidth usage. Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be related to the ongoing protection/restoration work done in CCAMP. Any comment is of course very welcome. Thanks. JP. >To: IETF-Announce:; >CC: mpls@UU.NET >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt >Date: Thu, 27 Jun 2002 06:39:03 -0400 >Sender: owner-mpls@UU.NET > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MPLS Traffic Engineering Fast reroute: backup > tunnel > path computation for bandwidth protection > Author(s) : J. Vasseur et al. > Filename : draft-vasseur-mpls-backup-computation-00.txt > Pages : 43 > Date : 26-Jun-02 > >This draft proposes an efficient model called ''Facility based >computation model'' for computing bypass tunnels paths in the context of >the MPLS TE Fast Reroute, while allowing bandwidth sharing between >backup tunnel protecting independent resources. Both a centralized and >a distributed path computation scenarios are described. The required >signaling extensions are also addressed in the draft. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-vasseur-mpls-backup-computation-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-vasseur-mpls-backup-computation-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: <20020626134733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Jun 2002 04:19:31 -0700 Date: Thu, 27 Jun 2002 20:15:54 +0900 From: Eiji Oki To: ccamp@ops.ietf.org Subject: Fw: I-D ACTION:draft-oki-ccamp-upstream-labelset-00.txt Message-Id: <20020627200225.B4BA.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit --------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit A new draft on Upstream Label Set was posted in the following. This draft describes an extended version of the bi-directional path setup RSVP-TE signaling procedure by using a new Upstream Label Set Object. The proposed procedure is useful in limited/non-wavelength-convertible optical networks, while it is consistent with the current version of the GMPLS RSVP-TE signaling. Your comments are appreciated. Thank you. Eiji -- Eiji Oki NTT Network Innovation Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan TEL: +81-422-59-3441 FAX: +81-422-59-6387 E-mail: oki.eiji@lab.ntt.co.jp ----------------------- Original Message ----------------------- From: Internet-Drafts@ietf.org To: IETF-Announce: ; Date: Thu, 27 Jun 2002 06:41:36 -0400 Subject: I-D ACTION:draft-oki-ccamp-upstream-labelset-00.txt ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Upstream Label Set Support in RSVP-TE extensions Author(s) : E. Oki Filename : draft-oki-ccamp-upstream-labelset-00.txt Pages : 7 Date : 26-Jun-02 This document describes extensions to GMPLS RSVP-TE signaling required to support a upstream label set when a bidirectional path is set up. In the existing drafts on GMPLS RSVP-TE signaling, a upstream label for the upstream path has to be reserved at an intermediate node before Path message is transmitted to the next-hop node. On the other hand, a label set that includes one or more labels for the downstream path is carried by Path message and then Resv message reserves a label at each interme- diate node on the route or a source node. This document proposes the way to support the upstream label set as is the case of the Label Set for downstream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-oki-ccamp-upstream-labelset-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-oki-ccamp-upstream-labelset-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. --------------------- Original Message Ends -------------------- --------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_ Content-Type: Multipart/Alternative; Boundary="OtherAccess" Content-Transfer-Encoding: 7bit --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020626135219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt --OtherAccess Content-Type: Message/External-body; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"; name="draft-oki-ccamp-upstream-labelset-00.txt" Content-Disposition: attachment; filename="draft-oki-ccamp-upstream-labelset-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020626135219.I-D@ietf.org> --OtherAccess-- --------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Jun 2002 03:45:42 -0700 Message-Id: <200206271041.GAA09713@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-oki-ccamp-upstream-labelset-00.txt Date: Thu, 27 Jun 2002 06:41:36 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Upstream Label Set Support in RSVP-TE extensions Author(s) : E. Oki Filename : draft-oki-ccamp-upstream-labelset-00.txt Pages : 7 Date : 26-Jun-02 This document describes extensions to GMPLS RSVP-TE signaling required to support a upstream label set when a bidirectional path is set up. In the existing drafts on GMPLS RSVP-TE signaling, a upstream label for the upstream path has to be reserved at an intermediate node before Path message is transmitted to the next-hop node. On the other hand, a label set that includes one or more labels for the downstream path is carried by Path message and then Resv message reserves a label at each interme- diate node on the route or a source node. This document proposes the way to support the upstream label set as is the case of the Label Set for downstream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-oki-ccamp-upstream-labelset-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-oki-ccamp-upstream-labelset-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: <20020626135219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-oki-ccamp-upstream-labelset-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135219.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Jun 2002 02:25:26 -0700 Message-Id: <5.0.2.5.2.20020627181624.00d07f88@img.m.ecl.ntt.co.jp> Date: Thu, 27 Jun 2002 18:20:02 +0900 To: ccamp@ops.ietf.org From: MATSUURA Nobuaki Subject: Fwd: I-D ACTION:draft-matsuura-reverse-lsp-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed F.Y.I. Any comments, please. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-matsuura-reverse-lsp-00.txt >Date: Mon, 24 Jun 2002 07:48:13 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Signaling Reverse-directional LSP in Generalized MPLS > Author(s) : N. Matsuura, E. Oki > Filename : draft-matsuura-reverse-lsp-00.txt > Pages : > Date : 21-Jun-02 > >Generalized MPLS extends the MPLS control plane to encompass >bidirectional LSPs. This document defines related extensions to >Generalized MPLS signaling to support the establishment of >reverse-directional LSPs. This document presents a functional >description of the extensions for signaling reverse-directional >LSPs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-matsuura-reverse-lsp-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-matsuura-reverse-lsp-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: <20020621121946.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-matsuura-reverse-lsp-00.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Jun 2002 03:45:46 -0700 Message-Id: <200206261041.GAA10423@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-aboulmagd-ccamp-crldp-ason-ext-00.txt Date: Wed, 26 Jun 2002 06:41:08 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CR-LDP Extensions for ASON Author(s) : O. Aboul-Magd Filename : draft-aboulmagd-ccamp-crldp-ason-ext-00.txt Pages : 10 Date : 25-Jun-02 This draft considers CR-LDP extensions for the support of the ITU ASON architecture (G.8080) [2] and its signaling requirements (G.7713) [3]. The CCAMP WG charter includes the statement: 'Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O- O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc.' This draft is within the CCAMP charter since it defines extensions to a CCAMP-defined signaling protocol, namely CR-LDP, for transport network tunnels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-aboulmagd-ccamp-crldp-ason-ext-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-aboulmagd-ccamp-crldp-ason-ext-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: <20020625141733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aboulmagd-ccamp-crldp-ason-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625141733.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Jun 2002 01:48:21 -0700 From: "Sushanthm" To: Subject: ERO doubt Date: Wed, 26 Jun 2002 14:16:03 +0530 Message-ID: <000201c21ced$e76b7000$6840010a@sasken.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In the section 6.0, draft-ietf-mpls-generalized-signaling-08.txt The ERO objects or ER-hop ( IP addr ) includes particular node/interface's for a desired LSP. Is it the data interface or the control interface? In optical domain,especially Lamda interface, is it only Strict routes are supported? Regards, Sushanth Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Jun 2002 08:57:27 -0700 Message-ID: From: Jonathan Lang To: ccamp@ops.ietf.org Cc: Ron Bonica , "Kireeti Kompella (E-mail)" Subject: Protection and Restoration Design Team drafts Date: Tue, 25 Jun 2002 08:44:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In addition to the updates to the Protection and Restoration analysis draft (draft-papadimitriou-ccamp-gmpls-recovery-analysis-01.txt) and terminology draft (draft-ietf-gmpls-recovery-terminology-01.txt), the Protection and Restoration design team has also produced a first version of the functional spec which can be found at http://www.cs.odu.edu/~sudheer/draft-bala-gmpls-recovery-functional-00.txt. We welcome your comments on the drafts. Thanks, GMPLS P&R Design team Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Jun 2002 04:07:26 -0700 Message-Id: <200206251102.HAA29298@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-ozugur-ccamp-gmpls-label-flag-00.txt Date: Tue, 25 Jun 2002 07:02:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label Set Priority and Flagging Operations Author(s) : T. Ozugur, D. Papadimitriou Filename : draft-ozugur-ccamp-gmpls-label-flag-00.txt Pages : 9 Date : 24-Jun-02 This document presents the GMPLS Signaling mechanisms referred to as generalized label flagging method, and RSVP-TE/CR-LDP specific signaling extensions formats needed to ease forward-link label unavailability when the downstream label selection is restricted by the upstream node using the Label Set. It also relaxes backward-link label collision when the downstream label collides with competing label selection. This method introduces the Flagged Label Set object/TLV in order to prioritize the reservation of the labels included in the Label Set enabling to decrease the forward- and backward-link blocking probability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ozugur-ccamp-gmpls-label-flag-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ozugur-ccamp-gmpls-label-flag-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-ozugur-ccamp-gmpls-label-flag-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: <20020624143804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ozugur-ccamp-gmpls-label-flag-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ozugur-ccamp-gmpls-label-flag-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143804.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Jun 2002 12:23:02 -0700 Message-Id: <4.3.2.7.2.20020624144032.01e59c78@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Mon, 24 Jun 2002 15:05:15 -0400 To: : From: "Thomas D. Nadeau" Subject: Re: draft-ietf-ccamp-gmpls-lsr-mib-00.txt Cc: cheenu@paramanet.com, afarrel@movaz.com, eph@dataconnection.com, timhall@dataconnection.com [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi, FYI, we were unable to post the CCAMP GMPLS LSR MIB by the deadline, so it is available here until after the next meeting: ftp://anonymous@ftp-eng.cisco.com/tnadeau/draft-ietf-ccamp-gmpls-lsr-mib-00.txt Please review the GMPLS-LSR and other GMPLS MIBs and send feedback to the CCAMP mailing list. The documents just published reflect the discussion we had during the last CCAMP WG meeting in Minnesota. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) Label Switched Routers (LSRs). ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Jun 2002 04:47:24 -0700 Message-Id: <200206241146.HAA29914@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-ietf-ccamp-gmpls-signaling-survey-02.txt Date: Mon, 24 Jun 2002 07:46:16 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signaling - Implementation Survey Author(s) : L. Berger, Y. Rekhter Filename : draft-ietf-ccamp-gmpls-signaling-survey-02.txt Pages : 86 Date : 21-Jun-02 This document provides a survey of GMPLS signaling implementations. The primary focus of this survey are the signaling protocol mechanisms specified in the Generalized MPLS signaling documents. Other specifications and documents are listed if included in the submitted form. The survey form and latest version of this document are available from http://www.labn.net/gmpls-survey. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ccamp-gmpls-signaling-survey-02.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-ietf-ccamp-gmpls-signaling-survey-02.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: <20020621121517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-signaling-survey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621121517.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Jun 2002 04:42:23 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3D17047A.A625C373@lucent.com> Date: Mon, 24 Jun 2002 13:37:30 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: jplang@calient.net, jdrake@calient.net, dimitri.Papadimitriou@alcatel.be Original-CC: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt Content-Type: multipart/mixed; boundary="------------1B116D1A6A920265DE0478CD" This is a multi-part message in MIME format. --------------1B116D1A6A920265DE0478CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, John, Dimitri, I'm surprised about the draft "Control Channel Bootstrap for LMP". http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt It seems somewhat premature to introduce the need to bootstrap a control channel when the control channel concept is apparently not clear. * Does a control network consist of DCC-like control channels ? * Is a control channel an IP tunnel on top of an existing control network (e.g. PPP-over-IP, RFC-2661) ? http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html * Is a control network an instantiation of a control channel ? http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00835.html With the help of Greg Bernstein, I've tried to rewrite the LMP draft (see attached file). This update proposal seems to provide the intended functionality without the need for a control channel. Hopefully this update proposal gives more clarification on what I intended to say with my email of April 9. http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html Best regards, Michiel Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Control Channel Bootstrap for LMP > Author(s) : J. Lang, J. Drake > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > Pages : 7 > Date : 10-Jun-02 > > The Link Management Protocol (LMP) requires that at least one bi- > directional control channel is established between the nodes. The > control channel may be transmitted either in-band with the data > links or out-of-band over a separate wavelength, fiber, or IP > network. This draft specifies a simple procedure to dynamically > bootstrap control channels and exchange interface mappings using a > new LMP message that is transmitted in-band over the data links. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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: <20020610143047.I-D@ietf.org> -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ --------------1B116D1A6A920265DE0478CD Content-Type: text/plain; charset=iso-8859-1; name="draft-everdingen-ccamp-lmp-update-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-everdingen-ccamp-lmp-update-00.txt" CCAMP Working Group Michiel van Everdingen = Internet Draft (Lucent Technologies) = Expiration Date: December 2002 Greg Bernstein (Ciena Corporation) = = = June 2002 = Link Management Protocol Update = = draft-everdingen-ccamp-lmp-update-00.txt = = = Status of this Memo = = This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [RFC2026]. = = Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet- Drafts. = = Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet- Drafts as reference = material or to cite them other than as "work in progress." = = The list of current Internet-Drafts can be accessed at = http://www.ietf.org/ietf/1id-abstracts.txt = = The list of Internet-Draft Shadow Directories can be accessed at = http://www.ietf.org/shadow.html. = = = Abstract = = Optical networks are being developed to include photonic switches, = optical crossconnects, SONET/SDH crossconnects and routers. These = networks consist of data links and a logically separated control = network. Furthermore, multiple data links may be combined to form a = single traffic engineering (TE) link for routing purposes. This = draft proposes an update of the Link Management Protocol LMP. LMP = runs between neighboring nodes (regarding data links) and is used to = manage TE links. Specifically, LMP can be used to discover and = verify the physical connectivity of the data links, correlate the = data link property information, suppress downstream alarms, and = localize link failures for protection/restoration purposes in GMPLS = switched networks. = = Everdingen et al [Page 1] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Table of Contents = 1. Introduction..................................................3 = 2. LMP Overview..................................................6 = 3. Neighbor Discovery............................................8 = 4. Link Property Correlation....................................12 = 5. Verifying Data Link Connectivity.............................14 = 5.1. Example of Link Connectivity Verification................16 = 6. Fault Management.............................................18 = 6.1. Fault Detection..........................................19 = 6.2. Fault Localization Procedure.............................19 = 6.3. Examples of Fault Localization...........................19 = 7. Addressing...................................................23 = 8. LMP Authentication...........................................23 = 9. IANA Considerations..........................................23 = 10. LMP Finite State Machines....................................24 = 10.1. TE Link FSM.............................................24 = 10.2. Data Link FSM...........................................25 = 11. LMP Message Formats..........................................29 = 11.1. Common Header...........................................29 = 11.2. LMP Object Format.......................................30 = 11.3. Authentication..........................................31 = 11.4. Link Verification.......................................33 = 11.5. Link Summary Messages...................................36 = 11.6. Fault Management Messages...............................37 = 12. LMP Object Definitions.......................................39 = 12.1. NODE_ID Classes.........................................39 = 12.2. LINK _ID Classes........................................40 = 12.3. INTERFACE_ID Classes....................................41 = 12.4. MESSAGE_ID Class........................................41 = 12.5. MESSAGE_ID_ACK Class....................................42 = 12.6. BEGIN_VERIFY Class......................................42 = 12.7. BEGIN_VERIFY_ACK Class..................................43 = 12.8. VERIFY_ID Class.........................................43 = 12.9. TE_LINK Class...........................................43 = 12.10. DATA_LINK Class........................................44 = 12.11. CHANNEL_STATUS Class...................................48 = 12.12. CHANNEL_STATUS_REQUEST Class...........................49 = 12.13. ERROR_CODE Class.......................................49 = 13. Security Considerations......................................51 = 14. References...................................................51 = 15. Authors' Addresses...........................................52 = = Everdingen et al [Page 2] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Changes compared to [LMP] = = - Removed the concept "control channel". = - Removed possibility of (UDP over HDLC encoded) test messages to = be directly sent on DCC channels, bypassing the DCN network = - Included optional procedure for neighbor discovery. = - Made clear that LMP's fault management procedure implements = a tandem connection monitoring function. = - Several editorial changes (a.o. in abstract and introduction) = = 1. Introduction = = Optical network elements can use a common control plane like GMPLS to = dynamically allocate resources and to provide network survivability = using protection and restoration techniques. These optical network = elements form together an optical network. = = Optical networks consist of several layer networks. The main layers = are: = - OC-N / STM-N: a layer consisting of OC-N/SMN-N data links = - STS-N / HO-VC: a layer consisting of STS-N/HO-VC data links = - VT-1.5 / LO-VC: a layer consisting of VT-1.5/LO-VC data links = = As seen from a single layer network, three functions are of interest: = - Optical Switching (OXC) = - Optical Multiplexing (MUX) = - Optical Termination (TRM). = = From an OC-N, STM-n perspective: = - Optical Line Systems (OLS) contain the MUX function: these systems = multiplex OC-n/STM-n signals into a DWDM signal. = - Fully transparent optical cross connects contain the OXC function. = - SONET/SDH ADMs and IP Routers contain the TRM function. = = From an HO-VC, STS-N perspective: = - Optical Line Systems (OLS) are not visible. = - Fully transparent optical cross connects are not visible. = - SONET/SDH ADMs contain the OXC, MUX and TRM functions. = - IP Routers contain the TRM function. = = In the remainder of this document, we will refer to these optical = functions (OXC, MUX and TRM) as 'nodes'. = = LMP can be used for any type of optical network element, regardless = if the network combines an OXC and a MUX function or not. = = A pair of nodes (e.g., two OXCs) may be connected by thousands of = fibers. In this document, these fibers are more generally called = data links. Note that these data links may be multiplexed together = in multiplexing systems. Furthermore, independently of this = multiplexing, multiple data links may be combined into a single = traffic-engineering (TE) link for routing purposes. = = Everdingen et al [Page 3] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = To enable communication between nodes for routing, signaling, and = link management, a control network must be present that connects = every pair of nodes that are neighbors regarding data links. = = This draft specifies an update of the link management protocol [LMP]. = LMP runs between neighboring nodes (neighboring regarding the data = links) and is used to manage TE links; see Figure 1. = = +------+ +------+ +------+ +------+ = | | ----- | | ----- | | ----- | | = | TRM1 | ----- | OXC1 | ----- | OXC2 | ----- | TRM2 | = | | ----- | | ----- | | ----- | | = +------+ +------+ +------+ +------+ = ^ ^ ^ ^ ^ ^ = | | | | | | = +----LMP---+ +----LMP----+ +---LMP-----+ = Figure 1: LMP Model = = Note that LMP runs between nodes that are either = - Terminating the data link (TRM1 and TRM2) or = - Cross connecting the data link (OXC1 and OXC2). = = Note furthermore that LMP does not consider multiplexing nodes that = multiplex the data link (see Figure 2). A companying draft [LMP- DWDM] specifies the protocol to be used between OXC and MUX. = = +------+ +------+ +------+ +------+ = | | ----- | | | | ----- | | = | OXC1 | ----- | MUX1 | =3D=3D=3D=3D=3D | MUX2 | ----- | O= XC2 | = | | ----- | | | | ----- | | = +------+ +------+ +------+ +------+ = ^ ^ = | | = +----------------------LMP----------------------+ = Figure 2: LMP and Multiplexing nodes = = = In GMPLS, the control network between two neighboring nodes is no = longer required to use the same physical medium as the data links = between those nodes. For example, a control network could use = separate wavelengths, fibers or Ethernet links and may contain IP = routers that are not involved in any operation on the data links. = = A consequence of allowing the control network to be physically = diverse from the associated data links is that the health of this = control network does not necessarily correlate to the health of the = data links, and vice-versa. Therefore, a clean separation between = the fate of the control network and data links must be made. = = = Everdingen et al [Page 4] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Each of the two end-points of a data link will be either a TTP or a = CTP, depending on its multiplexing capability. A TTP, which resides = in a TRM node, terminates the data link. A CTP, which resides in an = OXC node, transparently cross connects the signal on the data link. = = The distinction between TTP and CTP is important since the management = of the data-bearing links (including, for example, discovery and = verification) is different based on the type of end-points connected. = = For example, a SONET crossconnect is a TTP for an OC-192 data link. = This implies that, for this data link, the SONET crossconnect will = always send out the same access point identifier in the in-band J0 = signal. In contrast, a photonic cross connect, which is a CTP for an = OC-192 data link, may use the in-band J0 signal as a kind of "test- signal". = = If data links are grouped together into a single TE link using link = bundling [BUNDLE], then the link resources must be identified using = two levels: TE link Id, and interface Id (an Id of the data link = within the TE link). Resource allocation happens at the lowest level = (the data links). = = LMP is designed to support aggregation of one or more data-bearing = links into a TE link (either ports into TE links, or component links = into TE links). The purpose of forming a TE link is to group/map the = information about certain physical resources (and their properties) = into the information that is used by Constrained SPF for the purpose = of path computation, and by GMPLS signaling. = = = Everdingen et al [Page 5] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 2. LMP Overview = = The core procedure of LMP is link property correlation. Link = property correlation is used to synchronize the TE link properties = and verify configuration. = = An "LMP adjacency" is present between two nodes that are neighbors = regarding a data link. LMP provides an optional procedure to = automatically discover the connectivity of the data links, but this = connectivity can also be manually provisioned. = = The link property correlation function of LMP is designed to = aggregate multiple data links into a TE link and to synchronize the = properties of the TE link. As part of the link property correlation = function, a LinkSummary message exchange is defined. The LinkSummary = message includes the local and remote TE Link Ids, a list of all data = links that comprise the TE link, and various link properties. A = LinkSummaryAck or LinkSummaryNack message MUST be sent in response to = the receipt of a LinkSummary message indicating agreement or = disagreement on the link properties. = = In this draft, two additional LMP procedures are defined: link = connectivity verification and fault management. Link connectivity = verification is used to verify the continued physical connectivity of = the data links between the nodes. The link verification procedure = uses a test signal that is sent over the data links and TestStatus = messages that are transmitted back over the control network. = = Fault management is used to localize a fault to a specific data link. = By means of this procedure, an OXC or TRM node can detect if an = incoming signal fault is caused by a fault on the incoming data link = or is caused by a fault further in the upstream direction. = = The LMP fault management procedure is based on a ChannelStatus = exchange using the following messages: ChannelStatus, = ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. = The ChannelStatus message is sent unsolicitated and is used to notify = an LMP neighbor about the status of one or more data links of a TE = link. The ChannelStatusAck message is used to acknowledge the = receipt of the ChannelStatus message. The ChannelStatusRequest = message is used to query an LMP neighbor for the status of one or = more data channels of a TE Link. The ChannelStatusResponse message = is used to acknowledge receipt of the ChannelStatusRequest message = and indicate the states of the queried data links. = = All LMP messages are UDP encoded. This implies that the control = network must provide a UDP service. = = LMP messages are transmitted reliably over the control network using = Message Ids and retransmissions. Message Ids are carried in = MESSAGE_ID objects. No more than one MESSAGE_ID object may be = included in an LMP message. The Message Id is always within the = = Everdingen et al [Page 6] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = scope of the LMP adjacency. The value of the Message Id is = monotonically increasing and only decreases when the value wraps. = = In addition to these UDP based LMP messages, LMP uses the in-band = "access point identifier" for neighbor discovery and link = verification. = = The organization of the remainder of this document is as follows. In = Section 3, a method is presented to discover the connectivity of the = data links. In Section 4, the link property correlation function = using the LinkSummary message exchange is described. The link = verification procedure is discussed in Section 5. In Section 6, it = is shown how LMP can be used to isolate TE link and data link = failures within the optical network. Sections 7, 8 and 9 describe = the usage of message identifiers, graceful restart and addressing = respectively. Several finite state machines (FSMs) are given in = Section 12. The message formats and object definitions are defined in = Section 13 and 14 respectively. = = = Everdingen et al [Page 7] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 3. Neighbor Discovery = = In this section, an optional LMP procedure is described to = automatically detect the identification of the other end of a data = link in the upstream direction. In other words the neighbor = discovery procedure automatically detects the association . = The neighboring node in the upstream direction is informed of this = association by means of the subsequent link correlation procedure. = = The optional neighbor discovery as described in this section uses the = capability of optical systems to carry an in-band "access point = identifier" [G707]. Alternative discovery procedures that do not = require the usage of this access point identifier are described in = [OIF-UNI] and in [NDP-PPP]. These procedures use the line or section = DCC (data communications channel) and are especially useful in case = the access point identifier is not available for use, i.e., = prohibited by the carrier, or in accessible by the equipment. These = alternative discovery procedures are applicable in case the data link = is an STM-N, OC-N and STS-1/3/.../VC-3/4/...; they are not applicable = in case the data link is an VT-1.5, VC-11 or VC-12 data link. = = Basically, automatic neighbor discovery as described in this section = is implemented by reading the incoming access point identifier. = = A Sub-Network Point (TTP or CTP) that implements the automatic = neighbor discovery procedure MUST send its identification in the = access point identifier in a signal present on the data link. = = In case the Sub-Network Point is a TTP, the access point identifier = is sent continuously. In case the Sub-Network Point is a CTP, the = access point identifier is sent in any test signal, e.g. the = supervisory unequipped signal (see [G707] and [G783]). = = The access point identifier is encoded in a specific byte in the data = link according to the table below: = = Data link type Access point identifier to be used = -------------- ---------------------------------- = STM-N, OC-N J0 = STS-1/3/.../VC-3/4/... J1 = VT-1.5/VC-11/12 J2 = = In case an IPv4 control network is used, the identification SHOULD be = formatted into 16 bytes as follows ([OIF 2000.159.01]): = = +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ = | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| = +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ = |CRC|Typ|Dis| Node Identifier | I'face Identifier | = +---+---+---+-------------------------------+-------------------+ = = Everdingen et al [Page 8] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Figure 3: format of the access point identifier to = enable automatic neighbor discovery = = The format as specified in Figure 3 is in line with the specification = in [G707]. This SDH standard places the most stringent constraints = on the contents of the access point identifiers. = = A Sub-Network Point (TTP or CTP) MAY also use an alternative format = for the access point identifier, e.g. the one specified in G.831, = Appendix I. In this case, discovery of the address of the sending = access point will need involvement of a 'name server'. In case an = IPv6 control network is used, the neighbor discovery scheme MUST = follow this approach. = = According to [G707], all entries in the access point identifier in = the are are formatted printable 7 bit encoded ASCII characters = (except for the CRC field). In case the access point identifier is = formatted according to Figure 3, the fields have the following = interpretation: = = CRC = The CRC-7 code of the previous frame as specified in G.707. = = Typ = The "type indicator" informs the receiver of the sender's role. = Values are: = "T": Trail Termination Point = "C": Connection Termination Point = = Dis = The "distinguishing identifier" avoids the proposed format to be = confused with some other optional format, e.g. the format = specified in G.831, Appendix I. = Value: = "@" = = Node Identifier = The "node identifier" is the IPv4 address that identifies the = sending Node_Id. The IPv4 address is encoded in 8 hex characters. = = I'face Identifier = The "Interface Identifier" identifies the sender's Interface_Id in = hex format. This gives port numbers 0-FFFFF (1,048,575) which = should be enough for all types of Network Elements. = = = As an example, a node with IP address 192.168.2.23 would sent out the = following access point identifier (excluding the CRC) from a TTP with = local interface id 421: = T@C0A80217001A5 = = = Everdingen et al [Page 9] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = A sending TTP that implements the automatic neighbor discovery scheme = will continuously send out its own identification. This is according = to [G831], "the access point identifier should not change while the = access point remains in existence". = = A sending CTP that implements the automatic neighbor discovery scheme = MUST send its identification as long as it has not received a = linkSummary message indicating that the associated receiver has = discovered this sending CTP. The CTP MAY send its identification = continuously, until it is discovered. The CTP MAY also send its = identification in intervals, until it is discovered. = = Example: Figure 4 shows 4 nodes and a single data link between these = nodes. Two nodes terminate the data link on interfaces marked with = 'T' (TTP). Two other nodes are transparent to the data link on = interfaces marked with 'C' (CTP). = = Note that neighbor discovery is defined per datalink, so the actual = number of datalinks per NE is not relevant. = = +------+ +------+ +------+ +------+ = | T-|--->--|-C C-|--->--|-C C-|--->--|-T | = | | A | | B | | C | | = | | | | | | | | = | TRM1 | | OXC1 | | OXC2 | | TRM2 | = +------+ +------+ +------+ +------+ = Figure 4: automatic discovery example - 1 = = OXC1 should, when it wants to discover data link B, connect a test- set that sends an access point identifier to identify the sending = connection point C in OXC1. This test-signal should be send long = enough for OXC2 to detect and read the test-signal. OXC2 will = continuously scan all its not discovered input ports for a discovery = signal. = = At some point, OXC2 will detect the test-signal on data link B. See = Figure 5. = = = +------+ +------+ +------+ +------+ = | T-|--->--|-C C-|--->--|-C C-|--->--|-T | = | | A | / | B | \ | C | | = | | | T | | T | | | = | TRM1 | | OXC1 | | OXC2 | | TRM2 | = +------+ +------+ +------+ +------+ = Figure 5: automatic discovery example - 2 = = When OXC2 has read the access point identifier in the test signal, = data link B is discovered. Subsequent link property correlation can = then be invoked. = = Everdingen et al [Page 10] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = Discovery of data link A is similar, except that the access point = identifier is continuously sent. Discovery of data link C is also = similar, except that the access point identifier is continuously = monitored. In other words, there is no need for a sending = respectively monitoring 'test-set' in TRM1 and TRM2. = = = = Everdingen et al [Page 11] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 4. Link Property Correlation = = As part of LMP, a link property correlation exchange is defined for = TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack = messages. The contents of these messages are built using LMP = objects, which can be either negotiable or non-negotiable (identified = by the N flag in the Object header). Negotiable objects can be used = to let both sides agree on certain link parameters. Non-negotiable = objects are used for announcement of specific values that do not = need, or do not allow, negotiation. = = Each TE link has an identifier (Link_Id) that is assigned at each end = of the link. = = The TE-link is only considered to be 'up' in case a linkSummaryAck = message is received that indicates that the neighboring node agreed = on the current TE-link configuration. See also section 12.1. = = Next to this usage for the initial agreement on the TE-link = configuration, link property correlation MAY be done at any time a = link is 'up'. = = The LinkSummary message is used to verify the consistency of the TE- link and containing data links on both sides. I.e. Link Summary = messages are used to = - Check bi-directional connectivity of the data links = - Exchange and correlate data link parameters = - Exchange and correlate TE link parameters = - Agree on the aggregation of multiple data links into one TE link = = The LinkSummary message includes a TE_LINK object followed by one or = more DATA_LINK objects. The TE_LINK object identifies the TE link's = local and remote Link Id and indicates support for fault management = and link verification procedures for that TE link. The DATA_LINK = objects are used to characterize the data links that comprise the TE = link. These objects include the local and remote Interface Ids, and = may include one or more subobjects further describing the properties = of the data links. = = If the LinkSummary message is received from a remote node and the = Interface Id mappings match those that are stored locally, then the = two nodes have agreement on the verification procedure (see Section = 5) and the configuration of the data links. If the verification = procedure is not used, the LinkSummary message can be used to verify = agreement on manual configuration. = = The LinkSummaryAck message is used to signal agreement on the = Interface Id mappings and link property definitions. Otherwise, a = LinkSummaryNack message MUST be transmitted, indicating which = Interface mappings are not correct and/or which link properties are = not accepted. = = = Everdingen et al [Page 12] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = If a LinkSummaryNack message indicates that the Interface Id mappings = are not correct and the link verification procedure is enabled, the = link verification process SHOULD be repeated for all mismatched free = data links. = = If a LinkSummaryNack message includes negotiable parameters, then = acceptable values for those parameters MUST be included. If a = LinkSummaryNack message is received and includes negotiable = parameters, then the initiator of the LinkSummary message SHOULD send = a new LinkSummary message. The new LinkSummary message SHOULD = include new values for the negotiable parameters. These values = SHOULD take into account the acceptable values received in the = LinkSummaryNack message. = = = = Everdingen et al [Page 13] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 5. Verifying Data Link Connectivity = = In this section, an optional procedure is described that may be used = to verify the physical connectivity of the data-bearing links. The = procedure SHOULD be done any time there is uncertainty about the = continued connectivity of the data-bearing links, e.g. after a data = link failure. The procedure MAY be done on a periodic basis for all = unallocated (free) data links of the TE link. = = Note that verification of the data links is only done after the data = links have been discovered and correlated. = = The discovery procedure as described in this section uses the in-band = access point identifier. Because the discovery procedure uses the = access point identifier, it is only applicable for CTP-->--CTP and = CTP-->--TTP data links. The verify procedure is not applicable for = TTP-->--CTP and TTP-->--TTP data links: TTPs constantly send out = their identification in-band. In other words, a TRM node does not = need to explicitly send a "beginVerify" message to its LMP adjacency = as this neighboring node can at any time verify the connectivity of = the data link (by reading the access point identifier). = = Other verification procedures may be negotiated as part of the link = property correlation. Specific flags in the TE_Link object can be = used for this purpose. At the moment, only a flag value is defined = for the verification method as described in this section. = = If a BeginVerify message is received and link verification is not = supported for the TE link, then a BeginVerifyNack message MUST be = transmitted with Error Code =3D 1, "Link Verification Procedure not = supported for this TE Link". = = If a BeginVerifyAck message is received, the local (transmitting) = node sends the an in-band test signal over the corresponding data = link(s). The only relevant information in this test signal is the = access point identifier. This access point identifier is formatted = according to format of the discovery message (see Figure 3). = = A characteristic of CTPs (points at an OXC node) is that the data = links are transparent when allocated to user traffic. This = characteristic poses a challenge for validating the connectivity of = the data links. Therefore, to ensure proper verification of data = link connectivity, it is required that a test-set is available to = send and receive an in-band test signal at times the data link is not = allocated for use traffic. In other words, the test-set must be able = to terminate the test signal. = = The local (transmitting) node sends the test signal on the = corresponding data link until (1) it receives a correlating = TestStatusSuccess or TestStatusFailure message on the control network = from the remote (receiving) node or (2) a timeout occurs. The remote = node will send a given TestStatus message periodically over the = = Everdingen et al [Page 14] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = control network until it receives either a correlating TestStatusAck = message or an EndVerify message is received over the control network. = = There is no requirement that all data links be terminated = simultaneously, but at a minimum, the network element MUST be able to = terminate the data links one at a time. = = For link verification, a TE link MUST include at least one data link. = = Furthermore, link verification will only succeed if the neighbors = regarding the data link have connectivity over the control plane. = = To initiate the link verification procedure, the local node MUST send = a BeginVerify message over the control network. To limit the scope = of Link Verification to a particular TE Link, the LOCAL_LINK_ID MUST = be non-zero. Furthermore, the BeginVerify message contains the = number of data links that are to be verified. = = If the remote node receives a BeginVerify message and it is ready to = process Test messages, it MUST send a BeginVerifyAck message back to = the local node. When the local node receives a BeginVerifyAck = message from the remote node, it SHOULD begin testing the data links = by transmitting a test signal over each data link. The remote node = MUST send either a TestStatusSuccess or a TestStatusFailure message = in response for each data link. A TestStatusAck message MUST be sent = to confirm receipt of the TestStatusSuccess and TestStatusFailure = messages. = = It is also permissible for the sender to terminate the Test procedure = anytime after sending the BeginVerify message. An EndVerify message = SHOULD be sent for this purpose. = = Message correlation is done using message identifiers. This enables = verification of data links, belonging to different link bundles or = LMP sessions, in parallel. = = When the test signal is received, the received Interface Id is = recorded and mapped to the local Interface Id for that data link, and = a TestStatusSuccess message MUST be sent. The TestStatusSuccess = message includes the local Interface Id and the remote Interface Id = (received in the Test message). The receipt of a TestStatusSuccess = message indicates that the test signal was detected at the remote = node and the connectivity of the data link has been verified. When = the TestStatusSuccess message is received, the local node SHOULD mark = the data link as UP and send a TestStatusAck message to the remote = node. If, however, the Test signal is not detected at the remote = node within an observation period (specified by the = VerifyDeadInterval), the remote node will send a TestStatusFailure = message over the control network indicating that the verification of = the physical connectivity of the data link has failed. When the = local node receives a TestStatusFailure message, it SHOULD mark the = data link as FAILED and send a TestStatusAck message to the remote = node. When all the data links on the list have been tested, the = = Everdingen et al [Page 15] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = local node SHOULD send an EndVerify message to indicate that testing = is complete on this link. = = If the local/remote data link mappings are known, then the link = verification procedure can be optimized by testing the data links in = a defined order known to both nodes. The suggested criteria for this = ordering is in increasing value of the Remote_Interface_ID. = = Both the local and remote nodes SHOULD maintain the complete list of = Interface Id mappings for correlation purposes. = = = 5.1. Example of Link Connectivity Verification = = Figure 6 shows an example of the link verification scenario that is = executed when the connectivity of all data links between OXC A and = OXC B is to be verified. In this example, the TE link consists of = three free CTPs. Furthermore OXC A and OXC B can communicate over a = control network (indicated by a "c"). = = The verification process is as follows: OXC A sends a BeginVerify = message over the control network "c" to OXC B indicating it will = begin verifying the ports. OXC B receives the BeginVerify message = and returns the BeginVerifyAck message over the control network to = OXC A. When OXC A receives the BeginVerifyAck message, it begins = transmitting the test signal over the first CTP (Interface Id=3D1). = When OXC B receives the test signal, it maps the received Interface = Id to its own local Interface Id =3D 10 and transmits a = TestStatusSuccess message over the control network back to OXC A. = The TestStatusSuccess message includes both the local and received = Interface Ids for the port. OXC A will send a TestStatusAck message = over the control network back to OXC B indicating it received the = TestStatusSuccess message. The process is repeated until all of the = data links are verified. At this point, OXC A will send an EndVerify = message over the control network to OXC B to indicate that testing is = complete; OXC B will respond by sending an EndVerifyAck message over = the control network back to OXC A. = = c = -----+----------------------------------+------ = | | = +-----------+ +-----------+ = | OXC A | | OXC B | = | 1-+--------------------->+-10 | = | | | | = | 2-+ /---->+-11 | = | | /---------/ | | = | 3-+----/ +-12 | = | | | | = | 4-+--------------------->+-14 | = | | | | = +-----------+ +-----------+ = = Everdingen et al [Page 16] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = Figure 6: Example of link verification between OXC A and = OXC B. = = = Everdingen et al [Page 17] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 6. Fault Management = = In this section, an optional LMP procedure is described that is used = to manage failures by rapid notification of the status of one or more = data links of a TE Link. The scope of this procedure is within a TE = link, and as such, the use of this procedure is negotiated as part of = the LinkSummary exchange. The procedure can be used to rapidly = isolate link failures and is designed to work for both unidirectional = and bi-directional data links. = = The fault management procedure for a specific data link is especially = useful in two cases: = 1. The OXC node does not get fault information from the MUX node. = 2. The OXC node can't use fault information from the MUX node = = An example for case (1) is when the OXC node and the MUX node are = separate network elements and no communication, like e.g. LMP-DWDM, = is available between these nodes. = = An example for case (2) is if the data link is actually a serial = compound data link. In the latter case, LMP's fault management = function provides a kind of tandem connection monitoring function. = = LMP implements this tandem connection monitoring by sending the state = of the signal at the egress node of the serial compound data link to = the ingress node of the serial compound data link. The ingress node = then compares this information with it's own information regarding = the state of the signal. The difference between the state of the = signal at the egress node and the ingress node gives information = about the serial compound data link. = = +------+ +------+ +------+ +------+ = | C-|--->--|-C--C-|--->--|-C--C-|--->--|-C | = | | A | | B | | C | | = | | | | | | | | = | OXC1 | | OXC2 | | OXC3 | | OXC4 | = +------+ +------+ +------+ +------+ = Figure 7: serial compound data link = = Figure 7 shows an example of a serial compound data link. OXC2 and = OXC3 do not implement LMP nor GMPLS. They are simply fixed through = cross-connects for this data link. In this case, OXC4 can't find out = if the data link between OXC1 and OXC4 is failed from MUX nodes that = might be present between OXC3 and OXC4. The only way OXC4 can know = that the data link between OXC1 and OXC4 is failed is by comparing = the fault state of the signal incoming at OXC4 and the fault state of = the signal outgoing from OXC1. In other words, fault management = provides a way to find out if this data link is failed on any of the = sections A, B or C. = = = = Everdingen et al [Page 18] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 6.1. Fault Detection = = Fault detection determines that there is a failure in the received = signal on a data link. How fault detection is done is outside the = scope of LMP. = = 6.2. Fault Localization Procedure = = LMP provides a failure notification through the ChannelStatus = message. This message may be used to indicate that a single data = link has failed, multiple data links have failed, or an entire TE = link has failed. Failure correlation is done locally at each node = upon receipt of the failure notification. = = To localize a fault to a particular data link between neighboring = OXCs, a downstream node (downstream in terms of data flow) that = detects data link failures will send a ChannelStatus message to its = upstream neighbor indicating that a failure has occurred (bundling = together the notification of all of the failed data links). An = upstream node that receives the ChannelStatus message MUST send a = ChannelStatusAck message to the downstream node indicating it has = received the ChannelStatus message. The upstream node should = correlate the failure to see if the failure is also detected locally = for the corresponding data link(s). If, for example, the failure is = clear on the input of the upstream node or internally, then the = upstream node will have localized the failure. = = After this correlation process, the upstream node MUST send a = ChannelStatus message to the downstream node indicating that the data = link is failed or is ok. The upstream node MUST repeat this = ChannelStatus message until it receives a corresponding = ChannelStatusAck message. Once the failure has been localized, GMPLS = signaling protocols can be used to initiate span or path = protection/restoration procedures. = = If all of the data links of a TE link have failed, then the upstream = node MAY be notified of the TE link failure without specifying each = data link of the failed TE link. This is done by sending failure = notification in a ChannelStatus message identifying the TE Link = without including the Interface Ids in the CHANNEL_STATUS object. = = = 6.3. Examples of Fault Localization = = In Figure 8, a sample network is shown where four OXCs are connected = in a linear array configuration. The control network is indicated by = a line labeled with a "c". The data links are bi-directional. = = Figure 8 shows two types of data link failures (indicated by ## in = the figure): = (A) a data link corresponding to the downstream direction of a bi- directional LSP fails, = = Everdingen et al [Page 19] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = (B) two data links corresponding to both directions of a bi- directional LSP fail. = = In the first example [see Figure 8(a)], there is a failure on one = direction of the bi-directional LSP. OXC 4 will detect the failure = and will send a ChannelStatus message to OXC3 indicating the failure = to the corresponding upstream node. When OXC3 receives the = ChannelStatus message from OXC4, it returns a ChannelStatusAck = message back to OXC4 and correlates the failure locally. OXC3 = determines that the signal it sends on the data link to OXC4 is free = of failure. Correlation of this information with the information = received from OXC4 learns that the failure is located on the data = link between OXC3 and OXC4. OXC3 will subsequently send a = ChannelStatus message to OXC4 to inform OXC4 of the failure on the = data link between OXC3 and OXC4. = = In the second example [see Figure 8(b)], a single failure (e.g., = fiber cut) affects both directions of the bi-directional data link. = OXC3 (OXC2) will detect the failure of the downstream direction and = send a ChannelStatus message to the upstream node OXC2 (OXC3) = indicating the failure. Upon reception of the ChannelStatus message, = OXC2 (OXC3) will send a ChannelStatusAck message to OXC3 (OXC2). = Consequently, both OXC2 and OXC3 have localized the failure in both = directions of the data link. = = c = --+----------------+----------------+----------------+-- = | | | | = +-------+ +-------+ +-------+ +-------+ = | OXC 1 | | OXC 2 | | OXC 3 | | OXC 4 | = | | | | | | | | = ----+---\ | | | | | | | = <---+---\\--+--------+-------+---\ | | | /--+---> = | \--+--------+-------+---\\---+-------+---##---+---//--+---- = | | | | \---+-------+--------+---/ | = | | | | | | (a) | | = ----+-------+--------+---\ | | | | | = <---+-------+--------+---\\--+---##---+--\ | | | = | | | \--+---##---+--\\ | | | = | | | | (b) | \\--+--------+-------+---> = | | | | | \--+--------+-------+---- = | | | | | | | | = +-------+ +-------+ +-------+ +-------+ = = Figure 8 Two types of data link failures (indicated with ##) = = = Data link Activation Indication = = The ChannelStatus message may also be used to notify an LMP neighbor = that the data link should be actively monitored. This is called Data = Link Activation Indication. This is particularly useful in networks = with transparent OXC nodes where the fault monitoring of data links = = Everdingen et al [Page 20] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = may need to be triggered using messages over the control plane. = Active monitoring MAY be used before user traffic is allowed on the = data link. = = The ChannelStatus message is used to indicate that a data link or = group of data links are now active. The ChannelStatusAck message = MUST be transmitted upon receipt of a ChannelStatus message. When a = ChannelStatus message is received, the node must send a signal on the = corresponding data link(s). If the downstream node consequently = detects a failure, the ChannelStatus message MUST be transmitted as = described in Section 6.2. = = Data Link Deactivation Indication = = The ChannelStatus message MAY also be used to notify an LMP neighbor = that the data link no longer needs to be actively monitored. This is = the counterpart to the Data Link Active Indication. = = When a ChannelStatus message is received with Data Link Deactive = Indication, the node MAY remove the signal from the corresponding = data link(s). = = 7. Message_Id Usage = = The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP = messages to support reliable message delivery. This section = describes the usage of these objects. = = The MESSAGE_ID and MESSAGE_ID_ACK objects contain a Message_Id field. = = Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP = message. = = The Message_Id field is within the scope of the LMP adjacency. = = The Message_Id field of the MESSAGE_ID object MUST contain a = monotonically increasing value. The Message_Id field of the = MESSAGE_ID_ACK object contains the Message_Id field of the message = being acknowledged. = = Unacknowledged messages sent with the MESSAGE_ID object SHOULD be = retransmitted until the message is acknowledged or until a retry = limit is reached. = = Nodes processing incoming messages SHOULD check to see if a newly = received message is out of order and can be ignored. Out-of-order = messages can be identified by examining the value in the Message_Id = field. If the Message_Id value is less than the largest Message_Id = value previously received from the sender of the LMP adjacency, then = the message SHOULD be treated as being out of order and consequently = be ignored. = = = 8. Graceful Restart = = Everdingen et al [Page 21] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = This section describes the mechanism to resynchronize the LMP state = between LMP adjacencies. Resynchronization is needed in case of an = LMP component restart. = = Note that resynchronization is not needed in case of a failure in the = control plane. Normal retransmission timers for the linkSummary and = channelStatus messages take care of resynchronization as soon as the = connectivity between LMP adjacencies is restored. = = If the control plane failure was the result of an LMP component = restart, then the "LMP Restart" flag MUST be set in all LMP messages = until the LMP adjacency has acknowledged the reception of the = linkSummary and the channelStatusRequest message. = = Upon restart of the LMP component, this component MUST send a = LinkSummary message for each TE Link across the adjacency. All the = objects of the LinkSummary message MUST have the N-bit set to 0 = indicating that the parameters are non-negotiable. This provides the = local/remote Link Id and Interace Id mappings, the associated TE Link = and data link parameters, and indication of which data links are = currently allocated to user traffic. = = When the LMP adjacency receives the LinkSummary message, it checks = the consistency with its local configuration as described in Section = 4 with the exception that the allocated/deallocated flag of the = DATA_LINK Object received in the LinkSummary message MUST take = precedence over any local value. If, however, the LMP adjacency was = not capable of retaining the LMP Link information across a restart, = the node MUST accept the TE link and data link parameters of the = received LinkSummary message and respond with a LinkSummaryAck = message. = = Upon completion of the LinkSummary exchange, the restarted LMP = component SHOULD send a ChannelStatusRequest message for all TE = links. The restarted LMP component SHOULD also verify the = connectivity of all unallocated data links. = = = Everdingen et al [Page 22] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 9. Addressing = = All LMP messages are sent over UDP. The destination address of the = IP packet MUST be either the address learned in a manual = configuration procedure or the address learned in the automatic = neighbor discovery procedure. = = = 10. = LMP Authentication = = LMP authentication is optional (included in the Common Header) and, = if used, MUST be supported by both nodes that are neighbors regarding = the data links. The method used to authenticate LMP packets is based = on the authentication technique used in [OSPF]. This uses = cryptographic authentication using MD5. = = As a part of the LMP authentication mechanism, a flag is included in = the LMP common header indicating the presence of authentication = information. Authentication information itself is appended to the = LMP packet. It is not considered to be a part of the LMP packet, but = is transferred in the same IP packet. = = When the Authentication flag is set in the LMP packet header, an = authentication data block is attached to the packet. This block has = a standard authentication header and a data portion. The contents of = the data portion depend on the authentication type. Currently, only = MD5 is supported for LMP. = = 11. = IANA Considerations = = LMP defines the following name spaces that require management: = = - Msg Type Name Space. = - LMP Object Class name space. = - LMP Object Class type (C-Type). These are unique with Object = Class. = = Following the policies outlined in [IANA], Msg Type, Object Class, = and Class type are allocated through an IETF Consensus action. = = = Everdingen et al [Page 23] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 12. = LMP Finite State Machines = = = 12.1. TE Link FSM = = The TE Link FSM defines the states and logics of operation of an LMP = TE Link. Note that the TE link (in contrast to the data link) offers = bi-directional transmission. The TE link is considered 'up' in case = both ends of the TE link have received the linkSummaryAck message. = = 12.1.1. TE Link States = = An LMP TE link can be in one of the states described below. Every = state corresponds to a certain condition of the TE link. = = Down: There are no data links allocated to the TE link. = = Init: Data links have been allocated to the TE link, but the = configuration has not yet been synchronized with the LMP = neighbor. = = Up: This is the normal operational state of the TE link. = = = 12.1.2. TE Link Events = = Operation of the LMP TE link is described in terms of FSM states and = events. Every event has its number and a symbolic name. Description = of possible TE link events is given below. = = 1 : evDLUp: The number of data links in the TE link has been = changed. The resulting TE link contains at least one = data chennel. = 2 : evSumAck: LinkSummary message received and positively = acknowledged. = 3 : evSumNack: LinkSummary message received and negatively = acknowledged. = 4 : evRcvAck: LinkSummaryAck message received acknowledging = the TE Link Configuration. = 5 : evRcvNack: LinkSummaryNack message received. = 6 : evSumRet: Retransmission timer has expired and LinkSummary = message is resent. = 7 : evDLDown: Last data link of the TE link has been removed. = = = 12.1.3. TE Link FSM Description = = Figure 9 illustrates operation of the LMP TE Link FSM in a form of = FSM state transition diagram. = = Everdingen et al [Page 24] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 3 = +--+ = | | = | v = +--------+ = | | = | Down |<---------+ = | | | = +--------+ | = | ^ | = 1| |7 | = v | | = +--------+ | = | |<-+ 2, | = | Init | |3,5,6 |7 = | |--+ | = +--------+ | = | ^ | = 4| | 1,3,5 | = v | | = +--------+ | = | |----------+ = | Up | = | | = +--------+ = | ^ = | | = +--+ = 2,4,6 = = Figure 9: LMP TE Link FSM = = 12.2. Data Link FSM = = The data link FSM defines the states and logics of operation of a = data link within an LMP TE link. Operation of a data link is = described in terms of FSM states and events. = = The end points of data links can either be in the transmitting mode = or in the receiving mode. For clarity, separate FSMs are defined for = these modes. = = 12.2.1. Data Link States = = Any data link can be in one of the states described below. Every = state corresponds to a certain condition of the TE link. = = Down: The data link has not been put in the resource pool = (i.e., the data link is not "in service" = = Test: A test signal is sent over the data link. = = Everdingen et al [Page 25] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = PasvTest: The data link is being checked for an incoming test = signal. = = Up/Free: The data link has been successfully tested and is = now put in the pool of resources (in-service). The = link has not yet been allocated to data traffic. = = Up/Allocated: The link is UP and has been allocated for data = traffic. = = 12.2.2. Data Link Events = = Data bearing link events are generated by the FSMs of the associated = TE link. Every event has its number and a symbolic name. = Description of possible data link events is given below: = 3 :evStartTst: This is an external event that triggers the sending = of the test signal over the data bearing link. = 4 :evStartPsv: This is an external event that triggers the = listening for a test signal over the data bearing = link. = 5 :evTestOK: Link verification was successful and the link can = be used for path establishment. This event indicates = the Link Verification procedure (see Section 5) was = successful for this data link and a = TestStatusSuccess message was received. = 6 :evTestRcv: Test signal was received over the data link and a = TestStatusSuccess message is transmitted over the = control network. = 7 :evTestFail: Link verification returned negative results. This = could be because (a) a TestStatusFailure message = was received, or (b) the Verification procedure has = ended without receiving a TestStatusSuccess or = TestStatusFailure message for the data link. = 8 :evPsvTestFail:Link verification returned negative results. This = indicates that a Test message was not detected and = either (a) the VerifyDeadInterval has expired or = (b) the Verification procedure has ended and the = VerifyDeadInterval has not yet expired. = 9 :evLnkAlloc: The data link has been allocated. = 10:evLnkDealloc: The data link has been deallocated. = 11:evTestRet: A retransmission timer has expired and the Test = signal is resent. = 12:evSummaryFail:The LinkSummary did not match for this data port. = 13:evLocalizeFail:A Failure has been localized to this data link. = 14:evdlDown: The data link is no longer available. = = = = 12.2.3. FSM Description Transmitter = = Figure 10 illustrates operation of the transmitting side of the data = link in the form of FSM state transition diagram. = = Everdingen et al [Page 26] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = Note that the FSM may start in the Up/Free state. This may be the = case when the data link has been discovered via LMP's automatic = neighbor discovery procedure. = = +------+ = | |<-------+ = +--------->| Down | | = | | |<-----+ | = | +------+ | | = | 3| ^ | | = | | |2,7 | | = | v | | | = | +------+ | | = | | |<-+ | | = | | Test | |11 | | = |12 | |--+ | | = | +------+ | | = | 5| 3^ | | = | | | | | = | v | | | = | +---------+ | | = | | |14 | | = | | Up/Free |----+ | = +---------| | | = +---------+ | = 9| ^ | = | | | = v |10 | = +---------+ | = | |13 | = |Up/Alloc |------+ = | | = +---------+ = = Figure 10: FSM description of transmitting side of Data = Link = = = Everdingen et al [Page 27] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 12.2.4. FSM Description receiver = = Figure 11 illustrates operation of the receiving side of the data = link in the form of FSM state transition diagram. = = Note that the FSM may start in the Up/Free state. This may be the = case when the data link has been discovered via LMP's automatic = neighbor discovery procedure. = = +------+ = | |<------+ = +---------->| Down | | = | | |<----+ | = | +------+ | | = | 4| ^ | | = | | |2,8 | | = | v | | | = | +----------+ | | = | | PasvTest | | | = |12 +----------+ | | = | 6| 4^ | | = | | | | | = | v | | | = | +---------+ | | = | | Up/Free |14 | | = | | |---+ | = +----------| | | = +---------+ | = 9| ^ | = | | | = v |10 | = +---------+ | = | |13 | = |Up/Alloc |-----+ = | | = +---------+ = = Figure 11: FSM description of receiving side of Data = Link = = = Everdingen et al [Page 28] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 13. = LMP Message Formats = = All LMP messages are UDP encoded with port number xxx - TBA (to be = assigned) by IANA. = = 13.1. Common Header = = In addition to the standard UDP header, all LMP messages have the = following common header: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Vers | (Reserved) | Flags | Msg Type | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Vers: 4 bits = = Protocol version number. This is version 1. = = Flags: 8 bits. The following values are defined. All other values = are reserved. = = 0x02: LMP Restart = = This bit is set to indicate the LMP component has = restarted. = = 0x08: Authentication = = When set, this bit indicates that an authentication = block is attached at the end of the LMP message. See = Section 10 for more details. = = Msg Type: 8 bits. The following values are defined. All other = values are reserved. = = 5 =3D BeginVerify = = 6 =3D BeginVerifyAck = = 7 =3D BeginVerifyNack = = 8 =3D EndVerify = = 9 =3D EndVerifyAck = = 11 =3D TestStatusSuccess = = 12 =3D TestStatusFailure = = 13 =3D TestStatusAck = = = Everdingen et al [Page 29] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 14 =3D LinkSummary = = 15 =3D LinkSummaryAck = = 16 =3D LinkSummaryNack = = 17 =3D ChannelStatus = = 18 =3D ChannelStatusAck = = 19 =3D ChannelStatusRequest = = 20 =3D ChannelStatusResponse = = = = 13.2. LMP Object Format = = LMP messages are built using objects. Each object is identified by = its Object Class and Class-type. Each object has a name, which is = always capitalized in this document. LMP objects can be either = negotiable or non-negotiable (identified by the N bit in the Object = header). Negotiable objects can be used to let the devices agree on = certain values. Non-negotiable Objects are used for announcement of = specific values that do not need or do not allow negotiation. = = The format of the LMP object is as follows: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |N| C-Type | Class | Length | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = // (Object contents) // = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = N: 1 bit = = The N flag indicates if the object is negotiable (N=3D1) or non- negotiable (N=3D0). = = C-Type: 7 bits = = Class-type, unique within an Object Class. Values are defined = in Section 14. = = Class: 8 bits = = The Class indicates the Object type. Each Object has a name, = which is always capitalized in this document. = = = Everdingen et al [Page 30] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Length: 16 bits = = The Length field indicates the length of the Object in bytes, = including the N, C-Type, Class, and Length fields. = = 13.3. Authentication = = When authentication is used for LMP, the authentication itself is = appended to the LMP packet. It is not considered to be a part of = the LMP packet, but is transmitted in the same UDP packet as shown = below: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = // LMP Common Header // = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = // LMP Payload // = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = // Authentication Block // = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = The authentication block consists of an 8 byte header followed by the = data portion shown as follows: = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | 0 | Auth Type | Key ID | Auth Data Len | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Cryptographic Sequence Number | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = | MD5 Signature (16) | = | | = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Auth Type: 8 bits = This defines the type of authentication used for LMP = messages. The following authentication types are = defined, all other are reserved for future use: = = 0 No authentication = 1 Cryptographic authentication = = Key ID: 8 bits = = Everdingen et al [Page 31] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = This field is defined only for cryptographic = authentication. = = Auth Data Length: 8 bits = This field contains the length of the data portion of the = authentication block. = = The LMP packet authentication procedure is very similar to the one = used in OSPF, including multiple key support, key management, etc. = The details specific to LMP are defined below. = = Sending authenticated packets = ----------------------------- = = When a packet needs to be sent over the control network and an = authentication method is configured for it, the Authentication flag = in the LMP header is set to 1, the LMP Length field is set to the = length of the LMP packet only, not including the authentication = block. = = 1) The Checksum field in the LMP packet is set to zero (this will = make the receiving side drop the packet if authentication is not = supported). = 2) The LMP authentication header is filled out properly. The message = digest is calculated over the LMP packet together with the LMP = authentication header. The input to the message digest = calculation consists of the LMP packet, the LMP authentication = header, and the secret key. When using MD5 as the authentication = algorithm, the message digest calculation proceeds as follows: = = (a) The authentication header is appended to the LMP packet. = (b) The 16 byte MD5 key is appended after the LMP = authentication header. = (c) Trailing pad and length fields are added, as specified in = [MD5]. = (d) The MD5 authentication algorithm is run over the = concatenation of the LMP packet, authentication header, = secret key, pad and length fields, producing a 16 byte = message digest (see [MD5]). = (e) The MD5 digest is written over the secret key (i.e., = appended to the original authentication header). = = The authentication block is added to the IP packet right after the = LMP packet, so IP packet length includes the length of both LMP = packet and LMP authentication blocks. = = Receiving authenticated packets = ------------------------------- = = When an LMP packet, with the Authentication flag set, has been = received, it must be authenticated. The value of the Authentication = field MUST match the configured authentication type. = = = Everdingen et al [Page 32] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = If an LMP protocol packet is accepted as authentic, processing of the = packet continues. Packets that fail authentication are discarded. = Note that the checksum field in the LMP packet header is not checked = when the packet is authenticated. = = (1) If the key is not configured, or if the key is not valid for = reception (i.e., current time does not fall into the key's = active time frame), the LMP packet is discarded. = (2) If the cryptographic sequence number found in the LMP = authentication header is less than the cryptographic sequence = number recorded in the node, the LMP packet is discarded. = (3) Verify the message digest in the data portion of the = authentication block in the following steps: = (a) The received digest is set aside. = (b) A new digest is calculated, as specified in the previous = section. = (c) The calculated and received digests are compared. If they = do not match, the LMP packet is discarded. If they do = match, the LMP protocol packet is accepted as authentic, = and the "cryptographic sequence number" in the node's data = structure is set to the sequence number found in the = packet's LMP header. = = = 13.4. Link Verification = = 13.4.1. BeginVerify Message (Msg Type =3D 5) = = The BeginVerify message is sent over the control network and is used = to initiate the link verification process. The format is as follows: = = ::=3D = = = = The above transmission order SHOULD be followed. = = To limit the scope of Link Verification to a particular TE Link, the = LOCAL_LINK_ID and REMOTE_LINK_ID MUST be non-zero. = = The BeginVerify message MUST be periodically transmitted until (1) = the node receives either a BeginVerifyAck or BeginVerifyNack message = to accept or reject the verify process or (2) a timeout expires and = no BeginVerifyAck or BeginVerifyNack message has been received. Both = the retransmission interval and the timeout period are local = configuration parameters. = = 13.4.2. BeginVerifyAck Message (Msg Type =3D 6) = = When a BeginVerify message is received and test signals are ready to = be processed, a BeginVerifyAck message MUST be transmitted. = = ::=3D = = Everdingen et al [Page 33] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK object MUST be obtained from the = BeginVerify message being acknowledged. = = The VERIFY_ID object contains a node-unique value that is assigned by = the generator of the BeginVerifyAck message. This value is used to = uniquely identify the Verification process from multiple LMP = neighbors and/or parallel test procedures between the same LMP = neighbors. = = = 13.4.3. BeginVerifyNack Message (Msg Type =3D 7) = = If a BeginVerify message is received and a node is unwilling or = unable to begin the Verification procedure, a BeginVerifyNack message = MUST be transmitted. = = ::=3D = = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK object MUST be obtained from the = BeginVerify message being negatively acknowledged. = = If the Verification process is not supported, the ERROR_CODE MUST = indicate "Link Verification Procedure not supported". = = If Verification is supported, but the node unable to begin the = procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a = BeginVerifyNack message is received with such an ERROR_CODE, the node = that originated the BeginVerify SHOULD schedule a BeginVerify = retransmission after Rf seconds, where Rf is a locally defined = parameter. = = If the Verification Transport mechanism is not supported, the = ERROR_CODE MUST indicate "Unsupported verification transport = mechanism". = = If the LOCAL_LINK_ID, REMOTE_LINK_ID combination in the BeginBVerify = message does not match the node's configuration, the ERROR_CODE MUST = indicate "TE Link Id configuration error". = = The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. = = 13.4.4. EndVerify Message (Msg Type =3D 8) = = The EndVerify message is sent over the control network and is used to = terminate the link verification process. The EndVerify message may = = Everdingen et al [Page 34] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = be sent at any time the initiating node desires to end the Verify = procedure. The format is as follows: = = ::=3D = = The above transmission order SHOULD be followed. = = The EndVerify message will be periodically transmitted until (1) an = EndVerifyAck message has been received or (2) a timeout expires and = no EndVerifyAck message has been received. Both the retransmission = interval and the timeout period are local configuration parameters. = = 13.4.5. EndVerifyAck Message (Msg Type =3D9) = = The EndVerifyAck message is sent over the control network and is used = to acknowledge the termination of the link verification process. The = format is as follows: = = ::=3D = = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK object MUST be obtained from the = EndVerify message being acknowledged. = = = 13.4.6. TestStatusSuccess Message (Msg Type =3D 11) = = The TestStatusSuccess message is transmitted over the control network = and is used to transmit the mapping between the local Interface Id = and the Interface Id that was received in the Test message. = = ::=3D = = = = The above transmission order SHOULD be followed. = = The contents of the REMOTE_INTERFACE_ID object MUST be obtained from = the corresponding test signal being positively acknowledged. = = 13.4.7. TestStatusFailure Message (Msg Type =3D 12) = = The TestStatusFailure message is transmitted over the control network = and is used to indicate that the test signal was not received. = = ::=3D = = = = The above transmission order SHOULD be followed. = = = Everdingen et al [Page 35] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 13.4.8. TestStatusAck Message (Msg Type =3D 13) = = The TestStatusAck message is used to acknowledge receipt of the = TestStatusSuccess or TestStatusFailure messages. = = ::=3D = = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK object MUST be obtained from the = TestStatusSuccess or TestStatusFailure message being acknowledged. = = 13.5. Link Summary Messages = = 13.5.1. LinkSummary Message (Msg Type =3D 14) = = The LinkSummary message is used to synchronize the Interface Ids and = correlate the properties of the TE link. The format of the = LinkSummary message is as follows: = = ::=3D = [...] = = The above transmission order SHOULD be followed. = = The LinkSummary message can be exchanged at any time a link is not in = the Verification process. The LinkSummary message MUST be = periodically transmitted until (1) the node receives a LinkSummaryAck = or LinkSummaryNack message or (2) a timeout expires and no = LinkSummaryAck or LinkSummaryNack message has been received. Both = the retransmission interval and the timeout period are local = configuration parameters. = = 13.5.2. LinkSummaryAck Message (Msg Type =3D 15) = = The LinkSummaryAck message is used to indicate agreement on the = Interface Id synchronization and acceptance/agreement on all the link = parameters. It is on the reception of this message that the local = node makes the TE Link Id associations. = = ::=3D = = The above transmission order SHOULD be followed. = = 13.5.3. LinkSummaryNack Message (Msg Type =3D 16) = = The LinkSummaryNack message is used to indicate disagreement on non- negotiated parameters or propose other values for negotiable = parameters. Parameters where agreement was reached MUST NOT be = included in the LinkSummaryNack Object. = = ::=3D = = Everdingen et al [Page 36] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = [...] = = The above transmission order SHOULD be followed. = = The DATA_LINK Objects MUST include acceptable values for all = negotiable parameters. If the LinkSummaryNack includes DATA_LINK = Objects for non-negotiable parameters, they MUST be copied from the = DATA_LINK Objects received in the LinkSummary message. = = If the LinkSummaryNack message is received and only includes = negotiable parameters, then a new LinkSummary message SHOULD be sent. = = The values received in the new LinkSummary message SHOULD take into = account the acceptable parameters included in the LinkSummaryNack = message. = = The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2. = = 13.6. Fault Management Messages = = 13.6.1. ChannelStatus Message (Msg Type =3D 17) = = The ChannelStatus message is sent over the control network and is = used to notify an LMP neighbor of the status of a data link. A node = that receives a ChannelStatus message MUST respond with a = ChannelStatusAck message. The format is as follows: = = ::=3D = = = The above transmission order SHOULD be followed. = = If the CHANNEL_STATUS object does not include any Interface Ids, then = this indicates the entire TE Link has failed. = = 13.6.2. ChannelStatusAck Message (Msg Type =3D 18) = = The ChannelStatusAck message is used to acknowledge receipt of the = ChannelStatus Message. The format is as follows: = = ::=3D = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK object MUST be obtained from the = ChannelStatus message being acknowledged. = = 13.6.3. ChannelStatusRequest Message (Msg Type =3D 19) = = The ChannelStatusRequest message is sent over the control network and = is used to request the status of one or more data link(s). A node = that receives a ChannelStatusRequest message MUST respond with a = ChannelStatusResponse message. The format is as follows: = = = Everdingen et al [Page 37] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = ::=3D = = [] = = The above transmission order SHOULD be followed. = = If the CHANNEL_STATUS_REQUEST object is not included, then the = ChannelStatusRequest is being used to request the status of ALL of = the data link(s) of the TE Link. = = 13.6.4. ChannelStatusResponse Message (Msg Type =3D 20) = = The ChannelStatusResponse message is used to acknowledge receipt of = the ChannelStatusRequest Message and notify the LMP neighbor of the = status of the data link(s). The format is as follows: = = ::=3D = = = = The above transmission order SHOULD be followed. = = The contents of the MESSAGE_ID_ACK objects MUST be obtained from the = ChannelStatusRequest message being acknowledged. = = Everdingen et al [Page 38] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 14. = LMP Object Definitions = = 14.1. NODE_ID Classes = = 14.1.1. LOCAL_NODE_ID Class = = Class =3D 3. = IPv4, C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Node_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = IPv6, C-Type =3D 2 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = + + = | | = + Node_Id (16 bytes) + = | | = + + = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Node_Id: = = This identifies the address (in the control plane) of the node = that originated the LMP packet. = = This Object is non-negotiable. = = 14.1.2. REMOTE _NODE_ID Class = = Class =3D 4. = IPv4, C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Node_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = IPv6, C-Type =3D 2 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = = Everdingen et al [Page 39] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = + + = | | = + Node_Id (16 bytes) + = | | = + + = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Node_Id: = = This identities the remote node. = = This Object is non-negotiable. = = 14.2. LINK _ID Classes = = 14.2.1. LOCAL_LINK_ID Class = = Class =3D 5 = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Link_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Link_Id: = This identifies the sender's Link associated with the message. = This Object is non-negotiable. = = 14.2.2. REMOTE _LINK_ID Class = = Class =3D 6 = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Link_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Link_Id: = = This identifies the remote node's Link Id and MUST be non-zero. = = This Object is non-negotiable. = = = Everdingen et al [Page 40] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 14.3. INTERFACE_ID Classes = = 14.3.1. LOCAL_INTERFACE_ID Class = = Class =3D 7 = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Interface_Id: = = This identifies the data link (either port or component link). = The Interface_Id MUST be node-wide unique and non-zero. The = Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit = into the in-band discovery and test messages. = = This Object is non-negotiable. = = 14.3.2. REMOTE_INTERFACE_ID Class = = Class =3D 8. = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Interface_Id: = = This identifies the remote node's data link (either port or = component link). The Interface Id MUST be non-zero. The = Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit = into the in-band discovery and test messages. = = This Object is non-negotiable. = = 14.4. MESSAGE_ID Class = = Class =3D 9. = MessageId, C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Message_Id | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Everdingen et al [Page 41] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = Message_Id: = The Message_Id field is used to identify a message. This value is = incremented and only decreases when the value wraps. This is used = for message acknowledgment. = This Object is non-negotiable. = = 14.5. MESSAGE_ID_ACK Class = = Class =3D 10. = MessageIdAck, C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Message_Id | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Message_Id: = = The Message_Id field is used to identify the message being = acknowledged. This value is copied from the MESSAGE_ID object = of the message being acknowledged. = = This Object is non-negotiable. = = = 14.6. BEGIN_VERIFY Class = = Class =3D 13. = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Number of Data Links (n) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | local interface id. #1 | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | : | = // : // = | : | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | local interface id. #n | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Number of Data Links: 32 bits = = This is the number of data links that will be verified. = = Interface_Id: = = = Everdingen et al [Page 42] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = This identifies the local node's data link (either port or = component link) that is to be verified. = = = 14.7. BEGIN_VERIFY_ACK Class = = Class =3D 14. = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | VerifyDeadInterval | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = VerifyDeadInterval: 16 bits = = If a Test message is not detected within the = VerifyDeadInterval, then a node will send the TestStatusFailure = message for that data link. = = This Object is non-negotiable. = = = 14.8. VERIFY_ID Class = = Class =3D 15. = C-Type =3D 1 = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | VerifyId | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = VerifyId: 32 bits = This is used to differentiate Test messages from different TE = links and/or LMP peers. This is a node-unique value that is = assigned by the recipient of the BeginVerify message. = = This Object is non-negotiable. = = = 14.9. TE_LINK Class = = Class =3D 16. = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Flags | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Local_Link_Id (4 bytes) | = = Everdingen et al [Page 43] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Remote_Link_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Flags: 16 bits = The following flags are defined. All other values are = reserved. = = 0x01 Fault Management Supported. = = 0x02 Link Verification via access point identifier method supported. = = Local_Link_Id: = = This identifies the node's local Link Id and MUST be non-zero. = = Remote_Link_Id: = = This identifies the remote node's Link Id and MUST be non-zero. = = 14.10. DATA_LINK Class = = Class =3D 17. = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Flags | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Local_Interface_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Remote_Interface_Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | | = // (Subobjects) // = | | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Flags: 8 bits = The following flags are defined. All other values are = reserved. = 0x02 Allocated Link: If set, the data link is currently = allocated for user traffic. If a single = Interface_Id is used for both the transmit = and receive data links, then this bit only = applies to the transmit interface. = 0x04 Failed Link: If set, the data link is failed and not = suitable for user traffic. = = Local_Interface_Id: = = = Everdingen et al [Page 44] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = This is the local identifier of the data link. This MUST = be node-wide unique and non-zero. = = Remote_Interface_Id: = = This is the remote identifier of the data link. This MUST be = non-zero. = = Subobjects = = The contents of the data link object MAY consist of a = series of variable-length data items called subobjects. = The subobjects are defined in subsequent sub-sections. = = = The contents of the DATA_LINK object include a series of variable- length data items called subobjects. Each subobject has the form: = = 0 1 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ = | Type | Length | (Subobject contents) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ = = Type: 8 bits = = The Type indicates the type of contents of the subobject. = = Length: 8 bits = = The Length contains the total length of the subobject in bytes, = including the Type and Length fields. The Length MUST be at = least 4, and MUST be a multiple of 4. = = = 14.10.1. Subobject Type 1: Local Access Identifier (Local AID) = = The Local Access Identifier (Local AID) identifies the local = interface_id in a human-readable format. = = The format of the local AID is as follows: = = 0 1 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ = | Type | Length | local AID | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ = = = local AID: = = Any human-readable string. = = = Everdingen et al [Page 45] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 14.10.2. Subobject Type 2: Remote Access Identifier (Local AID) = = The Remote Access Identifier (Remote AID) identifies the remote = interface_id in a human-readable format. = = The format of the remote AID is as follows: = = 0 1 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ = | Type | Length | remote AID | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ = = = remote AID: = = Any human-readable string. = = 14.10.3. Subobject Type 3: Shared Risk Link Group Identifier (SRLG) = = SRLGs of which the data link is a member. This information is = manually configured per data link may be used for diverse path = computation. = = The format of the SRLG sub-object is as follows: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Type | Length | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | SRLG value #1 | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | ............ | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | SRLG value #N | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Length: 8 bits = = The length is (N+1)*4, where N is the number of SRLG values. = = Shared Risk Link Group Value: 32 bits = = List as many SRLGs as apply. = = Reserved: 16 bits = = Must be set to zero on transmit and ignored on receive. = = 14.10.4. Subobject Type 4: multiplex protection = = = Everdingen et al [Page 46] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = The contents of the multiplex protection object determine whether the = data link is protected on multiplex level. Examples of protection = schemes on multiplex level: MSP/line protection, MS-SPRing/BLSR = etcetera. This information can be used as a measure of the quality of = the data link. It may be advertised by routing and used by signaling = as a selection criterion as described in [GMPLS]. = = The format of the Optical Protection subobject is as follows: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Type | Length | Link Flags| Reserved | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Length: 8 bits = = The length field has value '4'. = = Link Flags: 6 bits = = Encoding for Link Flags can be found in [GMPLS]. = = = 14.10.5. Subobject Type 5: Total Span delay = = The total span delay object determines the delay any bit experiences = when travelling over the data link. = = The format of the span delay sub-object is as follows: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Type | Length | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Span Length | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = Length: 8 bits = = The length field has value '8'. = = Span Length: 32 bits = = Total Length of the WDM span in meters expressed as an unsigned = integer. = = Reserved: 16 bits = = Must be set to zero on transmit and ignored on receive. = = 14.10.6. Subobject Type 6: Administrative Cost = = Everdingen et al [Page 47] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = The administrative cost sub-object gives the cost of the data link = for path routing purposes. This information is manually configured = per data link. = = The format of the Administrative Group sub-object is as follows: = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Type | Length | (Reserved) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Administrative Cost (cont) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Administrative Cost: 32 bits = = A 32 bit value. = = Reserved: 16 bits = = Must be set to zero on transmit and ignored on receive. = = = 14.11. CHANNEL_STATUS Class = = Class =3D 18 = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |A| Channel Status | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | : | = // : // = | : | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |A| Channel Status | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = = Active bit: 1 bit = = This indicates that the data link is allocated to user traffic and = the data link should be actively monitored. = = Direction bit: 1 bit = = Everdingen et al [Page 48] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = This indicates the direction (transmit/receive) of the data link = referred to in the Channel_Status object. If set, this indicates the = data channel is in the transmit direction. = = Channel_Status: 31 bits = = This indicates the status condition of a data link. The = following values are defined. All other values are reserved. = 1. Signal Okay (OK): Data link is operational = 2. Signal Degrade (SD): A soft failure caused by a BER = exceeding a preselected threshold. The specific BER used = to define the threshold is configured. = 3. Signal Fail (SF): A hard signal failure including (but not = limited to) loss of signal (LOS), loss of frame (LOF), or = Line AIS. = = This Object contains one or more Interface Ids followed by a = Channel_Status field. = = To indicate the status of the entire TE Link, there MUST only be one = Interface Id and it MUST be zero. = = This Object is non-negotiable. = = 14.12. CHANNEL_STATUS_REQUEST Class = = Class =3D 19 = C-Type =3D 1 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | : | = // : // = | : | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | Interface Id (4 bytes) | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = This Object contains one or more Interface Ids. = = The Length of this object is 4N in bytes, where N is the number of = Interface Ids. = = This Object is non-negotiable. = = 14.13. ERROR_CODE Class = = Class =3D 20. = BEGIN_VERIFY_ERROR, C-Type =3D 1 = = Everdingen et al [Page 49] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | ERROR CODE | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = The following bit-values are defined: = = 0x01 =3D Link Verification Procedure not supported for this TE = Link. = 0x02 =3D Unwilling to verify at this time = 0x08 =3D TE Link Id configuration error = = All other values are Reserved. = = Multiple bits may be set to indicate multiple errors. = = This Object is non-negotiable. = = If a BeginVerifyNack message is received with Error Code 2, the node = that originated the BeginVerify SHOULD schedule a BeginVerify = retransmission after Rf seconds, where Rf is a locally defined = parameter. = = LINK_SUMMARY_ERROR, C-Type =3D 2 = = 0 1 2 3 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | ERROR CODE | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = = The following bit-values are defined: = = 0x01 =3D Unacceptable non-negotiable LINK_SUMMARY parameters = 0x02 =3D Renegotiate LINK_SUMMARY parameters = 0x04 =3D Bad Received Remote_Link_Id = 0x08 =3D Bad TE Link Object = 0x10 =3D Bad Data Link Object = = All other values are Reserved. = = Multiple bits may be set to indicate multiple errors. = = This Object is non-negotiable. = = = Everdingen et al [Page 50] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = 15. = Security Considerations = = LMP exchanges may be authenticated using the Cryptographic = authentication option. MD5 is currently the only message digest = algorithm specified. = = 16. = References = = [RFC2026] Bradner, S., "The Internet Standards Process-Revision = 3," BCP 9, RFC 2026, October 1996. = [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., = "Multi-Protocol Lambda Switching: Combining MPLS Traffic = Engineering Control with Optical Crossconnects," = Internet Draft, draft-awduche-mpls-te-optical-03.txt, = (work in progress), April 2001. = [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in = MPLS Traffic Engineering," Internet Draft, draft- = kompella-mpls-bundle-05.txt, (work in progress), February = 2001. = [RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., = Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP = Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- = tunnel-08.txt, (work in progress), February 2001. = [CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using = LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, = (work in progress), September 1999. = [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering = Extensions to OSPF," Internet Draft, draft-katz-yeung- = ospf-traffic-04.txt, (work in progress), February 2001. = [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic = Engineering," Internet Draft,draft-ietf-isis-traffic- = 02.txt, (work in progress), September 2000. = [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998. = [LMP] Lang, J.P. et al, "Link Management Protocol", Internet = Draft, draft-ietf-ccamp-lmp-03.txt, (work in progress), = March 2002. = [LMP-DWDM] Fredette, A., Lang, J. P., editors, "Link Management = Protocol (LMP) for WDM Transmission Systems,=F6 Internet = Draft, draft-fredette-lmp-wdm-03.txt, (work in = progress), November 2001. = [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC = 1321, April 1992. = [GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized = MPLS - Signaling Functional Description," Internet Draft, = draft-ietf-mpls-generalized-signaling-06.txt, (work in = progress), October 2001. = [G707] ITU-T G.707, "Network node interface for the synchronous = digital hierarchy (SDH)," March 1996. = [G783] ITU-T G.783, "Characteristics of Synchronous Digital = Hierarchy (SDH) equipment functional blocks," October = 2000. = [GR253] GR-253-CORE, "Synchronous Optical Network (SONET) = Transport Systems: Common Generic Criteria," Telcordia = = Everdingen et al [Page 51] = =0C Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 = = = Technologies, Issue 3, September 2000. = [LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with MPLS = TE," Internet Draft, draft-ietf-mpls-lsp-hierarchy- = 02.txt, (work in progress), February 2001. = [OIF-UNI] The Optical Internetworking Forum, "UNI 1.0 Signaling = Specification", October, 2001. = [NDP-PPP] J. Sadler et al, "Neighbor Discovery via PPP", Internet = draft draft-sadler-pppext-disc-01.txt, June 2002. = = = 17. = Authors' Addresses = = Michiel van Everdingen = Lucent Technologies = P.O. Box 18 = 1270 AA Huizen = The Netherlands = Email: MvanEverdingen@lucent.com = = Greg Bernstein = Ciena Corporation = 10480 Ridgeview Court = Cupertino, CA 94014 = Phone: (510) 573-2237 = Email: gregb@ciena.com = = = Everdingen et al [Page 52] = =0C --------------1B116D1A6A920265DE0478CD-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Jun 2002 10:15:56 -0700 Message-ID: <3D10BA16.9354D6E8@nayna.com> Date: Wed, 19 Jun 2002 10:06:30 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Ron Bonica CC: ccamp@ops.ietf.org, GMPLS P&R Design Team Subject: Re: FW: reminder if you have asked for or will ask for an agenda slot inYokohama Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Ron and Kireeti: Can you allocate the following for the Protection and restoration design team drafts: - Update on the terminology draft - 5 minutes Speaker: Dimitri or Eric - Update on the recovery analysis document - 5 minutes Speaker: Dimitri - GMPLS recovery framework document - 10 minutes Speaker: Bala or Jonathan Thanks GMPLS P&R Design team Ron Bonica wrote: > This applies equally to the CCAMP WG > > Ron > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa > > Andersson > > Sent: Monday, June 17, 2002 9:12 AM > > To: mpls wg; George Swallow; Scott Bradner > > Subject: reminder if you have asked for or will ask for an agenda slot > > in Yokohama > > > > > > All, > > > > just a short reminder to those who have or are requesting agenda > > slots at the MPLS WG in Yokohama. Please consider this when you > > prepare for the meeting. > > > > > > > > It is not the purpose of a WG session to have > > presentation of the content of a document. It > > is assumed that all attendees will have read the > > drafts in advance of the meeting. > > > > For documents that are work-in-progress, the > > presentation should cover issues resolved since > > the last draft followed by open issues and > > controversial topics with the intent to reach a > > resolution of said issues and topics. > > > > For new work items, the presentation should focus on > > what the problem is and why it is necessary for the > > work group to address it. Further it should be either > > shown how it falls within the existing charter or why > > and how the charter should be extended to encompass it. > > The solution should only be sketched. > > > > The appropriate way of bringing new work to the working > > group is to send a draft to the mailing list and promoting > > discussion on the list. Slots on the agenda should be used > > to discuss outstanding topics that has not be solved on the > > mailing list. > > > > For new proposals addressing issues where > > work-in-progess the presentation should focus > > on the (perceived) short-fallings of the existing > > work and why those issues need to be addressed > > both in terms of why they are required and why they > > cannot be addressed in the existing work. > > the new work must be related to existing work (i.e. > > compatible, mutually exclusive, outright replacement). > > Finally, the new solution should be skechted, > > explaining how the solution overcomes those issues. > > The primary purpose of this last part is to allow commentary > > from the floor, it should not be orientented toward selling > > the idea. > > > > In all cases only a limited number of slides should be used. > > Speakers should budget their at least 25% of their time to > > allow for questions. > > > > Loa and George > > > > -- > > 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: Wed, 19 Jun 2002 03:12:46 -0700 Message-ID: <010701c21779$acdb9ab0$9600000a@oleg> Reply-To: "Oleg Allenov" From: "Oleg Allenov" To: "ccamp" Subject: GMPLS LSP encoding Date: Wed, 19 Jun 2002 14:11:27 +0400 Organization: AMT Group MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit in draft-ietf-mpls-generalized-signaling-08.txt section 3.1.1 when defining LSP Encoding Type why do we differentiate between 1 - Packet and 2 - Ethernet? Does not generic packet label request cover ethernet and all the other packet technologies? Cheers, oleg Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Jun 2002 07:41:01 -0700 Message-ID: <3D0F4572.5000801@lucent.com> Date: Tue, 18 Jun 2002 10:36:34 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 MIME-Version: 1.0 To: ccamp , tsg15q14@itu.int Subject: new draft: GMPLS for ASON Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I've uploaded a new draft covering the GMPLS usage and extensions to support the ASON requirements. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T in support of ITU's ASON standardization effort, and only provides the extensions for RSVP-TE signaling. Among the major extensions include support for the concept of "call", as well as support for setting up soft permanent connections. http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Thanks Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Jun 2002 14:46:52 -0700 From: "Richard Rabbat" To: "'Yangguang Xu'" Cc: , "'Richard Rabbat'" Subject: RE: questions of your draft Date: Mon, 17 Jun 2002 14:45:03 -0700 Message-ID: <000d01c21648$3d316960$e23ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C2160D.90D29160" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C2160D.90D29160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yangguang, The protection path is set up (e.g., path computation and label mapping) together with the working path when the connection request arrives. However, protection paths are activated and put into service after the network fault, assuming shared protection. With respect to the setting up of the protection path, we do not change the end-to-end signaling using RSVP-TE or CR-LDP. Only the activation process is done through flooding. The rationale behind using end-to-end signaling for the setting up of the protection path is that this is a process that is not bound by a certain time constraint. At activation time, assuming a WDM network, ingress-initiated end-to-end signaling does not scale well and cannot guarantee time bounds. The scalability issue comes into the picture because for every wavelength in a fiber, a notification message would be needed using end-to-end signaling. The issue with time bounds is the amount of messages that are sent out. Let us assume a fiber cut disrupted 128 wavelengths. Then, the 128th notification message from the detecting NE will have to wait in the outgoing queue of that NE until all other 127 messages have been sent to their respective ingress LSRs. At every NE in the network, again, in a WDM network, each NE may receive again from 0 up to 128 notification signals to activate the protection path (including reconfiguration of the switching core). Flooding requires less messages in the network and ensures that only one message has to be processed at any NE, solving the issue of buffering at every NE. In addition, the ability to do the reconfiguration in parallel (if supported by the hardware) is allowed through flooding, but not allowed by end-to-end signaling, since the signal may only tell of one LSP activation. You are correct in your assumption that each NE has the knowledge of which path it is protecting. This is done during the path setup phase. -----Original Message----- From: Yangguang Xu [mailto:xuyg@attbi.com] Sent: Sunday, June 16, 2002 3:08 PM To: rabbat@fla.fujitsu.com Subject: questions of your draft Richard, I was reading your "Fault Notification and Service Recovery Protocol" draft. It's a very nice one. Several questions for me to fully understand your reasoning for flooding the fault notifications. My understanding of your proposal is that it doesn't need an end-to-end signaling to set up the protecting path. Rather, the protecting path is set up segment by segment triggered by the flooded notification messages. Am I right? Also are you assume that each NE has the knowledge of which path it is protecting? Thanks, Yangguang ------=_NextPart_000_000E_01C2160D.90D29160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Yangguang,

 

The protection path = is set up (e.g., path computation and label mapping) together with the working = path when the connection request arrives. However, protection paths are = activated and put into service after the network fault, assuming shared = protection.

With respect to the = setting up of the protection path, we do not change the end-to-end signaling = using RSVP-TE or CR-LDP. Only the activation process is done through = flooding.  The rationale behind using end-to-end signaling for the setting up of = the protection path is that this is a process that is not bound by a certain = time  constraint.

 

At activation time, = assuming a WDM network, ingress-initiated end-to-end signaling does not scale = well and cannot guarantee time bounds.

 

The scalability = issue comes into the picture because for every wavelength in a fiber, a notification message would be needed using end-to-end signaling.

 

The issue with time = bounds is the amount of messages that are sent out. Let us assume a fiber cut disrupted 128 wavelengths.  Then, the 128th notification message = from the detecting NE will have to wait in the outgoing queue of that NE until = all other 127 messages have been sent to their respective ingress LSRs.  At = every NE in the network, again, in a WDM network, each NE may receive again from = 0 up to 128 notification signals to activate the protection path (including = reconfiguration of the switching core).  Flooding requires less messages in the = network and ensures that only one message has to be processed at any NE, solving = the issue of buffering at every NE.

 

In addition, the = ability to do the reconfiguration in parallel (if supported by the hardware) is = allowed through flooding, but not allowed by end-to-end signaling, since the = signal may only tell of one LSP activation.

 

You are correct in = your assumption that each NE has the knowledge of which path it is protecting. This is = done during the path setup phase.

 

-----Original = Message-----
From: Yangguang Xu [mailto:xuyg@attbi.com]
Sent: Sunday, June 16, 2002 3:08 = PM
To: = rabbat@fla.fujitsu.com
Subject: questions of = your draft

 

Richard,

 

I was reading your = "Fault Notification and Service Recovery Protocol" draft. It's a very nice = one.

 

Several questions for me to = fully understand your reasoning for flooding the fault notifications. My understanding of your proposal is that it doesn't need an = end-to-end signaling to set up the protecting path. Rather, the protecting path is = set up segment by segment triggered by the flooded notification messages. Am I = right? Also are you assume that each NE has the knowledge of which path it = is protecting?


Thanks,

 

Yangguang

------=_NextPart_000_000E_01C2160D.90D29160-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Jun 2002 09:59:56 -0700 Date: Mon, 17 Jun 2002 12:43:38 -0400 From: Ron Bonica Subject: FW: reminder if you have asked for or will ask for an agenda slot in Yokohama To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE This applies equally to the CCAMP WG Ron > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa > Andersson > Sent: Monday, June 17, 2002 9:12 AM > To: mpls wg; George Swallow; Scott Bradner > Subject: reminder if you have asked for or will ask for an agenda s= lot > in Yokohama > > > All, > > just a short reminder to those who have or are requesting agenda > slots at the MPLS WG in Yokohama. Please consider this when you > prepare for the meeting. > > > > It is not the purpose of a WG session to have > presentation of the content of a document. It > is assumed that all attendees will have read the > drafts in advance of the meeting. > > For documents that are work-in-progress, the > presentation should cover issues resolved since > the last draft followed by open issues and > controversial topics with the intent to reach a > resolution of said issues and topics. > > For new work items, the presentation should focus on > what the problem is and why it is necessary for the > work group to address it. Further it should be either > shown how it falls within the existing charter or why > and how the charter should be extended to encompass it. > The solution should only be sketched. > > The appropriate way of bringing new work to the working > group is to send a draft to the mailing list and promoting > discussion on the list. Slots on the agenda should be used > to discuss outstanding topics that has not be solved on th= e > mailing list. > > For new proposals addressing issues where > work-in-progess the presentation should focus > on the (perceived) short-fallings of the existing > work and why those issues need to be addressed > both in terms of why they are required and why they > cannot be addressed in the existing work. > the new work must be related to existing work (i.e. > compatible, mutually exclusive, outright replacement). > Finally, the new solution should be skechted, > explaining how the solution overcomes those issues. > The primary purpose of this last part is to allow commenta= ry > from the floor, it should not be orientented toward sellin= g > the idea. > > In all cases only a limited number of slides should be use= d. > Speakers should budget their at least 25% of their time to > allow for questions. > > Loa and George > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > R=E5sundav=E4gen 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: Mon, 17 Jun 2002 09:52:09 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on LMP Date: Mon, 17 Jun 2002 19:49:31 +0300 Message-ID: Thread-Topic: RE: Question on LMP Thread-Index: AcIWHvPXY4g5NkK/S8O6vSP/5PR6ew== From: "Liran Siglat" To: , , , , Hi, Reading the following thread: = http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00217.html It seems that you have reached the decision that: "The source IP address = identifies the originator of the LMP message". Is this decision still standing ? >From this decision I deduce that the LMP application MUST set the source = ip-address of the packets it sends, so the receiver would identify it and map it correctly to the = control-channel, (as opposed to letting it be chosen according to the interface through = which the packet is sent). This doesn't seem like the right thing to do, since the source = ip-address in the IP header has its own uses. If LMP runs over IP it shouldn't identify the originator of a LMP = message according to fields in the IP header, instead it should use its own identifiers (CCID) even in messages such = as LinkSummary messages which are not sent in the scope of a particular control channel. Some clarification on the issue, will be great. Thanks, Liran. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Jun 2002 05:57:05 -0700 Date: Mon, 17 Jun 2002 08:55:37 -0400 From: Dave McDysan Subject: Reminder - Call for Presentations for MPLS 2002: Oct. 27-29, Washington D.C. To: Ppvpn , Ccamp , Mpls , Pwe3 Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Dear Colleagues, The MPLS 2002 Conference will be held in Washington D.C. from October 27 through October 29. See www.mpls2002.com for more information. A group of industry experts on the Technical Program Committee is soliciting presentation proposals for this conference. This note is a reminder that if you wish to suggest a particular topic or a contribution please send a brief proposal to the attention of the Technical Program Committee at TPC@mpls2002.com by June 21, 2002. See above web site for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting edge topics. They are solicting presentations from both the vendor and service provider community on new technologies and operational experience. Regards, David E. McDysan WorldCom Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Jun 2002 22:50:27 -0700 Date: Mon, 17 Jun 2002 11:12:25 +0530 (IST) From: Chaya To: Subject: info about ctype Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi Should the C-type be same for the link id and interface id. or suppose can the link id be unnumbered and interface id be IPv4 or is Ctype configurable for link id and interface id for each of the messages which invloves it pls reply thanks, Chaya Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 16 Jun 2002 08:38:12 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: Out-of-fiber CCs Date: Sun, 16 Jun 2002 18:34:12 +0300 Message-ID: Thread-Topic: Out-of-fiber CCs Thread-Index: AcIVS0QCtqZ2ihi/SCya5IiiWKTC1Q== From: "Liran Siglat" To: Hi, Is there any point in having several out-of-fiber CCs? I didn't find any point in this, since when the CC is out-of-fiber = messages are sent to the configured Node-ID, (so if one CC fails this actually means all the CCs have failed too). Thanks, Liran. Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 15 Jun 2002 18:05:51 -0700 Message-ID: <39469E08BD83D411A3D900204840EC55763212@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'V'" , ccamp@ops.ietf.org Subject: RE: OSPF-TE question.... Date: Sat, 15 Jun 2002 21:00:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Venkat, -> Is this possible: -> -> -> +------R1--------+ -> ^ Area 0 v -> ^ v -> N1 N5 -> / \ / \ -> / \ / \ -> N2 area N3------N6 area N7 -> \ 2 / \ 3 / -> \ / \ / -> N4 N8 -> -> N1-N8 are OXC nodes. -> R1 is a router providing control plane connectivity. -> -> All Na-Nb links are TDM links and provide control plane -> connectivity except -> N3-N6 where control plane connectivity is provided -> out-of-band. All Na-Nb links -> have TE attributes that need to be advertised. -> -> Links N1-R1-N5 are not TE links. -> -> If the service provider requires that N1-N4 needs to be part -> of area 2 and N5-N8 -> be part of area 3: -> 1. Can N3-N6 be advertised at all? A link (reachability or TE) must be in one and only one OSPF area. If you configure N3->N6 link in Area 2 and N6->N3 link in area 3, then N3 and N6 won't form any OSPF adjacency as per RFC2328. But N3 and N6 routers *MAY* (depending on the implementation) advertise their respective links to respective areas. Finally, you will end up seeing unidirectional links being advertised in Area 2 (N3->N6) and in Area 3 (N6->N3) TE topology database. Unlike, OSPF SPF, there is no *rule* for bi-directionality test in (G)MPLS CSPF. Again, you *MAY* (depending on the ingress LER CSPF) successful establish a uni-directional LSP to N3/N6 as egress LERs (depending on area 2 or 3 CSPF). You may get unpredictable results in case of multi-area TE approaches. -> 2. Can you couple two area (2 and 3 in this example) from a -> TE topology point of view but not for the regular topology? You may want to look at: http://www.ietf.org/internet-drafts/draft-venkata-ospf-te-only-option-00.txt -> 3. Based on answers for 2 and 3, would N3 and N6 need to -> establish ospf adjacency? see answer to question 1. -- Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 18:37:33 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Subject: SUKLM doubt Date: Tue, 11 Jun 2002 15:03:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is not applicable and is set to zero. Does this means all the fields viz {SUKLM} should be zero ? Why not S value to be non-zero i.e. set to the lowest index in Nth multiplex (which will be 1) ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 16:20:46 -0700 Message-ID: <3D0A6CF7.DEE5C9C9@noname.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 15:23:51 -0700 From: V To: ccamp@ops.ietf.org Subject: OSPF-TE question.... [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Is this possible: +------R1--------+ ^ Area 0 v ^ v N1 N5 / \ / \ / \ / \ N2 area N3------N6 area N7 \ 2 / \ 3 / \ / \ / N4 N8 N1-N8 are OXC nodes. R1 is a router providing control plane connectivity. All Na-Nb links are TDM links and provide control plane connectivity except N3-N6 where control plane connectivity is provided out-of-band. All Na-Nb links have TE attributes that need to be advertised. Links N1-R1-N5 are not TE links. If the service provider requires that N1-N4 needs to be part of area 2 and N5-N8 be part of area 3: 1. Can N3-N6 be advertised at all? 2. Can you couple two area (2 and 3 in this example) from a TE topology point of view but not for the regular topology? 3. Based on answers for 2 and 3, would N3 and N6 need to establish ospf adjacency? Please post your replies to the list. Thanks - Venkat. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 10:43:27 -0700 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Cc: ccamp@ops.ietf.org Subject: Question Re: Path State Removed in Path Err Date: Fri, 14 Jun 2002 13:39:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In section 7.2.1 of draft-ietf-mpls-generalized-rsvp-te-07.txt it says: 7.2.1. Deletion procedure In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down. In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress: 1. The ingress node precedes an LSP deletion by inserting an Admin Status Object in a Path message and setting the Reflect (R) and Delete (D) bits. 2. Transit and egress nodes process the Admin Status Object as described above. (Alternatively, the egress MAY respond with a PathErr message with the Path_State_Removed flag set, see section 4.4.) 3. Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP and normal RSVP processing takes place. I presume that a Resv Tear would also be a legal alternative in step 2? If so, would the same node be required to send a Path Tear downstream, or would a Path w/D bit and R bit set be ok? Thanks Michael Mandelberg FirstWave ION Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 09:39:05 -0700 From: "Richard Rabbat" To: "'Ron Bonica'" , , Cc: "'Richard Rabbat'" Subject: RE: Agenda Date: Fri, 14 Jun 2002 09:36:08 -0700 Message-ID: <000101c213c1$968a7f30$d63aa485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ron, Kireeti, I would like to request a 5-10 min slot for the following ID: "Fault Notification and Service Recovery Protocol" available as of today at: http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-prot ocol-00.txt Abstract This draft describes a fault notification and service recovery protocol that can be used in GMPLS-enabled networks to achieve bounded time activation of protection paths in the case of single failures. It presents a complete solution to the problem and justifies choices made for the notification method, extensions required to current algorithms and protocols and any security and deployment issues. For those interested in some of simulation results using this approach, please refer to the white paper posted at: http://perth.mit.edu/~richard/wp-ietf-fault-notification.pdf Best, Richard. -- Richard Rabbat, Ph.D. Fujitsu Laboratories of America, Inc 595 Lawrence Expressway Sunnyvale, CA 94085 Phone: 1-408-530-4537 Fax: 1-408-530-4515 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 04:34:59 -0700 Message-Id: <200206141129.HAA24822@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-iwata-mpls-crankback-03.txt Date: Fri, 14 Jun 2002 07:29:55 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for MPLS Signaling Author(s) : A. Iwata, N. Fujita, G. Ash, A. Farrel, S. Marshall-Unitt Filename : draft-iwata-mpls-crankback-03.txt Pages : 31 Date : 13-Jun-02 This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-iwata-mpls-crankback-03.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-iwata-mpls-crankback-03.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: <20020613142936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020613142936.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Jun 2002 04:34:53 -0700 Message-Id: <200206141129.HAA24785@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-rabbat-fault-notification-protocol-00.txt Date: Fri, 14 Jun 2002 07:29:46 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Fault Notification and Service Recovery Protocol Author(s) : R. Rabbat et al. Filename : draft-rabbat-fault-notification-protocol-00.txt Pages : 18 Date : 13-Jun-02 This draft describes a fault notification and service recovery protocol that can be used in GMPLS-enabled networks to achieve bounded time activation of protection paths in the case of single failures. It presents a complete solution to the problem and justifies choices made for the notification method, extensions required to current algorithms and protocols and any security and deployment issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rabbat-fault-notification-protocol-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-rabbat-fault-notification-protocol-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: <20020613142911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rabbat-fault-notification-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rabbat-fault-notification-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020613142911.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 19:48:18 -0700 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: How to choose TBA Class-Nums Date: Tue, 11 Jun 2002 17:36:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" For example, the Label_Set object has Class-Num 0bbbbbbb. Are these intended to be vendor specific? Thanks Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 17:03:35 -0700 Date: Thu, 13 Jun 2002 19:52:25 -0400 From: Ron Bonica Subject: WG last call: draft-ietf-ccamp-gmpls-sonet-sdh-05 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, This email is a last call for comments regarding draft-ietf-ccamp-gmpls-sonet-sdh-05. The WG last call period will end two weeks from today, on June 27th at 23:59 EDT. Please restrict comments to the deltas between the previous and current draft versions. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Entia non sunt multiplicanda sine necessitate." -- William of Ockham Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 16:53:18 -0700 Date: Thu, 13 Jun 2002 19:42:18 -0400 From: Ron Bonica Subject: WG Last Call: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, This email is a last call for comments regarding draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03. The WG last call period will end two weeks from today, on June 27th at 23:59 EDT. Please restrict comments to the deltas between the previous and current draft versions. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Entia non sunt multiplicanda sine necessitate." -- William of Ockham Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 16:50:39 -0700 Message-Id: <200206121112.HAA22718@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-ietf-ccamp-gmpls-g709-01.txt Date: Wed, 12 Jun 2002 07:12:45 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : D. Papadimitriou et al. Filename : draft-ietf-ccamp-gmpls-g709-01.txt Pages : 20 Date : 11-Jun-02 This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ccamp-gmpls-g709-01.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-ietf-ccamp-gmpls-g709-01.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: <20020611122639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020611122639.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 16:43:43 -0700 Date: Thu, 13 Jun 2002 19:32:13 -0400 From: Ron Bonica Subject: WG Last Call: draft-ietf-ccamp-gmpls-architecture-02 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, This email is a last call for comments regarding draft-ietf-ccamp-gmpls-architecture-02. The WG last call period will end two weeks from today, on June 27th at 23:59 EDT. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Entia non sunt multiplicanda sine necessitate." -- William of Ockham Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 15:46:58 -0700 Message-ID: From: Jonathan Lang To: 'Baktha Muralidharan' Cc: ccamp@ops.ietf.org Subject: RE: Comments on draft-ietf-ccamp-lmp-04.txt Date: Thu, 13 Jun 2002 15:37:28 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2132A.E5B65080" 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_01C2132A.E5B65080 Content-Type: text/plain; charset="iso-8859-1" Baktha, The lmp-04 draft is an authors-only preview. If you still have questions after it has been submitted, please feel free to post them. Thanks, Jonathan -----Original Message----- From: Baktha Muralidharan [mailto:muralidb@cisco.com] Sent: Thursday, June 13, 2002 12:51 PM To: Jonathan Lang Cc: ccamp@ops.ietf.org Subject: Comments on draft-ietf-ccamp-lmp-04.txt Hi Jonathan Please see my comments on ccamp-lmp-04 below, prefixed Baktha> Regards, /Baktha ========================================================================== 1. "... 10.2. Retransmission Algorithm After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The ..." Baktha> Shouldn't the first retransmission be after Ri seconds, rather than (1+Delta)*Ri ? 2. "... Prior to initial transmission, initialize Rk = Ri and Rn = 0. while (Rn++ < Rl) { transmit the message; wake up after Rk milliseconds; Rk = Rk * (1 + Delta); } /* acknowledged message or no reply from receiver and Rl reached*/ ..." Baktha> It is not clear if the initial transmission happens before entering the [while] loop or Baktha> inside the loop. If the initial transmission happens happens inside the loop, we want Baktha> the while condition to be (Rn++ <= Rl) 3. Baktha> I assume that the backoff procedure applicable to ALL LMP procedures; might want to state this explicitly. 4. Baktha> If the response to an LMP message is received within "rk" milliseconds, it is accepted and the retransmission is cancelled. Baktha> I believe that this renders the timeout period insignificant. 5. Baktha> State that the retry limit is a local configuration parameter. ------_=_NextPart_001_01C2132A.E5B65080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Baktha,
 =20 The lmp-04 draft is an authors-only preview. If you still have = questions after=20 it has been submitted, please feel free to post = them.
 =20
Thanks,
Jonathan
-----Original Message-----
From: Baktha = Muralidharan=20 [mailto:muralidb@cisco.com]
Sent: Thursday, June 13, 2002 = 12:51=20 PM
To: Jonathan Lang
Cc:=20 ccamp@ops.ietf.org
Subject: Comments on=20 draft-ietf-ccamp-lmp-04.txt

Hi = Jonathan

     =20 Please see my comments on ccamp-lmp-04 below, prefixed=20 = Baktha>

Regards,
/Baktha

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.

"...10.2.=20
     Retransmission Algorithm =
   =20
   After a node transmits a message requiring = acknowledgement,=20 it
   should immediately schedule a retransmission = after Ri=20 seconds.  If a
   corresponding acknowledgement = message is=20 received before Ri seconds,
   then message = retransmission=20 SHOULD be canceled.  Otherwise, it will
   = retransmit the=20 message after (1+Delta)*Ri seconds.  = The

..."

Baktha>=20 Shouldn't the first retransmission be after Ri seconds, rather than=20 (1+Delta)*Ri ?

2.
        = "...
      = Prior to=20 initial transmission, initialize Rk =3D Ri and Rn =3D 0.=20
       =
     =20 while (Rn++ < Rl) {
        = transmit=20 the message;
        wake up = after Rk=20 milliseconds;
        Rk =3D = Rk * (1 +=20 Delta);
      }=20
      /* acknowledged message or no = reply from=20 receiver and Rl
     =20 = reached*/
        ..."

Baktha>=20 It is not clear if the initial transmission happens before entering = the=20 [while] loop or
Baktha> inside the loop. If the initial = transmission=20 happens happens inside the loop, we want
Baktha> the while = condition to=20 be (Rn++ <=3D Rl)

3.

Baktha> I assume that the = backoff=20 procedure applicable to ALL LMP procedures; might want to state this=20 explicitly.

4.

Baktha> If the response to an LMP = message is=20 received within "rk" milliseconds, it is accepted and the = retransmission is=20 cancelled.
Baktha> I believe that this renders the timeout = period=20 insignificant.

5.

Baktha> State that the retry limit = is a=20 local configuration parameter.
------_=_NextPart_001_01C2132A.E5B65080-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 13:21:10 -0700 Message-ID: <076236BAE727D611943F00508BA0F9590A9833@XOVER.dedham.mindspeed.com> From: "Bhargava, Nidhi" To: 'Baktha Muralidharan' , jplang@calient.net Cc: ccamp@ops.ietf.org Subject: RE: Comments on draft-ietf-ccamp-lmp-04.txt Date: Thu, 13 Jun 2002 16:14:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21316.EC581900" 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_01C21316.EC581900 Content-Type: text/plain; charset="iso-8859-1" Baktha, I couldn't find draft-ietf-ccamp-lmp-04.txt on the IETF site. Can you please give the link for the same. Thanks Nidhi ------------------------------- Nidhi Bhargava NetPlane Systems Inc. A Mindspeed Technologies Company Tel: + 1.781.329.3200 x5353 Web: http://www.netplane.com -----Original Message----- From: Baktha Muralidharan [mailto:muralidb@cisco.com] Sent: Thursday, June 13, 2002 3:51 PM To: jplang@calient.net Cc: ccamp@ops.ietf.org Subject: Comments on draft-ietf-ccamp-lmp-04.txt Hi Jonathan Please see my comments on ccamp-lmp-04 below, prefixed Baktha> Regards, /Baktha ========================================================================== 1. "... 10.2. Retransmission Algorithm After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The ..." Baktha> Shouldn't the first retransmission be after Ri seconds, rather than (1+Delta)*Ri ? 2. "... Prior to initial transmission, initialize Rk = Ri and Rn = 0. while (Rn++ < Rl) { transmit the message; wake up after Rk milliseconds; Rk = Rk * (1 + Delta); } /* acknowledged message or no reply from receiver and Rl reached*/ ..." Baktha> It is not clear if the initial transmission happens before entering the [while] loop or Baktha> inside the loop. If the initial transmission happens happens inside the loop, we want Baktha> the while condition to be (Rn++ <= Rl) 3. Baktha> I assume that the backoff procedure applicable to ALL LMP procedures; might want to state this explicitly. 4. Baktha> If the response to an LMP message is received within "rk" milliseconds, it is accepted and the retransmission is cancelled. Baktha> I believe that this renders the timeout period insignificant. 5. Baktha> State that the retry limit is a local configuration parameter. ------_=_NextPart_001_01C21316.EC581900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Baktha,
I=20 couldn't find draft-ietf-ccamp-lmp-04.txt on the IETF site. Can you=20 please give the link
for=20 the same.
Thanks
Nidhi
------------------------------- =
Nidhi Bhargava
NetPlane Systems Inc.
A=20 Mindspeed Technologies Company
Tel:   + 1.781.329.3200 x5353
Web:   http://www.netplane.com
 

 -----Original = Message-----
From:=20 Baktha Muralidharan [mailto:muralidb@cisco.com]
Sent: = Thursday, June=20 13, 2002 3:51 PM
To: jplang@calient.net
Cc:=20 ccamp@ops.ietf.org
Subject: Comments on=20 draft-ietf-ccamp-lmp-04.txt

Hi=20 Jonathan

      Please see my comments = on=20 ccamp-lmp-04 below, prefixed=20 = Baktha>

Regards,
/Baktha

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.

"...10.2.=20
     Retransmission Algorithm =
   =20
   After a node transmits a message requiring = acknowledgement,=20 it
   should immediately schedule a retransmission = after Ri=20 seconds.  If a
   corresponding acknowledgement = message is=20 received before Ri seconds,
   then message = retransmission=20 SHOULD be canceled.  Otherwise, it will
   = retransmit the=20 message after (1+Delta)*Ri seconds.  = The

..."

Baktha>=20 Shouldn't the first retransmission be after Ri seconds, rather than=20 (1+Delta)*Ri ?

2.
        = "...
      = Prior to=20 initial transmission, initialize Rk =3D Ri and Rn =3D 0.=20
       =
     =20 while (Rn++ < Rl) {
        = transmit=20 the message;
        wake up = after Rk=20 milliseconds;
        Rk =3D = Rk * (1 +=20 Delta);
      }=20
      /* acknowledged message or no = reply from=20 receiver and Rl
     =20 = reached*/
        ..."

Baktha>=20 It is not clear if the initial transmission happens before entering = the=20 [while] loop or
Baktha> inside the loop. If the initial = transmission=20 happens happens inside the loop, we want
Baktha> the while = condition to=20 be (Rn++ <=3D Rl)

3.

Baktha> I assume that the = backoff=20 procedure applicable to ALL LMP procedures; might want to state this=20 explicitly.

4.

Baktha> If the response to an LMP = message is=20 received within "rk" milliseconds, it is accepted and the = retransmission is=20 cancelled.
Baktha> I believe that this renders the timeout = period=20 insignificant.

5.

Baktha> State that the retry limit = is a=20 local configuration parameter.
------_=_NextPart_001_01C21316.EC581900-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 12:52:21 -0700 Message-Id: <4.3.2.7.2.20020613154339.016d5b68@funnel.cisco.com> Date: Thu, 13 Jun 2002 15:51:20 -0400 To: jplang@calient.net From: Baktha Muralidharan Subject: Comments on draft-ietf-ccamp-lmp-04.txt Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23405565==_.ALT" --=====================_23405565==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jonathan Please see my comments on ccamp-lmp-04 below, prefixed Baktha> Regards, /Baktha =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. =93=85 10.2. Retransmission Algorithm After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The =85=94 Baktha> Shouldn=92t the first retransmission be after Ri seconds, rather= than=20 (1+Delta)*Ri ? 2. =93=85 Prior to initial transmission, initialize Rk =3D Ri and Rn =3D 0. while (Rn++ < Rl) { transmit the message; wake up after Rk milliseconds; Rk =3D Rk * (1 + Delta); } /* acknowledged message or no reply from receiver and Rl reached*/ =85=94 Baktha> It is not clear if the initial transmission happens before entering= =20 the [while] loop or Baktha> inside the loop. If the initial transmission happens happens inside= =20 the loop, we want Baktha> the while condition to be (Rn++ <=3D Rl) 3. Baktha> I assume that the backoff procedure applicable to ALL LMP=20 procedures; might want to state this explicitly. 4. Baktha> If the response to an LMP message is received within =93rk=94=20 milliseconds, it is accepted and the retransmission is cancelled. Baktha> I believe that this renders the timeout period insignificant. 5. Baktha> State that the retry limit is a local configuration parameter. --=====================_23405565==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonathan

      Please see my comments on ccamp-lmp-04 below, prefixed Baktha>

Regards,
/Baktha

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.

=93=85
10.2.
     Retransmission Algorithm
   
   After a node transmits a message requiring acknowledgement, it
   should immediately schedule a retransmission after Ri seconds.  If a
   corresponding acknowledgement message is received before Ri seconds,
   then message retransmission SHOULD be canceled.  Otherwise, it will
   retransmit the message after (1+Delta)*Ri seconds.  The

=85=94

Baktha> Shouldn=92t the first retransmission be after Ri seconds, rather than (1+Delta)*Ri ?

2.
        =93=85
      Prior to initial transmission, initialize Rk =3D Ri and Rn =3D 0.
      
      while (Rn++ < Rl) {
        transmit the message;
        wake up after Rk milliseconds;
        Rk =3D Rk * (1 + Delta);
      }
      /* acknowledged message or no reply from receiver and Rl
      reached*/
        =85=94

Baktha> It is not clear if the initial transmission happens before entering the [while] loop or
Baktha> inside the loop. If the initial transmission happens happens inside the loop, we want
Baktha> the while condition to be (Rn++ <=3D Rl)

3.

Baktha> I assume that the backoff procedure applicable to ALL LMP procedures; might want to state this explicitly.

4.

Baktha> If the response to an LMP message is received within =93rk=94 milliseconds, it is accepted and the retransmission is cancelled.
Baktha> I believe that this renders the timeout period insignificant.

5.

Baktha> State that the retry limit is a local configuration parameter.
 --=====================_23405565==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Jun 2002 12:19:51 -0700 Message-ID: <01ce01c2130e$844a58d0$681810ac@movaz.com> From: "Adrian Farrel" To: Subject: MPLS Management Overview Date: Thu, 13 Jun 2002 15:14:18 -0400 Hi, A new version of the MPLS Management Overview has been posted. Discussion on the MPLS WG mailing list. Main changes are an increase in detail and a description of the inter-relation between MIB modules, and between MIB tables. http://search.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-02.txt Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Jun 2002 14:55:31 -0700 Message-ID: From: Jonathan Lang To: "'Bernstein, Greg'" , "'ccamp@ops.ietf.org'" Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Date: Wed, 12 Jun 2002 14:44:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Wednesday, June 12, 2002 10:02 AM > To: Jonathan Lang; 'ccamp@ops.ietf.org' > Cc: Razdan, Rajender > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Hi Jonathan, in response to some of your points and questions: > > (a) G.7714.1 is new work on automatic discovery specific to SDH/G.709 > approved to move forward at the meeting in Geneva. It starts with OIF UNI > discovery as a base and will modify as appropriate. I expect contributions > on this to come into the T1X1 meeting next week in Greensboro NC. Maybe you > can come out and discuss. Thanks. I misinterpreted you previous email to indicate that G.7714.1 was more than a statement of work. > > (b) Protocol mechanisms can be very similar but their use much different. > For example in-band/in-fiber OIF-UNI discovery only uses the > CONFIG/CONFIG_ACK with the CCID set to the port number. Periodic hellos > aren't needed (we have many ways of telling whether the DCCs are working). > Link verification isn't needed since it gets included with the > config/config-ack. Hence this seems quite different from the intent within > the LMP draft. LMP consists of 4 pieces: control channel management, link property correlation, link verification, and fault management. The link verification and fault management procedures are optional. In addition, the fast keep-alives (i.e. periodic Hellos) of control channel management are also optional. Per OIF UNI 1.0 Discovery section (Section 8), LMP Control channel management and LMP link property correlation are required, link verification is optional, and fault management isn't used. The periodic Hellos of control channel management are also optional. > > (c) Concerning J0, section DCC, line DCC: Each of these is a different > mechanism with different pros and cons. In addition, J0 and section DCC > apply at a different layer than line DCC. This is also true for J1 (path > trace), J2 (vt path trace). The transport network is layered and hence the > notion of "layer adjacency discovery" in G.7714 or of multi-layer discovery > as discussed in OIF2000.159v2. Exactly, see section 5.3 of draft-lang-ccamp-lmp-bootstrap-00.txt. > > (d) What mechanism to use at which layer (TTP or CTP, i.e., trail or test > signal) depends somewhat on the layers involved. There are subtleties with > the SONET/SDH overhead and practical implementations. see above comment. > For example, I'd > really like a "line trace", like we have a section trace (J0) and a path > trace (J1), but its not there. Hence, why I think these types of > discussions belong at T1/ITU-T. How does this relate to LMP? > > (e) I didn't see pre-OTN transparent work such as LMP and LMP-DWDM including > previously standardized technologies such as SONET, SDH and G.709. I really > don't see LMP applying to these technologies in its current incarnation. I > think performance monitoring, fault management, automated discovery, control > channel management for these technologies belongs in a different forum. Are you saying you didn't read the OIF UNI 1.0? > > (f) I thought that the LMP messages were going to go over UDP. The latest > draft (I've got) still says IP. Was a decision reversed? No, the decision was not reversed. -Jonathan > > Greg > > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Tuesday, June 11, 2002 4:06 PM > To: Bernstein, Greg; ccamp@ops.ietf.org > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Greg, > > > -----Original Message----- > > From: Bernstein, Greg [mailto:GregB@ciena.com] > > Sent: Tuesday, June 11, 2002 3:51 PM > > To: Jonathan Lang; ccamp@ops.ietf.org > > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > > > > Hi Jonathan, > > I understand this is addressing the In-band/In-fiber case, > like we did at > > with the OIF UNI, but the mechanism seems different. > Particularly in the > > case of line or section DCC (the case most of us have > already implemented > > and interoperated with). > The ID we submitted addresses the Out-of-band/out-of-fiber > case. The ib/if > case is already supported in LMP today (the OIF UNI 1.0 is > aligned with > LMP). > > > > > For a trail trace mechanism, i.e., you mention using J0. > If I recall this > > doesn't solve George Swallows problem of a "dumb mux" > between a router and > a > > SONET/SDH switch. I think J1 (path trace) was the solution > we discussed > way > > back then. I think Michiel's e-mail probably summarized > some of this best > an > > proposed a more general solution. > The ID we submitted supports multiple options. J0 is but one. > > > However, I still think mucking with this > > part of the SONET/SDH signal needs to be done at ITU-T. For the > > transparent/pre-OTN stuff we could leave it with CCAMP > along with WDM-LMP. > SONET/SDH & GigE are included in pre-OTN. > > > > > I did a check on OIF2000.089 and found the following: > > oif2000.089.00 - > > OIF OAM&P Working Group - Living List Author: Ren Wu > > Company: Lucent > > Technologies Date created: 04/24/2000 Date updated: > > 04/24/2000 Working > > group(s): OAM&P > > Abstract: The OIF OAM&P Working Group met on January 21 - > > February 1, 2000 > > in New Orleans, LA. The OAM&P WG Living List was updated during this > > meeting. The updated Living List includes two additional > > issues (readline). > > In addition, it was agreed to expa... > > > > This doesn't seem like the right reference. I saw Michiel > referencing > > OIF2000.159v2 some of my old work at OIF along these lines... > > Ooops. This should be oif2000.289 > > Did you get a chance to post G.7714.1? > > -Jonathan > > > > > Greg > > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: Tuesday, June 11, 2002 3:08 PM > > To: Bernstein, Greg; ccamp@ops.ietf.org > > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > > > > Greg, > > > > > -----Original Message----- > > > From: Bernstein, Greg [mailto:GregB@ciena.com] > > > Sent: Tuesday, June 11, 2002 8:40 AM > > > To: ccamp@ops.ietf.org > > > Subject: Comparision to OIF UNI discovery? RE: I-D > > > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt > > > > > > > > > Hi John, Jonathan and Dimitri. How does this compare to > > the OIF UNI auto > > > discovery. I recall that John and Jonathan were > co-authors on that > > > specification. At first glance this looks like a different > > approach. Do > > we > > > need another approach? > > The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control > > channels. As mentioned in this ID, a proposal for bootstraping > > out-of-fiber/out-of-band control channels was originally > > submitted to the > > OIF as oif2000.089.0, but was defered for a later version > of the UNI. > > > > This ID is basically that proposal with more details fleshed > > out. We decided > > to submit it as an ID because of the recent interest on the list. > > > > This proposal is consistent with the if/ib case described in > > UNI 1.0 and > > supported in the base LMP document. (This is mentioned in the > > Introduction > > to this ID - I'm not sure if you read introductions.) > > > > > > > > Also this seems fairly focused on SDH/G.709 type signals, > > i.e., trail > > traces > > > and DCC channels. ITU-T already has work underway in the form of > > G.7714.1. > > > A liason has already been sent to IETF from ITU-T. > > > > > > It seems to me that this work is better done as part of > > that effort, at > > > least the SDH/G.709 aspects of it, since its technology > specific and > > > suggests reusing channels/mechanisms that are defined for > > other functions > > by > > > the ITU-T. > > In the liason, it states, "Draft new Recommendation G.7714.1, > > which is based > > on the OIF UNI 1.0 neighbour and service discovery > > specification and will be > > developed to meet the protocol neutral discovery requirements in > > Recommendation G.7714". > > > > Since the OIF UNI 1.0 neighbor and service discovery spec. is > > based on LMP, > > I think it is quite appropriate to do this work where LMP is > > being defined. > > > > (I couldn't find a version of G.7714.1. If there is a current > > version, can > > you please post it.) > > > > -Jonathan > > > > > > > > Greg B. > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Tuesday, June 11, 2002 4:06 AM > > > To: IETF-Announce; @ops.ietf.org@ciena.com > > > Cc: ccamp@ops.ietf.org > > > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : Control Channel Bootstrap for LMP > > > Author(s) : J. Lang, J. Drake > > > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > > > Pages : 7 > > > Date : 10-Jun-02 > > > > > > The Link Management Protocol (LMP) requires that at least one bi- > > > directional control channel is established between the nodes. The > > > control channel may be transmitted either in-band with the data > > > links or out-of-band over a separate wavelength, fiber, or IP > > > network. This draft specifies a simple procedure to dynamically > > > bootstrap control channels and exchange interface > mappings using a > > > new LMP message that is transmitted in-band over the data links. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots > > trap-00.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Jun 2002 11:12:38 -0700 Message-ID: <3D078E99.42C22268@alcatel.be> Date: Wed, 12 Jun 2002 20:10:33 +0200 From: Dimitri.Papadimitriou@alcatel.be Organization: Alcatel Bell - Optical NA (Antwerpen) MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org Subject: Re: SUKLM doubt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii manoj, see in-line... manoj juneja wrote: > > Hi All, > In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when > a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is > not applicable and is set to zero. Does this means all the fields viz > {SUKLM} should be zero ? well, this seems at least and as indicated clear that all values are set to zero Why not S value to be non-zero i.e. set to the > lowest index in Nth multiplex (which will be 1) ? because in this case internal structure (as pointed by the label) is not applicable that's why you see "the label is not applicable", in the text we have already received several comments on this item and the sentence should be understood as "the {SUKLM} label is not applicable" i will try to clarify this... - dimitri. > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Website: http://www.rc.bel.alcatel.be/~papadimd/index.html Address: Alcatel - Optical NA, Fr. Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Jun 2002 10:22:54 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B1CC@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Jonathan Lang'" , "'ccamp@ops.ietf.org'" Cc: "Razdan, Rajender" Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Date: Wed, 12 Jun 2002 10:02:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Jonathan, in response to some of your points and questions: (a) G.7714.1 is new work on automatic discovery specific to SDH/G.709 approved to move forward at the meeting in Geneva. It starts with OIF UNI discovery as a base and will modify as appropriate. I expect contributions on this to come into the T1X1 meeting next week in Greensboro NC. Maybe you can come out and discuss. (b) Protocol mechanisms can be very similar but their use much different. For example in-band/in-fiber OIF-UNI discovery only uses the CONFIG/CONFIG_ACK with the CCID set to the port number. Periodic hellos aren't needed (we have many ways of telling whether the DCCs are working). Link verification isn't needed since it gets included with the config/config-ack. Hence this seems quite different from the intent within the LMP draft. (c) Concerning J0, section DCC, line DCC: Each of these is a different mechanism with different pros and cons. In addition, J0 and section DCC apply at a different layer than line DCC. This is also true for J1 (path trace), J2 (vt path trace). The transport network is layered and hence the notion of "layer adjacency discovery" in G.7714 or of multi-layer discovery as discussed in OIF2000.159v2. (d) What mechanism to use at which layer (TTP or CTP, i.e., trail or test signal) depends somewhat on the layers involved. There are subtleties with the SONET/SDH overhead and practical implementations. For example, I'd really like a "line trace", like we have a section trace (J0) and a path trace (J1), but its not there. Hence, why I think these types of discussions belong at T1/ITU-T. (e) I didn't see pre-OTN transparent work such as LMP and LMP-DWDM including previously standardized technologies such as SONET, SDH and G.709. I really don't see LMP applying to these technologies in its current incarnation. I think performance monitoring, fault management, automated discovery, control channel management for these technologies belongs in a different forum. (f) I thought that the LMP messages were going to go over UDP. The latest draft (I've got) still says IP. Was a decision reversed? Greg -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Tuesday, June 11, 2002 4:06 PM To: Bernstein, Greg; ccamp@ops.ietf.org Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Tuesday, June 11, 2002 3:51 PM > To: Jonathan Lang; ccamp@ops.ietf.org > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Hi Jonathan, > I understand this is addressing the In-band/In-fiber case, like we did at > with the OIF UNI, but the mechanism seems different. Particularly in the > case of line or section DCC (the case most of us have already implemented > and interoperated with). The ID we submitted addresses the Out-of-band/out-of-fiber case. The ib/if case is already supported in LMP today (the OIF UNI 1.0 is aligned with LMP). > > For a trail trace mechanism, i.e., you mention using J0. If I recall this > doesn't solve George Swallows problem of a "dumb mux" between a router and a > SONET/SDH switch. I think J1 (path trace) was the solution we discussed way > back then. I think Michiel's e-mail probably summarized some of this best an > proposed a more general solution. The ID we submitted supports multiple options. J0 is but one. > However, I still think mucking with this > part of the SONET/SDH signal needs to be done at ITU-T. For the > transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP. SONET/SDH & GigE are included in pre-OTN. > > I did a check on OIF2000.089 and found the following: > oif2000.089.00 - > OIF OAM&P Working Group - Living List Author: Ren Wu > Company: Lucent > Technologies Date created: 04/24/2000 Date updated: > 04/24/2000 Working > group(s): OAM&P > Abstract: The OIF OAM&P Working Group met on January 21 - > February 1, 2000 > in New Orleans, LA. The OAM&P WG Living List was updated during this > meeting. The updated Living List includes two additional > issues (readline). > In addition, it was agreed to expa... > > This doesn't seem like the right reference. I saw Michiel referencing > OIF2000.159v2 some of my old work at OIF along these lines... Ooops. This should be oif2000.289 Did you get a chance to post G.7714.1? -Jonathan > > Greg > > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Tuesday, June 11, 2002 3:08 PM > To: Bernstein, Greg; ccamp@ops.ietf.org > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Greg, > > > -----Original Message----- > > From: Bernstein, Greg [mailto:GregB@ciena.com] > > Sent: Tuesday, June 11, 2002 8:40 AM > > To: ccamp@ops.ietf.org > > Subject: Comparision to OIF UNI discovery? RE: I-D > > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt > > > > > > Hi John, Jonathan and Dimitri. How does this compare to > the OIF UNI auto > > discovery. I recall that John and Jonathan were co-authors on that > > specification. At first glance this looks like a different > approach. Do > we > > need another approach? > The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control > channels. As mentioned in this ID, a proposal for bootstraping > out-of-fiber/out-of-band control channels was originally > submitted to the > OIF as oif2000.089.0, but was defered for a later version of the UNI. > > This ID is basically that proposal with more details fleshed > out. We decided > to submit it as an ID because of the recent interest on the list. > > This proposal is consistent with the if/ib case described in > UNI 1.0 and > supported in the base LMP document. (This is mentioned in the > Introduction > to this ID - I'm not sure if you read introductions.) > > > > > Also this seems fairly focused on SDH/G.709 type signals, > i.e., trail > traces > > and DCC channels. ITU-T already has work underway in the form of > G.7714.1. > > A liason has already been sent to IETF from ITU-T. > > > > It seems to me that this work is better done as part of > that effort, at > > least the SDH/G.709 aspects of it, since its technology specific and > > suggests reusing channels/mechanisms that are defined for > other functions > by > > the ITU-T. > In the liason, it states, "Draft new Recommendation G.7714.1, > which is based > on the OIF UNI 1.0 neighbour and service discovery > specification and will be > developed to meet the protocol neutral discovery requirements in > Recommendation G.7714". > > Since the OIF UNI 1.0 neighbor and service discovery spec. is > based on LMP, > I think it is quite appropriate to do this work where LMP is > being defined. > > (I couldn't find a version of G.7714.1. If there is a current > version, can > you please post it.) > > -Jonathan > > > > > Greg B. > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 11, 2002 4:06 AM > > To: IETF-Announce; @ops.ietf.org@ciena.com > > Cc: ccamp@ops.ietf.org > > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Control Channel Bootstrap for LMP > > Author(s) : J. Lang, J. Drake > > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > > Pages : 7 > > Date : 10-Jun-02 > > > > The Link Management Protocol (LMP) requires that at least one bi- > > directional control channel is established between the nodes. The > > control channel may be transmitted either in-band with the data > > links or out-of-band over a separate wavelength, fiber, or IP > > network. This draft specifies a simple procedure to dynamically > > bootstrap control channels and exchange interface mappings using a > > new LMP message that is transmitted in-band over the data links. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots > trap-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Jun 2002 04:16:17 -0700 Message-Id: <200206121112.HAA22718@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-ietf-ccamp-gmpls-g709-01.txt Date: Wed, 12 Jun 2002 07:12:45 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control Author(s) : D. Papadimitriou et al. Filename : draft-ietf-ccamp-gmpls-g709-01.txt Pages : 20 Date : 11-Jun-02 This document is a companion to the Generalized MPLS (GMPLS) signalling documents. It describes the technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ccamp-gmpls-g709-01.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-ietf-ccamp-gmpls-g709-01.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: <20020611122639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020611122639.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 16:15:31 -0700 Message-ID: From: Jonathan Lang To: "'Bernstein, Greg'" , ccamp@ops.ietf.org Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Date: Tue, 11 Jun 2002 16:05:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Tuesday, June 11, 2002 3:51 PM > To: Jonathan Lang; ccamp@ops.ietf.org > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Hi Jonathan, > I understand this is addressing the In-band/In-fiber case, like we did at > with the OIF UNI, but the mechanism seems different. Particularly in the > case of line or section DCC (the case most of us have already implemented > and interoperated with). The ID we submitted addresses the Out-of-band/out-of-fiber case. The ib/if case is already supported in LMP today (the OIF UNI 1.0 is aligned with LMP). > > For a trail trace mechanism, i.e., you mention using J0. If I recall this > doesn't solve George Swallows problem of a "dumb mux" between a router and a > SONET/SDH switch. I think J1 (path trace) was the solution we discussed way > back then. I think Michiel's e-mail probably summarized some of this best an > proposed a more general solution. The ID we submitted supports multiple options. J0 is but one. > However, I still think mucking with this > part of the SONET/SDH signal needs to be done at ITU-T. For the > transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP. SONET/SDH & GigE are included in pre-OTN. > > I did a check on OIF2000.089 and found the following: > oif2000.089.00 - > OIF OAM&P Working Group - Living List Author: Ren Wu > Company: Lucent > Technologies Date created: 04/24/2000 Date updated: > 04/24/2000 Working > group(s): OAM&P > Abstract: The OIF OAM&P Working Group met on January 21 - > February 1, 2000 > in New Orleans, LA. The OAM&P WG Living List was updated during this > meeting. The updated Living List includes two additional > issues (readline). > In addition, it was agreed to expa... > > This doesn't seem like the right reference. I saw Michiel referencing > OIF2000.159v2 some of my old work at OIF along these lines... Ooops. This should be oif2000.289 Did you get a chance to post G.7714.1? -Jonathan > > Greg > > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Tuesday, June 11, 2002 3:08 PM > To: Bernstein, Greg; ccamp@ops.ietf.org > Subject: RE: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt > > > Greg, > > > -----Original Message----- > > From: Bernstein, Greg [mailto:GregB@ciena.com] > > Sent: Tuesday, June 11, 2002 8:40 AM > > To: ccamp@ops.ietf.org > > Subject: Comparision to OIF UNI discovery? RE: I-D > > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt > > > > > > Hi John, Jonathan and Dimitri. How does this compare to > the OIF UNI auto > > discovery. I recall that John and Jonathan were co-authors on that > > specification. At first glance this looks like a different > approach. Do > we > > need another approach? > The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control > channels. As mentioned in this ID, a proposal for bootstraping > out-of-fiber/out-of-band control channels was originally > submitted to the > OIF as oif2000.089.0, but was defered for a later version of the UNI. > > This ID is basically that proposal with more details fleshed > out. We decided > to submit it as an ID because of the recent interest on the list. > > This proposal is consistent with the if/ib case described in > UNI 1.0 and > supported in the base LMP document. (This is mentioned in the > Introduction > to this ID - I'm not sure if you read introductions.) > > > > > Also this seems fairly focused on SDH/G.709 type signals, > i.e., trail > traces > > and DCC channels. ITU-T already has work underway in the form of > G.7714.1. > > A liason has already been sent to IETF from ITU-T. > > > > It seems to me that this work is better done as part of > that effort, at > > least the SDH/G.709 aspects of it, since its technology specific and > > suggests reusing channels/mechanisms that are defined for > other functions > by > > the ITU-T. > In the liason, it states, "Draft new Recommendation G.7714.1, > which is based > on the OIF UNI 1.0 neighbour and service discovery > specification and will be > developed to meet the protocol neutral discovery requirements in > Recommendation G.7714". > > Since the OIF UNI 1.0 neighbor and service discovery spec. is > based on LMP, > I think it is quite appropriate to do this work where LMP is > being defined. > > (I couldn't find a version of G.7714.1. If there is a current > version, can > you please post it.) > > -Jonathan > > > > > Greg B. > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 11, 2002 4:06 AM > > To: IETF-Announce; @ops.ietf.org@ciena.com > > Cc: ccamp@ops.ietf.org > > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Control Channel Bootstrap for LMP > > Author(s) : J. Lang, J. Drake > > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > > Pages : 7 > > Date : 10-Jun-02 > > > > The Link Management Protocol (LMP) requires that at least one bi- > > directional control channel is established between the nodes. The > > control channel may be transmitted either in-band with the data > > links or out-of-band over a separate wavelength, fiber, or IP > > network. This draft specifies a simple procedure to dynamically > > bootstrap control channels and exchange interface mappings using a > > new LMP message that is transmitted in-band over the data links. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots > trap-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 15:52:59 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B1C7@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: "'Jonathan Lang'" , ccamp@ops.ietf.org Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Date: Tue, 11 Jun 2002 15:50:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Jonathan, I understand this is addressing the In-band/In-fiber case, like we did at with the OIF UNI, but the mechanism seems different. Particularly in the case of line or section DCC (the case most of us have already implemented and interoperated with). For a trail trace mechanism, i.e., you mention using J0. If I recall this doesn't solve George Swallows problem of a "dumb mux" between a router and a SONET/SDH switch. I think J1 (path trace) was the solution we discussed way back then. I think Michiel's e-mail probably summarized some of this best an proposed a more general solution. However, I still think mucking with this part of the SONET/SDH signal needs to be done at ITU-T. For the transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP. I did a check on OIF2000.089 and found the following: oif2000.089.00 - OIF OAM&P Working Group - Living List Author: Ren Wu Company: Lucent Technologies Date created: 04/24/2000 Date updated: 04/24/2000 Working group(s): OAM&P Abstract: The OIF OAM&P Working Group met on January 21 - February 1, 2000 in New Orleans, LA. The OAM&P WG Living List was updated during this meeting. The updated Living List includes two additional issues (readline). In addition, it was agreed to expa... This doesn't seem like the right reference. I saw Michiel referencing OIF2000.159v2 some of my old work at OIF along these lines... Greg -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Tuesday, June 11, 2002 3:08 PM To: Bernstein, Greg; ccamp@ops.ietf.org Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Tuesday, June 11, 2002 8:40 AM > To: ccamp@ops.ietf.org > Subject: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt > > > Hi John, Jonathan and Dimitri. How does this compare to the OIF UNI auto > discovery. I recall that John and Jonathan were co-authors on that > specification. At first glance this looks like a different approach. Do we > need another approach? The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control channels. As mentioned in this ID, a proposal for bootstraping out-of-fiber/out-of-band control channels was originally submitted to the OIF as oif2000.089.0, but was defered for a later version of the UNI. This ID is basically that proposal with more details fleshed out. We decided to submit it as an ID because of the recent interest on the list. This proposal is consistent with the if/ib case described in UNI 1.0 and supported in the base LMP document. (This is mentioned in the Introduction to this ID - I'm not sure if you read introductions.) > > Also this seems fairly focused on SDH/G.709 type signals, i.e., trail traces > and DCC channels. ITU-T already has work underway in the form of G.7714.1. > A liason has already been sent to IETF from ITU-T. > > It seems to me that this work is better done as part of that effort, at > least the SDH/G.709 aspects of it, since its technology specific and > suggests reusing channels/mechanisms that are defined for other functions by > the ITU-T. In the liason, it states, "Draft new Recommendation G.7714.1, which is based on the OIF UNI 1.0 neighbour and service discovery specification and will be developed to meet the protocol neutral discovery requirements in Recommendation G.7714". Since the OIF UNI 1.0 neighbor and service discovery spec. is based on LMP, I think it is quite appropriate to do this work where LMP is being defined. (I couldn't find a version of G.7714.1. If there is a current version, can you please post it.) -Jonathan > > Greg B. > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 11, 2002 4:06 AM > To: IETF-Announce; @ops.ietf.org@ciena.com > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Control Channel Bootstrap for LMP > Author(s) : J. Lang, J. Drake > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > Pages : 7 > Date : 10-Jun-02 > > The Link Management Protocol (LMP) requires that at least one bi- > directional control channel is established between the nodes. The > control channel may be transmitted either in-band with the data > links or out-of-band over a separate wavelength, fiber, or IP > network. This draft specifies a simple procedure to dynamically > bootstrap control channels and exchange interface mappings using a > new LMP message that is transmitted in-band over the data links. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots trap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 15:18:18 -0700 Message-ID: From: Jonathan Lang To: "'Bernstein, Greg'" , ccamp@ops.ietf.org Subject: RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt Date: Tue, 11 Jun 2002 15:08:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Greg, > -----Original Message----- > From: Bernstein, Greg [mailto:GregB@ciena.com] > Sent: Tuesday, June 11, 2002 8:40 AM > To: ccamp@ops.ietf.org > Subject: Comparision to OIF UNI discovery? RE: I-D > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt > > > Hi John, Jonathan and Dimitri. How does this compare to the OIF UNI auto > discovery. I recall that John and Jonathan were co-authors on that > specification. At first glance this looks like a different approach. Do we > need another approach? The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control channels. As mentioned in this ID, a proposal for bootstraping out-of-fiber/out-of-band control channels was originally submitted to the OIF as oif2000.089.0, but was defered for a later version of the UNI. This ID is basically that proposal with more details fleshed out. We decided to submit it as an ID because of the recent interest on the list. This proposal is consistent with the if/ib case described in UNI 1.0 and supported in the base LMP document. (This is mentioned in the Introduction to this ID - I'm not sure if you read introductions.) > > Also this seems fairly focused on SDH/G.709 type signals, i.e., trail traces > and DCC channels. ITU-T already has work underway in the form of G.7714.1. > A liason has already been sent to IETF from ITU-T. > > It seems to me that this work is better done as part of that effort, at > least the SDH/G.709 aspects of it, since its technology specific and > suggests reusing channels/mechanisms that are defined for other functions by > the ITU-T. In the liason, it states, "Draft new Recommendation G.7714.1, which is based on the OIF UNI 1.0 neighbour and service discovery specification and will be developed to meet the protocol neutral discovery requirements in Recommendation G.7714". Since the OIF UNI 1.0 neighbor and service discovery spec. is based on LMP, I think it is quite appropriate to do this work where LMP is being defined. (I couldn't find a version of G.7714.1. If there is a current version, can you please post it.) -Jonathan > > Greg B. > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 11, 2002 4:06 AM > To: IETF-Announce; @ops.ietf.org@ciena.com > Cc: ccamp@ops.ietf.org > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Control Channel Bootstrap for LMP > Author(s) : J. Lang, J. Drake > Filename : draft-lang-ccamp-lmp-bootstrap-00.txt > Pages : 7 > Date : 10-Jun-02 > > The Link Management Protocol (LMP) requires that at least one bi- > directional control channel is established between the nodes. The > control channel may be transmitted either in-band with the data > links or out-of-band over a separate wavelength, fiber, or IP > network. This draft specifies a simple procedure to dynamically > bootstrap control channels and exchange interface mappings using a > new LMP message that is transmitted in-band over the data links. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots trap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 15:05:32 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: SUKLM doubt Date: Tue, 11 Jun 2002 15:03:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is not applicable and is set to zero. Does this means all the fields viz {SUKLM} should be zero ? Why not S value to be non-zero i.e. set to the lowest index in Nth multiplex (which will be 1) ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 14:41:38 -0700 Message-ID: From: "Michael I Mandelberg(Isaac)" To: ccamp@ops.ietf.org Subject: How to choose TBA Class-Nums Date: Tue, 11 Jun 2002 17:36:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" For example, the Label_Set object has Class-Num 0bbbbbbb. Are these intended to be vendor specific? Thanks Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 10:22:17 -0700 Message-Id: <4.3.2.7.2.20020611185914.065dc5b0@paris.cisco.com> Date: Tue, 11 Jun 2002 19:19:39 +0200 To: Ron Bonica , kireeti@juniper.net From: Jean Philippe Vasseur Subject: Re: Agenda Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13785983==_.ALT" --=====================_13785983==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ron and Kireeti, May I request a 5mn slot for: - "RSVP Path computation request and reply messages" - draft-vasseur-mpls-path-computation-rsvp-te-3.txt - To be posted soon. There are also two drafts related to the announcement of Path Computation Server capability both for OSPF and ISIS. Here is the abstract for the OSPF draft: Abstract This draft proposes an OSPF extension for a router to announce its Path Computation Server capability used in the context of MPLS Traffic Engineering. This draft defines a new opaque LSA called PCSD (Path Computation Server Discovery). The PCSD LSA has a variable length and is made of a set of TLVs. 1. Where does this draft fit in the picture of the Sub-IP work This document specifies OSPF extensions in support of MPLS Traffic Engineering. It relates to the work on off-load computation of Traffic Engineering Label Switch Path covered by CCAMP. Would you mind accepting those two drafts within CCAMP ? If yes, thanks to allocate two times 5 minutes slots: OSPF Path Computation Server discovery :draft-vasseur-mpls-path-computation-rsvp-te-013.txt IS-IS Path Computation Server discovery TLV: draft-vasseur-mpls-pcsd-isis-discovery-00.txt Many thanks in advance. Best regards. JP. At 11:31 10/06/2002 -0400, Ron Bonica wrote: >All, > >The CCAMP meeting in Yokohama is tentatively planned for Monday afternoon. > >If you would like time on the agenda, please send a request to Kireeti and >me. Include the name and title of you ID and an estimate of how much time >you would need. > > >=========================================== >Ronald P. Bonica Ph: 703 886 1681 >vBNS Engineering page: 1 888 268 8021 >Ashburn, Va. >=========================================== >"Entia non sunt multiplicanda sine necessitate." > -- William of Ockham --=====================_13785983==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ron and Kireeti,

May I request a 5mn slot for:
- "RSVP Path computation request and reply messages" - draft-vasseur-mpls-path-computation-rsvp-te-3.txt - To be posted soon.

There are also two drafts related to the announcement of Path Computation Server capability both for OSPF and ISIS. Here is the abstract for the OSPF draft:
Abstract

This draft proposes an OSPF extension for a router to announce its Path Computation Server capability used in the context of MPLS Traffic Engineering. This draft defines a new opaque LSA called PCSD (Path Computation Server Discovery). The PCSD LSA has a variable length and is made of a set of TLVs.

1. Where does this draft fit in the picture of the Sub-IP work

This document specifies OSPF extensions in support of MPLS Traffic Engineering. It relates to the work on off-load computation of Traffic Engineering Label Switch Path covered by CCAMP.

Would you mind accepting those two drafts within CCAMP ?

If yes, thanks to allocate two times 5 minutes slots:
OSPF Path Computation Server discovery :draft-vasseur-mpls-path-computation-rsvp-te-013.txt
IS-IS Path Computation Server discovery TLV: draft-vasseur-mpls-pcsd-isis-discovery-00.txt

Many thanks in advance.

Best regards.

JP.

At 11:31 10/06/2002 -0400, Ron Bonica wrote:
All,

The CCAMP meeting in Yokohama is tentatively planned for Monday afternoon.

If you would like time on the agenda, please send a request to Kireeti and
me.  Include the name and title of you ID and an estimate of how much time
you would need.


===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Entia non sunt multiplicanda sine necessitate."
                -- William of Ockham
--=====================_13785983==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 08:47:12 -0700 Message-ID: <2135200C183FD5119588009027DE57230151B1BF@wntcsdexg02.csd.ciena.com> From: "Bernstein, Greg" To: ccamp@ops.ietf.org Subject: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt Date: Tue, 11 Jun 2002 08:39:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi John, Jonathan and Dimitri. How does this compare to the OIF UNI auto discovery. I recall that John and Jonathan were co-authors on that specification. At first glance this looks like a different approach. Do we need another approach? Also this seems fairly focused on SDH/G.709 type signals, i.e., trail traces and DCC channels. ITU-T already has work underway in the form of G.7714.1. A liason has already been sent to IETF from ITU-T. It seems to me that this work is better done as part of that effort, at least the SDH/G.709 aspects of it, since its technology specific and suggests reusing channels/mechanisms that are defined for other functions by the ITU-T. Greg B. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, June 11, 2002 4:06 AM To: IETF-Announce; @ops.ietf.org@ciena.com Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Control Channel Bootstrap for LMP Author(s) : J. Lang, J. Drake Filename : draft-lang-ccamp-lmp-bootstrap-00.txt Pages : 7 Date : 10-Jun-02 The Link Management Protocol (LMP) requires that at least one bi- directional control channel is established between the nodes. The control channel may be transmitted either in-band with the data links or out-of-band over a separate wavelength, fiber, or IP network. This draft specifies a simple procedure to dynamically bootstrap control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Jun 2002 04:10:34 -0700 Message-Id: <200206111106.HAA17829@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-lang-ccamp-lmp-bootstrap-00.txt Date: Tue, 11 Jun 2002 07:06:05 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Control Channel Bootstrap for LMP Author(s) : J. Lang, J. Drake Filename : draft-lang-ccamp-lmp-bootstrap-00.txt Pages : 7 Date : 10-Jun-02 The Link Management Protocol (LMP) requires that at least one bi- directional control channel is established between the nodes. The control channel may be transmitted either in-band with the data links or out-of-band over a separate wavelength, fiber, or IP network. This draft specifies a simple procedure to dynamically bootstrap control channels and exchange interface mappings using a new LMP message that is transmitted in-band over the data links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lang-ccamp-lmp-bootstrap-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-lang-ccamp-lmp-bootstrap-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: <20020610143047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lang-ccamp-lmp-bootstrap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143047.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Jun 2002 08:45:29 -0700 Date: Mon, 10 Jun 2002 11:31:57 -0400 From: Ron Bonica Subject: Agenda To: ccamp@ops.ietf.org Cc: kireeti@juniper.net, ronald.p.bonica@wcom.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit All, The CCAMP meeting in Yokohama is tentatively planned for Monday afternoon. If you would like time on the agenda, please send a request to Kireeti and me. Include the name and title of you ID and an estimate of how much time you would need. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "Entia non sunt multiplicanda sine necessitate." -- William of Ockham Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Jun 2002 22:40:05 -0700 Date: Mon, 10 Jun 2002 14:35:04 +0900 From: Eiji Oki To: "#SHEN SHU#" , Subject: Re: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Message-Id: <20020610143101.C7C1.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Shu, Yes, in principle, whenever event of link-state change occurs, optical link information is updated. How it causes a OSPF convergence problem depends on the frequency of the link-state update and network topology. I think that the wavelength availability information is needed to perform traffic engineering in optical networks. I am now describing this issue and the updated version will be posted soon. Hope this helps. Best regards. Eiji On Sun, 9 Jun 2002 23:06:22 +0800 "#SHEN SHU#" wrote: > Hi, Eiji Oki, > > Regarding your ID (draft-oki-ipo-optlink-req-00.txt), I have the following question: > > How is flooding of optical link information originated? Is it triggered by event of link change? > --If yes, won't the frequent wavelength availability change impact OSPF convergence? > --If no, how often will the timer be? Use the OSPF 30min max timer? how could up-to-date information garrentteed or approached? > > I am not quite sure if such details should be included in your ID or stated in another document. > If it's out of your scope, is there any other doc takeing care of this? > > Your kindly answers/clarifications will be highly appreciated. > > Best regards, > Shu SHEN > Research student > Network Technology Research Center > Nanyang Technological University, Singapore > Personal Website: http://shenshu.myip.org/ > > > -----Original Message----- > From: #SHEN SHU# > Sent: Sunday, June 09, 2002 10:56 PM > To: 'Ravi Ravindran' > Cc: 'ccamp@ops.ietf.org'; 'oki.eiji@lab.ntt.co.jp' > Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS? > > > Hi, Ravi, > > I don't quite understand why you say information such as wavelength availability is "strictly binds to data plane". > Is this because of wavelength availability is specific to LSC? or maybe a LSC from some vendors never use such information to make routing decisions? > Either reason I would not agree. > I think support for exchanging such information should be included within control plane, at least as an option. > Please explain further. > > About the ID you suggested, do you know what's its current status? I found it's not on the IPO WG's ID list. > May be the authors of this ID can provide more information about it. > > Thanks a lot! > > Cheers, > Shu > > -----Original Message----- > From: Ravi Ravindran [mailto:rravindr@nortelnetworks.com] > Sent: Sunday, June 09, 2002 4:27 AM > To: #SHEN SHU# > Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS? > > > OSPF-GMPLS extensions only try to address the common rourting issues relating to all non-packet switched interfaces. Extensions to things like you stated is more vendor specific, since that strictly binds to data plane property. > The following ID discusses some ways to deal with LSC nodes. > http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt > Ravi > -----Original Message----- > From: #SHEN SHU# [mailto:PG03053527@ntu.edu.sg] > Sent: Saturday, June 08, 2002 3:36 AM > To: ccamp@ops.ietf.org > Subject: Can wavelength availability information be carried by OSPF-Ext > for GMPLS? > > > Dear All, > Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my understanding is that there's no way to exchange wavelength availability information with such extension. Is this right? > If a LSC router wants to make routing decision based on wavelength availability, how could it collect such information from each link of the network? > Or does the OSPF extension leaves wavelength assignment to LDP completely? > Please comment, thanks! > Best regards, > Shu SHEN > Research student > Network Technology Research Center > Nanyang Technological University, Singapore > Personal Website: http://shenshu.myip.org/ -- Eiji Oki NTT Network Innovation Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan TEL: +81-422-59-3441 FAX: +81-422-59-6387 E-mail: oki.eiji@lab.ntt.co.jp Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Jun 2002 08:33:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Date: Sun, 9 Jun 2002 23:06:22 +0800 Message-ID: Thread-Topic: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Thread-Index: AcIPKtiGGEf0t1TURzW6+YxWjDXSlAAmAIowAADBZAA= From: "#SHEN SHU#" To: Cc: Hi, Eiji Oki, Regarding your ID (draft-oki-ipo-optlink-req-00.txt), I have the = following question: How is flooding of optical link information originated? Is it triggered = by event of link change?=20 --If yes, won't the frequent wavelength availability change impact OSPF = convergence? --If no, how often will the timer be? Use the OSPF 30min max timer? how = could up-to-date information garrentteed or approached? I am not quite sure if such details should be included in your ID or = stated in another document. If it's out of your scope, is there any other doc takeing care of this? Your kindly answers/clarifications will be highly appreciated. Best regards,=20 Shu SHEN=20 Research student=20 Network Technology Research Center=20 Nanyang Technological University, Singapore=20 Personal Website: http://shenshu.myip.org/ -----Original Message----- From: #SHEN SHU#=20 Sent: Sunday, June 09, 2002 10:56 PM To: 'Ravi Ravindran' Cc: 'ccamp@ops.ietf.org'; 'oki.eiji@lab.ntt.co.jp' Subject: RE: Can wavelength availability information be carried by = OSPF-Ext for GMPLS? Hi, Ravi, I don't quite understand why you say information such as wavelength = availability is "strictly binds to data plane". Is this because of wavelength availability is specific to LSC? or maybe = a LSC from some vendors never use such information to make routing = decisions? Either reason I would not agree. I think support for exchanging such information should be included = within control plane, at least as an option. Please explain further. About the ID you suggested, do you know what's its current status? I = found it's not on the IPO WG's ID list. May be the authors of this ID can provide more information about it.=20 Thanks a lot! Cheers, Shu -----Original Message----- From: Ravi Ravindran [mailto:rravindr@nortelnetworks.com] Sent: Sunday, June 09, 2002 4:27 AM To: #SHEN SHU# Subject: RE: Can wavelength availability information be carried by = OSPF-Ext for GMPLS? OSPF-GMPLS extensions only try to address the common rourting issues = relating to all non-packet switched interfaces. Extensions to things = like you stated is more vendor specific, since that strictly binds to = data plane property.=20 The following ID discusses some ways to deal with LSC nodes.=20 http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt=20 Ravi=20 -----Original Message-----=20 From: #SHEN SHU# [mailto:PG03053527@ntu.edu.sg]=20 Sent: Saturday, June 08, 2002 3:36 AM=20 To: ccamp@ops.ietf.org=20 Subject: Can wavelength availability information be carried by OSPF-Ext=20 for GMPLS?=20 Dear All,=20 Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my = understanding is that there's no way to exchange wavelength availability = information with such extension. Is this right? If a LSC router wants to make routing decision based on wavelength = availability, how could it collect such information from each link of = the network? Or does the OSPF extension leaves wavelength assignment to LDP = completely?=20 Please comment, thanks!=20 Best regards,=20 Shu SHEN=20 Research student=20 Network Technology Research Center=20 Nanyang Technological University, Singapore=20 Personal Website: http://shenshu.myip.org/=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Jun 2002 08:28:13 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Date: Sun, 9 Jun 2002 22:56:11 +0800 Message-ID: Thread-Topic: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Thread-Index: AcIPKtiGGEf0t1TURzW6+YxWjDXSlAAmAIow From: "#SHEN SHU#" To: "Ravi Ravindran" Cc: , Hi, Ravi, I don't quite understand why you say information such as wavelength = availability is "strictly binds to data plane". Is this because of wavelength availability is specific to LSC? or maybe = a LSC from some vendors never use such information to make routing = decisions? Either reason I would not agree. I think support for exchanging such information should be included = within control plane, at least as an option. Please explain further. About the ID you suggested, do you know what's its current status? I = found it's not on the IPO WG's ID list. May be the authors of this ID can provide more information about it.=20 Thanks a lot! Cheers, Shu -----Original Message----- From: Ravi Ravindran [mailto:rravindr@nortelnetworks.com] Sent: Sunday, June 09, 2002 4:27 AM To: #SHEN SHU# Subject: RE: Can wavelength availability information be carried by = OSPF-Ext for GMPLS? OSPF-GMPLS extensions only try to address the common rourting issues = relating to all non-packet switched interfaces. Extensions to things = like you stated is more vendor specific, since that strictly binds to = data plane property.=20 The following ID discusses some ways to deal with LSC nodes.=20 http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt=20 Ravi=20 -----Original Message-----=20 From: #SHEN SHU# [mailto:PG03053527@ntu.edu.sg]=20 Sent: Saturday, June 08, 2002 3:36 AM=20 To: ccamp@ops.ietf.org=20 Subject: Can wavelength availability information be carried by OSPF-Ext=20 for GMPLS?=20 Dear All,=20 Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my = understanding is that there's no way to exchange wavelength availability = information with such extension. Is this right? If a LSC router wants to make routing decision based on wavelength = availability, how could it collect such information from each link of = the network? Or does the OSPF extension leaves wavelength assignment to LDP = completely?=20 Please comment, thanks!=20 Best regards,=20 Shu SHEN=20 Research student=20 Network Technology Research Center=20 Nanyang Technological University, Singapore=20 Personal Website: http://shenshu.myip.org/=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Jun 2002 00:41:31 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Date: Sat, 8 Jun 2002 15:36:22 +0800 Message-ID: Thread-Topic: Can wavelength availability information be carried by OSPF-Ext for GMPLS? Thread-Index: AcIOvylFJoC9XM0BTR2iT4PtzfPeYg== From: "#SHEN SHU#" To: Dear All, Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my = understanding is that there's no way to exchange wavelength availability = information with such extension. Is this right? If a LSC router wants to make routing decision based on wavelength = availability, how could it collect such information from each link of = the network? Or does the OSPF extension leaves wavelength assignment to LDP = completely? Please comment, thanks! Best regards,=20 Shu SHEN=20 Research student=20 Network Technology Research Center=20 Nanyang Technological University, Singapore=20 Personal Website: http://shenshu.myip.org/ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Jun 2002 13:04:46 -0700 From: "Robin Qiu" To: BRaja@tellium.com Cc: ccamp@ops.ietf.org, oif-signal@oiforum.com Bcc: Subject: OIF-UNI/LMP - service discovery Date: Thu, 06 Jun 2002 16:03:01 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Bala, all, I have seen some LMP "Service Discovery" implementations (as specified in oif2001.125.7, section 9) that mandate the message exchange sequence as illustrated in Figure 9-2 (page 42), i.e. * one ServiceConfig Msg#1 from UNI-C to UNI-N (ServiceConfig Ack/Nack from UNI-N to UNI-C), followed by * one or more ServiceConfig Msg#2 from UNI-C to UNI-N (one or more ServiceConfig Ack/Nack from UNI-N to UNI-C), followed by * one ServiceConfig Msg#3 from UNI-N to UNI-C (ServiceConfig Ack/Nack from UNI-C to UNI-N) While this is literally compliant with the spec (page 42, section 9.3) "There can be more than one exchange of ServiceConfig Message #2 and the corresponding ServiceConfig Ack/Nack. A ServiceConfig Message #3, is sent by the UNI-N to the UNI-C after the latter has received the Client Port-Level Service Attributes corresponding to all the links between the TNE it represents and the clients represented by the UNI-C.", I wonder if this is the authors' intention, to enforce this message sequence. My questions are: 1. Why couldn't UNI-N independently send ServiceConfig Msg#3 to UNI-C, instead of following ServiceConfig Msg#2? 2. If Msg#3 MUST follow Msg#2, how does UNI-N know when Msg#2 exchange is complete, because there could be more than one Msg#2? Thanks. Robin _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Jun 2002 10:23:38 -0700 content-class: urn:content-classes:message Subject: RE: Sonet Ring provisioning Date: Thu, 6 Jun 2002 10:21:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <8CDD92FF12940B41B5053950398AC6E00266F4@bvtn-email.qoptics.com> Thread-Topic: Sonet Ring provisioning Thread-Index: AcINebtCYh/NXTiuQsClFcv06ACPqAABCcwA From: "Vikram Anantha" To: I am reading that to mean, RSVP-TE/CR-LDP allow for TRAFFIC-SPEC objects, but do not specify what the allowable TRAFFIC-SPEC objects are. Am I offbase here. This is of course based on my assumption that a type of service translates to a TRAFFIC-SPEC. Vik -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com]=20 Sent: Thursday, June 06, 2002 9:46 AM To: Vikram Anantha Cc: ccamp@ops.ietf.org Subject: Re: Sonet Ring provisioning Good points Vikram. Since we cannot standardize services, we need to keep them in min while proposing the mechanisms. This is waht we are trying to do also. Vikram Anantha wrote: > Here's my two bits. > > It appears to me that there are many ways of representing "restoration > islands",. By restoration islands, I refer to BLSR or vendor specific=20 > mesh etc. As Zhi and Sudheer have pointed out it could be "protected=20 > nodes" or "protected links". But in any case, the way of representing=20 > an "restoration island" depends to a large extent on what kind of a=20 > service the user desires. Some of the types of services may be: > - end to end 1+1/1:1 > - end to end dynamic mesh > - end to end unprotected. > - dynamic mesh going thro' "restoration islands" These restoration islands are called risk domains in draft-many-ccamp-srg-01.txt. > > > For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1) > and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to=20 > specify a path from A to Z that could be one of the following: > > 1. Not routed thro' a BLSR ring > 2. routed thro' one BLSR ring > 3. Routed thro' two BLSR rings > These can be again achieved through the SRG draft. Please note the discussion on the inclusive and exclusive constraints. > > J1-----K1 J11----K11 > / \ / \ > I1 L1--- I11 L11 > / \ / \ / \ > / N1-----M1 N11----M11 \ > / \ > / J------K \ > / / \ \ > A------B------H------I L-------O-------Y------Z > \ \ / / > \ N------M F------G > \ / > C---------------D---------E > > So the first question we have to answer is what are the kinds of=20 > services we are trying to provide. Is it fully redundant, mesh, mesh + > partially redundant? > Well we cannot standardize services. So the approach we are taking is what is the scope of this GMPLS P&R work. Until now we are concentrating on the mesh restoration. We need to consider ring protection and using server layer protection as near future enhancements, provided we get more support from the working group discussions. - sudheer > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Friday, May 31, 2002 10:32 AM > To: v.sharma@ieee.org > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;=20 > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > Hi All: > > This is very interesting discussion. > > Some of the people on this discussion list already looked > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt=20 > for more information. > > Here is my opinion: > > Transport networks provide their own protection mechanisms such as the > rings under discussion. As others pointed out it makes good sense to=20 > use them for faster restoration times. These rings may be created=20 > through NMS/EMS - this is not a concern to the control plane. > > The real problem is how to represent this ring topology in the control > plane for the path computation. Well one proposal as mentioned by Zhi=20 > was to represent by a logical node with node capability being "highly=20 > protected node" (inheriting the property of the ring). Another way to=20 > see this, as mentioned in the srg draft is to represent by=20 > point-to-multi point links with the exit points to the ring as the=20 > terminating points of the links and define the same "highly protected" > property on the links (unlike on the node). Now that we have the links > and link property we can use it in the path computation. Once path is=20 > computed it is the nodes, which are on the ring and participate in the > control plane, to make a connection between the end points. Please=20 > refer to the above draft or=20 > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > - sudheer > > Vishal Sharma wrote: > > > Zhi and all, > > > > Great discussion! I'm glad we're finally discussing some of these=20 > > issues, and highlighting that mix inherent ring protection with the=20 > > control domain mechanisms is non-trivial. > > > > Comments in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Zhi-Wei Lin > > > Sent: Thursday, May 30, 2002 11:54 AM > > > To: Suresh Katukam > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp=20 > > > (E-mail); mpls@UU. NET (E-mail) > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > Hi Suresh, > > > > > > Yes agree this is very complex if you try to create too much=20 > > > dependencies between control plane and transport plane protection=20 > > > interactions. That is why my simplistic approach: > > > > > > * Control plane sees the entire ring as offering "highly > available" > > > connections > > > * Control plane sets up a single connection across this ring > > > "sub-network" (if you think this about this, the entire ring > can > > > actually be treated by a control plane controller as a=20 > > > single > node > > > where the BLSR ring nodes may be thought of as aggregate=20 > > > ports > on > > > the single node) > > > * The ring sub-network, by virtue of providing the protection > and > > > knowing *exactly* how protection is provided can set up the > > > protection channel automatically (but control plane need not > know > > > this as it is irrelevant to the control plane -- it only=20 > > > needs > to > > > know that the single connection is protected) > > > > What mechanism will the ring use to setup the internal protection=20 > > channel? > > > > Will it require EMS/NMS intervention, as proposed on this thread=20 > > earlier, or will there be another sequence of control plane messages > > (initiated internal to the ring) to set this path up. The latter=20 > > would > > > be prefereable if the objective is to have fully-automated path=20 > > setup (otherwise, we have EMS/NMS intervention for the ring), but it > > does complicate the control plane protocols (since a new sequence of > > setup steps may have to be initiated internal to each ring on the=20 > > path of the end-to-end circuit/trail that is being setup. > > > > -Vishal > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Jun 2002 09:52:03 -0700 Message-ID: <3CFF91CC.8B617502@nayna.com> Date: Thu, 06 Jun 2002 09:46:04 -0700 From: Sudheer Dharanikota MIME-Version: 1.0 To: Vikram Anantha CC: ccamp@ops.ietf.org Subject: Re: Sonet Ring provisioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Good points Vikram. Since we cannot standardize services, we need to keep them in min while proposing the mechanisms. This is waht we are trying to do also. Vikram Anantha wrote: > Here's my two bits. > > It appears to me that there are many ways of representing "restoration > islands",. By restoration islands, I refer to BLSR or vendor specific > mesh etc. As Zhi and Sudheer have pointed out it could be "protected > nodes" or "protected links". But in any case, the way of representing an > "restoration island" depends to a large extent on what kind of a service > the user desires. > Some of the types of services may be: > - end to end 1+1/1:1 > - end to end dynamic mesh > - end to end unprotected. > - dynamic mesh going thro' "restoration islands" These restoration islands are called risk domains in draft-many-ccamp-srg-01.txt. > > > For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1) > and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to > specify a path from A to Z that could be one of the following: > > 1. Not routed thro' a BLSR ring > 2. routed thro' one BLSR ring > 3. Routed thro' two BLSR rings > These can be again achieved through the SRG draft. Please note the discussion on the inclusive and exclusive constraints. > > J1-----K1 J11----K11 > / \ / \ > I1 L1--- I11 L11 > / \ / \ / \ > / N1-----M1 N11----M11 \ > / \ > / J------K \ > / / \ \ > A------B------H------I L-------O-------Y------Z > \ \ / / > \ N------M F------G > \ / > C---------------D---------E > > So the first question we have to answer is what are the kinds of > services we are trying to provide. Is it fully redundant, mesh, mesh + > partially redundant? > Well we cannot standardize services. So the approach we are taking is what is the scope of this GMPLS P&R work. Until now we are concentrating on the mesh restoration. We need to consider ring protection and using server layer protection as near future enhancements, provided we get more support from the working group discussions. - sudheer > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Friday, May 31, 2002 10:32 AM > To: v.sharma@ieee.org > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) > Subject: Re: Sonet Ring provisioning > > Hi All: > > This is very interesting discussion. > > Some of the people on this discussion list already looked > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt for > more information. > > Here is my opinion: > > Transport networks provide their own protection mechanisms such as the > rings under discussion. As others pointed out it makes good sense to use > them for faster restoration times. These rings may be created through > NMS/EMS - this is not a concern to the control plane. > > The real problem is how to represent this ring topology in the control > plane for the path computation. Well one proposal as mentioned by Zhi > was to represent by a logical node with node capability being "highly > protected node" (inheriting the property of the ring). Another way to > see this, as mentioned in the srg draft is to represent by > point-to-multi point links with the exit points to the ring as the > terminating points of the links and define the same "highly protected" > property on the links (unlike on the node). Now that we have the links > and link property we can use it in the path computation. Once path is > computed it is the nodes, which are on the ring and participate in the > control plane, to make a connection between the end points. Please refer > to the above draft or > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf > > - sudheer > > Vishal Sharma wrote: > > > Zhi and all, > > > > Great discussion! I'm glad we're finally discussing some of these > > issues, and highlighting that mix inherent ring protection with the > > control domain mechanisms is non-trivial. > > > > Comments in-line. > > > > -Vishal > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > > Behalf Of Zhi-Wei Lin > > > Sent: Thursday, May 30, 2002 11:54 AM > > > To: Suresh Katukam > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp > > > (E-mail); mpls@UU. NET (E-mail) > > > Subject: Re: Sonet Ring provisioning > > > > > > > > > Hi Suresh, > > > > > > Yes agree this is very complex if you try to create too much > > > dependencies between control plane and transport plane protection > > > interactions. That is why my simplistic approach: > > > > > > * Control plane sees the entire ring as offering "highly > available" > > > connections > > > * Control plane sets up a single connection across this ring > > > "sub-network" (if you think this about this, the entire ring > can > > > actually be treated by a control plane controller as a single > node > > > where the BLSR ring nodes may be thought of as aggregate ports > on > > > the single node) > > > * The ring sub-network, by virtue of providing the protection > and > > > knowing *exactly* how protection is provided can set up the > > > protection channel automatically (but control plane need not > know > > > this as it is irrelevant to the control plane -- it only needs > to > > > know that the single connection is protected) > > > > What mechanism will the ring use to setup the internal protection > > channel? > > > > Will it require EMS/NMS intervention, as proposed on this thread > > earlier, or will there be another sequence of control plane messages > > (initiated internal to the ring) to set this path up. The latter would > > > be prefereable if the objective is to have fully-automated path setup > > (otherwise, we have EMS/NMS intervention for the ring), but it does > > complicate the control plane protocols (since a new sequence of setup > > steps may have to be initiated internal to each ring on the path of > > the end-to-end circuit/trail that is being setup. > > > > -Vishal > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Jun 2002 02:14:16 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CFF26E7.431981CD@lucent.com> Date: Thu, 06 Jun 2002 11:09:59 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Alex Zinin Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Alex, > I believe that neighbor discovery, being a rather new topic for > the WG, would take some time to reach consensus on. This would > delay the main LMP spec. Are you sure that neighbor discovery is rather new ? - I agree with Martin Dubuc that the current LMP spec can be used for neighbor discovery in point-to-point configurations. My understanding is that he is even using LMP for a.o. this purpose. - Jonathan already explained how the current LMP draft "can be used to discover the connectivity of the data ports". Note that "discovering the connectivity of data ports" is alternative terminology to what I have called "neighbor discovery". Please refer to http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html > > If neighbor discovery is not to be included in LMP, I think there > > are at least some clarifications needed in the LMP draft on what > > is and what is not supported. Furthermore, some clarifications on > > 'control channel management' are needed. > > Sounds reasonable to me. Please work off-line with Jonathan on this > (feel free to CC me). I've tried to be as cooperative as possible by specifying the exact locations in LMP that can be improved regarding "control channel": http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html My feeling is still that this control channel concept is tied into the current means of LMP to do neighbor discovery. I've expressed that feeling several times on this list; no reactions. If this is true, I would like to see the more general description of neighbor discovery in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html as an alternative to "control channel management". If it would help to progress LMP, I can propose an update of the full LMP draft. Just let me know. Thanks, Michiel Alex Zinin wrote: > > Michiel, > > >> While I agree that neighbor > >> discovery is useful, I do not believe we should stop the LMP spec > >> from progressing. > > > I don't understand this remark. > [...] > > If there is anything more I can do to help the LMP spec to progress, > > please let me know ! > > I believe that neighbor discovery, being a rather new topic for > the WG, would take some time to reach consensus on. This would > delay the main LMP spec. > > > If neighbor discovery is not to be included in LMP, I think there > > are at least some clarifications needed in the LMP draft on what > > is and what is not supported. Furthermore, some clarifications on > > 'control channel management' are needed. > > Sounds reasonable to me. Please work off-line with Jonathan on this > (feel free to CC me). > > Alex -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Jun 2002 01:36:10 -0700 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubts in GMPLS-LSR-MIB Date: Thu, 06 Jun 2002 01:32:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, a) The gmplsInSegmentEntry in gmpls-lsr-mib contains gmplsInSegmentIfIndex. In case if the data channel interface and control channel interfaces are different (i.e. out of band signaling) then should gmplsInSegmentIfIndex in gmplsInSegmentEntry represent the ifIndex of control channel interface or the data channel interface ? As per my understanding it should be of data channel interface. b) What should gmplsInterfaceLabelMinIn represent in gmplsInterfaceConfEntry if the ifIndex corresponds to the control channel interface (as the labels are bound to the data channel interface instead the control channel interface in GMPLS) ? Regards, manoj. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Jun 2002 16:39:42 -0700 content-class: urn:content-classes:message Subject: RE: Sonet Ring provisioning Date: Wed, 5 Jun 2002 16:36:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <8CDD92FF12940B41B5053950398AC6E00266F3@bvtn-email.qoptics.com> Thread-Topic: Sonet Ring provisioning Thread-Index: AcIIy4A/Ck62o52dTGCOWLcflh9oAwD/7d0w From: "Vikram Anantha" To: Here's my two bits. It appears to me that there are many ways of representing "restoration islands",. By restoration islands, I refer to BLSR or vendor specific mesh etc. As Zhi and Sudheer have pointed out it could be "protected nodes" or "protected links". But in any case, the way of representing an "restoration island" depends to a large extent on what kind of a service the user desires. Some of the types of services may be: - end to end 1+1/1:1 - end to end dynamic mesh - end to end unprotected. - dynamic mesh going thro' "restoration islands" For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1) and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to specify a path from A to Z that could be one of the following: 1. Not routed thro' a BLSR ring 2. routed thro' one BLSR ring 3. Routed thro' two BLSR rings J1-----K1 J11----K11 =20 / \ / \ =20 I1 L1--- I11 L11 / \ / \ / \ =20 / N1-----M1 N11----M11 \ / \ / J------K \ / / \ \ A------B------H------I L-------O-------Y------Z \ \ / / \ N------M F------G \ / C---------------D---------E So the first question we have to answer is what are the kinds of services we are trying to provide. Is it fully redundant, mesh, mesh + partially redundant? -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com]=20 Sent: Friday, May 31, 2002 10:32 AM To: v.sharma@ieee.org Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail) Subject: Re: Sonet Ring provisioning Hi All: This is very interesting discussion. Some of the people on this discussion list already looked at some of these issues. Please refer to draft-many-ccamp-srg-01.txt for more information. Here is my opinion: Transport networks provide their own protection mechanisms such as the rings under discussion. As others pointed out it makes good sense to use them for faster restoration times. These rings may be created through NMS/EMS - this is not a concern to the control plane. The real problem is how to represent this ring topology in the control plane for the path computation. Well one proposal as mentioned by Zhi was to represent by a logical node with node capability being "highly protected node" (inheriting the property of the ring). Another way to see this, as mentioned in the srg draft is to represent by point-to-multi point links with the exit points to the ring as the terminating points of the links and define the same "highly protected" property on the links (unlike on the node). Now that we have the links and link property we can use it in the path computation. Once path is computed it is the nodes, which are on the ring and participate in the control plane, to make a connection between the end points. Please refer to the above draft or http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf - sudheer Vishal Sharma wrote: > Zhi and all, > > Great discussion! I'm glad we're finally discussing some of these=20 > issues, and highlighting that mix inherent ring protection with the=20 > control domain mechanisms is non-trivial. > > Comments in-line. > > -Vishal > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > > Behalf Of Zhi-Wei Lin > > Sent: Thursday, May 30, 2002 11:54 AM > > To: Suresh Katukam > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp=20 > > (E-mail); mpls@UU. NET (E-mail) > > Subject: Re: Sonet Ring provisioning > > > > > > Hi Suresh, > > > > Yes agree this is very complex if you try to create too much=20 > > dependencies between control plane and transport plane protection=20 > > interactions. That is why my simplistic approach: > > > > * Control plane sees the entire ring as offering "highly available" > > connections > > * Control plane sets up a single connection across this ring > > "sub-network" (if you think this about this, the entire ring can > > actually be treated by a control plane controller as a single node > > where the BLSR ring nodes may be thought of as aggregate ports on > > the single node) > > * The ring sub-network, by virtue of providing the protection and > > knowing *exactly* how protection is provided can set up the > > protection channel automatically (but control plane need not know > > this as it is irrelevant to the control plane -- it only needs to > > know that the single connection is protected) > > What mechanism will the ring use to setup the internal protection=20 > channel? > > Will it require EMS/NMS intervention, as proposed on this thread=20 > earlier, or will there be another sequence of control plane messages=20 > (initiated internal to the ring) to set this path up. The latter would > be prefereable if the objective is to have fully-automated path setup=20 > (otherwise, we have EMS/NMS intervention for the ring), but it does=20 > complicate the control plane protocols (since a new sequence of setup=20 > steps may have to be initiated internal to each ring on the path of=20 > the end-to-end circuit/trail that is being setup. > > -Vishal > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Jun 2002 11:31:59 -0700 Message-Id: <200206051829.OAA06536@photon.poly.edu> Date: Wed, 5 Jun 2002 14:27:59 -0500 From: "Tao Li" Reply-To: tli@photon.poly.edu To: "ccamp@ops.ietf.org" Subject: Liberal label retention vs. Conservative label retention Organization: Polytechnic University Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit Dear All, I get confused about the label retention mode used in GMPLS. It reads 'Liberal label retention is normally used, but conservative label retention mode could also be used' in . Since GMPLS mandates downstream-on-demand label allocation with ingress initiated ordered control, how could liberal label retention being typically used? RFC3036 describes liberal label retention as 'When operating in Downstream on Demand mode with liberal label retention, an LSR might choose to request label mappings for all known prefixes from all peer LSRs.' For SONET or WDM-switch based LSRs, the above situation will never happen. I am a student and just begin to learn GMPLS. Your help is highly appreciated. Regards, Tao Li ECE Department Polytechnic University Brooklyn, NY 11201 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Jun 2002 10:29:45 -0700 Date: Wed, 5 Jun 2002 10:26:49 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <15310852519.20020605102649@psg.com> To: Michiel van Everdingen CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michiel, >> While I agree that neighbor >> discovery is useful, I do not believe we should stop the LMP spec >> from progressing. > I don't understand this remark. [...] > If there is anything more I can do to help the LMP spec to progress, > please let me know ! I believe that neighbor discovery, being a rather new topic for the WG, would take some time to reach consensus on. This would delay the main LMP spec. > If neighbor discovery is not to be included in LMP, I think there > are at least some clarifications needed in the LMP draft on what > is and what is not supported. Furthermore, some clarifications on > 'control channel management' are needed. Sounds reasonable to me. Please work off-line with Jonathan on this (feel free to CC me). Alex Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Jun 2002 06:58:12 -0700 Message-ID: <3CFE1880.9C0CA9E0@lucent.com> Date: Wed, 05 Jun 2002 15:56:16 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I've received several private questions on how the neighbor discovery function in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html would work for the special case of SONET cross connects. The problem would be that - SONET HO path switches (STS-1, STS-Nc) would not have J1 termination capabilities. - SONET LO path switches (VT-1.5) would not have J2 termination capabilities. The solution is to use test signal generators that are able to create and monitor the 'supervisory unequipped' signal (see ITU G.707 and ITU G.783). By virtue of this signal, - SONET HO path switches (STS-1, STS-Nc) *do* have J1 termination capabilities. - SONET LO path switches (VT-1.5) *do* have J2 termination capabilities. Alternatively, SONET HO path switches can use J0 to discover the OC trail and infer the STS connectivity from this discovered OC trail. Likewise, SONET LO path switches can use J1 to discover the STS trail and infer the VT-1.5 connectivity from this discovered STS trail. This alternative approach however has some limitations: - Not applicable for serial compound linkConnections See also http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00621.html - Not applicable for STS connectivity discovery in case regenerators terminate the J0 in-between STS cross connects. Same concept applies in SDH and OTN (supervisory unequipped is called 'NULL client' in OTN). Hope this helps ! Best regards, Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Jun 2002 06:13:34 -0700 Cc: ccamp@ops.ietf.org Message-ID: <3CFE0D71.F53C8A82@lucent.com> Date: Wed, 05 Jun 2002 15:09:05 +0200 From: Michiel van Everdingen Organization: Lucent Technologies MIME-Version: 1.0 To: Alex Zinin Original-CC: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Alex, > The main point of contention is whether the LMP spec should > include neighbor discovery or not. Agreed. > While I agree that neighbor > discovery is useful, I do not believe we should stop the LMP spec > from progressing. I don't understand this remark. I've given very explicit text that can - in my mind - extremely simple be added as *optional* procedure in the current LMP draft. As far as I know, I did not receive a single question or single problem with adding this text into the current LMP draft. For the text, please refer to http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html As this type of neighbor discovery is *optional*, I think it covers Martin's worry that it has a big impact on vendors that have implementations according to the current LMP draft. If there is anything more I can do to help the LMP spec to progress, please let me know ! > I suggest that the WG follows the recommendation made by > its co-chair (see Kireeti's message on May 29th), i.e., work on > the LMP spec is completed without neighbor discovery and folks > interested in defining this functionality work together in a > _constructive_ manner and come up with a separate draft. If neighbor discovery is not to be included in LMP, I think there are at least some clarifications needed in the LMP draft on what is and what is not supported. Furthermore, some clarifications on 'control channel management' are needed. Please see also my reaction on Kireeti's message, posted on May 30th. I would be interested in your reply also ! Thanks, Michiel Alex Zinin wrote: > > Folks, > > This discussion has been going on for a while and I think it > is past the point where it could help the progress of the WG. > > The main point of contention is whether the LMP spec should > include neighbor discovery or not. While I agree that neighbor > discovery is useful, I do not believe we should stop the LMP spec > from progressing. > > I suggest that the WG follows the recommendation made by > its co-chair (see Kireeti's message on May 29th), i.e., work on > the LMP spec is completed without neighbor discovery and folks > interested in defining this functionality work together in a > _constructive_ manner and come up with a separate draft. > > Regards, > > Alex Zinin -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Jun 2002 18:19:39 -0700 Date: Tue, 4 Jun 2002 18:15:18 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <3936135831.20020604181518@psg.com> To: ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, This discussion has been going on for a while and I think it is past the point where it could help the progress of the WG. The main point of contention is whether the LMP spec should include neighbor discovery or not. While I agree that neighbor discovery is useful, I do not believe we should stop the LMP spec from progressing. I suggest that the WG follows the recommendation made by its co-chair (see Kireeti's message on May 29th), i.e., work on the LMP spec is completed without neighbor discovery and folks interested in defining this functionality work together in a _constructive_ manner and come up with a separate draft. Regards, Alex Zinin Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Jun 2002 13:45:11 -0700 Message-ID: <3CFD2613.6030303@lucent.com> Date: Tue, 04 Jun 2002 16:41:55 -0400 From: Carmine Daloia User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: Martin Dubuc CC: Michiel van Everdingen , ccamp@ops.ietf.org Subject: Re: LMP & neighbor discovery Content-Type: multipart/alternative; boundary="------------010804020600010909070600" --------------010804020600010909070600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Martin, See below. Carmine Martin Dubuc wrote: >Michiel, > >Just because it is easy to specify the address of an endpoint in a 15 character field doesn't mean that this is the way to go. Why not put a 30 byte field in every message in order for vendors to add any extensions they'd like? In my mind, any extensions we add to LMP has to make sense in the framework of LMP. As I said before, there is absolutely no mention of CTPs and TTPs in the current LMP spec. Introducing anything that makes reference to CTPs/TTPs would require major rework to LMP spec and might have big impact on any vendor (on this earth) implementing LMP. I am not sure it makes sense at this point in the game. > I don't think anyone really cares about the exact terminology so long as it is clear and understandable. What is more important is making sure that LMP actually provides what is needed. Until LMP does provide what is needed, I don't think its too late to change a LMP specification. Isn't this still a work in progress? > > >I am not convinced that it is not possible to perform TTP->CTP or TTP->TTP link verification with the current spec. I am pretty positive that one can perform TTP->TTP link verification when one models the TTP as a component link. > The reason why Michiel stated that LMP is not applicable for TTP->CTP or TTP->TTP is because the current LMP specification requires the TTP generating the test signal to change its Access Point Identifier over time which is not in line with G.831. G.831 requires that the TTP API be constant over time. Michiel's proposal satisfies the G.831 requirement (see Michiel's email http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html) . > > >Regarding the automatic discovery aspects of LMP, you are right that there is a deficiency with regards to non point-to-point configuration. Current framework of LMP works very well for point-to-point configurations. > So you agree that LMP does cover discovery when a point-to-point control channel exists across each data link. So this seems to imply that Discovery is within the scope of LMP. From reading the emails on this topic the past few weeks it is obvious that this was not clear to many on the ccamp list and even not clear to folks that are listed on the LMP specification itself. Given that Discovery is within the scope of LMP, what is being proposed is that we meed to make it applicable/useful to network configurations that do not support a point-to-point control channel across each data link. A big portion of the LMP specification introduction describes Photonic Cross-connects, yet Photonic Cross-connects will not be capable of supporting a point-to-point control channel in each of its data links. So given that PXCs are within the Framework of LMP and Discovery is as well, it would make sense to me that Discovery would apply to PXCs. Its also going to be important for the new "intelligent-switched" network to interwork with the embedded switches that are controlled by the management plane. This leads to the need to support discovery across serial-compound link connections, which LMP does not. Shouldn't the ability to interwork with the embedded base be considered in LMP or is LMP only applicable for new start-up companies building entirely new networks? > I do not know if we should extend the current spec to also allow auto-discovery of non point-to-point configuration. LMP is most useful in my mind in a point-to-point configuration, so I don't have much problems with the current limitation, which is that control channels for non point-to-point neighbors need to be manually provisioned. > >Finally, I am not sure why you bring the 7200 OADX in the discussion. Is this a lame argument to discredit my interventions? I hope that we could have discussions at another level. > >Regards, > >Martin > >-----Original Message----- >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] >Sent: Friday, May 31, 2002 5:59 AM >To: Martin Dubuc >Cc: ccamp@ops.ietf.org >Subject: Re: LMP & neighbor discovery > > >Hello Martin, > >You seem to only be able to make bold statements without following >up on them: > >- On your statement that we don't need TTP and CTP terminology > because you find these concepts complex: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html > Please follow up on my question for alternative terminology: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html > >- On your statement that my proposal for neighbor discovery is > tailored specifically for Sonet/SDH: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html > Please follow up on my reply that it is more general > applicable: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html > >- On your statement that we don't need to enhance the > discovery aspects of LMP: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html > Please follow up on Carmine's question in: > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html > > >Would the background of your annoyance be that for your specific >product, 7200 OADX, you are only interested in LMP-WDM (i.e. >not LMP) ? I can understand that in a product that integrates >OADM and OXC, it is no problem to have a fixed (not operator >provisioned) control channel between the OADM and the OXC. >However, your specific product is not the only product on this >earth... > > >Best regards, > >Michiel > > >Martin Dubuc wrote: > >>Michiel, >> >>Neighbor discovery, through use of appropriate control channel management >>(see Section 3 and 9), is supported with the current LMP draft. There is >>no need for any extension to the draft for this purpose. >> >>Regards, >> >>Martin >>[...snip...] >> > > > --------------010804020600010909070600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Martin,

See below.

Carmine


Martin Dubuc wrote:
Michiel,

Just because it is easy to specify the address of an endpoint in a 15 character field doesn't mean that this is the way to go. Why not put a 30 byte field in every message in order for vendors to add any extensions they'd like? In my mind, any extensions we add to LMP has to make sense in the framework of LMP. As I said before, there is absolutely no mention of CTPs and TTPs in the current LMP spec. Introducing anything that makes reference to CTPs/TTPs would require major rework to LMP spec and might have big impact on any vendor (on this earth) implementing LMP. I am not sure it makes sense at this point in the game.
I don't think anyone really cares about the exact terminology so long as it is clear and understandable. What is more important is making sure that LMP actually provides what is needed.  Until LMP does provide what is needed, I don't think its too late to change a LMP specification. Isn't this still a work in progress?


I am not convinced that it is not possible to perform TTP->CTP or TTP->TTP link verification with the current spec. I am pretty positive that one can perform TTP->TTP link verification when one models the TTP as a component link.

    The reason why Michiel stated
that LMP is not applicable for TTP->CTP or TTP->TTP is because the
current LMP specification requires the TTP generating the test signal to
change its Access Point Identifier over time which is not in line with G.831.
G.831 requires that the TTP API be constant over time. Michiel's proposal
satisfies the G.831 requirement (see Michiel's email http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html)
. 

    

      
 
 
Regarding the automatic discovery aspects of LMP, you are right that there is a deficiency with regards to non point-to-point configuration. Current framework of LMP works very well for point-to-point configurations.

      

      So you agree that LMP
does cover discovery when a point-to-point control channel exists across
each data link. So this seems to imply that Discovery is within the scope
of LMP. From reading the emails on this topic the past few weeks it is obvious
that this was not clear to many on the ccamp list and even not clear to folks
that are listed on the LMP specification itself.

      

Given that Discovery is within the scope of LMP, what is being proposed is
that we meed to make it applicable/useful to network configurations that
do not support a point-to-point control channel across each data link. A
big portion of the LMP specification introduction describes Photonic Cross-connects,
yet Photonic Cross-connects will not be capable of supporting a point-to-point
control channel in each of its data links. So given that PXCs are within
the Framework of LMP and Discovery is as well, it would make sense to me
that Discovery would apply to PXCs. Its also going to be important for the
new "intelligent-switched" network to interwork with the embedded switches
that are controlled by the management plane. This leads to the need to support
discovery across serial-compound link connections, which LMP does not. Shouldn't
the ability to interwork with the embedded base be considered in LMP or is
LMP only applicable for new start-up companies building entirely new networks?
      

      

        
 I do not know if we should extend the current spec to also allow auto-discovery of non point-to-point configuration. LMP is most useful in my mind in a point-to-point configuration, so I don't have much problems with the current limitation, which is that control channels for non point-to-point neighbors need to be manually provisioned.

Finally, I am not sure why you bring the 7200 OADX in the discussion. Is this a lame argument to discredit my interventions? I hope that we could have discussions at another level.

Regards,

Martin

-----Original Message-----
From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
Sent: Friday, May 31, 2002 5:59 AM
To: Martin Dubuc
Cc: ccamp@ops.ietf.org
Subject: Re: LMP & neighbor discovery


Hello Martin,

You seem to only be able to make bold statements without following
up on them:

- On your statement that we don't need TTP and CTP terminology
  because you find these concepts complex:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
  Please follow up on my question for alternative terminology:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html

- On your statement that my proposal for neighbor discovery is
  tailored specifically for Sonet/SDH:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html
  Please follow up on my reply that it is more general
  applicable:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html

- On your statement that we don't need to enhance the 
  discovery aspects of LMP:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html
  Please follow up on Carmine's question in:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html


Would the background of your annoyance be that for your 
specific
product, 7200 OADX, you are only interested in LMP-WDM (i.e.
not LMP) ? I can understand that in a product that integrates
OADM and OXC, it is no problem to have a fixed (not operator
provisioned) control channel between the OADM and the OXC.
However, your specific product is not the only product on this
earth...


Best regards,

Michiel


Martin Dubuc wrote:

        

          
Michiel,

Neighbor discovery, through use of appropriate control channel management
(see Section 3 and 9), is supported with the current LMP draft. There is
no need for any extension to the draft for this purpose.

Regards,

Martin
[...snip...]

          

          




          

          

          
          

--------------010804020600010909070600--




Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 04 Jun 2002 09:44:15 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: LMP & neighbor discovery
Date: Tue, 4 Jun 2002 12:40:12 -0400
Message-ID: <2B192BF55E1A4440A1176A12D86600C915C8BE@edgsvr04.edgeflow.edgeflow.com>
Thread-Topic: LMP & neighbor discovery
Thread-Index: AcIIiaI3oDrygTPpRkaB8FZCSAvs3ADQPkmw
From: "Martin Dubuc" 
To: "Michiel van Everdingen" 
Cc: 

Michiel,

Just because it is easy to specify the address of an endpoint in a 15 =
character field doesn't mean that this is the way to go. Why not put a =
30 byte field in every message in order for vendors to add any =
extensions they'd like? In my mind, any extensions we add to LMP has to =
make sense in the framework of LMP. As I said before, there is =
absolutely no mention of CTPs and TTPs in the current LMP spec. =
Introducing anything that makes reference to CTPs/TTPs would require =
major rework to LMP spec and might have big impact on any vendor (on =
this earth) implementing LMP. I am not sure it makes sense at this point =
in the game.

I am not convinced that it is not possible to perform TTP->CTP or =
TTP->TTP link verification with the current spec. I am pretty positive =
that one can perform TTP->TTP link verification when one models the TTP =
as a component link.=20
=20
Regarding the automatic discovery aspects of LMP, you are right that =
there is a deficiency with regards to non point-to-point configuration. =
Current framework of LMP works very well for point-to-point =
configurations. I do not know if we should extend the current spec to =
also allow auto-discovery of non point-to-point configuration. LMP is =
most useful in my mind in a point-to-point configuration, so I don't =
have much problems with the current limitation, which is that control =
channels for non point-to-point neighbors need to be manually =
provisioned.

Finally, I am not sure why you bring the 7200 OADX in the discussion. Is =
this a lame argument to discredit my interventions? I hope that we could =
have discussions at another level.

Regards,

Martin

-----Original Message-----
From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
Sent: Friday, May 31, 2002 5:59 AM
To: Martin Dubuc
Cc: ccamp@ops.ietf.org
Subject: Re: LMP & neighbor discovery


Hello Martin,

You seem to only be able to make bold statements without following
up on them:

- On your statement that we don't need TTP and CTP terminology
  because you find these concepts complex:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
  Please follow up on my question for alternative terminology:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html

- On your statement that my proposal for neighbor discovery is
  tailored specifically for Sonet/SDH:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html
  Please follow up on my reply that it is more general
  applicable:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html

- On your statement that we don't need to enhance the=20
  discovery aspects of LMP:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html
  Please follow up on Carmine's question in:
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html


Would the background of your annoyance be that for your specific
product, 7200 OADX, you are only interested in LMP-WDM (i.e.
not LMP) ? I can understand that in a product that integrates
OADM and OXC, it is no problem to have a fixed (not operator
provisioned) control channel between the OADM and the OXC.
However, your specific product is not the only product on this
earth...


Best regards,

Michiel


Martin Dubuc wrote:
>=20
> Michiel,
>=20
> Neighbor discovery, through use of appropriate control channel =
management
> (see Section 3 and 9), is supported with the current LMP draft. There =
is
> no need for any extension to the draft for this purpose.
>=20
> Regards,
>=20
> Martin
> [...snip...]



--=20
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:MvanEverdingen@lucent.com  |
+------------------------------------------------------------------+



Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 04 Jun 2002 04:46:57 -0700
Message-Id: <200206041143.HAA23372@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-yagyu-gmpls-shared-restoration-routing-00.txt
Date: Tue, 04 Jun 2002 07:43:22 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Extensions to OSPF-TE for supporting shared mesh  
                          restoration
	Author(s)	: T. Yagyu, Y. Suemura, A. Kolarov
	Filename	: draft-yagyu-gmpls-shared-restoration-routing-00.txt
	Pages		: 10
	Date		: 03-Jun-02
	
Shared mesh restoration technique efficiently uses network resources
since restoration capacity is shared across multiple independent
failures. In this scheme, when a new working LSP is established, its
corresponding backup LSP is pre-calculated and resources along the
restoration route are reserved. The resources reserved on each link
along the restoration path may be shared across different working
LSPs that are not expected to fail simultaneously. To make the method
for selection of backup LSPs more efficient in terms of utilization
of network resources, each link should provide the route calculator
with information about its restoration capacity and SRLGs of working
LSPs whose backup LSPs share the link restoration capacity. In this
document we propose extensions to OSPF-TE in support of carrying link
'Sharable Bandwidth' information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yagyu-gmpls-shared-restoration-routing-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-yagyu-gmpls-shared-restoration-routing-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-yagyu-gmpls-shared-restoration-routing-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:	<20020603125346.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-yagyu-gmpls-shared-restoration-routing-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-yagyu-gmpls-shared-restoration-routing-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020603125346.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jun 2002 05:30:46 -0700
Message-Id: <4.3.2.7.2.20020603082745.03079da0@mo-ex1>
Date: Mon, 03 Jun 2002 08:29:27 -0400
To: ccamp@ops.ietf.org
From: Lou Berger 
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,
         Please note the version number on and in this file.  They are 
correct.  The -00 version was mistakenly published with -01 in the document.

Lou

At 07:37 AM 6/3/2002, Internet-Drafts@ietf.org wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Common Control and Measurement Plane 
>Working Group of the IETF.
>
>         Title           : Generalized MPLS Signaling - Implementation Survey
>         Author(s)       : L. Berger, Y. Rekhter
>         Filename        : draft-ietf-ccamp-gmpls-signaling-survey-01.txt
>         Pages           : 81
>         Date            : 31-May-02
>
>This document provides a survey of GMPLS signaling implementations.
>The primary focus of this survey are the signaling protocol
>mechanisms specified in the Generalized MPLS signaling documents.
>Other specifications and documents are listed if included in the
>submitted form.  The survey form and latest version of this document
>are available from 
>http://www.labn.net/gmpls-survey.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt 
>
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-ietf-ccamp-gmpls-signaling-survey-01.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-ietf-ccamp-gmpls-signaling-survey-01.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.
>




Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jun 2002 04:39:34 -0700
Message-Id: <200206031137.HAA08301@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-ietf-ccamp-gmpls-sonet-sdh-05.txt
Date: Mon, 03 Jun 2002 07:37:36 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching 
                          ExtensionsExtensions for SONET and SDH Control
	Author(s)	: E. Mannie, D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
	Pages		: 22
	Date		: 31-May-02
	
This document is a companion to the Generalized Multiprotocol 
Label Switching (GMPLS) signaling.  It defines the SONET/SDH 
technology specific information needed when using GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-gmpls-sonet-sdh-05.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-ietf-ccamp-gmpls-sonet-sdh-05.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:	<20020531131552.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020531131552.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jun 2002 04:39:25 -0700
Message-Id: <200206031137.HAA08265@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-ietf-ccamp-gmpls-signaling-survey-01.txt
Date: Mon, 03 Jun 2002 07:37:23 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS Signaling - Implementation Survey
	Author(s)	: L. Berger, Y. Rekhter
	Filename	: draft-ietf-ccamp-gmpls-signaling-survey-01.txt
	Pages		: 81
	Date		: 31-May-02
	
This document provides a survey of GMPLS signaling implementations.
The primary focus of this survey are the signaling protocol
mechanisms specified in the Generalized MPLS signaling documents.
Other specifications and documents are listed if included in the
submitted form.  The survey form and latest version of this document
are available from http://www.labn.net/gmpls-survey.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-gmpls-signaling-survey-01.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-ietf-ccamp-gmpls-signaling-survey-01.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:	<20020531131532.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-signaling-survey-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020531131532.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jun 2002 04:39:19 -0700
Message-Id: <200206031137.HAA08283@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-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
Date: Mon, 03 Jun 2002 07:37:29 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching Extensions 
                          to Control Non-Standard SONET and SDH Features
	Author(s)	: E. Mannie, D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
	Pages		: 14
	Date		: 31-May-02
	
This document is a companion to the Generalized Multiprotocol 
Label Switching (GMPLS) signaling extensions to control SONET and 
SDH that define the SONET/SDH technology specific information 
needed when using GMPLS signaling. 
This informational document defines GMPLS signaling extensions to 
control four optional non-standard (i.e. proprietary) SONET and 
SDH features: group signals, arbitrary concatenation, virtual 
concatenation of contiguously concatenated signals and per byte 
transparency.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ietf-ccamp-gmpls-sonet-sdh-extensions-03.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-ietf-ccamp-gmpls-sonet-sdh-extensions-03.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:	<20020531131542.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020531131542.I-D@ietf.org>

--OtherAccess--

--NextPart--





Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jun 2002 02:16:42 -0700
Cc: Sudheer Dharanikota , Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" 
Message-ID: <3CFB336F.807CA33A@lucent.com>
Date: Mon, 03 Jun 2002 11:14:23 +0200
From: Maarten Vissers 
Organization: Lucent Technologies
MIME-Version: 1.0
To: v.sharma@ieee.org
Original-CC: Sudheer Dharanikota , Zhi-Wei Lin , Suresh Katukam , "R. Muralidharan" , "Bernstein, Greg" , "'Manoj Agiwal'" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" 
Subject: Re: Sonet Ring provisioning
Content-Type: multipart/mixed; boundary="------------315C0C790378FFCA7E5E0DA5"

This is a multi-part message in MIME format.
--------------315C0C790378FFCA7E5E0DA5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vishal,

The answer to this issue is layer networking. I.e. the HOVC layer network sees
the MS SPring protected ring as a set of HOVC fabrics and (1, 2 or 3 types of)
interconnecting HOVC links. 
The HOVC fabrics have a restriction; there is no time slot interchange possible
between the two main links. I.e. the link connection in those two links must
have the same number.

The HOVC control plane selects in which type of HOVC link (protected,
unprotected, preemptable) the new connection has to be created, and then routes
this connection through the HOVC fabrics and links.

The MS SPring [BLSR] control function within the ring network elements (if
supported) will have to populate the ring nodes with the appropriate further
information to run the ring, but this is outside the HOVC control plane's view.

>From a HOVC control plane, this is almost a trivial issue... only constraint is
no "time slot interchange" on ring HOVC links.

Regards,

Maarten

Vishal Sharma wrote:
> 
> Sudheer,
> 
> While I agree that representing nodes/domains/rings etc. is an important
> problem, I think there are two issues being mixed below.
> 
> One is the problem of the initial configuration of the UPSR/BLSR ring,
> which is clearly (today) an NMS/EMS operation.

And may be supported by MSn control plane in the future...

> 
> The other is of dynamically setting up trails on the ring. It is this
> latter problem that falls under the purview of an automated control
> plane, and is the one being discussed. This will involve the control plane,
> and the issue there, as Suresh pointed out, is how does one deal with
> mixed mesh-ring networks, similar, for example, to the topology drawn by
> Nik Langrind.
> 
> In that case, I don't think the GMPLS specifications are complete enough
> to enable one to accomplish path setup. There are several issues
> there, including the difficulty of deciding exactly the process by
> which path setup on rings will be handled, and how the various items
> that Zhi outlined in an earlier email (ring/span switching supported?,
> extra traffic supported? etc.) will be handled.

GMPLS is quite complete; only item is if it can handle the "no time slot
interchange" case. The rest is taken care of in setting up the HOVC layer
network topology... i.e. you must use GMPLS in a layered networking manner...

> 
> I see the issue of representation as somewhat tied to how one does
> path setup above. That will dictate how the rings and their nodes/links
> should be represented in the routing protocols, and how path computation
> will take them into account.
> 
> Some of these issues were discussed by us in a draft a while back
> http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx
> t
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Sudheer Dharanikota [mailto:sudheer@nayna.com]
> > Sent: Friday, May 31, 2002 10:32 AM
> > To: v.sharma@ieee.org
> > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;
> > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)
> > Subject: Re: Sonet Ring provisioning
> >
> >
> > Hi All:
> >
> > This is very interesting discussion.
> >
> > Some of the people on this discussion list already looked
> > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt
> > for more information.
> >
> > Here is my opinion:
> >
> > Transport networks provide their own protection mechanisms such
> > as the rings under discussion. As others pointed out it makes good
> > sense to use them for faster restoration times. These rings may
> > be created through NMS/EMS - this is not a concern to the control
> > plane.
> >
> > The real problem is how to represent this ring topology in the control
> > plane for the path computation. Well one proposal as mentioned by
> > Zhi was to represent by a logical node with node capability being
> > "highly protected node" (inheriting the property of the ring). Another
> > way to see this, as mentioned in the srg draft is to represent by
> > point-to-multi point links with the exit points to the ring as the
> > terminating points of the links and define the same "highly protected"
> > property on the links (unlike on the node). Now that we have the
> > links and link property we can use it in the path computation.
> > Once path is computed it is the nodes, which are on the ring and
> > participate in the control plane, to make a connection between
> > the end points. Please refer to the above draft or
> > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf
> >
> > - sudheer
> >
> >
> >
> > Vishal Sharma wrote:
> >
> > > Zhi and all,
> > >
> > > Great discussion! I'm glad we're finally discussing some of these
> > > issues, and highlighting that mix inherent ring protection with
> > > the control domain mechanisms is non-trivial.
> > >
> > > Comments in-line.
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > > > Behalf Of Zhi-Wei Lin
> > > > Sent: Thursday, May 30, 2002 11:54 AM
> > > > To: Suresh Katukam
> > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail);
> > > > mpls@UU. NET (E-mail)
> > > > Subject: Re: Sonet Ring provisioning
> > > >
> > > >
> > > > Hi Suresh,
> > > >
> > > > Yes agree this is very complex if you try to create too much
> > > > dependencies between control plane and transport plane protection
> > > > interactions. That is why my simplistic approach:
> > > >
> > > >     * Control plane sees the entire ring as offering "highly
> > available"
> > > >       connections
> > > >     * Control plane sets up a single connection across this ring
> > > >       "sub-network" (if you think this about this, the entire ring can
> > > >       actually be treated by a control plane controller as a
> > single node
> > > >       where the BLSR ring nodes may be thought of as
> > aggregate ports on
> > > >       the single node)
> > > >     * The ring sub-network, by virtue of providing the protection and
> > > >       knowing *exactly* how protection is provided can set up the
> > > >       protection channel automatically (but control plane
> > need not know
> > > >       this as it is irrelevant to the control plane -- it
> > only needs to
> > > >       know that the single connection is protected)
> > >
> > > What mechanism will the ring use to setup the internal
> > protection channel?
> > >
> > > Will it require EMS/NMS intervention, as proposed on this
> > thread earlier,
> > > or will there be another sequence of control plane messages (initiated
> > > internal to the ring) to set this path up. The latter would be
> > prefereable
> > > if the objective is to have fully-automated path setup (otherwise, we
> > > have EMS/NMS intervention for the ring), but it does complicate the
> > > control plane protocols (since a new sequence of setup steps may
> > > have to be initiated internal to each ring on the path of the end-to-end
> > > circuit/trail that is being setup.
> > >
> > > -Vishal
> > >
> > > >
--------------315C0C790378FFCA7E5E0DA5
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

--------------315C0C790378FFCA7E5E0DA5--