Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 23:50:39 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: kireeti@juniper.net, mvissers@lucent.com, eric.mannie@gtsgroup.com Bcc: Subject: Re: Bandwidth modification in GMPLS Date: Sat, 01 Dec 2001 00:42:59 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If the bandwidth modification is not supported by GMPLS then it should be clearly mentioned in the drafts (at least the architecture draft). Please see the attached mail for reference. I am still not clear whether GMPLS supports SE-style of reservation. My original question related to SE-style of reservation was and I didn't get any reply on the mailing list : " I have a doubt related to SE style of reservation in GMPLS. As in RSVP-TE, multiple senders can share the reservation but they can be assigned different labels to distinguish different senders from one other. In GMPLS, as the label itself is a resource on the link, it means that if there are multiple senders in the same session sharing reservation, they should be assigned the same label. They can't be assigned different labels or is it that GMPLS does not support SE style of reservation ?" Please correct me if I am missing something. Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: Bandwidth modification in GMPLS >Date: Fri, 30 Nov 2001 11:45:25 +0100 > >Manoj, > >manoj juneja wrote: > > > > Hi All, > > Is it possible to modify/increase the bandwidth of an existing >GMPLS > > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be >possible to > > increase the bandwidth to say VC-4 ? > >No, this is not possible. > >Regards, > >Maarten > > > > > Should the new request be considered independent of previous one ? > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 23:33:42 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: jplang@calient.net Bcc: Subject: LSC Interface Doubt ... Date: Sat, 01 Dec 2001 00:31:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If I need to establish a bi-directional LSC LSP then do I need to configure the remote end wavelengths on an LSC interface ? Is there any case where both the upstream and downstream labels of an bi-directional LSC LSP be same ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 15:14:33 -0800 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC6240FA6E0@OCCLUST02EVS1.ugd.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Maarten Vissers'" , Dimitri Papadimitriou Cc: ccamp , q14/15 Subject: RE: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Date: Fri, 30 Nov 2001 18:11:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Just back from vacation, my comments may be late but they are not much different from my previous comments. It seems we are still discussing one label vs. two... I, and others, have continually commented that G.707 contains both ETSI SDH and ANSI SONET. It has always contained both. Supporting two gmpls general labels - one for ANSI T1.105 and one for ITU-T G.707 - is incorrect and adds unnecessary complexity for both equipment and operators. If by sdh, the implication is the TUG-3 structure, than refer to this explicitly in the label. Or say ETSI sdh. The preference by international operators is to simplify - we prefer one general label with technology specific details (TUG3 vs. TUG2) to be addressed by the technology specific documents. Other international operators have supported my comments on this exploder. If this comment is not acceptable by the editors of the mpls-gen signaling document, it would be productive to have a response as to why? If the draft on sonet-sdh-interwork is intended to be a rationale for maintaining two different labels, we can grueling go thru the exercise on this exploder and comment on it. I would propose (as Randy has already requested) for sdh/sonet technology discussions, let's take the discussion to the ITU-T exploder i.e. my first comment on this draft is the incorrect assumption that one needs to do transport level processing to interwork a VC-3 with a STS-1 SPE. This is incorrect - one does not touch the signal - no removal of fixed stuff bytes is required - the VC-3 and STS-1 SPE are equivalent for DS3 mappings and 34M (note the DS3 mapping is different than a 34M mapping). It is simply transporting a VC-3 containing a DS3 (or 34M) via AU3 or via AU4 (both supported in G.707!). If the authors of this document need additional info, just ask via the ITU-T Q11 exploder. Or we can discuss here... We can continue to go thru the draft line by line, or to move this discussion quickly, if we go to section 4, the only interworking rule which is listed as needed, is the conversion of the LSP encoding type from sdh to sonet. IF the same label would apply, there would be no need for gmpls sdh-sonet interworking. As Maarten notes below, there are many capabilities (positive connotation)/differences (negative connotation) within ETSI SDH and within ANSI SONET which do not allow for simply connecting two pieces of equipment either at a link level or end-to-end path level. A simple connection request may not even work between the same vendor's equipment :-( Defining different gmpls labels for sdh vs. sonet does not guarantee transport connectivity for SDH equipment or SONET equipment. Deborah Brungard AT&T -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 23, 2001 4:49 AM To: Dimitri Papadimitriou Cc: ccamp; q14/15 Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Dimitri, These differences are not specifically between SDH and SONET, you will also find a number of those between SDH and SDH or between SONET and SONET. Furthermore there are many more items that may require negotiation between elements in the connection. If you look into the items you will notice that they are associated with the ports at the end of the connection or at intermediate points along the connection. As such a generic mechanism is required that establishes interworking for the case two ports (monitoring points) have different options selected. Port types to be considered (just a first quick list; still very incomplete): VC-m (m=11,12,2) port - Path Trace Identifier (J2): 16-byte and 64-byte path trace identifier strings - performance monitoring: BIP violation counting, Errored Block (EB) counting VC-m (m=11,12,2) SNC protected port - all kind of SNC protection related parameters; e.g. SNC protection type, operation type, holdoff timer, etc. VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) port - Path Trace Identifier (J1): 16-byte and 64-byte path trace identifier strings - Path Trace Identifier (J1): 64-byte path trace identifier formats - performance monitoring: BIP violation counting, Errored Block (EB) counting - user channel support: none/F2/F2F3/F3 VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) TCM port - Tandem connection monitoring: option I and II VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) SNC protected port - all kind of SNC protection related parameters; e.g. SNC protection type, operation type, holdoff timer, etc. STM-N (N=0,1,4,16,64,256) RS port - Regenerator Section Trace Identifier (J0): 1-byte and 16-byte section trace identifier strings - RS-DCC support - RS orderwire support - RS user channel support STM-N MS port - older AU/STS pointer processors: ss-bits source processing: generation of "10" or "00" pattern, sink processing: verify presence of ss-bit pattern or ignore ss-bit pattern - newer AU/STS pointer processors: source generates ss-bits "10", sink ignores ss-bits ==> i.e. no interworking issue - Synchronisation Status Message (SSM) code set: option I, II or III (see G.781) - MS-REI: MS-REI supported/not-supported - STM-64 MS-REI: M0M1 or M1 only - MS-DCC support - RS orderwire support STM-N (N=0,1,4,16,64,256) MS protected port - K1K2 MSP-APS switching type codes (uni-/bi-directional) in K2[6-8] for case of 1:n - all kind of MS protection related parameters (see G.841 and G.783); e.g. switching type, operation type, architecture type, etc. STM-N (N=16,64,256) MS SPRing protected port - all kind of MS SPring protection related parameters In general, the setup of the connection may have more than one phase associated: 1) connection bearer setup 2) connection monitoring setup 3) connection protection setup The latter two phases require a detailed review of the MI_XXX parameters in the atomic functions in G.705, G.781, G.783, G.798 as well as a review of the set of atomic functions that represent normally optional functionality. Everything that allows selectivity on a per connection basis needs to be identified and allocated to connection monitoring and protection service signalling. As you can see the few specific SONET/SDH differences are like noise and don't deserve separate LSP encoding types. Different LSP encoding types will complicate things more than help. Regards, Maarten Dimitri Papadimitriou wrote: > > Hi Maarten, > > Thanks for these comments, it has been left for further consideration > within this document, but you know that they are "differences" between > Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are > mainly J0 at RS/SOH and K2 MS/LOH. > > Nevertheless, the key question is does it impact the control plane > specification ? And this is one of the purpose of this document (again > at a first stage). > > So, prior to propose a merge of the control plane code-points i would > like first to ask you if the current proposals made in order to provide > interoperability have been accepted and integrated. Knowing that we can > then evaluate the impact on the control plane and after we could > consider > your proposal. > > Many thanks, > - dimitri. > > Maarten Vissers wrote: > > > > All, > > > > I had a look on contribution > > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to provide > > some comment. > > > > 1) I "liked" :-( the first sentence in section 2: "This section describes how > > SDH and SONET can interwork at the transport plane level." I only thought that > > this was already defined for many years in G.707. :-) > > A reference to section 6.4/G.707 seems more appropriate, as it will show > > interconnection in general between VC-3 transport in multiplex sections (AU-3, > > STS-1) and VC-4 paths (TU-3). > > It will also show interconnection between VC-11 transport in VC-11 link > > connections (TU-11, VT1.5) and VC-12 link connections (TU-12). > > > > 2) From a connection management perspective (scope of the control plane), the > > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one signal type. > > Interworking happens simply within the VC-3 layer network by means of connecting > > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP. > > It is unimportant how the VC-3/STS-1 arrives/departs at/from the VC-3/STS-1 SNP; > > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3. > > > > Links (link bundles) which support VC-3/STS-1 link connections will simply > > advertise this capability via their LSAs. A VC-3 fabric having two VC-3 > > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP within > > the first link to a VC-3/STS-1 SNP within the second link. > > > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary due to the > > fact that two LSP Encoding Types were allocated. If just one LSP Encoding Type > > would be allocated for both SDH and SONET, we would not require any GMPLS > > SDH-SONET interworking functionality. > > > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one > > codepoint referred to as SDH/SONET. > > > > Regards, > > > > Maarten Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 12:15:12 -0800 Message-ID: <3C07E765.1090208@lucent.com> Date: Fri, 30 Nov 2001 15:09:09 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: question on draft-ietf-ccamp-ospf-gmpls-extensions-01.txt, draft-katz-yeung-ospf-traffic-06.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, For the OSPF TE extensions, the sub-TLV range: 32768-32772 - Reserved for Cisco-specific extensions Can any vendor ask for the reservations for these extensions? What's the process for asking for codepoints? Thanks Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 11:36:22 -0800 Message-Id: <200111301932.fAUJWG071475@merlot.juniper.net> To: Edward Harrison cc: "Karmakar, Soumen" , "'ccamp@ops.ietf.org'" Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57998.1007148736.1@juniper.net> Date: Fri, 30 Nov 2001 11:32:16 -0800 From: Yakov Rekhter Ed, > draft-ietf-mpls-bundle-01.txt clearly states that only TLVs of types 1 > (IPv4), 2(IPv6) or 3(IF_INDEX) are to be used in the IF_ID object (when > dealing with component links). correct. > However, types 4 & 5 (the COMPONENT_IF_* > types) are still defined in the new GMPLS draft > (draft-ietf-mpls-generalized-signaling-07.txt). that is correct too. > Should they have been retired from this latest revision of the generalized > signaling draft? I wouldn't argue against this :-) > Also, draft-ietf-mpls-generalized-rsvp-te-06.txt specifies that, for > component links, it is still possible to specify distinct downstream and > upstream component data channels: > > ...In the special case where a > bidirectional LSP that traverses a bundled link, it is possible to > specify a downstream data channel that differs from the upstream data > channel. > > If one shouldn't use the COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM > TLVs, then presumably one would have two TLVs in the IF_ID hop object. Is > there a convention which says which TLV refers to the downstream and which > the upstream direction? If there are sufficient *practical* justification to support the special case (downstream channel different from the upstream channel), then we would add text to the link bundling draft to cover this case by using COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM TLVs. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 10:36:11 -0800 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F81363BC@baker.datcon.co.uk> From: Edward Harrison To: 'Yakov Rekhter' , "Karmakar, Soumen" Cc: "'ccamp@ops.ietf.org'" Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 Date: Fri, 30 Nov 2001 18:22:30 -0000 Deferred-Delivery: Fri, 30 Nov 2001 18:25:00 -0000 MIME-Version: 1.0 Content-Type: text/plain Yakov, draft-ietf-mpls-bundle-01.txt clearly states that only TLVs of types 1 (IPv4), 2(IPv6) or 3(IF_INDEX) are to be used in the IF_ID object (when dealing with component links). However, types 4 & 5 (the COMPONENT_IF_* types) are still defined in the new GMPLS draft (draft-ietf-mpls-generalized-signaling-07.txt). Should they have been retired from this latest revision of the generalized signaling draft? Also, draft-ietf-mpls-generalized-rsvp-te-06.txt specifies that, for component links, it is still possible to specify distinct downstream and upstream component data channels: ...In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from the upstream data channel. If one shouldn't use the COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM TLVs, then presumably one would have two TLVs in the IF_ID hop object. Is there a convention which says which TLV refers to the downstream and which the upstream direction? Cheers, Ed Harrison ------ Edward Harrison mailto:eph@dataconnection.com Network Convergence Group Data Connection Ltd. http://www.dataconnection.com/ Tel: +44 20 8366 1177 Fax: +44 20 8363 1468 -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: 29 November 2001 19:06 To: Karmakar, Soumen Cc: 'ccamp@ops.ietf.org' Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 Soumen, > Was there a decision taken on this and reflected in drafts (or to come) of > the removal of COMPONENT_IF_UPSTREAM ? Or that the type is supported and may > not be used. The UNI specifications mandates that both upstream and > downstream component id must be specified for bidirectional connection. Will > these also be reflected in the OUNI (oif2000.125.7) specification ? see draft-ietf-mpls-bundle-01.txt Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 07:15:10 -0800 Message-ID: <3C07A24A.8090607@lucent.com> Date: Fri, 30 Nov 2001 10:14:18 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: comments on rsvp-te-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi folks, In rsvp-te-06, IANA consideration section, the Notify message message type also needs to be assigned by IANA. Also, several error codes/values were introduced in the document. I believe these also need to be identified and assigned (e.g., routing problem/switching type, routing problem/unsupported link protection) In section 9.3, two error messages were defined: "Control Channel Degraded State" "Control Channel Active State" Are these both new error codes, or a single error code with two error values, or part of an existing error code? Also, the text says "inform other nodes of the restoration via a PathErr...". What are the other nodes? Is it all RSVP-aware nodes, all nodes where a LSP passes through the failed node, etc. ? In section 4.3.1, reference to RFC2205 for error codes and values is insufficient. Many of the relevant error codes are also in the RSVP-TE I-D. In section 7.2.1, both step 3 are the same description. Based on the flow of description, I think the first step 3 should read: "Upon receiving the Admin Status Object with the Delete (D) bit set in the Path message, the egress node sends a PathErr message (with ^^^^ ^^^^^^ ^^^^^^^ ^^^^^ Path_State_Removed flag set) upstream to remove the LSP and normal RSVP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing takes place." In section 9.1, a statement under "recovery time": A value of 0xffffffff indicates that resynchronization may occur at a rate selected by the receiver. while in section 9.5.2, the following statement is made: A Recovery Time value of 0xffffffff indicates that the Recovery Period is effectively infinite. which is correct? or am I misinterpreting this? Looking forward to comments... Zhi Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 02:57:51 -0800 Message-Id: <200111301057.FAA02003@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-architecture-01.txt Date: Fri, 30 Nov 2001 05:57:12 -0500 --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 Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie et al. Filename : draft-ietf-ccamp-gmpls-architecture-01.txt Pages : 56 Date : 29-Nov-01 Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-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-architecture-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-architecture-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: <20011129143633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129143633.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Nov 2001 02:46:57 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3C076345.2E14EC03@lucent.com> Date: Fri, 30 Nov 2001 11:45:25 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: Bandwidth modification in GMPLS Content-Type: multipart/mixed; boundary="------------00E4DDEB429CC10EF7D2E85C" This is a multi-part message in MIME format. --------------00E4DDEB429CC10EF7D2E85C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, manoj juneja wrote: > > Hi All, > Is it possible to modify/increase the bandwidth of an existing GMPLS > tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be possible to > increase the bandwidth to say VC-4 ? No, this is not possible. Regards, Maarten > > Should the new request be considered independent of previous one ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------00E4DDEB429CC10EF7D2E85C 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 --------------00E4DDEB429CC10EF7D2E85C-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 18:25:10 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Bandwidth modification in GMPLS Date: Thu, 29 Nov 2001 19:17:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Is it possible to modify/increase the bandwidth of an existing GMPLS tunnel ? I mean to say if I establish a VC-3 SDH LSP, will it be possible to increase the bandwidth to say VC-4 ? Should the new request be considered independent of previous one ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 14:19:33 -0800 Date: Thu, 29 Nov 2001 14:12:47 -0800 (PST) From: Kireeti Kompella Message-Id: <200111292212.OAA29750@kummer.juniper.net> To: ccamp@ops.ietf.org, mpls@uu.net Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 > see draft-ietf-mpls-bundle-01.txt In fact, it would be a good idea for those interested to look at the latest versions of the bundling, unnumbered and hierarchy drafts. There are a number of changes, and hopefully the sum total is more coherent and consistent now. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 13:36:35 -0800 Date: Thu, 29 Nov 2001 16:34:26 -0500 From: Ron Bonica Subject: FW: I-D ACTION:draft-bonica-tunneltrace-02.txt To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT F.Y.I. > -----Original Message----- > From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On > Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, November 29, 2001 6:10 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-bonica-tunneltrace-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Tracing Requirements for Generic Tunnels > Author(s) : R. Bonica, K. Kompella, D. Meyer > Filename : draft-bonica-tunneltrace-02.txt > Pages : 11 > Date : 28-Nov-01 > > This document specifies requirements for a generic route tracing > application. The application must provide all functionality that > 'traceroute' [RFC 2151] currently provides. It also must provide > enhanced capabilities with regard to tunnel tracing (e.g., tracing > through IP-in-IP tunnels, tracing through MPLS LSPs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bonica-tunneltrace-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-bonica-tunneltrace-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-bonica-tunneltrace-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 12:47:47 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be Bcc: Subject: SE style of reservation in GMPLS Date: Thu, 29 Nov 2001 13:44:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a doubt related to SE style of reservation in GMPLS. As in RSVP-TE, multiple senders can share the reservation but they can be assigned different labels to distinguish different senders from one other. In GMPLS, as the label itself is a resource on the link, it means that if there are multiple senders in the same session sharing reservation, they should be assigned the same label. They can't be assigned different labels or is it that GMPLS does not support SE style of reservation ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 11:09:33 -0800 Message-Id: <200111291905.fATJ5Y001480@merlot.juniper.net> To: "Karmakar, Soumen" cc: "'ccamp@ops.ietf.org'" Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30281.1007060734.1@juniper.net> Date: Thu, 29 Nov 2001 11:05:34 -0800 From: Yakov Rekhter Soumen, > Was there a decision taken on this and reflected in drafts (or to come) of > the removal of COMPONENT_IF_UPSTREAM ? Or that the type is supported and may > not be used. The UNI specifications mandates that both upstream and > downstream component id must be specified for bidirectional connection. Will > these also be reflected in the OUNI (oif2000.125.7) specification ? see draft-ietf-mpls-bundle-01.txt Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 10:14:15 -0800 Message-Id: <200111291808.NAA27650@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-many-inference-srlg-02.txt Date: Thu, 29 Nov 2001 13:08:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inference of Shared Risk Link Groups Author(s) : D. Papadimitriou et al. Filename : draft-many-inference-srlg-02.txt Pages : 17 Date : 28-Nov-01 The Shared Risk Link Group (SRLG) concept introduced in [IPO-Frame] is considered as one of the most important criteria concerning the constrained-based path computation of optical channel routes. By applying the SRLG constraint criteria to the constrained-based path computation, one can select a route taking into account resource and logical structure disjointness that implies a lower probability of simultaneous lightpath failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-inference-srlg-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-many-inference-srlg-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-many-inference-srlg-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: <20011128144006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-many-inference-srlg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-many-inference-srlg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144006.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 10:08:59 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCB7C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Dave Cooper'" , "Dekany, Steven" , ccamp@ops.ietf.org, te-wg@ops.ietf.org, pwe3@ietf.org Subject: RE: 52nd IETF - MPLS OAM BOF announcement Date: Thu, 29 Nov 2001 10:02:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Sure, We will do both. -Shahram > -----Original Message----- > From: Dave Cooper [mailto:dcooper@gblx.net] > Sent: Thursday, November 29, 2001 12:36 PM > To: Dekany, Steven; Shahram Davari; ccamp@ops.ietf.org; > te-wg@ops.ietf.org; pwe3@ietf.org > Subject: RE: 52nd IETF - MPLS OAM BOF announcement > > > > Shahram, > > > > > > It might be helpful perhaps to use the 20 minute discussion > time on the > > agenda to encourage Service Providers to address this issue > from their > > perspective. What are the additional and specific business > and operational > > benefits for them, for potentially implementing - and > paying for - a new > > and drawbacks. > > -dave > > > > MPLS OAM mechanism. > > > > Just a thought for consideration. > > > > > > Thanks and Best Regards, > > > > Steven > > > > > > Steven Dekany > > Marconi Communications > > (972)916-4292 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, November 29, 2001 10:40 AM > > To: ccamp@ops.ietf.org; te-wg@ops.ietf.org; pwe3@ietf.org > > Subject: 52nd IETF - MPLS OAM BOF announcement > > > > > > 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) > > > > The purpose of the MPLS OAM BOF is to determine what type > of operations and > > maintenance tools are required for MPLS networks. The BOF > will address if > > traceroute and ping are sufficient operations and > maintenance tools for > > MPLS network operators. The BOF will consider the need for > other types of > > OAM tools for MPLS networks. > > > > The agenda for this BOF is available at: > > > > http://www.ietf.org/ietf/01dec/mplsoam.txt > > > > > > Regards, > > Shahram Davari > > PMC-Sierra, Inc. > > Phone: (613) 271-4018 > > Fax: (613) 271-6468 > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 09:43:25 -0800 From: "Dave Cooper" To: "Dekany, Steven" , "Shahram Davari" , , , Subject: RE: 52nd IETF - MPLS OAM BOF announcement Date: Thu, 29 Nov 2001 09:35:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Shahram, > > > It might be helpful perhaps to use the 20 minute discussion time on the > agenda to encourage Service Providers to address this issue from their > perspective. What are the additional and specific business and operational > benefits for them, for potentially implementing - and paying for - a new and drawbacks. -dave > MPLS OAM mechanism. > > Just a thought for consideration. > > > Thanks and Best Regards, > > Steven > > > Steven Dekany > Marconi Communications > (972)916-4292 > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, November 29, 2001 10:40 AM > To: ccamp@ops.ietf.org; te-wg@ops.ietf.org; pwe3@ietf.org > Subject: 52nd IETF - MPLS OAM BOF announcement > > > 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) > > The purpose of the MPLS OAM BOF is to determine what type of operations and > maintenance tools are required for MPLS networks. The BOF will address if > traceroute and ping are sufficient operations and maintenance tools for > MPLS network operators. The BOF will consider the need for other types of > OAM tools for MPLS networks. > > The agenda for this BOF is available at: > > http://www.ietf.org/ietf/01dec/mplsoam.txt > > > Regards, > Shahram Davari > PMC-Sierra, Inc. > Phone: (613) 271-4018 > Fax: (613) 271-6468 > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 09:37:19 -0800 Message-Id: <200111291105.GAA20249@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-routing-01.txt Date: Thu, 29 Nov 2001 06:05:27 -0500 --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 : Routing Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-gmpls-routing-01.txt Pages : 21 Date : 28-Nov-01 This document specifies routing extensions in support of Generalized Multi-Protocol Label Switching (GMPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-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-routing-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-routing-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: <20011128143449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-routing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-routing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143449.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 09:37:12 -0800 Message-Id: <200111291107.GAA20637@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-many-inference-srlg-02.txt Date: Thu, 29 Nov 2001 06:07:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inference of Shared Risk Link Groups Author(s) : D. Papadimitriou et al. Filename : draft-many-inference-srlg-02.txt Pages : 17 Date : 28-Nov-01 The Shared Risk Link Group (SRLG) concept introduced in [IPO-Frame] is considered as one of the most important criteria concerning the constrained-based path computation of optical channel routes. By applying the SRLG constraint criteria to the constrained-based path computation, one can select a route taking into account resource and logical structure disjointness that implies a lower probability of simultaneous lightpath failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-inference-srlg-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-many-inference-srlg-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-many-inference-srlg-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: <20011128144006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-many-inference-srlg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-many-inference-srlg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144006.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 09:37:03 -0800 Message-Id: <200111291105.GAA20237@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-ospf-gmpls-extensions-01.txt Date: Thu, 29 Nov 2001 06:05:21 -0500 --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 : OSPF Extensions in Support of Generalized MPLS Author(s) : K. Kompella et al. Filename : draft-ietf-ccamp-ospf-gmpls-extensions-01.txt Pages : 9 Date : 28-Nov-01 This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-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-ospf-gmpls-extensions-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-ospf-gmpls-extensions-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: <20011128143438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ospf-gmpls-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143438.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 09:17:31 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Asymmetric optical links in GMPLS Date: Thu, 29 Nov 2001 10:14:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Marteen, I have a very basic question about optical networks. If I have a bi-directional SDH link between two nodes A and B and I get a request to establish a uni-directional VC-4 SDH LSP, what happens to the bandwidth corresponding to the same VC-4 in the other direction ? Can I allocate the other direction of VC-4 to some other uni -directional LSP in opposite direction ? In other terms I mean to say that does the GMPLS or optical networks supports asymmetric links like ATM does ? What about the wavelength links ? Are these asymmetric too ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 08:59:30 -0800 Message-ID: <73573B0D37AFD311A3A800204840ED032DB596@dal-server-01.pit.comms.marconi.com> From: "Dekany, Steven" To: Shahram Davari , ccamp@ops.ietf.org, te-wg@ops.ietf.org, pwe3@ietf.org Subject: RE: 52nd IETF - MPLS OAM BOF announcement Date: Thu, 29 Nov 2001 11:53:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Shahram, It might be helpful perhaps to use the 20 minute discussion time on the agenda to encourage Service Providers to address this issue from their perspective. What are the additional and specific business and operational benefits for them, for potentially implementing - and paying for - a new MPLS OAM mechanism. Just a thought for consideration. Thanks and Best Regards, Steven Steven Dekany Marconi Communications (972)916-4292 -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, November 29, 2001 10:40 AM To: ccamp@ops.ietf.org; te-wg@ops.ietf.org; pwe3@ietf.org Subject: 52nd IETF - MPLS OAM BOF announcement 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) The purpose of the MPLS OAM BOF is to determine what type of operations and maintenance tools are required for MPLS networks. The BOF will address if traceroute and ping are sufficient operations and maintenance tools for MPLS network operators. The BOF will consider the need for other types of OAM tools for MPLS networks. The agenda for this BOF is available at: http://www.ietf.org/ietf/01dec/mplsoam.txt Regards, Shahram Davari PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 08:55:10 -0800 Message-ID: <3C0667D8.8000802@lucent.com> Date: Thu, 29 Nov 2001 11:52:40 -0500 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: Jonathan Lang CC: Sudheer Dharanikota , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: FW: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan, Thanks for taking the time to review and incorporate some of my comments. I have some more remarks related to some of the comments that you did not incorporate. Please see below. Thanks! Carmine Jonathan Lang wrote: >Carmine, > Thanks for the careful review of the document. We've incorporated many of >your comments. Specific responses pasted below: new text identified in >quotes after [Jonathan] > >Thanks, >Jonathan > > >======================== > Abstract > > Future networks will consist of photonic switches, optical > crossconnects, and routers that may be configured with control > channels and data links. Furthermore, multiple data links may be > combined to form a single traffic engineering (TE) link for routing > purposes. This draft specifies a link management protocol (LMP) that > runs between neighboring nodes and is used to manage TE links. > Specifically, LMP will be used to maintain control channel > connectivity, verify the physical connectivity of the data-bearing > channels, correlate the link property information, >[Insert: suppress downstream alarms in pre-G.709 networks, and localize >faults in both opaque and transparent networks to a particular link >between adjacent cross-connects for protection/restoration actions.] >[Delete: and manage link failures. A unique feature of the fault management >technique is that it is able to localize failures in both opaque and >transparent >networks, independent of the encoding scheme used for the data.] >[Jonathan]"suppress downstream alarms, and localize link failures in both >opaque and transparent networks for protection/restoration purposes." > Why did you not include the "pre-G.709" portion of the text? > > >1. Introduction > > > In GMPLS, the control channels between two adjacent nodes are no > longer required to use the same physical medium as the data-bearing > links between those nodes. For example, a control channel could use > a separate wavelength or fiber, an Ethernet link, >[Delete: or] > an IP tunnel through a separate management network >[Delete: .] >[Insert: , or a multi-hop IP network] >[Jonathan]"an IP tunnel through a separate management network, or a >multi-hop IP network." > >2. LMP Overview > > >In this draft, >[Delete: two] >[Insert: three] > additional LMP procedures are defined: link > connectivity verification >[Delete: and fault management] >[Insert: suppression of downstream alarms, and localization >faults in both opaque and transparent networks to a particular link >between adjacent cross-connects for protection/restoration actions] > . >[Delete: These procedures are particularly useful when the control >channels are physically diverse from the data-bearing links.] >[Jonathan] no change made. > I'm not sure why you didn't incorporate this comment. My reasoning behind the comment was to list the separate applications that are covered. Fault management, without a definition is confusing to me. I think the sentence that I suggested clearly indicates the three applications. > > > Link connectivity > verification is used to verify the physical connectivity of the > data-bearing links between the nodes and exchange the Interface Ids; > Interface Ids are used in GMPLS signaling, either as Port labels or > Component Interface Ids, depending on the configuration. The link > verification procedure uses in-band Test messages that are sent over > the data-bearing links and TestStatus messages that are transmitted > back over the control channel. Note that the Test message is the > only LMP message that must be transmitted over the data-bearing > link. >[Delete: The fault management scheme uses] >[Insert: Both the suppression of downstream alarms and the localization >of faults for protection/restoration use] > ChannelStatus message > exchanges between adjacent nodes >[Delete: to localize failures] > in both opaque > and transparent networks, independent of the encoding scheme used > for the data. As a result, both local span and end-to-end path > protection/restoration procedures can be initiated. >[Jonathan]"Both the suppression of downstream alarms and the localization of >faults for protection/restoration use ChannelStatus message exchanges >between adjacent nodes in both opaque and transparent networks, indepedent >of the encoding scheme used for the data." > >[Insert: Note that the fault localization scheme supported in LMP localizes >faults on a link and does not address node failures. Therefore additional >mechanisms are needed to detect node failures for end-to-end path >protection/restoration.] >[Jonathan]no change made. > Is my statement incorrect? > > >[Delete: For the LMP link connectivity verification procedure, the free >(unallocated) data-bearing links MUST be opaque (i.e., able to be >terminated); however, once a data link is allocated, it may become >transparent.] >[Insert: For LMP link conncetivity verification procedure between adjacent >PXCs, the test message is generated and termindated by opaque test units >that >may be shared among multiple ports on the PXC. Opaque test units are needed >since the PXC ports are transparent.] >[Jonathan]change made as suggested. > > > > > >The LMP fault management procedure >[Insert: (i.e., the suppression of downstream alarms in pre-G.709 networks, >and the localization of faults to a particular link between adjacent OXCs >for >protection/restoration actions)] > 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 channels > of a TE link. >[Jonathan]no change made. > >3. Control Channel Management > > >For the purposes of LMP, the exact implementation of the control > channel is not specified; it could be, for example, a separate > wavelength or fiber, an Ethernet link, an IP tunnel through a > separate management network, >[Insert: a multi-hop IP network,] >[Jonathan]change made. > > > >The control channel can be either explicitly configured or > automatically selected, however, for the purpose of this document > the control channel is assumed to be explicitly configured. >[Insert: The term configured means that the destination IP address to >reach the adjacent node on the far end of the control channel is known >at the near-end. The destination IP address may be manually configured, >or automatically discovered.] >[Jonathan]Replacing the above text starting with "The Control channel.." >with "To establish a control channel, the destination IP address on the far >end of the control channel must be known. This knowledge may be manually >configured or automaticaly discovered." > > > Control channels exist independently of TE links and multiple > control channels may be active simultaneously between a pair of > nodes. Individual control channels can be realized in different > ways; one might be implemented in-fiber while another one may be > implemented out-of-fiber. >[Insert: Maintenance of control channels (i.e., detection of control >channel failures and restoral of communication) is needed. Various >mechanisms could be used to provide maintenance of control channels, >depending on the level of service required. For example, control channel >failures could be detected and restored via normal IP routing protocols, >however this may not support the necessary level of service due to the >time required to update the routing tables. For very fast recovery of >control channels, other mechanisms such as bridging messages at the near-end >and selecting messages at the far-end can be used. LMP defines a Hello >protocol that can be used to detect control failures. To support >the Hello protocol,] >[Delete: As such, ] > control channel parameters MUST > be negotiated over each individual control channel, and LMP Hello > packets MUST be exchanged over each control channel to maintain LMP > connectivity if other mechanisms are not available. >[Jonathan]no change > >3.1. Parameter Negotiation > >[Insert: Activation of the LMP Hello Protocol] >[Delete: Control channel activation] > begins with a parameter negotiation > exchange using Config, ConfigAck, and ConfigNack messages. >[Jonathan] no change. LMP control channel activation requires Config >message exchange even if LMP Hellos are not run. > Maybe I don't understand what the Config message is actually providing... could you please explain to me... As I understood it, the Config message was only beginning the parameter negotiation for the LMP Hello Protocol... Is it doing something else? > > > > >To begin >[Delete: control channel] >[Insert: Hello Protocol] > activation, a node MUST transmit a Config > message to the remote node. >[Jonathan] no change > >3.2. Hello Protocol > >Once >[Delete: a control channel] >[Insert: the Hello Protocol] > is activated between two adjacent nodes, the ... >[Jonathan]no change > >5. Verifying Link Connectivity >[Question: The following paragraph is a bit confusing to me. What is the >problem >that it is trying to describe? Thanks :-)] > I see your answer below. Thanks. However, the text still seems confusing to me. From your answer below, it seems as though you are trying to say that since PXC ports do not terminate the optical signal it is difficult to determine the status of the data link. Therefore, opaque test units can be used to generate and terminate signals between adjacent PXCs to determine the status of the data link. I would suggest replacing the below paragraph with similar text as in my previous two sentences. > > A unique characteristic of all-optical PXCs is that the data-bearing > links are transparent when allocated to user traffic. > I assume when you say transparent, you mean all-optical and not service transparent. Just because PXCs support all-optical ports (i.e., no O/E conversion) does not mean that the data-link between the adjacent PXCs is all-optical (or "transparent" as you say). >This > characteristic of PXCs poses a challenge for validating the > connectivity of the data links since shining unmodulated light > through a link may not result in received light at the next PXC. > I am not sure what you mean here? Even if you send out a signal on an electrical cross-connect, it may not result in received light at the next electrical cross-connect since there could be a fiber cut between the two. > > This is because there may be terminating (or opaque) elements, such > as DWDM equipment, between the PXCs. > It seems to me that if there were terminating (or opaque) elements, such as DWDM equipment, between PXCs, then it would be more likely that the downstream PXC always sees light, even if a failure occurred on the DWDM line system, since the opaque DWDM port could possibly generate a new signal. In this situation, the PXC would see light, but not know if the light was a good signal or a keep-alive signal... This is another reason for using opaque test units to test a data link, so the PXC would be able to terminate the test signal after it was sent across the data link, rather then just monitoring for power. >Therefore, to ensure proper > verification of data link connectivity, it is required that until > the links are allocated for user traffic, they must be opaque. > The links must be opaque is a bit misleading. I think you just mean that until the links are allocated for user traffic, opaque test units are used to test the data-links. This is a similar comment to the one I made in the LMP overview Section 2 that you incorporated. >To > support various degrees of opaqueness (e.g., examining overhead > bytes, terminating the payload, etc.), and hence different > mechanisms to transport the Test messages, a Verify Transport > Mechanism field is included in the BeginVerify and BeginVerifyAck > messages. There is no requirement that all data links be terminated > simultaneously, but at a minimum, the data links MUST be able to be > terminated one at a time. Furthermore, for the link verification > procedure it is assumed that the nodal architecture is designed so > that messages can be sent and received over any data link. Note > that this requirement is trivial for DXCs (and OEO devices in > general) since each data link is terminated and processed > electronically before being forwarded to the next OEO device, but > that in PXCs (and transparent devices in general) this is an > additional requirement. >[Jonathan]There is a challenge in verifying the connectivity between PXCs >since a PXC just interconnects ports without termination the signals. > > > >6.2. Fault Localization Procedure > >[Insert: 6.2.1 Suppression of downstream alarms in pre-G.709 networks] >[Jonathan] Rather than separate the section into two subsections, I will add >text to clarify both features provided by LMP. > > If data links fail between two PXCs, the power monitoring system in > all of the downstream nodes may detect LOL and indicate a failure. > To avoid multiple alarms stemming from the same failure, LMP > provides a failure notification through the ChannelStatus message. > This message may be used to indicate that a single data channel has > failed, multiple data channels have failed, or an entire TE link has > failed. >[Insert: A ChannelStatus message is sent to the downstream node indicating >to the downstream node that the failure has been detected upstream and >therefore to suppress the alarm.] >[Delete: Failure correlation is done locally at each node upon > receipt of the failure notification.] >[Jonathan]no change > Why was this comment not included? Is the text I proposed incorrect? > > >[Insert: 6.2.2 Localization of a fault to a link for protection/restoration] >[Jonathan]see comment above > >[Delete: As part of the fault localization,] >[Insert: To localize a fault to a particular link between adjacent OXCs,] >[Jonathan]change made. > 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). > > > >Once the failure has been localized, the signaling > protocols can be used to initiate span or path > protection/restoration procedures. >[Insert: Note that the fault localization scheme supported in LMP localizes >faults on a link and does not address node failures. Therefore additional >mechanisms are needed to detect node failures for end-to-end path >protection/restoration.] >[Jonathan]no change. > Is the statement I proposed incorrect? > > >[Insert: 6.2.2.1 Examples of Fault Localization] >[Delete: 6.3. Examples of Fault Localization] >[Jonathan]see comment above > > >-----Original Message----- >From: Carmine Daloia [mailto:daloia@lucent.com] >Sent: Monday, November 26, 2001 7:43 AM >To: Sudheer Dharanikota >Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org >Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... > > >Hi Sudheer, Jonathan, and all, > >Attached is the LMP draft with my proposed text inserted. I inserted >proposed text on the suppression of downstream alarms, as well as some other >sections. > >Please let me know what you think of the proposed text. >The notation I used is as follows: >[Insert: .... new proposed text....] >[Delete: .... text that I propose to be deleted...] > >Thanks >Carmine > >Sudheer Dharanikota wrote: > >Carmine Daloia wrote: >Hi Sudheer,My last comment wasn't meant to be an argument :-)Maybe if I >propose some text specific to the suppressionof downstream alarms that would >help clarify the scope ofapplicability. The text would state that when >clientdevices (e.g., SONET/SDH cross-connects, IP routers) areinterconnected >via a standard OTN network then thesuppression of downstream alarms is >already handled in thetransport/user plane via the OTN overhead (both >in-bandvia the digitial overhead as well as out-of-band vianon-associated >overhead). Also the text would address PXCswithin a standard OTN network. In >this case, again thesuppression of downstream alarms is handled via the >OTNoverhead.The implementation proposed in LMP for suppression ofdownstream >alarms applies to PXCs or client devices (e.g,SONET/SDH cross-connects or IP >routers) interconnected viaa non-standard DWDM network. In this case, it is >as >summedthat the non-standard DWDM network does not provide theneccesary >overhead within the transport/user plane tosuppress alarms on PXCs and >client devices and thereforeLMP provides a mechanism to carry such alarm >suppressionmessages in the control plane.I'll take a crack at specific text >so that the group canreview it. Does this sound like something that would >behelpful. >Sure.Regards,sudheer > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Nov 2001 08:42:08 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCB76@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ccamp@ops.ietf.org, te-wg@ops.ietf.org, pwe3@ietf.org Subject: 52nd IETF - MPLS OAM BOF announcement Date: Thu, 29 Nov 2001 08:40:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) The purpose of the MPLS OAM BOF is to determine what type of operations and maintenance tools are required for MPLS networks. The BOF will address if traceroute and ping are sufficient operations and maintenance tools for MPLS network operators. The BOF will consider the need for other types of OAM tools for MPLS networks. The agenda for this BOF is available at: http://www.ietf.org/ietf/01dec/mplsoam.txt Regards, Shahram Davari PMC-Sierra, Inc. Phone: (613) 271-4018 Fax: (613) 271-6468 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Nov 2001 17:27:20 -0800 Message-ID: From: Jonathan Lang To: 'Carmine Daloia' , Sudheer Dharanikota Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org, Jonathan Lang Subject: FW: [T1X1.5] Re: Suppression of Downstream Alarms... Date: Wed, 28 Nov 2001 17:19:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Carmine, Thanks for the careful review of the document. We've incorporated many of your comments. Specific responses pasted below: new text identified in quotes after [Jonathan] Thanks, Jonathan ======================== Abstract Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data-bearing channels, correlate the link property information, [Insert: suppress downstream alarms in pre-G.709 networks, and localize faults in both opaque and transparent networks to a particular link between adjacent cross-connects for protection/restoration actions.] [Delete: and manage link failures. A unique feature of the fault management technique is that it is able to localize failures in both opaque and transparent networks, independent of the encoding scheme used for the data.] [Jonathan]"suppress downstream alarms, and localize link failures in both opaque and transparent networks for protection/restoration purposes." 1. Introduction In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, [Delete: or] an IP tunnel through a separate management network [Delete: .] [Insert: , or a multi-hop IP network] [Jonathan]"an IP tunnel through a separate management network, or a multi-hop IP network." 2. LMP Overview In this draft, [Delete: two] [Insert: three] additional LMP procedures are defined: link connectivity verification [Delete: and fault management] [Insert: suppression of downstream alarms, and localization faults in both opaque and transparent networks to a particular link between adjacent cross-connects for protection/restoration actions] . [Delete: These procedures are particularly useful when the control channels are physically diverse from the data-bearing links.] [Jonathan] no change made. Link connectivity verification is used to verify the physical connectivity of the data-bearing links between the nodes and exchange the Interface Ids; Interface Ids are used in GMPLS signaling, either as Port labels or Component Interface Ids, depending on the configuration. The link verification procedure uses in-band Test messages that are sent over the data-bearing links and TestStatus messages that are transmitted back over the control channel. Note that the Test message is the only LMP message that must be transmitted over the data-bearing link. [Delete: The fault management scheme uses] [Insert: Both the suppression of downstream alarms and the localization of faults for protection/restoration use] ChannelStatus message exchanges between adjacent nodes [Delete: to localize failures] in both opaque and transparent networks, independent of the encoding scheme used for the data. As a result, both local span and end-to-end path protection/restoration procedures can be initiated. [Jonathan]"Both the suppression of downstream alarms and the localization of faults for protection/restoration use ChannelStatus message exchanges between adjacent nodes in both opaque and transparent networks, indepedent of the encoding scheme used for the data." [Insert: Note that the fault localization scheme supported in LMP localizes faults on a link and does not address node failures. Therefore additional mechanisms are needed to detect node failures for end-to-end path protection/restoration.] [Jonathan]no change made. [Delete: For the LMP link connectivity verification procedure, the free (unallocated) data-bearing links MUST be opaque (i.e., able to be terminated); however, once a data link is allocated, it may become transparent.] [Insert: For LMP link conncetivity verification procedure between adjacent PXCs, the test message is generated and termindated by opaque test units that may be shared among multiple ports on the PXC. Opaque test units are needed since the PXC ports are transparent.] [Jonathan]change made as suggested. The LMP fault management procedure [Insert: (i.e., the suppression of downstream alarms in pre-G.709 networks, and the localization of faults to a particular link between adjacent OXCs for protection/restoration actions)] 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 channels of a TE link. [Jonathan]no change made. 3. Control Channel Management For the purposes of LMP, the exact implementation of the control channel is not specified; it could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, [Insert: a multi-hop IP network,] [Jonathan]change made. The control channel can be either explicitly configured or automatically selected, however, for the purpose of this document the control channel is assumed to be explicitly configured. [Insert: The term configured means that the destination IP address to reach the adjacent node on the far end of the control channel is known at the near-end. The destination IP address may be manually configured, or automatically discovered.] [Jonathan]Replacing the above text starting with "The Control channel.." with "To establish a control channel, the destination IP address on the far end of the control channel must be known. This knowledge may be manually configured or automaticaly discovered." Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. [Insert: Maintenance of control channels (i.e., detection of control channel failures and restoral of communication) is needed. Various mechanisms could be used to provide maintenance of control channels, depending on the level of service required. For example, control channel failures could be detected and restored via normal IP routing protocols, however this may not support the necessary level of service due to the time required to update the routing tables. For very fast recovery of control channels, other mechanisms such as bridging messages at the near-end and selecting messages at the far-end can be used. LMP defines a Hello protocol that can be used to detect control failures. To support the Hello protocol,] [Delete: As such, ] control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. [Jonathan]no change 3.1. Parameter Negotiation [Insert: Activation of the LMP Hello Protocol] [Delete: Control channel activation] begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages. [Jonathan] no change. LMP control channel activation requires Config message exchange even if LMP Hellos are not run. To begin [Delete: control channel] [Insert: Hello Protocol] activation, a node MUST transmit a Config message to the remote node. [Jonathan] no change 3.2. Hello Protocol Once [Delete: a control channel] [Insert: the Hello Protocol] is activated between two adjacent nodes, the ... [Jonathan]no change 5. Verifying Link Connectivity [Question: The following paragraph is a bit confusing to me. What is the problem that it is trying to describe? Thanks :-)] A unique characteristic of all-optical PXCs is that the data-bearing links are transparent when allocated to user traffic. This characteristic of PXCs poses a challenge for validating the connectivity of the data links since shining unmodulated light through a link may not result in received light at the next PXC. This is because there may be terminating (or opaque) elements, such as DWDM equipment, between the PXCs. Therefore, to ensure proper verification of data link connectivity, it is required that until the links are allocated for user traffic, they must be opaque. To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for DXCs (and OEO devices in general) since each data link is terminated and processed electronically before being forwarded to the next OEO device, but that in PXCs (and transparent devices in general) this is an additional requirement. [Jonathan]There is a challenge in verifying the connectivity between PXCs since a PXC just interconnects ports without termination the signals. 6.2. Fault Localization Procedure [Insert: 6.2.1 Suppression of downstream alarms in pre-G.709 networks] [Jonathan] Rather than separate the section into two subsections, I will add text to clarify both features provided by LMP. If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message. This message may be used to indicate that a single data channel has failed, multiple data channels have failed, or an entire TE link has failed. [Insert: A ChannelStatus message is sent to the downstream node indicating to the downstream node that the failure has been detected upstream and therefore to suppress the alarm.] [Delete: Failure correlation is done locally at each node upon receipt of the failure notification.] [Jonathan]no change [Insert: 6.2.2 Localization of a fault to a link for protection/restoration] [Jonathan]see comment above [Delete: As part of the fault localization,] [Insert: To localize a fault to a particular link between adjacent OXCs,] [Jonathan]change made. 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). Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures. [Insert: Note that the fault localization scheme supported in LMP localizes faults on a link and does not address node failures. Therefore additional mechanisms are needed to detect node failures for end-to-end path protection/restoration.] [Jonathan]no change. [Insert: 6.2.2.1 Examples of Fault Localization] [Delete: 6.3. Examples of Fault Localization] [Jonathan]see comment above -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Monday, November 26, 2001 7:43 AM To: Sudheer Dharanikota Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Hi Sudheer, Jonathan, and all, Attached is the LMP draft with my proposed text inserted. I inserted proposed text on the suppression of downstream alarms, as well as some other sections. Please let me know what you think of the proposed text. The notation I used is as follows: [Insert: .... new proposed text....] [Delete: .... text that I propose to be deleted...] Thanks Carmine Sudheer Dharanikota wrote: Carmine Daloia wrote: Hi Sudheer,My last comment wasn't meant to be an argument :-)Maybe if I propose some text specific to the suppressionof downstream alarms that would help clarify the scope ofapplicability. The text would state that when clientdevices (e.g., SONET/SDH cross-connects, IP routers) areinterconnected via a standard OTN network then thesuppression of downstream alarms is already handled in thetransport/user plane via the OTN overhead (both in-bandvia the digitial overhead as well as out-of-band vianon-associated overhead). Also the text would address PXCswithin a standard OTN network. In this case, again thesuppression of downstream alarms is handled via the OTNoverhead.The implementation proposed in LMP for suppression ofdownstream alarms applies to PXCs or client devices (e.g,SONET/SDH cross-connects or IP routers) interconnected viaa non-standard DWDM network. In this case, it is as summedthat the non-standard DWDM network does not provide theneccesary overhead within the transport/user plane tosuppress alarms on PXCs and client devices and thereforeLMP provides a mechanism to carry such alarm suppressionmessages in the control plane.I'll take a crack at specific text so that the group canreview it. Does this sound like something that would behelpful. Sure.Regards,sudheer Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Nov 2001 13:38:56 -0800 Message-ID: <3C055931.116FB63@tellabs.com> Date: Wed, 28 Nov 2001 15:37:53 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Two week Last Call on LMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oops. I re-read my message and found a confusing statement. See inline. Jonathan.Sadler@tellabs.com wrote: > The current definition also states: > > "If more than one subobject of the same Type appears, only the first > subobject of that Type is meaningful. Subsequent subobjects of the same > Type MAY be ignored." > > This is problematic regardless of how you interpret the minimum/maximum > bandwidth range as it doesn't allow for multiple subobjects. Sorry, I ment to say: "doesn't require support for multiple subojects within a switching capability, and encoding type." > Multiple > subobjects will be needed for devices that don't support all signals for > the minimum/maximum bandwidth range given for a particular switching > capability, and encoding type. This support would be needed for a > device that supported standard SONET VT1.5, VT2, STS-1, STS-3c, STS-12c, > and STS-48c switching, but couldn't switch VT6. Hope this clears up any confusion. Jonathan Sadler Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Nov 2001 13:31:43 -0800 Message-ID: <3C055727.AEDA18E@tellabs.com> Date: Wed, 28 Nov 2001 15:29:11 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Two week Last Call on LMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jonathan, et al. Some comments on draft-ietf-ccamp-lmp-02.txt: 1. (Sec 14.13) The definition of the Interface Switching Capability subobject within the Data Link Object seems inconsistant with the definition that exists within the routing drafts where the interpretation of minimum/maximum bandwidth range is different for each swithing type. The current definition also states: "If more than one subobject of the same Type appears, only the first subobject of that Type is meaningful. Subsequent subobjects of the same Type MAY be ignored." This is problematic regardless of how you interpret the minimum/maximum bandwidth range as it doesn't allow for multiple subobjects. Multiple subobjects will be needed for devices that don't support all signals for the minimum/maximum bandwidth range given for a particular switching capability, and encoding type. This support would be needed for a device that supported standard SONET VT1.5, VT2, STS-1, STS-3c, STS-12c, and STS-48c switching, but couldn't switch VT6. 2. (Sec. 13.6.6) The Test message only includes VERIFY_ID and LOCAL_INTERFACE_ID. Since this message could be extended to support automatic "discovery" of neighbors, why not also include a "control plane contact address"? 3. (Sec. 14.9) No details are given regarding the encoding of the test message for DCCS or DCCL. I assume that if PPP is used, it will be conformant to appropriate IETF standards (ie. RFC 1661). Jonathan Sadler Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Nov 2001 02:58:03 -0800 Message-Id: <200111281055.FAA28461@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-02.txt Date: Wed, 28 Nov 2001 05:55:47 -0500 --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 Filename : draft-iwata-mpls-crankback-02.txt Pages : 31 Date : 27-Nov-01 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-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-iwata-mpls-crankback-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-iwata-mpls-crankback-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: <20011127134710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-iwata-mpls-crankback-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-iwata-mpls-crankback-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134710.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Nov 2001 16:06:17 -0800 Message-ID: From: Jonathan Lang To: 'Baktha Muralidharan' , ccamp@ops.ietf.org Cc: Jonathan Lang Subject: RE: Comments on LMP Date: Tue, 27 Nov 2001 15:57:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Baktha, Thanks for the comments. Please see responses inline. Thanks, Jonathan >-----Original Message----- >From: Baktha Muralidharan [mailto:muralidb@cisco.com] >Sent: Tuesday, November 20, 2001 11:22 AM >To: ccamp@ops.ietf.org >Subject: Comments on LMP > > >Hello, > Please find attached my comments; Beside the few I list immediately below, I > have embedded most of my comments in the document, to make it easier to read. > > My comments are prefixed BM> > >Thanks, >/Baktha > >--------------------------------------------------------------------------- -------------- >------ >1. Remove all references to TLVs. We have changed over to Objects. done. >2. Draft requires that link summary be sent periodically until an ack/nack or timeout. > > Whenever a link summary is sent, the expected outcomes are either a timeout or an > ack/nack, isn't it? > It is not clear then as to whether we recommend that the "periodic transmission of > link summary" to be stopped upon a timeout. If that is not what we are recommending, > i.e. we are recommending sending of link summary regardless of whether we get a > response or not, the above statement is unnecessary and I believe is actually > confusing. If a timeout occurs, periodic transmission of link summary should be stopped. >3. [Parameter] Negotiability is described in terms of objects. Some objects have > subobjects and/or several attributes. Negotiability at these "lower granularities" > need to be spelt out. > > For example, consider the DATA LINK object; it is negotiable. And so, are its > subobjects. The data link sub-object carry interface switching capability, bandwidth > and encoding type. Can we interpret then that ALL of these are negotiable parameters?. > If they are, spelling them out would help. Having negotiable parameters doesn't ensure convergence as the acceptable parameter list isn't guaranteed to overlap. As such, I'm not sure it's necessary to define negotiability at the "lower granularities". >4. Under TE Link FSM, evDCDown is interpreted as "Last data channel of TE Link has been > removed > Under data bearing link evDCDown is described as "data link is no longer available". > Administratively shutting down a data bearing link could fit the "no longer available" > description. Yet, the data bearing link could well be a member of a TE Link (i.e. > might not have been removed). Suggest using the same description. The difference is that the TE Link event is referring to a Data Link being removed from the resource pool, whereas the Data Link event is referring to availability. Please see rest of the comments to be embedded; look for lines starting with BM> ========================================================================== 1. Introduction For the purposes of this document, a data-bearing link may be either a "port" or a "component link" depending on its multiplexing capability; component links are multiplex capable, whereas ports are not multiplex capable. This distinction is important since the management of such links (including, for example, resource allocation, label assignment, and their physical verification) is different based on their multiplexing capability. For example, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams. If multiple interfaces are grouped together into a single TE link using link bundling [BUNDLE], then the link resources must be identified using three levels: TE link Id, component interface Id, and timeslot label. Resource allocation happens at the lowest level (timeslots), but physical connectivity happens at the component link level. As another example, consider the case where a PXC transparently switches OC-192 lightpaths. If multiple interfaces are once again grouped together into a single TE link, then link bundling [BUNDLE] is not required and only two levels of identification are required: TE link Id and port Id. In this case, both resource allocation and physical connectivity happen at the lowest level (i.e. port level). BM> It looks like a TE Link is a "group of interfaces", regardless BM> of whether they are bundled. BM> Why "group" multiple interfaces (into a TE Link), if bundling BM> and the associated benefits are the not the objective? [Jonathan] 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." (see draft-ccamp-gmpls-routing). Bundling strictly refers to the [BUNDLE] draft. You can have benefits from aggregation of interfaces into a TE Link without using the [BUNDLE] draft. 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). BM> BM> An example of "unbundled aggregation of data links into a BM> TE Link" would greatly help to clear up BM> [Jonathan] This is given 2 paragraphs above. I can see about adding more detail to clarify... 2. LMP Overview The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify configuration. LMP requires that a pair of nodes have at least one active bi- directional control channel between them. The two directions of the BM> Aren't control channels always bidirectional?. The successful BM> config message exchange always marks the "bidirectional BM> control channel establishment", isn't it? BM> Suggest removing the word bidirectional from references to IPCC. I don't think it hurts to say it explicitly. control channel are coupled together using the LMP Config message exchange. All LMP messages are IP encoded [except in some cases, the Test Message which may be limited by the transport mechanism for in-band messaging]. The link level encoding of the control channel is outside the scope of this document. Lang et al [Page 4] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 An "LMP adjacency" is formed between two nodes when at least one bi- directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged by the adjacent nodes over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes. BM> This (the concept of logical control channel) applies to an implementation's BM> treatment of multiple control channels and should be removed to avoid confusion. BM> Logical control channels are not discussed elsewhere in the document. [Jonathan] For practical purposes, I think the concept is important. The fact that multiple LMP control channels is exposed as a single logical control channel for higher layers is a key feature. This allows only a single adjacency at the higher layers, while underneath you can have multiple LMP adjacencies. The link property correlation function of LMP is designed to aggregate multiple data links (ports or component 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 glinks that comprise the TE BM> links [Jonathan] done 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. For the LMP link connectivity verification procedure, the free (unallocated) data-bearing links MUST be opaque (i.e., able to be terminated); however, once a data link is allocated, it may become transparent. The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various degrees of transparency (e.g., examining overhead bytes, terminating the payload, etc.), and hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data-bearing links must be terminated simultaneously, but at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST terminate on the same two nodes that the TE link spans. Since the BeginVerify BM> This is true for ALL LMP procedures, not just for connectivity BM> verification. i.e. CC, by definition, is between a pair of neighbors. 3. Control Channel Management 3.2. Hello Protocol 3.2.3. Control Channel Down To allow bringing a control channel DOWN gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links. When bringing a control channel DOWN administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set. When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the Down state. BM> On the receiving node, suggest transitioning to CONFSND state rather BM> than DOWN state.. otherwise, it could not automatically get into BM> config procedure- i.e. would need a trigger/event BM> On the sending side, the trigger is the operator command to bring up BM> the control channel As it stands, an implementation may have an automatic trigger taking you from Down to CONFSND or CONFRCV. 4. Link Property Correlation Each TE link has an identifier (Link_Id) that is assigned at each end of the link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is assigned an identifier (Interface_Id) at each end. These identifiers MUST be the same type at both ends. BM> Why the restriction that both ends of a TE Link have to use the same BM> identification? [Jonathan] Having the same type of identification is just a restriction of IP architecture (as in IP you can't have a link whose one end is numbered and another is unnumbered). 7. Message_Id Usage 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 is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the CCID, then the message SHOULD be treated as being out of order. If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out of order. BM> Isn't this logic true for link verification as well? [Jonathan] no. Out-of-order link verification messages should be accepted. 8. Graceful Restart This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after an LMP adjacency has failed, or as a result of an LMP component restart. The latter is detected by setting the "Control Plane Restart" bit in the Common BM> Isn't the bit called LMP Restart? [Jonathan] yes. I've corrected the text as you suggest. 12. LMP Finite State Machines 12.2. TE Link FSM The TE Link FSM defines the states and logics of operation of an LMP TE Link. 12.2.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 and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links. 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. BM> I guess we are saying that once initially synchronized, subsequent changes BM> to TE Links that cause link summary to run could happen whilst the TE Link BM> is still in UP state. [Jonathan] yes BM> In the middle of the day, is the IDs and/or other properties BM> of links are changed such that a TE Links go out of synchronization, BM> should we go back to "Init" state?, such that the above definition of BM> Init state is observed all the time? [Jonathan] It doesn't make sense to change TE link properties if it is part of a data connection. Up: This is the normal operational state of the TE link. At least one primary CC is required to be operational between the nodes sharing the TE link. Degraded: In this state, all primary CCs are down, but the TE link still includes some allocated data links. BM> Does the term "allocated" here refer to "allocated to data traffic"? BM> I don't think so.. but could we be explicit? [Jonathan]yes it does. I will change wording to say "includes some data links that are allocated to data traffic." BM> Related question. Whilst in Init state, if the last CC goes down, BM> Shouldn't the TE Link go into degraded? [Jonathan]no. Degraded implies data links are allocated to data traffic 12.2.3. TE Link FSM Description Figure 4 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram. 3,7,8 +--+ | | | v +--------+ | | +------------>| Down |<---------+ | | | | | +--------+ | | | ^ | | 1| |9 | | v | | | +--------+ | | | |<-+ | | | Init | |3,5,6 |9 | | |--+ 7,8 | 9| +--------+ | | | | | 2,4| | | v | +--------+ 7 +--------+ | | |------>| |----------+ | Deg | | Up | | |<------| | +--------+ 8 +--------+ | ^ | | +--+ 2,3,4,5,6 Figure 4: LMP TE Link FSM In the above FSM, the sub-states that may be implemented when the link verification procedure is used have been omitted. BM> Consider a TE Link that transitions to Down state via Degraded.. it BM> has no data links and no CCs either. If now a DC is added to the TE BM> Link, shouldn't it go [back] to degraded state, rather than Init. BM> When a TE Link in the Down state gets a new data link, it fits BM> the definition of the degraded state. [Jonathan]no. Degraded applies only when data links are allocated to data traffic. 13. LMP Message Formats All LMP messages are IP encoded (except, in some cases, the Test messages are limited by the transport mechanism for in-band messaging) with protocol number xxx - TBA (to be assigned) by IANA. 13.1. Common Header In addition to the standard IP header, all LMP messages (except, in some cases, the Test messages which are limited by the transport mechanism for in-band messaging) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMP Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 4 bits Protocol version number. This is version 1. Flags: 8 bits. The following values are defined. All other values are reserved. 0x01: ControlChannelDown 0x02: LMP Restart This bit is set to indicate the LMP component has restarted. This flag may be reset to 0 when a Hello message is received with RcvSeqNum equal to the local TxSeqNum. 0x04: LMP-WDM Support When set, indicates that this node is willing and capable of receiving all the messages and objects described in [LMP-DWDM]. 0x08: Authentication When set, this bit indicates that an authentication block is attached at the end of the LMP message. See Sections 7 and 9.3 for more details. Msg Type: 8 bits. The following values are defined. All other values are reserved. 1 = Config 2 = ConfigAck 3 = ConfigNack 4 = Hello 5 = BeginVerify 6 = BeginVerifyAck 7 = BeginVerifyNack 8 = EndVerify 9 = EndVerifyAck 10 = Test 11 = TestStatusSuccess 12 = TestStatusFailure 13 = TestStatusAck 14 = LinkSummary 15 = LinkSummaryAck 16 = LinkSummaryNack 17 = ChannelStatus 18 = ChannelStatusAck 19 = ChannelStatusRequest 20 = ChannelStatusResponse All of the messages are sent over the control channel EXCEPT the Test message, which is sent over the data link that is being tested. LMP Length: 16 bits The total length of this LMP message in bytes, including the common header and any variable-length objects that follow. Checksum: 16 bits The standard IP checksum of the entire contents of the LMP message, starting with the LMP message header. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before calculating the checksum. BM> One thing that will be of great help for implementation is a "message BM> specific" field (perhaps a couple of them). An example use of such a field BM> could be to store the number of data link objects in a link summary BM> and link summary ack message. 13.4. Parameter Negotiation Messages BM> Suggest changing to "Hello parameter negotiation messages". [Jonathan]I'd rather not. Currently all that is exchanged in Config is Hello parameters, but this may not always be the case. 13.4.1. Config Message (MsgType = 1) The Config message is used in the control channel negotiation phase of LMP. The contents of the Config message are built using LMP objects. The format of the Config message is as follows: ::= The above transmission order SHOULD be followed. BM> If order is to be followed for ALL messages, include it in one BM> place at beginning of section 13 [Jonathan]Since these are objects, they may come in any order. However Common Header must the first thing in an Lmp frame. The MESSAGE_ID is within the scope of the CCID. The Config message MUST be periodically transmitted until (1) it receives a ConfigAck or ConfigNack message, (2) a timeout expires and no ConfigAck or ConfigNack message has been received, or (3) it receives a Config message from the remote node and has lost the contention (e.g., the Node Id of the remote node is higher than the Node Id of the local node). Both the retransmission interval and the timeout period are local configuration parameters. 13.5. Hello Message (MsgType = 4) The format of the Hello message is as follows: ::= BM> ^^^^^^ Should be in upper case [Jonathan]thanks. 13.7.3. LinkSummaryNack Message (MsgType = 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. ::= [...] The above transmission order SHOULD be followed. The LinkSummary TLVs MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes LinkSummary TLVs for non-negotiable parameters, they MUST be copied from the LinkSummary TLVs 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. BM> It looks like sending a linksummarynack that includes both non-negotiable BM> parameters as well as negotiable parameters is kind of useless.. BM> because the initiator will not resend a link summary in that case. Yes? [Jonathan]It provides information as to why the link will not be brought up. This can be used to correct a misconfiguration. 14. LMP Object Definitions 14.1. CCID (Control Channel ID) Classes 14.1.1. LOCAL_CCID Class Class = 1. o C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC_Id: 32 bits This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message. This Object is non-negotiable. BM> Suggestion: Why not reserve C-Type = 2 for OIF- OIF OUNI 125.7 allows BM> CCID to be either numbered (IPv4) or unnumbered. [Jonathan]The CCId is defined as a 32-bit number. Both IPv4 and unnumbered fit into this case. I don't think any distinction is needed in this case. 14.7. CONFIG Class Class = 11. o HelloConfig, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | HelloDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloInterval: 16 bits. Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms). HelloDeadInterval: 16 bits. If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. BM> Given that the only parameters negotiated by Hello COnfig are BM> these two parameters, if fast keep-alive mechanism is not used, BM> why bother with Hello Config protocol? Why then say Hello Config BM> is mandatory? [Jonathan]The Config message can still be used to indicate that Hellos will not be used. 14.16. ERROR_CODE Class Class = 20. o CONFIG_ERROR, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. BM> How about adding a bit for "Ill-formed message" to cover BM> such cases as object-order-violations? BM> THese could be under a special C-Type, say, PROTOCOL_ERROR Good idea about a PROTOCOL_ERROR C-Type. As a side note, object order is a SHOULD, so violations must not result in an ERROR. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Nov 2001 08:07:21 -0800 From: "Robin Qiu" To: kireeti@juniper.net Cc: ccamp@ops.ietf.org Bcc: Subject: RE: Two week Last Call on LMP Date: Tue, 27 Nov 2001 11:04:58 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi, A few comments/questions/requests. Appreciate your response: 1. In secion 2 "LMP Overview", paragraph 7, it says "however, (for link connectivity verification procedure) the control channel MUST terminate on the same two nodes that the TE link spans". Why is this a requirement? This prevents a "proxy" LMP implementation. 2. In section 3.2.1, it says "Once it has both sent and received a Hello message, the control channel moves to the UP state". Should a "valid" (expected RcvSeqNum) Hello be received before moving to UP state? 3. In section 4 "Link Property Correlation MUST be done before the link is brought up". Is it necessary to be "MUST"? Ramesh S. brought up this issue too and Jonathan answered. 4. Section 5 "Verify Link Connectivity", paragraph 9 "It is also permissible for the sender to terminate the Test procedure without receiving a TestStatusSuccess or TestStatusFailure message by sending an EndVerify message". This seems misleading that the sender can't terminate the Test procedure in other situations. Can it be more straightforward like this "It is also permissible for the sender to terminate the Test procedure anytime after sending BeginVerify. An EndVerify message SHOULD be sent for this purpose."? 5. In section 7 "Message_Id Usage", can something be added to describe how to identify a message_id value wrapping? Because the message_id is made by the other node, it is impossible to know when it wraps without some common rule. For example, can we dictate that message_id be incremented by 1? 6. In section 8 "Graceful Restart", it doesn't cover the scenario where both ends restart. In this case, both sides must process the LinkSummary process as described in section 4. 7. In section 12.1 "Control Channel FSM", if a CC is brought down administratively by one side, should it only be brought up by that same side? Based on the current specification, either side can bring it up again. 8. In section 13, is 140 officially assigned to LMP? 9. In 13.6.5, 13.6.6, can object be put at the end of the object list for both EndVerifyAck and Test, i.e. ::= ::= This is consistent with other messages, so that it is easier to comply with the recommendation "The transmission order SHOULD be followed". 10. In general, can default values be suggested for various LMP timers? 11. In section 14.9 "BEGIN_VERIFY Class", what is the expected usage for "Number of Data Links" on the receiving side? The Test process is driven by the sending side until a EndVerify is received. Should receiving side count the number of data links tested and take some action after it exceeds "number of data links"? 12. In section 14.12 "TE_LINK Class", don't know who has the authority to request this, but C-Type=4 should be reserved for OIF, just as in LOCAL_LINK_ID Class (14.3.1). Regards, Robin Qiu -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, November 12, 2001 9:00 PM To: ccamp@ops.ietf.org Subject: Two week Last Call on LMP Hi All, This is to announce a two week Last Call on the LMP draft: draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. Please send questions, comments and requests for clarifications to the CCAMP list. Kireeti. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 22:15:43 -0800 Message-ID: From: Jonathan Lang To: 'S Ramesh' Cc: 'George Young' , ccamp@ops.ietf.org Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Mon, 26 Nov 2001 22:07:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh, Please see inline. Thanks, Jonathan > -----Original Message----- > From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > Sent: Wednesday, November 21, 2001 11:35 PM > To: Jonathan Lang > Cc: 'George Young'; ccamp@ops.ietf.org > Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > Hi Jonathan, > > Kindly clarify me on the following: > > 1. Is Link verification has to be done before Link property correlation > procedure. Because with Link verification procedure only ( out of fiber case ) > the neighbour interface mappings can be identified. But in Link property > correlation procedure it is given that Link Property correlation MUST be done > before the link is brought UP and MAY be done when the link is UP and not in the > verification process. Here a Link will be brought UP only when TEST messages are > sent through the data link ( out of fiber case ). If so during the first > LinkSummary message we cannot identify the interface mappings right, only the TE > links parameters are exchanged. Am i right. Kindly clarify me. To understand the text, remember that the Link Verification procedure is optional for LMP, whereas Link property correlation procedure is mandatory for LMP. As a practical matter, Link Verification (when supported) would happen before Link Property correlation. > > 2. Is that a data link between the two neighbours must participate as a member > of any of the TE link? if not how it will be tested. A data link that hasn't yet been assigned to a TE Link can be tested using TE Link Id =0. > > 3. In the BeginVerify message, there are LOCAL_LINK_ID class and Begin verify > class. It is given that > > "To limit the scope of Link Verification to a particular TE Link, the > LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data > links can span multiple TE links and/or they may comprise a TE link > that is yet to be configured. " > > IF local link id field is ZERO means the data link can span multiple TE link. So > how to test this Data Link. Because in the BeginVerify Class, the Flags filed > cointains > > " 0x01 Verify all Links > If this bit is set, the verification process checks all > unallocated links; else it only verifies new ports or > component links that are to be added to this TE link. " > > If this bit is set means it will check all unallocated datalinks of the Node > right. if not set means the port or component links that are to be added to this > TE LINK ( means Local Link ID present ) has to be verified. > > If this is the case how a data link that span multiple TE link can be tested. or > a datalink that does not participate in any TE link ( if possible ) can be > tested . Kindly clarify me. To clarify, I propose the following text: To limit the scope of Link Verification to a particular TE Link, the LOCAL_LINK_ID MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. In the special case where the LOCAL_LINK_ID field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that not yet been assigned to a TE Link. Specifically, verification of data links that span multiple TE links is indicated by setting the LOCAL_LINK_ID field to zero and setting the "Verify all Links" flag. Verification of data links that have not yet been assigned to a TE Link is indicated by setting the LOCAL_LINK_ID field to zero and clearing the "Verify all Links" flag. > > Thanks, > Ramesh > > > > > Jonathan Lang wrote: > > > George, > > Event 2 can be removed. We will need to reword events 7 > & 8. My proposal > > below: > > > > 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. > > > > -Jonathan > > > > > -----Original Message----- > > > From: George Young [mailto:george.young@meriton.com] > > > Sent: Wednesday, November 21, 2001 5:41 AM > > > To: Jonathan Lang > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > and 12.3.4) > > > > > > > > > Hello Jonathan, > > > > > > See below: > > > > > > Regards, > > > George R. Young > > > Meriton Networks Inc. > > > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > phone: +1 613-270-9279 Ext 287 > > > fax: +1 613-270-9268 > > > > > > > > > >-----Original Message----- > > > >From: Jonathan Lang [mailto:jplang@calient.net] > > > >Sent: Tuesday, November 20, 2001 11:49 AM > > > >To: George Young > > > >Cc: ccamp@ops.ietf.org > > > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > and 12.3.4) > > > > > > > > > > > >George, > > > > Please see inline. > > > > > > > >Thanks, > > > >Jonathan > > > > > > > >> -----Original Message----- > > > >> From: George Young [mailto:george.young@meriton.com] > > > >> Sent: Tuesday, November 20, 2001 8:34 AM > > > >> To: Jonathan Lang > > > >> Cc: ccamp@ops.ietf.org > > > >> Subject: RE: Two week Last Call on LMP (Sections > 12.3.3 and 12.3.4) > > > >> > > > >> > > > >> Hello Jonathan, > > > >> > > > >> Comments/question below. Also please note, edgeFlow has > > > >> changed its name > > > >> to Meriton Networks Inc., and as a result the email address > > > >changes to > > > >> george.young@meriton.com. > > > >> > > > >> Regards, > > > >> George R. Young > > > >> Meriton Networks Inc. > > > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > >> phone: +1 613-270-9279 Ext 287 > > > >> fax: +1 613-270-9268 > > > >> > > > >> > > > >> >-----Original Message----- > > > >> >From: Jonathan Lang [mailto:jplang@calient.net] > > > >> >Sent: Monday, November 19, 2001 5:21 PM > > > >> >To: 'S Ramesh'; George Young > > > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang > > > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > > > and 12.3.4) > > > >> > > > > >> > > > > >> >Ramesh, > > > >> > Please see inline. > > > >> > > > > >> >Thanks, > > > >> >Jonathan > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > > > >> >> Sent: Thursday, November 15, 2001 11:15 PM > > > >> >> To: George Young > > > >> >> Cc: ccamp@ops.ietf.org > > > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 > > > >and 12.3.4) > > > >> >> > > > >> >> > > > >> >> Hi Young, > > > >> >> > > > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be > added in the > > > >> >> Data Link FSM's in the down state also. Agreed. > > > >> >I would actually propose that we remove the degraded state > > > >> >altogether from > > > >> >the data link fsms. This is already captured at the TE > > > link level. > > > >> >Comments? > > > >> > > > >> If I understand your response to messrs Ramesh and moi, > > > transition 10 > > > >> should be retained from Deg to Down. > > > >> If you then remove the Deg state, implying that in the > > > Up/Alloc state > > > >> you may not have a control channel, where would > transition 10 go? > > > >> > > > >> Transition 13 'fault localization' seems to need a > control channel. > > > >> Without the Deg state, how would you represent the idea that > > > >sometimes > > > >> transition 13 can't take place? > > > >What I'm proposing is that we decouple the notion of a control > > > >channel with > > > >the data link FSMs. As Ramesh said in an email, some of these > > > >events can be > > > >generated through management interface also. For active data > > > >link, the FSM > > > >would be: > > > > > > > > +------+ > > > > | |<-------+ > > > > +--------->| Down | | > > > > | +----| |<-----+ | > > > > | | +------+ | | > > > > | |5b 3| ^ | | > > > > | | | |2,7 | | > > > > | | v | | | > > > > | | +------+ | | > > > > | | | |<-+ | | > > > > | | | Test | |11 | | > > > > | | | |--+ | | > > > > | | +------+ | | > > > > | | 5a| 3^ | | > > > > | | | | | | > > > > | | v | | | > > > > |2,12 | +---------+ | | > > > > | +-->| |14 | | > > > > | | Up/Free |----+ | > > > > +---------| | | > > > > +---------+ | > > > > 9| ^ | > > > > | | | > > > > v |10 | > > > > +---------+ | > > > > | |13 | > > > > |Up/Alloc |------+ > > > > | | > > > > +---------+ > > > > > > > > > > Removing the Deg state simplifies the Link FSM as it's present in > > > the TE FSM. Editorially then (I think), transition 2 > would not take > > > place from Test/PasvTest to Down. > > > > > > > > > > >> > > > >> > > > > >> >> > > > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in > > > >> >the degraded > > > >> >> state. Yeah a control channel is needed, but this event > > > >> can also be a > > > >> >> external event know, from the user or a network management > > > >> >event. If this > > > >> >> is possible then this event is required in this > state. Kindly > > > >> >> clarify me. > > > >> >agreed. > > > >> > > > > >> >> > > > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv > > > >> >Test state. Since > > > >> >> to send a Test message or to receive a Test message we > > > need a data > > > >> >channel. > > > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will > > > >> >pose the next > > > >> >> state to Test & Pasv Test state from Up/Free state. > So the event > > > >> >> 14.evdcDown is also possible on both the states and > hence the > > > >> >> next state in both the case will be down. > > > >> >ok. > > > >> > > > > >> >> > > > >> >> Thanks, > > > >> >> Ramesh > > > >> >> > > > >> >> George Young wrote: > > > >> >> > > > >> >> > Looking at the Data Link FSMs in Sections 12.3.3 > and 12.3.4 of > > > >> >> > draft-ietf-ccamp-lmp-02.txt: > > > >> >> > > > > >> >> > 1) It appears that in the Down state, the control channel > > > >> >> can be either > > > >> >> > up or > > > >> >> > down. That being the case, there should be transitions > > > >> for events 1 > > > >> >> > :evCCUp: > > > >> >> > and 2 :evCCDown: from Down to Down. > > > >> >> > > > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > > > >> appear to be > > > >> >> > impossible, > > > >> >> > as there is no control channel available, and the control > > > >> >channel is > > > >> >> > required to coordinate taking the channel down at both > > > >> >> ends. I believe > > > >> >> > this > > > >> >> > transition should be removed. > > > >> >> > > > > >> >> > With these changes, the FSMs would look like: > > > >> >> > > > > >> >> > 12.3.3. Active Data Link FSM Description > > > >> >> > > > > >> >> > Figure 5 illustrates operation of the LMP active data > > > >> >> link FSM in a > > > >> >> > form of FSM state transition diagram. > > > >> >> > > > > >> >> > 1,2 > > > >> >> > +------+ > > > >> >> > | | > > > >> >> > | +------+ > > > >> >> > +-->| |<-------+ > > > >> >> > +--------->| Down | | > > > >> >> > | +----| |<-----+ | > > > >> >> > | | +------+ | | > > > >> >> > | |5b 3| ^ | | > > > >> >> > | | | |2,7 | | > > > >> >> > | | v | | | > > > >> >> > | | +------+ | | > > > >> >> > | | | |<-+ | | > > > >> >> > | | | Test | |11 | | > > > >> >> > | | | |--+ | | > > > >> >> > | | +------+ | | > > > >> >> > | | 5a| 3^ | | > > > >> >> > | | | | | | > > > >> >> > | | v | | | > > > >> >> > |2,12 | +---------+ | | > > > >> >> > | +-->| |14 | | > > > >> >> > | | Up/Free |----+ | > > > >> >> > +---------| | | > > > >> >> > +---------+ | > > > >> >> > 9| ^ | > > > >> >> > | | | > > > >> >> > v |10 | > > > >> >> > +-----+ 2 +---------+ | > > > >> >> > | |<--------| |13 | > > > >> >> > | Deg | |Up/Alloc |------+ > > > >> >> > | |-------->| | > > > >> >> > +-----+ 1 +---------+ > > > >> >> > > > > >> >> > Figure 5: Active LMP Data Link FSM > > > >> >> > > > > >> >> > 12.3.4. Passive Data Link FSM Description > > > >> >> > > > > >> >> > Figure 6 illustrates operation of the LMP passive data > > > >> >> link FSM in a > > > >> >> > form of FSM state transition diagram. > > > >> >> > > > > >> >> > 1,2 > > > >> >> > +------+ > > > >> >> > | | > > > >> >> > | +------+ > > > >> >> > +-->| |<------+ > > > >> >> > +---------->| Down | | > > > >> >> > | +-----| |<----+ | > > > >> >> > | | +------+ | | > > > >> >> > | |5b 4| ^ | | > > > >> >> > | | | |2,8 | | > > > >> >> > | | v | | | > > > >> >> > | | +----------+ | | > > > >> >> > | | | PasvTest | | | > > > >> >> > | | +----------+ | | > > > >> >> > | | 6| 4^ | | > > > >> >> > | | | | | | > > > >> >> > | | v | | | > > > >> >> > |2,12 | +---------+ | | > > > >> >> > | +--->| Up/Free |14 | | > > > >> >> > | | |---+ | > > > >> >> > +----------| | | > > > >> >> > +---------+ | > > > >> >> > 9| ^ | > > > >> >> > | | | > > > >> >> > v |10 | > > > >> >> > +-----+ +---------+ | > > > >> >> > | | 2 | |13 | > > > >> >> > | Deg |<--------|Up/Alloc |-----+ > > > >> >> > | |-------->| | > > > >> >> > +-----+ 1 +---------+ > > > >> >> > > > > >> >> > Figure 6: Passive LMP Data Link FSM > > > >> >> > > > > >> >> > Regards, > > > >> >> > George R. Young > > > >> >> > edgeflow Inc. > > > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > >> >> > phone: +1 613-270-9279 Ext 287 > > > >> >> > fax: +1 613-270-9268 > > > >> >> > > > > >> >> > >-----Original Message----- > > > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM > > > >> >> > >To: ccamp@ops.ietf.org > > > >> >> > >Subject: Two week Last Call on LMP > > > >> >> > > > > > >> >> > > > > > >> >> > >Hi All, > > > >> >> > > > > > >> >> > >This is to announce a two week Last Call on the > LMP draft: > > > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > > > >> Wed Nov 28. > > > >> >> > > > > > >> >> > >Please send questions, comments and requests for > > > clarifications > > > >> >> > >to the CCAMP list. > > > >> >> > > > > > >> >> > >Kireeti. > > > >> >> > > > > > >> >> > > > > > >> >> > > > >> >> > > > >> > > > > >> > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 16:24:03 -0800 Message-ID: From: Jonathan Lang To: 'S Ramesh' Cc: 'George Young' , ccamp@ops.ietf.org Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Mon, 26 Nov 2001 16:15:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh, Please see inline. Thanks, Jonathan > -----Original Message----- > From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > Sent: Wednesday, November 21, 2001 9:50 PM > To: Jonathan Lang > Cc: 'George Young'; ccamp@ops.ietf.org > Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > Hi Jonathan, > > As editorially speaking since Test/Pasv Test state is sending or receiving Test > messages alone event 2:ecdcDown is not needed in the state. agreed. > But in Test/Pasv > Test state event 7:evTestfail and 8:evPsvTestFail are possible. Actually these > two events need a control channel in order to receive a TestStatusFailure > message or EndVerify message in the first case ( Test sate ) and to receive a > EndVerify in the later case also ( PasvTest state ). So a control channel is > needed in these states even we send or receive a Test message alone ( as per > editorial definition of these states ). If this is the case then event > 2:evCCdown is possible in these two states and hence the resulting state will be > down. new definitions for events 7 & 8 should cover this. (see email exchange below) > > Also Jonathan as i already said 14.evdcDown is possible in Test/Pasv Test state. Why wouldn't this be covered in event 7 & 8? > > Thanks, > Ramesh > > > > > > Jonathan Lang wrote: > > > George, > > Event 2 can be removed. We will need to reword events 7 > & 8. My proposal > > below: > > > > 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. > > > > -Jonathan > > > > > -----Original Message----- > > > From: George Young [mailto:george.young@meriton.com] > > > Sent: Wednesday, November 21, 2001 5:41 AM > > > To: Jonathan Lang > > > Cc: ccamp@ops.ietf.org > > > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > and 12.3.4) > > > > > > > > > Hello Jonathan, > > > > > > See below: > > > > > > Regards, > > > George R. Young > > > Meriton Networks Inc. > > > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > phone: +1 613-270-9279 Ext 287 > > > fax: +1 613-270-9268 > > > > > > > > > >-----Original Message----- > > > >From: Jonathan Lang [mailto:jplang@calient.net] > > > >Sent: Tuesday, November 20, 2001 11:49 AM > > > >To: George Young > > > >Cc: ccamp@ops.ietf.org > > > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > and 12.3.4) > > > > > > > > > > > >George, > > > > Please see inline. > > > > > > > >Thanks, > > > >Jonathan > > > > > > > >> -----Original Message----- > > > >> From: George Young [mailto:george.young@meriton.com] > > > >> Sent: Tuesday, November 20, 2001 8:34 AM > > > >> To: Jonathan Lang > > > >> Cc: ccamp@ops.ietf.org > > > >> Subject: RE: Two week Last Call on LMP (Sections > 12.3.3 and 12.3.4) > > > >> > > > >> > > > >> Hello Jonathan, > > > >> > > > >> Comments/question below. Also please note, edgeFlow has > > > >> changed its name > > > >> to Meriton Networks Inc., and as a result the email address > > > >changes to > > > >> george.young@meriton.com. > > > >> > > > >> Regards, > > > >> George R. Young > > > >> Meriton Networks Inc. > > > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > >> phone: +1 613-270-9279 Ext 287 > > > >> fax: +1 613-270-9268 > > > >> > > > >> > > > >> >-----Original Message----- > > > >> >From: Jonathan Lang [mailto:jplang@calient.net] > > > >> >Sent: Monday, November 19, 2001 5:21 PM > > > >> >To: 'S Ramesh'; George Young > > > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang > > > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > > > and 12.3.4) > > > >> > > > > >> > > > > >> >Ramesh, > > > >> > Please see inline. > > > >> > > > > >> >Thanks, > > > >> >Jonathan > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > > > >> >> Sent: Thursday, November 15, 2001 11:15 PM > > > >> >> To: George Young > > > >> >> Cc: ccamp@ops.ietf.org > > > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 > > > >and 12.3.4) > > > >> >> > > > >> >> > > > >> >> Hi Young, > > > >> >> > > > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be > added in the > > > >> >> Data Link FSM's in the down state also. Agreed. > > > >> >I would actually propose that we remove the degraded state > > > >> >altogether from > > > >> >the data link fsms. This is already captured at the TE > > > link level. > > > >> >Comments? > > > >> > > > >> If I understand your response to messrs Ramesh and moi, > > > transition 10 > > > >> should be retained from Deg to Down. > > > >> If you then remove the Deg state, implying that in the > > > Up/Alloc state > > > >> you may not have a control channel, where would > transition 10 go? > > > >> > > > >> Transition 13 'fault localization' seems to need a > control channel. > > > >> Without the Deg state, how would you represent the idea that > > > >sometimes > > > >> transition 13 can't take place? > > > >What I'm proposing is that we decouple the notion of a control > > > >channel with > > > >the data link FSMs. As Ramesh said in an email, some of these > > > >events can be > > > >generated through management interface also. For active data > > > >link, the FSM > > > >would be: > > > > > > > > +------+ > > > > | |<-------+ > > > > +--------->| Down | | > > > > | +----| |<-----+ | > > > > | | +------+ | | > > > > | |5b 3| ^ | | > > > > | | | |2,7 | | > > > > | | v | | | > > > > | | +------+ | | > > > > | | | |<-+ | | > > > > | | | Test | |11 | | > > > > | | | |--+ | | > > > > | | +------+ | | > > > > | | 5a| 3^ | | > > > > | | | | | | > > > > | | v | | | > > > > |2,12 | +---------+ | | > > > > | +-->| |14 | | > > > > | | Up/Free |----+ | > > > > +---------| | | > > > > +---------+ | > > > > 9| ^ | > > > > | | | > > > > v |10 | > > > > +---------+ | > > > > | |13 | > > > > |Up/Alloc |------+ > > > > | | > > > > +---------+ > > > > > > > > > > Removing the Deg state simplifies the Link FSM as it's present in > > > the TE FSM. Editorially then (I think), transition 2 > would not take > > > place from Test/PasvTest to Down. > > > > > > > > > > >> > > > >> > > > > >> >> > > > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in > > > >> >the degraded > > > >> >> state. Yeah a control channel is needed, but this event > > > >> can also be a > > > >> >> external event know, from the user or a network management > > > >> >event. If this > > > >> >> is possible then this event is required in this > state. Kindly > > > >> >> clarify me. > > > >> >agreed. > > > >> > > > > >> >> > > > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv > > > >> >Test state. Since > > > >> >> to send a Test message or to receive a Test message we > > > need a data > > > >> >channel. > > > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will > > > >> >pose the next > > > >> >> state to Test & Pasv Test state from Up/Free state. > So the event > > > >> >> 14.evdcDown is also possible on both the states and > hence the > > > >> >> next state in both the case will be down. > > > >> >ok. > > > >> > > > > >> >> > > > >> >> Thanks, > > > >> >> Ramesh > > > >> >> > > > >> >> George Young wrote: > > > >> >> > > > >> >> > Looking at the Data Link FSMs in Sections 12.3.3 > and 12.3.4 of > > > >> >> > draft-ietf-ccamp-lmp-02.txt: > > > >> >> > > > > >> >> > 1) It appears that in the Down state, the control channel > > > >> >> can be either > > > >> >> > up or > > > >> >> > down. That being the case, there should be transitions > > > >> for events 1 > > > >> >> > :evCCUp: > > > >> >> > and 2 :evCCDown: from Down to Down. > > > >> >> > > > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > > > >> appear to be > > > >> >> > impossible, > > > >> >> > as there is no control channel available, and the control > > > >> >channel is > > > >> >> > required to coordinate taking the channel down at both > > > >> >> ends. I believe > > > >> >> > this > > > >> >> > transition should be removed. > > > >> >> > > > > >> >> > With these changes, the FSMs would look like: > > > >> >> > > > > >> >> > 12.3.3. Active Data Link FSM Description > > > >> >> > > > > >> >> > Figure 5 illustrates operation of the LMP active data > > > >> >> link FSM in a > > > >> >> > form of FSM state transition diagram. > > > >> >> > > > > >> >> > 1,2 > > > >> >> > +------+ > > > >> >> > | | > > > >> >> > | +------+ > > > >> >> > +-->| |<-------+ > > > >> >> > +--------->| Down | | > > > >> >> > | +----| |<-----+ | > > > >> >> > | | +------+ | | > > > >> >> > | |5b 3| ^ | | > > > >> >> > | | | |2,7 | | > > > >> >> > | | v | | | > > > >> >> > | | +------+ | | > > > >> >> > | | | |<-+ | | > > > >> >> > | | | Test | |11 | | > > > >> >> > | | | |--+ | | > > > >> >> > | | +------+ | | > > > >> >> > | | 5a| 3^ | | > > > >> >> > | | | | | | > > > >> >> > | | v | | | > > > >> >> > |2,12 | +---------+ | | > > > >> >> > | +-->| |14 | | > > > >> >> > | | Up/Free |----+ | > > > >> >> > +---------| | | > > > >> >> > +---------+ | > > > >> >> > 9| ^ | > > > >> >> > | | | > > > >> >> > v |10 | > > > >> >> > +-----+ 2 +---------+ | > > > >> >> > | |<--------| |13 | > > > >> >> > | Deg | |Up/Alloc |------+ > > > >> >> > | |-------->| | > > > >> >> > +-----+ 1 +---------+ > > > >> >> > > > > >> >> > Figure 5: Active LMP Data Link FSM > > > >> >> > > > > >> >> > 12.3.4. Passive Data Link FSM Description > > > >> >> > > > > >> >> > Figure 6 illustrates operation of the LMP passive data > > > >> >> link FSM in a > > > >> >> > form of FSM state transition diagram. > > > >> >> > > > > >> >> > 1,2 > > > >> >> > +------+ > > > >> >> > | | > > > >> >> > | +------+ > > > >> >> > +-->| |<------+ > > > >> >> > +---------->| Down | | > > > >> >> > | +-----| |<----+ | > > > >> >> > | | +------+ | | > > > >> >> > | |5b 4| ^ | | > > > >> >> > | | | |2,8 | | > > > >> >> > | | v | | | > > > >> >> > | | +----------+ | | > > > >> >> > | | | PasvTest | | | > > > >> >> > | | +----------+ | | > > > >> >> > | | 6| 4^ | | > > > >> >> > | | | | | | > > > >> >> > | | v | | | > > > >> >> > |2,12 | +---------+ | | > > > >> >> > | +--->| Up/Free |14 | | > > > >> >> > | | |---+ | > > > >> >> > +----------| | | > > > >> >> > +---------+ | > > > >> >> > 9| ^ | > > > >> >> > | | | > > > >> >> > v |10 | > > > >> >> > +-----+ +---------+ | > > > >> >> > | | 2 | |13 | > > > >> >> > | Deg |<--------|Up/Alloc |-----+ > > > >> >> > | |-------->| | > > > >> >> > +-----+ 1 +---------+ > > > >> >> > > > > >> >> > Figure 6: Passive LMP Data Link FSM > > > >> >> > > > > >> >> > Regards, > > > >> >> > George R. Young > > > >> >> > edgeflow Inc. > > > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > > >> >> > phone: +1 613-270-9279 Ext 287 > > > >> >> > fax: +1 613-270-9268 > > > >> >> > > > > >> >> > >-----Original Message----- > > > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM > > > >> >> > >To: ccamp@ops.ietf.org > > > >> >> > >Subject: Two week Last Call on LMP > > > >> >> > > > > > >> >> > > > > > >> >> > >Hi All, > > > >> >> > > > > > >> >> > >This is to announce a two week Last Call on the > LMP draft: > > > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > > > >> Wed Nov 28. > > > >> >> > > > > > >> >> > >Please send questions, comments and requests for > > > clarifications > > > >> >> > >to the CCAMP list. > > > >> >> > > > > > >> >> > >Kireeti. > > > >> >> > > > > > >> >> > > > > > >> >> > > > >> >> > > > >> > > > > >> > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 07:43:38 -0800 Message-ID: <3C0262F5.8050004@lucent.com> Date: Mon, 26 Nov 2001 10:42:45 -0500 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: Sudheer Dharanikota CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------080401080800090005080500" This is a multi-part message in MIME format. --------------080401080800090005080500 Content-Type: multipart/alternative; boundary="------------070601070402000203020109" --------------070601070402000203020109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, Jonathan, and all, Attached is the LMP draft with my proposed text inserted. I inserted proposed text on the suppression of downstream alarms, as well as some other sections. Please let me know what you think of the proposed text. The notation I used is as follows: [Insert: .... new proposed text....] [Delete: .... text that I propose to be deleted...] Thanks Carmine Sudheer Dharanikota wrote: > >Carmine Daloia wrote: > >>Hi Sudheer, >> >>My last comment wasn't meant to be an argument :-) >> >>Maybe if I propose some text specific to the suppression >>of downstream alarms that would help clarify the scope of >>applicability. The text would state that when client >>devices (e.g., SONET/SDH cross-connects, IP routers) are >>interconnected via a standard OTN network then the >>suppression of downstream alarms is already handled in the >>transport/user plane via the OTN overhead (both in-band >>via the digitial overhead as well as out-of-band via >>non-associated overhead). Also the text would address PXCs >>within a standard OTN network. In this case, again the >>suppression of downstream alarms is handled via the OTN >>overhead. >> >>The implementation proposed in LMP for suppression of >>downstream alarms applies to PXCs or client devices (e.g, >>SONET/SDH cross-connects or IP routers) interconnected via >>a non-standard DWDM network. In this case, it is assummed >>that the non-standard DWDM network does not provide the >>neccesary overhead within the transport/user plane to >>suppress alarms on PXCs and client devices and therefore >>LMP provides a mechanism to carry such alarm suppression >>messages in the control plane. >> >>I'll take a crack at specific text so that the group can >>review it. Does this sound like something that would be >>helpful. >> >> > >Sure. > >Regards, > >sudheer > >> --------------070601070402000203020109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sudheer, Jonathan, and all,

Attached is the LMP draft with my proposed text inserted. I inserted proposed text on the suppression of downstream alarms, as well as some other sections.

Please let me know what you think of the proposed text.
The notation I used is as follows:
[Insert: .... new proposed text....]
[Delete: .... text that I propose to be deleted...]

Thanks
Carmine

Sudheer Dharanikota wrote:

Carmine Daloia wrote:

Hi Sudheer,

My last comment wasn't meant to be an argument :-)

Maybe if I propose some text specific to the suppression
of downstream alarms that would help clarify the scope of
applicability. The text would state that when client
devices (e.g., SONET/SDH cross-connects, IP routers) are
interconnected via a standard OTN network then the
suppression of downstream alarms is already handled in the
transport/user plane via the OTN overhead (both in-band
via the digitial overhead as well as out-of-band via
non-associated overhead). Also the text would address PXCs
within a standard OTN network. In this case, again the
suppression of downstream alarms is handled via the OTN
overhead.

The implementation proposed in LMP for suppression of
downstream alarms applies to PXCs or client devices (e.g,
SONET/SDH cross-connects or IP routers) interconnected via
a non-standard DWDM network. In this case, it is as
summed
that the non-standard DWDM network does not provide the
neccesary overhead within the transport/user plane to
suppress alarms on PXCs and client devices and therefore
LMP provides a mechanism to carry such alarm suppression
messages in the control plane.

I'll take a crack at specific text so that the group can
review it. Does this sound like something that would be
helpful.



Sure.

Regards,

sudheer



--------------070601070402000203020109-- --------------080401080800090005080500 Content-Type: text/plain; name="draft-ietf-ccamp-lmp-02_daloia.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="draft-ietf-ccamp-lmp-02_daloia.txt" Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Network Working Group Jonathan P. Lang (Calient Networks) Internet Draft Krishna Mitra (Calient Networks) Expiration Date: May 2002 John Drake (Calient Networks) Kireeti Kompella (Juniper Networks) Yakov Rekhter (Juniper Networks) Lou Berger (Movaz Networks) Debanjan Saha (Tellium) Debashis Basak (Accelight Networks) Hal Sandick (Nortel Networks) Alex Zinin (Nexsi Systems) Bala Rajagopalan (Tellium) November 2001 Link Management Protocol (LMP) draft-ietf-ccamp-lmp-02.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 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data-bearing channels, correlate the link property information, [Insert: suppress downstream alarms in pre-G.709 networks, and localize faults in both opaque and transparent networks to a particular link between adjacent cross-connects for protection/restoration actions.] [Delete: and manage link failures. A unique feature of the fault management technique is that it is able to localize failures in both opaque and transparent networks, independent of the encoding scheme used for the data.] Lang et al [Page 1] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Table of Contents 1 Introduction ................................................ 3 2 LMP Overview ................................................ 4 3 Control Channel Management ................................... 6 3.1 Parameter Negotiation ................................... 7 3.2 Hello Protocol .......................................... 8 3.2.1 Hello Parameter Negotiation ...................... 8 3.2.2 Fast Keep-alive .................................. 9 3.2.3 Control Channel Down ............................. 10 3.2.4 Degraded (DEG) State ............................. 10 4 Link Property Correlation ................................... 10 5 Verifying Link Connectivity ................................. 12 5.1 Example of Link Connectivity Verification ............... 14 6 Fault Management ............................................ 15 6.1 Fault Detection ......................................... 15 6.2 Fault Localization Procedure ............................ 15 6.3 Examples of Fault Localization .......................... 16 6.4 Channel Activation Indication ........................... 17 6.5 Channel Deactivation Indication ......................... 18 7 Message_Id Usage ............................................ 18 8 Graceful Restart ............................................ 19 9 Addressing .................................................. 20 10 LMP Authentication .......................................... 20 11 IANA Considerations ......................................... 21 12 LMP Finite State Machine .................................... 22 12.1 Control Channel FSM .................................... 22 12.1.1 Control Channel States .......................... 22 12.1.2 Control Channel Events .......................... 22 12.1.3 Control Channel FSM Description ................. 25 12.2 TE Link FSM ............................................ 26 12.2.1 TE link States .................................. 26 12.2.2 TE link Events .................................. 26 12.2.3 TE link FSM Description ......................... 27 12.3 Data Link FSM .......................................... 27 12.3.1 Data Link States ................................ 28 12.3.2 Data Link Events ................................ 28 12.3.3 Active Data Link FSM Description ................ 30 12.3.4 Passive Data Link FSM Description ............... 31 13 LMP Message Formats ......................................... 32 13.1 Common Header .......................................... 32 13.2 LMP Object Format ...................................... 34 13.3Authentication .......................................... 34 13.4 Parameter Negotiation .................................. 37 13.5 Hello .................................................. 38 13.6 Link Verification ...................................... 39 13.7 Link Summary ........................................... 42 13.8 Fault Management ....................................... 43 14 LMP Object Definitions ...................................... 45 15 Security Conderations ....................................... 63 16 References .................................................. 64 17 Acknowledgments ............................................. 65 18 Authors' Addresses ......................................... 65 Lang et al [Page 2] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Changes from previous version: o Added IANI Considerations section. o Added clarifying text to the MessageId section. o Added clarifying text to the ChannelStatus section for fault localization. o Added Data Link Subobject to DATA_LINK object. 1. Introduction Future networks will consist of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM systems, and add-drop multiplexors (ADMs) that use a common control plane [e.g., Generalized MPLS (GMPLS)] to dynamically allocate resources and to provide network survivability using protection and restoration techniques. A pair of nodes (e.g., two PXCs) may be connected by thousands of fibers, and each fiber may be used to transmit multiple wavelengths if DWDM is used. Furthermore, multiple fibers and/or multiple wavelengths may be combined into a single traffic- engineering (TE) link for routing purposes. To enable communication between nodes for routing, signaling, and link management, control channels must be established between the node pair; however, the interface over which the control messages are sent/received may not be the same interface over which the data flows. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. In this draft, the naming convention of [LAMBDA] is followed, and OXC is used to refer to all categories of optical crossconnects, irrespective of the internal switching fabric. Furthermore, a distinction is made between crossconnects that require opto- electronic conversion, called digital crossconnects (DXCs), and those that are all-optical, called photonic switches or photonic crossconnects (PXCs) - referred to as pure crossconnects in [LAMBDA], because the transparent nature of PXCs introduces new restrictions for monitoring and managing the data links. LMP can be used for any type of node, enhancing the functionality of traditional DXCs and routers, while enabling PXCs and DWDMs to intelligently interoperate in heterogeneous optical networks. In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, [Delete: or] an IP tunnel through a separate management network [Delete: .] [Insert: , or a multi-hop IP network] A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data links is that the health of a control channel does not necessarily correlate to the health of the data links, and vice-versa. Therefore, a clean separation between the fate of the control channel and data-bearing links must be made. New mechanisms must be developed to manage the data-bearing links, both in terms of link provisioning and fault management. Lang et al [Page 3] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 For the purposes of this document, a data-bearing link may be either a "port" or a "component link" depending on its multiplexing capability; component links are multiplex capable, whereas ports are not multiplex capable. This distinction is important since the management of such links (including, for example, resource allocation, label assignment, and their physical verification) is different based on their multiplexing capability. For example, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams. If multiple interfaces are grouped together into a single TE link using link bundling [BUNDLE], then the link resources must be identified using three levels: TE link Id, component interface Id, and timeslot label. Resource allocation happens at the lowest level (timeslots), but physical connectivity happens at the component link level. As another example, consider the case where a PXC transparently switches OC-192 lightpaths. If multiple interfaces are once again grouped together into a single TE link, then link bundling [BUNDLE] is not required and only two levels of identification are required: TE link Id and port Id. In this case, both resource allocation and physical connectivity happen at the lowest level (i.e. port level). To ensure interworking between data links with different multiplexing capabilities, LMP capable devices SHOULD allow sub- channels of a component link to be locally configured as (logical) data links. For example, if a Router with 4 OC-48 interfaces is connected through a 4:1 MUX to an OXC with OC-192c interfaces, the OXC SHOULD be able to configure each OC-48 sub-channel as a data link. 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). 2. LMP Overview The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify configuration. LMP requires that a pair of nodes have at least one active bi- directional control channel between them. The two directions of the control channel are coupled together using the LMP Config message exchange. All LMP messages are IP encoded [except in some cases, the Test Message which may be limited by the transport mechanism for in-band messaging]. The link level encoding of the control channel is outside the scope of this document. Lang et al [Page 4] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 An ôLMP adjacencyö is formed between two nodes when at least one bi- directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged by the adjacent nodes over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes. The link property correlation function of LMP is designed to aggregate multiple data links (ports or component 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. LMP messages are transmitted reliably 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. For control channel specific messages, the Message Id is within the scope of the control channel over which is the message is sent. For TE link specific messages, the Message Id is within the scope of the LMP adjacency. This value of the Message Id is incremented and only decreases when the value wraps. In this draft, [Delete: two] [Insert: three] additional LMP procedures are defined: link connectivity verification [Delete: and fault management] [Insert: suppression of downstream alarms, and localization faults in both opaque and transparent networks to a particular link between adjacent cross-connects for protection/restoration actions] . [Delete: These procedures are particularly useful when the control channels are physically diverse from the data-bearing links.] Link connectivity verification is used to verify the physical connectivity of the data-bearing links between the nodes and exchange the Interface Ids; Interface Ids are used in GMPLS signaling, either as Port labels or Component Interface Ids, depending on the configuration. The link verification procedure uses in-band Test messages that are sent over the data-bearing links and TestStatus messages that are transmitted back over the control channel. Note that the Test message is the only LMP message that must be transmitted over the data-bearing link. [Delete: The fault management scheme uses] [Insert: Both the suppression of downstream alarms and the localization of faults for protection/restoration use] ChannelStatus message exchanges between adjacent nodes [Delete: to localize failures] in both opaque and transparent networks, independent of the encoding scheme used for the data. As a result, both local span and end-to-end path protection/restoration procedures can be initiated. [Insert: Note that the fault localization scheme supported in LMP localizes faults on a link and does not address node failures. Therefore additional mechanisms are needed to detect node failures for end-to-end path protection/restoration.] Lang et al [Page 5] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 [Delete: For the LMP link connectivity verification procedure, the free (unallocated) data-bearing links MUST be opaque (i.e., able to be terminated); however, once a data link is allocated, it may become transparent.] [Insert: For LMP link conncetivity verification procedure between adjacent PXCs, the test message is generated and termindated by opaque test units that may be shared among multiple ports on the PXC. Opaque test units are needed since the PXC ports are transparent.] The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various degrees of transparency (e.g., examining overhead bytes, terminating the payload, etc.), and hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data-bearing links must be terminated simultaneously, but at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST terminate on the same two nodes that the TE link spans. Since the BeginVerify message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links between opaque and transparent mode. The LMP fault management procedure [Insert: (i.e., the suppression of downstream alarms in pre-G.709 networks, and the localization of faults to a particular link between adjacent OXCs for protection/restoration actions)] 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 channels of a TE link. The ChannelStatusAck message is used to acknowledge 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. Upon receipt of the ChannelStatusRequest message, a node MUST send a ChannelStatusResponse message indicating the states of the queried data links. The organization of the remainder of this document is as follows. In Section 3, the role of the control channel and the messages used to establish and maintain link connectivity is discussed. 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 will be used to isolate link and channel failures within the optical network. Several finite state machines (FSMs) are given in Section 8, and the message formats are defined in Section 9. 3. Control Channel Management To initiate an LMP adjacency between two nodes, one or more bi- directional control channels MUST be activated. The control channels can be used to exchange control-plane information such as link provisioning and fault management information (implemented using a messaging protocol such as LMP, proposed in this draft), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR- LDP]), and network topology and state distribution information Lang et al [Page 6] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 (implemented using traffic engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). For the purposes of LMP, the exact implementation of the control channel is not specified; it could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, [Insert: a multi-hop IP network,] or the overhead bytes of a data-bearing link. Rather, a node-wide unique 32-bit non-zero integer control channel identifier (CCId) is assigned at each end of the control channel. This identifier comes from the same space as the unnumbered interface Id. Furthermore, LMP is run directly over IP. Thus, the link level encoding of the control channel is not part of the LMP specification. The control channel can be either explicitly configured or automatically selected, however, for the purpose of this document the control channel is assumed to be explicitly configured. [Insert: The term configured means that the destination IP address to reach the adjacent node on the far end of the control channel is known at the near-end. The destination IP address may be manually configured, or automatically discovered.] Note that for in-band signaling, a control channel could be explicitly configured on a particular data-bearing link. Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. [Insert: Maintenance of control channels (i.e., detection of control channel failures and restoral of communication) is needed. Various mechanisms could be used to provide maintenance of control channels, depending on the level of service required. For example, control channel failures could be detected and restored via normal IP routing protocols, however this may not support the necessary level of service due to the time required to update the routing tables. For very fast recovery of control channels, other mechanisms such as bridging messages at the near-end and selecting messages at the far-end can be used. LMP defines a Hello protocol that can be used to detect control failures. To support the Hello protocol,] [Delete: As such, ] control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH). There are four LMP messages that are used to manage individual control channels. They are the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel to which they refer. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes. In order to maintain an LMP adjacency, it is necessary to have at least one active control channel between a pair of adjacent nodes (recall that multiple control channels can be active simultaneously between a pair of nodes). In the event of a control channel failure, alternate active control channels can be used and it may be possible to activate additional control channels as mentioned below. 3.1. Parameter Negotiation [Insert: Activation of the LMP Hello Protocol] [Delete: Control channel activation] begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N bit in the Lang et al [Page 7] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 object header). Negotiable objects can be used to let LMP peers agree on certain values. Non-negotiable objects are used for the announcement of specific values that do not need, or do not allow, negotiation. To begin [Delete: control channel] [Insert: Hello Protocol] activation, a node MUST transmit a Config message to the remote node. The Config message contains the Control Channel ID (CCID), the senderÆs Node ID, a MessageId for reliable messaging, and a CONFIG Object. It is possible that both the local and remote nodes initiate the configuration procedure at the same time. To avoid ambiguities, the node with the higher Node Id wins the contention; the node with the lower Node Id MUST stop transmitting the Config message and respond to the Config message it received. The ConfigAck message is used to acknowledge receipt of the Config message and express agreement on ALL of the configured parameters (both negotiable and non-negotiable). The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable CONFIG objects are unacceptable, and propose alternate values for the negotiable parameters. If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters. If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages. Note that the problem may be solved by an operator changing parameters. In the case where multiple control channels use the same physical interface, the parameter negotiation exchange is performed for each control channel. The various LMP parameter negotiation messages are associated with their corresponding control channels by their node- wide unique identifiers (CCIds). 3.2. Hello Protocol Once [Delete: a control channel] [Insert: the Hello Protocol] is activated between two adjacent nodes, the LMP Hello protocol can be used to maintain control channel connectivity between the nodes and to detect control channel failures. The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link- state adjacencies are not removed unnecessarily. 3.2.1. Hello Parameter Negotiation Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will Lang et al [Page 8] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 be sent, and is measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has both sent and received a Hello message, the control channel moves to the UP state. (It is also possible to move to the UP state without sending Hellos if other methods are used to indicate bi-directional control-channel connectivity.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages and the control channel SHOULD NOT move to the UP state. See Section 8.1 for the complete control channel FSM. 3.2.2. Fast Keep-alive Each Hello message contains two sequence numbers: the first sequence number (TxSeqNum) is the sequence number for the Hello message being sent and the second sequence number (RcvSeqNum) is the sequence number of the last Hello message received over this control channel from the adjacent node. Each node increments its sequence number when it sees its current sequence number reflected in Hellos received from its peer. The sequence numbers start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to indicate that a Hello has not yet been seen. Under normal operation, the difference between the RcvSeqNum in a Hello message that is received and the local TxSeqNum that is generated will be at most 1. This difference can be more than one only when a control channel restarts or when the values wrap. Note that the 32-bit sequence numbers MAY wrap. The following expression may be used to test if a newly received TxSeqNum value is less than a previously received value: If ((int) old_id û (int) new_id > 0) { New value is less than old value; } Having sequence numbers in the Hello messages allows each node to verify that its peer is receiving its Hello messages. By including the RcvSeqNum in Hello packets, the local node will know which Hello packets the remote node has received. Lang et al [Page 9] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The following example illustrates how the sequence numbers operate. Note that only the operation at one node is shown: 1) After completing the configuration stage, Node A sends Hello messages to Node B with {TxSeqNum=1;RcvSeqNum=0}. 2) When Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=1}. 3) When Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}, it sends Hellos to Node B with {TxSeqNum=3;RcvSeqNum=2}. 3.2.3. Control Channel Down To allow bringing a control channel DOWN gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links. When bringing a control channel DOWN administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set. When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the Down state. 3.2.4. Degraded State A consequence of allowing the control channels to be physically diverse from the associated data links is that there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down a link that is carrying user traffic simply because the control channel is no longer available; however, the traffic that is using the data links may no longer be guaranteed the same level of service. Hence the TE link is in a Degraded state. When a TE link is in the Degraded state, routing and signaling SHOULD be notified so that new connections are not accepted and the TE link is advertised with no unreserved resources. 4. Link Property Correlation As part of LMP, a link property correlation exchange is defined using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which Lang et al [Page 10] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 can be either negotiable or non-negotiable (identified by the N flag in the TLV 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. Link property correlation MUST be done before the link is brought up and MAY be done at any time a link is UP and not in the Verification process. The LinkSummary message is used to verify for consistency the TE and data bearing link information on both sides. Link Summary messages are also used to aggregate multiple data links (either ports or component links) into a TE link; exchange, correlate (to determine inconsistencies), or change TE link parameters; and exchange, correlate (to determine inconsistencies), or change Interface Ids (either Port Ids or Component Interface Ids). Each TE link has an identifier (Link_Id) that is assigned at each end of the link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is assigned an identifier (Interface_Id) at each end. These identifiers MUST be the same type at both ends. 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). 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. 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 an allocated data link has a mapping mismatch, it SHOULD be flagged and verified when it becomes free. 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 MUST 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. It is possible that the LinkSummary message could grow quite large due to the number of Data Link TLVs. Since the LinkSummary message is IP encoded, normal IP fragmentation should be used if the resulting PDU exceeds the MTU. Lang et al [Page 11] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 5. Verifying 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 when establishing a TE link, and subsequently, on a periodic basis for all unallocated (free) data links of the TE link. If the link connectivity procedure is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code =1, ôLink Verification Procedure not supported for this TE Linkö. [Question: The following paragraph is a bit confusing to me. What is the problem that it is trying to describe? Thanks :-)] A unique characteristic of all-optical PXCs is that the data-bearing links are transparent when allocated to user traffic. This characteristic of PXCs poses a challenge for validating the connectivity of the data links since shining unmodulated light through a link may not result in received light at the next PXC. This is because there may be terminating (or opaque) elements, such as DWDM equipment, between the PXCs. Therefore, to ensure proper verification of data link connectivity, it is required that until the links are allocated for user traffic, they must be opaque. To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for DXCs (and OEO devices in general) since each data link is terminated and processed electronically before being forwarded to the next OEO device, but that in PXCs (and transparent devices in general) this is an additional requirement. To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link. Once a control channel has been established between the two nodes, data link connectivity can be verified by exchanging Test messages over each of the data links specified in the TE link. It should be noted that all LMP messages except the Test message are exchanged over the control channels and that Hello messages continue to be exchanged over each control channel during the data link verification process. The Test message is sent over the data link that is being verified. Data links are tested in the transmit direction as they are unidirectional, and therefore, it may be Lang et al [Page 12] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 possible for both nodes to (independently) exchange the Test messages simultaneously. To initiate the link verification procedure, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the LINK_ID MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. The BeginVerify message also contains the number of data links that are to be verified; the interval (called VerifyInterval) at which the Test messages will be sent; the encoding scheme and transport mechanisms that are supported; the data rate for Test messages; and, when the data links correspond to fibers, the wavelength identifier over which the Test messages will be transmitted. 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 specifying the desired transport mechanism for the TEST messages. The remote node includes a 32-bit node unique VerifyId in the BeginVerifyAck message. The VerifyId is then used in all corresponding verification messages to differentiate them from different LMP peers and/or parallel Test procedures. When the local node receives a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the VerifyId and the local Interface Id for the associated 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 without receiving a TestStatusSuccess or TestStatusFailure message by sending an EndVerify message. Message correlation is done using message identifiers and the Verify Id; this enables verification of data links, belonging to different link bundles or LMP sessions, in parallel. When the Test message is received, the received Interface Id (used in GMPLS as either a Port/Wavelength label or Component Interface Identifier depending on the configuration) 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), along with the VerifyId received in the Test message. The receipt of a TestStatusSuccess message indicates that the Test message was detected at the remote node and the physical connectivity of the data link has been verified. When the TestStatusSuccess message is received, the local node SHOULD mark Lang et al [Page 13] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the data link as UP and send a TestStatusAck message to the remote node. If, however, the Test message 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 channel 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 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 SHOULD 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 1 shows an example of the link verification scenario that is executed when a link between PXC A and PXC B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows: PXC A sends a BeginVerify message over the control channel ôcö to PXC B indicating it will begin verifying the ports. PXC B receives the BeginVerify message, assigns a VerifyId to the Test procedure, and returns the BeginVerifyAck message over the control channel to PXC A. When PXC A receives the BeginVerifyAck message, it begins transmitting periodic Test messages over the first port (Interface Id=1). When PXC B receives the Test messages, it maps the received Interface Id to its own local Interface Id = 10 and transmits a TestStatusSuccess message over the control channel back to PXC A. The TestStatusSuccess message includes both the local and received Interface Ids for the port as well as the VerifyId. PXC A will send a TestStatusAck message over the control channel back to PXC B indicating it received the TestStatusSuccess message. The process is repeated until all of the ports are verified. At this point, PXC A will send an EndVerify message over the control channel to PXC B to indicate that testing is complete; PXC B will respond by sending an EndVerifyAck message over the control channel back to PXC A. +---------------------+ +---------------------+ + + + + + PXC A +<-------- c --------->+ PXC B + + + + + + + + + + 1 +--------------------->+ 10 + Lang et al [Page 14] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 + + + + + + + + + 2 + /---->+ 11 + + + /----/ + + + + /---/ + + + 3 +----/ + 12 + + + + + + + + + + 4 +--------------------->+ 14 + + + + + +---------------------+ +---------------------+ Figure 1: Example of link connectivity between PXC A and PXC B. 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 channels 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 LSPs. An important implication of using PXCs is that traditional methods that are used to monitor the health of allocated data links in OEO nodes (e.g., DXCs) may no longer be appropriate, since PXCs are transparent to the bit-rate, format, and wavelength. Instead, fault detection is delegated to the physical layer (i.e., loss of light or optical monitoring of the data) instead of layer 2 or layer 3. Recall that a TE link connecting two nodes may consist of a number of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification so that appropriate protection/restoration mechanisms can be initiated. If the failure is subsequently cleared, then a mechanism must be used to notify that the failure is clear and the channel status is OK. 6.1. Fault Detection Fault detection should be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is detecting loss of light (LOL). Other techniques for monitoring optical signals are still being developed and will not be further considered in this document. However, it should be clear that the mechanism used for fault notification in LMP is independent of the mechanism used to detect the failure, but simply relies on the fact that a failure is detected. 6.2. Fault Localization Procedure Lang et al [Page 15] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 [Insert: 6.2.1 Suppression of downstream alarms in pre-G.709 networks] If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message. This message may be used to indicate that a single data channel has failed, multiple data channels have failed, or an entire TE link has failed. [Insert: A ChannelStatus message is sent to the downstream node indicating to the downstream node that the failure has been detected upstream and therefore to suppress the alarm.] [Delete: Failure correlation is done locally at each node upon receipt of the failure notification.] [Insert: 6.2.2 Localization of a fault to a link for protection/restoration] [Delete: As part of the fault localization,] [Insert: To localize a fault to a particular link between adjacent 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 (including ingress side) for the corresponding LSP(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. Once the failure is correlated, the upstream node SHOULD send a ChannelStatus message to the downstream node indicating that the channel is failed or is ok. If a ChannelStatus message is not received by the downstream node, it SHOULD send a ChannelStatusRequest message for the channel in question. Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures. [Insert: Note that the fault localization scheme supported in LMP localizes faults on a link and does not address node failures. Therefore additional mechanisms are needed to detect node failures for end-to-end path protection/restoration.] 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. [Insert: 6.2.2.1 Examples of Fault Localization] [Delete: 6.3. Examples of Fault Localization] In Fig. 2, a sample network is shown where four PXCs are connected in a linear array configuration. The control channels are bi- directional and are labeled with a "c". All LSPs are also bi- directional. In the first example [see Fig. 2(a)], there is a failure on one direction of the bi-drectional LSP. PXC 4 will detect the failure and will send a ChannelStatus message to PXC3 indicating the failure (e.g., LOL) to the corresponding upstream node. When PXC3 receives the ChannelStatus message from PXC4, it returns a ChannelStatusAck message back to PXC4 and correlates the failure locally. When PXC3 correlates the failure and verifies that it is CLEAR, it has localized the failure to the data link between PXC3 and PXC4. Lang et al [Page 16] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 In the second example [see Fig. 2(b)], a single failure (e.g., fiber cut) affects both directions of the bi-directional LSP. PXC2 (PXC3) will detect the failure of the upstream (downstream) direction and send a ChannelStatus message to the upstream (in terms of data flow) node indicating the failure (e.g., LOL). Simultaneously (ignoring propagation delays), PXC1 (PXC4) will detect the failure on the upstream (downstream) direction, and will send a ChannelStatus message to the corresponding upstream (in terms of data flow) node indicating the failure. PXC2 and PXC3 will have localized the two directions of the failure. +-------+ +-------+ +-------+ +-------+ + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + +-- c ---+ +-- c ---+ +-- c ---+ + ----+---\ + + + + + + + <---+---\\--+--------+-------+---\ + + + /--+---> + \--+--------+-------+---\\---+-------+---##---+---//--+---- + + + + \---+-------+--------+---/ + + + + + + + (a) + + ----+-------+--------+---\ + + + + + <---+-------+--------+---\\--+---##---+--\ + + + + + + \--+---##---+--\\ + + + + + + + (b) + \\--+--------+-------+---> + + + + + \--+--------+-------+---- + + + + + + + + +-------+ +-------+ +-------+ +-------+ Figure 2: Two types of data link failures are shown (indicated by ## in the figure): (A) a data link corresponding to the downstream direction of a bi-directional LSP fails, (B) two data links corresponding to both directions of a bi-directional LSP fail. The control channel connecting two PXCs is indicated with a "c". 6.4. Channel 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 Channel Activation Indication. This is particularly useful in networks with transparent nodes where the status of data links may need to be triggered using control channel messages. For example, if a data link is pre-provisioned and the physical link fails after verification and before inserting user traffic, a mechanism is needed to indicate the data link should be active or they may not be able to detect the failure. The ChannelStatus message is used to indicate that a channel or group of channels are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message. When a ChannelStatus message is received, the corresponding data link(s) MUST be put into the Active state. If upon putting them into the Lang et al [Page 17] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Active state, a failure is detected, the ChannelStatus message MUST be transmitted as described in Section 6.2. 6.5. Channel Deactivation Indication The ChannelStatus message may also be used to notify an LMP neighbor that the data link no longer needs to be monitored. This is the counterpart to the Channel Active Indication. When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state. 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. For control channel specific messages, the Message_Id field is within the scope of the CCID. For TE link specific messages, the Message_Id field is within the scope of the LMP adjacency. The Message_Id field of the MESSAGE_ID object contains a generator selected value. This value MUST be greater than any other value previously used. A value is considered to be previously used when it has been sent in an LMP message with the same CCID (for control channel specific messages) or LMP adjacency (for TE Link specific messages). 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. Note that the 32-bit Message_Id value MAY wrap. The following expression may be used to test if a newly received Message_Id value is less than a previously received value: If ((int) old_id û (int) new_id > 0) { New value is less than old value; } 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 is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the Lang et al [Page 18] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 sender for the CCID, then the message SHOULD be treated as being out of order. If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out of order. If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel. All other messages MUST NOT be treated as out-of-order. 8. Graceful Restart This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after an LMP adjacency has failed, or as a result of an LMP component restart. The latter is detected by setting the ôControl Plane Restartö bit in the Common Header of the LMP messages. When the control plane fails due to the loss of the control channel (rather than an LMP component restart), the LMP Link information should be retained. It is possible that a node may be capable of retaining the LMP Link information across an LMP component restart. However, in both cases the status of the data channels MUST be synchronized. We assume the Local Interface Ids remain stable across a control plane restart. After the control plane of a node restarts, the control channel(s) must be re-established using the procedures of Section 3.1. If the control plane failure was the result of an LMP component restart, then the ôControl Plane Restartö flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is UP and the LMP neighbor has detected the restart. Once a control channel is UP, the LMP neighbor 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 Lang et al [Page 19] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 indicating that the parameters are non-negotiable. This provides the local/remote Link Id and Interace Id mappings, the associated Link/Data channel parameters, and indication of which data links are currently allocated to user traffic. When a node receives the LinkSummary message, it checks its local configuration. If the node is capable of retaining the LMP Link information across a restart, it must process the LinkSummary message 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 node was not capable of retaining the LMP Link information across a restart, the node MUST accept the Link/Data channel parameters of the received LinkSummary message and respond with a LinkSummaryAck message. Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels. 9. Addressing All LMP messages are sent directly over IP (except, in some cases, the Test messages are limited by the transport mechanism for in-band messaging). The destination address of the IP packet MUST be the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the received Config message). The manner in which a Config message is addressed may depend on the signaling transport mechanism. When the transport mechanism is a point-to-point link, Config messages SHOULD be sent to the Multicast address (224.0.0.1). Otherwise, Config messages MUST be sent to an IP address on the neighboring node. This is configured at both ends of the control channel. 10. LMP Authentication LMP authentication is optional (included in the Common Header) and, if used, MUST be supported by both sides of the control channel. 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 Lang et al [Page 20] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the data portion depend on the authentication type. Currently, only MD5 is supported for LMP. 11. IANA Considerations LMP defines the following name spaces which require management: - Message Type Name Space. - Class and class type name spaces for LMP objects. The following sections provide guidelines for managing these name spaces. 11.1. Message Type Name Space LMP divides the name space for message types into two ranges. The following are the guidelines for managing these ranges: - Message Types 0 - 49 and 60 - 255: These message types are part of the LMP base protocol. Following the policies outlined in [IANA], message types in this range are allocated through an IETF Consensus action. - Message Types 50 - 59: Message types in this range are reserved for UNI LMP extensions and the allocation in this range is the responsibility of the OIF for supporting UNI signaling. IANA management of this range of the Message Type name space is unnecessary. 11.2. Object Class Name Space LMP divides the name space for object classes into two ranges. The following are the guidelines for managing these ranges: - Classes 0 - 49 and 60 - 127: Object types in this range are part of the LMP base protocol. Following the policies outlined in [IANA], class types in this range are allocated through an IETF Consensus action. Within each class, 256 class types are possible. The allocation of class types for base LMP objects are described in this draft and these are subject to IETF consensus action. - Classes 50 - 59 are reserved for UNI LMP extensions and the allocation in this range is the responsibility of the OIF for supporting UNI signaling. IANA management of this range of the class name space, and the underlying class types, is unnecessary. Lang et al [Page 21] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12. LMP Finite State Machines 12.1. Control Channel FSM The control channel FSM defines the states and logics of operation of an LMP control channel. The description of FSM state transitions and associated actions is given in Section 3. 12.1.1. Control Channel States A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end. Down: This is the initial control channel state. In this state, no attempt is being made to bring the control channel up and no LMP messages are sent. The control channel parameters should be set to the initial values. ConfigSnd: The control channel is in the parameter negotiation state. In this state the node periodically sends a Config message, and is expecting the other side to reply with either a ConfigAck or ConfigNack message. The FSM does not transition into the Active state until the remote side positively acknowledges the parameters. ConfRcv: The control channel is in the parameter negotiation state. In this state, the node is waiting for acceptable configuration parameters from the remote side. Once such parameters are received and acknowledged, the FSM can transition to the Active state. Active: In this state the node periodically sends a Hello message and is waiting to receive a valid Hello message. Once a valid Hello message is received, it can transition to the UP state. Up: The CC is in an operational state. The node receives valid Hello messages and sends Hello messages. GoingDown: A CC may go into this state because of administrative action. While a CC is in this state, the node sets the ControlChannelDown bit in all the messages it sends. 12.1.2. Control Channel Events Operation of the LMP control channel is described in terms of FSM states and events. Control channel Events are generated by the underlying protocols and software modules, as well as by the packet processing routines and FSMs of associated TE links. Every event Lang et al [Page 22] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 has its number and a symbolic name. Description of possible control channel events is given below. 1 : evBringUp: This is an externally triggered event indicating that the control channel negotiation should begin. This event, for example, may be triggered by an operator command, by the successful completion of a control channel bootstrap procedure, or by configuration. Depending on the configuration, this will trigger either 1a) the sending of a Config message, 1b) a period of waiting to receive a Config message from the remote node. 2 : evCCDn: This event is generated when there is indication that the control channel is no longer available. 3 : evConfDone: This event indicates a ConfigAck message has been received, acknowledging the Config parameters. 4 : evConfErr: This event indicates a ConfigNack message has been received, rejecting the Config parameters. 5 : evNewConfOK: New Config message was received from neighbor and positively Acknowledged. 6 : evNewConfErr: New Config message was received from neighbor and rejected with a ConfigNack message. 7 : evContenWin: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The Local node wins the contention. As a result, the received Config message is ignored. 8 : evContenLost: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The Local node loses the contention. 8a) The Config message is positively Acknowledged. 8b) The Config message is negatively Acknowledged. 9 : evAdminDown: The administrator has requested that the control channel is brought down administratively. Hello messages (with ControlChannelDown flag set) SHOULD be sent for HelloDeadInterval seconds or until an LMP message is received over the control channel with the ControlChannelDown flag set. 10: evNbrGoesDn: A packet with ControlChannelDown flag is received from the neighbor. Lang et al [Page 23] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 11: evHelloRcvd: A Hello packet with expected SeqNum has been received. 12: evHoldTimer: The HelloDeadInterval timer has expired indicating that no Hello packet has been received. This moves the control channel back into the Negotiation state, and depending on the local configuration, this will trigger either 12a) the sending of periodic Config messages, 12b) a period of waiting to receive Config messages from the remote node. 13: evSeqNumErr: A Hello with unexpected SeqNum received and discarded. 14: evReconfig: Control channel parameters have been reconfigured and require renegotiation. 15: evConfRet: A retransmission timer has expired and a Config message is resent. 16: evHelloRet: The HelloInterval timer has expired and a Hello packet is sent. 17: evDownTimer: A timer has expired and no messages have been received with the ControlChannelDown flag set. Lang et al [Page 24] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.1.3. Control Channel FSM Description Figure 3 illustrates operation of the control channel FSM in a form of FSM state transition diagram. +--------+ +----------------->| |<--------------+ | +--------->| Down |<----------+ | | |+---------| |<-------+ | | | || +--------+ | | | | || | ^ 2,9,10| 2| 2| | ||1b 1a| | | | | | || v | 2,9,10 | | | | || +--------+ | | | | || +->| |<------+| | | | || 4,7,| |ConfSnd | || | | | || 14,15+--| |<----+ || | | | || +--------+ | || | | | || 3,8a| | | || | | | || +---------+ |8b 14,12a| || | | | || | v | || | | | |+-|------>+--------+ | || | | | | | +->| |-----|-|+ | | | | |6,14| |ConfRcv | | | | | | | | +--| |<--+ | | | | | | | +--------+ | | | | | | | | 5| ^ | | | | | | | +---------+ | | | | | | | | | | | | | | | | | | | v v |6,12b | | | | | | |10 +--------+ | | | | | | +----------| | | | | | | | | +--| Active |---|-+ | | | 10,17| | 5,16| | |-------|---+ | +-------+ 9 | 13 +->| | | | | | Going |<--|----------+--------+ | | | | Down | | 11| ^ | | | +-------+ | | |5 | | | ^ | v | 6,12b| | | |9 |10 +--------+ | |12a,14 | | +----------| |---+ | | | | Up |-------+ | +------------------| |---------------+ +--------+ | ^ | | +---+ 11,13,16 Figure 3: Control Channel FSM Lang et al [Page 25] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Event evCCDn always forces the FSM to the Down State. Events evHoldTimer evReconfig always force the FSM to the Negotiation state (either ConfigSnd or ConfigRcv). 12.2. TE Link FSM The TE Link FSM defines the states and logics of operation of an LMP TE Link. 12.2.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 and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links. 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. At least one primary CC is required to be operational between the nodes sharing the TE link. Degraded: In this state, all primary CCs are down, but the TE link still includes some allocated data links. 12.2.2. TE Link Events Operation of the LMP TE link is described in terms of FSM states and events. TE Link events are generated by the packet processing routines and by the FSMs of the associated primary control channel(s) and the data links. Every event has its number and a symbolic name. Description of possible control channel events is given below. 1 : evDCUp: One or more data channels have been enabled and assigned to the TE Link. 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 : evCCUp: First active control channel goes up. 8 : evCCDown: Last active control channel goes down. Lang et al [Page 26] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 9 : evDCDown: Last data channel of TE Link has been removed. 12.2.3. TE Link FSM Description Figure 4 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram. 3,7,8 +--+ | | | v +--------+ | | +------------>| Down |<---------+ | | | | | +--------+ | | | ^ | | 1| |9 | | v | | | +--------+ | | | |<-+ | | | Init | |3,5,6 |9 | | |--+ 7,8 | 9| +--------+ | | | | | 2,4| | | v | +--------+ 7 +--------+ | | |------>| |----------+ | Deg | | Up | | |<------| | +--------+ 8 +--------+ | ^ | | +--+ 2,3,4,5,6 Figure 4: LMP TE Link FSM In the above FSM, the sub-states that may be implemented when the link verification procedure is used have been omitted. 12.3. Data Link FSM The data link FSM defines the states and logics of operation of a port or component link within an LMP TE link. Operation of a data link is described in terms of FSM states and events. Data-bearing links can either be in the active (transmitting) mode, where Test messages are transmitted from them, or the passive (receiving) mode, where Test messages are received through them. For clarity, Lang et al [Page 27] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 separate FSMs are defined for the active/passive data-bearing links; however, a single set of data link states and events are defined. 12.3.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 link is not æin serviceÆ Test: The data link is being tested. An LMP Test message is periodically sent through the link. PasvTest: The data link is being checked for incoming test messages. Up/Free: The 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. Degraded: The link was in the Up/Allocated state when the last CC associated with data link's TE Link has gone down. The link is put in the Degraded state, since it is still being used for data LSP. 12.3.2. Data Link Events Data bearing link events are generated by the packet processing routines and by the FSMs of the associated control channel and the TE link. Every event has its number and a symbolic name. Description of possible data link events is given below: 1 :evCCUp: CC has gone up. 2 :evCCDown: LMP neighbor connectivity is lost. This indicates the last LMP control channel has failed between neighboring nodes. 3 :evStartTst: This is an external event that triggers the sending of Test messages over the data bearing link. 4 :evStartPsv: This is an external event that triggers the listening for Test messages over the data bearing link. 5 :evTestOK: Link verification was successful and the link can be used for path establishment. (a) This event indicates the Link Verification procedure (see Section 5) was successful for this data link and a TestStatusSuccess Lang et al [Page 28] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 message was received over the control channel. (b) This event indicates the link is ready for path establishment, but the Link Verification procedure was not used. For in-band signaling of the control channel, the control channel establishment may be sufficient to verify the link. 6 :evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel. 7 :evTestFail: Link verification returned negative results. This could be because (a) a TestStatusFailure message was received, or (b) an EndVerifyAck message was received 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) an EndVerify messages has been received 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 message 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:evdcDown: The data channel is no longer available. Lang et al [Page 29] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.3.3. Active Data Link FSM Description Figure 5 illustrates operation of the LMP active data link FSM in a form of FSM state transition diagram. +------+ +------------->| |<-------+ | +--------->| Down | | | | +----| |<-----+ | | | | +------+ | | | | |5b 3| ^ | | | | | | |2,7 | | | | | v | | | | | | +------+ | | | | | | |<-+ | | | | | | Test | |11 | | | | | | |--+ | | | | | +------+ | | | | | 5a| 3^ | | | | | | | | | | | | v | | | | |2,12 | +---------+ | | | | +-->| |14 | | | | | Up/Free |----+ | | +---------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ 2 +---------+ | | |<--------| |13 | | Deg | |Up/Alloc |------+ | |-------->| | +-----+ 1 +---------+ Figure 5: Active LMP Data Link FSM Lang et al [Page 30] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.3.4. Passive Data Link FSM Description Figure 6 illustrates operation of the LMP passive data link FSM in a form of FSM state transition diagram. +------+ +------------->| |<------+ | +---------->| Down | | | | +-----| |<----+ | | | | +------+ | | | | |5b 4| ^ | | | | | | |2,8 | | | | | v | | | | | | +----------+ | | | | | | PasvTest | | | | | | +----------+ | | | | | 6| 4^ | | | | | | | | | | | | v | | | | |2,12 | +---------+ | | | | +--->| Up/Free |14 | | | | | |---+ | | +----------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ +---------+ | | | 2 | |13 | | Deg |<--------|Up/Alloc |-----+ | |-------->| | +-----+ 1 +---------+ Figure 6: Passive LMP Data Link FSM Lang et al [Page 31] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 13. LMP Message Formats All LMP messages are IP encoded (except, in some cases, the Test messages are limited by the transport mechanism for in-band messaging) with protocol number xxx - TBA (to be assigned) by IANA. 13.1. Common Header In addition to the standard IP header, all LMP messages (except, in some cases, the Test messages which are limited by the transport mechanism for in-band messaging) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMP Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 4 bits Protocol version number. This is version 1. Flags: 8 bits. The following values are defined. All other values are reserved. 0x01: ControlChannelDown 0x02: LMP Restart This bit is set to indicate the LMP component has restarted. This flag may be reset to 0 when a Hello message is received with RcvSeqNum equal to the local TxSeqNum. 0x04: LMP-WDM Support When set, indicates that this node is willing and capable of receiving all the messages and objects described in [LMP-DWDM]. 0x08: Authentication When set, this bit indicates that an authentication block is attached at the end of the LMP message. See Sections 7 and 9.3 for more details. Msg Type: 8 bits. The following values are defined. All other values are reserved. 1 = Config Lang et al [Page 32] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 2 = ConfigAck 3 = ConfigNack 4 = Hello 5 = BeginVerify 6 = BeginVerifyAck 7 = BeginVerifyNack 8 = EndVerify 9 = EndVerifyAck 10 = Test 11 = TestStatusSuccess 12 = TestStatusFailure 13 = TestStatusAck 14 = LinkSummary 15 = LinkSummaryAck 16 = LinkSummaryNack 17 = ChannelStatus 18 = ChannelStatusAck 19 = ChannelStatusRequest 20 = ChannelStatusResponse All of the messages are sent over the control channel EXCEPT the Test message, which is sent over the data link that is being tested. LMP Length: 16 bits The total length of this LMP message in bytes, including the common header and any variable-length objects that follow. Checksum: 16 bits The standard IP checksum of the entire contents of the LMP message, starting with the LMP message header. This checksum is Lang et al [Page 33] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before calculating the checksum. 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 TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (TLV Object) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N: 1 bit The N flag indicates if the object is negotiable (N=1) or non- negotiable (N=0). C-Type: 7 bits Class-type 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. Length: 16 bits The Length field indicates the length of the Object in bytes. 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 Lang et al [Page 34] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the LMP packet, but is transmitted in the same IP 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 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. Lang et al [Page 35] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 LMP authentication is performed on a per control channel basis. The 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 a control channel 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 on a control channel that is configured for authentication, it must be authenticated. The value of the Authentication field MUST match the authentication type configured for the control channel (if any). 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. Lang et al [Page 36] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 (1) Locate the receiving control channel's configured key having Key ID equal to that specified in the received LMP authentication block. If the key is not found, 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 control channel data structure, 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 control channel's data structure is set to the sequence number found in the packet's LMP header. 13.4. Parameter Negotiation Messages 13.4.1. Config Message (MsgType = 1) The Config message is used in the control channel negotiation phase of LMP. The contents of the Config message are built using LMP objects. The format of the Config message is as follows: ::= The above transmission order SHOULD be followed. The MESSAGE_ID is within the scope of the CCID. The Config message MUST be periodically transmitted until (1) it receives a ConfigAck or ConfigNack message, (2) a timeout expires and no ConfigAck or ConfigNack message has been received, or (3) it receives a Config message from the remote node and has lost the contention (e.g., the Node Id of the remote node is higher than the Node Id of the local node). Both the retransmission interval and the timeout period are local configuration parameters. 13.4.2. ConfigAck Message (MsgType = 2) The ConfigAck message is used to acknowledge receipt of the Config message and indicate agreement on all parameters. Lang et al [Page 37] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::= The above transmission order SHOULD be followed. The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged. 13.4.3. ConfigNack Message (MsgType = 3) The ConfigNack message is used to acknowledge receipt of the Config message and indicate disagreement on non-negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Message. The format of the ConfigNack message is as follows: ::= [] The above transmission order SHOULD be followed. The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged. The ConfigNack uses CONFIG_ERROR_ C-Type 1. It is possible that multiple parameters may be invalid in the Config message. As such, multiple bits may be set in the ERROR_CODE. If a negotiable CONFIG object is included in the ConfigNack message, it MUST include acceptable values for the parameters. The ERROR_CODE MUST indicate ôRenegotiate CONFIG parameter.ö If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message. The ERROR_CODE MUST indicate ôUnacceptable non- negotiable CONFIG parameter.ö If the ConfigNack message is received and only includes CONFIG objects that are negotiable, then a new Config message SHOULD be sent. The values in the CONFIG object of the new Config message SHOULD take into account the acceptable values included in the ConfigNack message. 13.5. Hello Message (MsgType = 4) The format of the Hello message is as follows: Lang et al [Page 38] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::= The above transmission order SHOULD be followed. The Hello message MUST be periodically transmitted at least once every HelloInterval msec. If no Hello message is received within the HelloDeadInterval, the control channel is assumed to have failed. 13.6. Link Verification 13.6.1. BeginVerify Message (MsgType = 5) The BeginVerify message is sent over the control channel and is used to initiate the link verification process. The format is as follows: ::= [] The above transmission order SHOULD be followed. To limit the scope of Link Verification to a particular TE Link, the LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. The REMOTE_LINK_ID may be included if the local/remote Link Id mapping is known. The REMOTE_LINK_ID MUST be non-zero if included. 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.6.2. BeginVerifyAck Message (MsgType = 6) When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted. ::= [] The above transmission order SHOULD be followed. Lang et al [Page 39] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The LOCAL_LINK_ID may be included if the local/remote Link Id mapping is known or learned through the BeginVerify message. The LOCAL_LINK_ID MUST be non-zero if included. 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.6.3. BeginVerifyNack Message (MsgType = 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. ::= 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 remote configuration of the TE Link Id is not supported and the REMOTE_LINK_ID object (included in the BeginVerify message) does not match any configured values, the ERROR_CODE MUST indicate ôTE Link Id configuration errorö. The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. 13.6.4. EndVerify Message (MsgType = 8) Lang et al [Page 40] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The EndVerify message is sent over the control channel and is used to terminate the link verification process. The EndVerify message may be sent at any time the initiating node desires to end the Verify procedure. The format is as follows: ::= 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.6.5. EndVerifyAck Message (MsgType =9) The EndVerifyAck message is sent over the control channel and is used to acknowledge the termination of the link verification process. The format is as follows: ::= 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.6.6. Test Message (MsgType = 10) The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated in the Verify Transport Mechanism description for the BEGIN_VERIFY class, this is transmitted as an IP packet with payload format as follows: ::= The above transmission order SHOULD be followed. Note that this message is sent over a data link and NOT over the control channel. The transport mechanism for the Test message is negotiated using Verify Transport Mechanism field of the BeginVerify Object and the Verify Transport Response field of the BeginVerifyAck Object (see Sections 14.9 and 14.10). The local (transmitting) node sends a given Test message periodically (at least once every VerifyInterval ms) on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node or (2) all active control channels between the two nodes have failed. The remote node will send a given TestStatus message periodically over the control Lang et al [Page 41] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 channel until it receives either a correlating TestStatusAck message or an EndVerify message is received over the control channel. 13.6.7. TestStatusSuccess Message (MsgType = 11) The TestStatusSuccess message is transmitted over the control channel and is used to transmit the mapping between the local Interface Id and the Interface Id that was received in the Test message. ::= The above transmission order SHOULD be followed. The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged. 13.6.8. TestStatusFailure Message (MsgType = 12) The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received. ::= The above transmission order SHOULD be followed. 13.6.9. TestStatusAck Message (MsgType = 13) The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages. ::= 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.7. Link Summary Messages 13.7.1. LinkSummary Message (MsgType = 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: Lang et al [Page 42] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::= [...] 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.7.2. LinkSummaryAck Message (MsgType = 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. ::= The above transmission order SHOULD be followed. 13.7.3. LinkSummaryNack Message (MsgType = 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. ::= [...] The above transmission order SHOULD be followed. The LinkSummary TLVs MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes LinkSummary TLVs for non-negotiable parameters, they MUST be copied from the LinkSummary TLVs 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 3. 13.8. Fault Management Messages 13.8.1. ChannelStatus Message (MsgType = 17) Lang et al [Page 43] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The ChannelStatus message is sent over the control channel 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: ::= 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.8.2. ChannelStatusAck Message (MsgType = 18) The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus Message. The format is as follows: ::= 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.8.3. ChannelStatusRequest Message (MsgType = 19) The ChannelStatusRequest message is sent over the control channel 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: ::= [] 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.8.4. ChannelStatusResponse Message (MsgType = 20) The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest Message and notify the LMP neighbor of the status of the data channel(s). The format is as follows: ::= Lang et al [Page 44] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged. 14. LMP Object Definitions 14.1. CCID (Control Channel ID) Classes 14.1.1. LOCAL_CCID Class Class = 1. o C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC_Id: 32 bits This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message. This Object is non-negotiable. 14.1.2. REMOTE_CCID Class Class = 2. o C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC_Id: 32 bits This identifies the remote nodeÆs CC_Id and MUST be non-zero. This Object is non-negotiable. 14.2. NODE_ID Classes 14.2.1. LOCAL_NODE_ID Class Class = 3. Lang et al [Page 45] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identities the node that originated the LMP packet. This Object is non-negotiable. 14.2.2. REMOTE _NODE_ID Class Class = 4. o C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identities the remote node. This Object is non-negotiable. 14.3. LINK _ID Classes 14.3.1. LOCAL_LINK_ID Class Class = 5 o IPv4, C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 46] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 | | + + | | + Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Reserved for OIF, C-Type = 4 Link_Id: This identifies the senderÆs Link associated with the message. This Object is non-negotiable. 14.3.2. REMOTE _LINK_ID Class Class = 6 o IPv4, C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 47] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o Unnumbered, C-Type = 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Reserved for OIF, C-Type = 4 Link_Id: This identifies the remote nodeÆs Link Id and MUST be non-zero. This Object is non-negotiable. 14.4. INTERFACE_ID Classes 14.4.1. LOCAL_INTERFACE_ID Class Class = 7 o IPv4, C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 48] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Interface_Id: This identifies the data link (either port or component link). The Interface_Id MUST be node-wide unique and non-zero. This Object is non-negotiable. 14.4.2. REMOTE _INTERFACE_ID Class Class = 8. o IPv4, C-Type = 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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. This Object is non-negotiable. 14.5. MESSAGE_ID Class Class = 9. Lang et al [Page 49] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o MessageId, C-Type = 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 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.6. MESSAGE_ID_ACK Class Class = 10. o MessageIdAck, C-Type = 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.7. CONFIG Class Class = 11. o HelloConfig, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | HelloDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloInterval: 16 bits. Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms). Lang et al [Page 50] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 HelloDeadInterval: 16 bits. If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. 14.8. HELLO Class Class = 12 o Type 1 Hello, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RcvSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TxSeqNum: 32 bits This is the current sequence number for this Hello message. This sequence number will be incremented when the sequence number is reflected in the RcvSeqNum of a Hello packet that is received over the control channel. TxSeqNum=0 is not allowed. TxSeqNum=1 is reserved to indicate that the control channel has booted or restarted. RcvSeqNum: 32 bits This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=0 is reserved to indicate that a Hello message has not yet been received. This Object is non-negotiable. 14.9. BEGIN_VERIFY Class Class = 13. o C-Type = 1 Lang et al [Page 51] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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 | VerifyInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Data Links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncType | (Reserved) | Verify Transport Mechanism | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 16 bits The following flags are defined: 0x01 Verify all Links If this bit is set, the verification process checks all unallocated links; else it only verifies new ports or component links that are to be added to this TE link. 0x02 Data Link Type If set, the data links to be verified are ports, otherwise they are component links VerifyInterval: 16 bits This is the interval between successive Test messages and is measured in milliseconds (ms). Number of Data Links: 32 bits This is the number of data links that will be verified. EncType: 8 bits This is the encoding type of the data link. The defined EncType values are consistent with the Link Encoding Type values of [GMPLSSIG] Verify Transport Mechanism: 16 bits This defines the transport mechanism for the Test Messages. The scope of this bit mask is restricted to each link encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting LMP test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message. For SONET/SDH Encoding Type, the following flags are defined: Lang et al [Page 52] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 0x01 J0-16: Capable of transmitting Test messages using J0 overhead bytes with string length of 16 bytes (with CRC-7). Note that Due to the byte limitation, a special Test message is defined as follows: The Test message is a 15-byte message, where the last 7 bits of each byte are usable. Due to the byte limitation, the LMP Header is not included. The first usable 32 bits MUST be the VerifyId that was received in the VERIFY_ID Object of the BeginVerifyAck message. The second usable 32 bits MUST be the Interface_Id. The next usable 8 bits are used to determine the address type of the Interface_Id. For IPv4, this value is 1. For unnumbered, this value is 3. The remaining bits are Reserved. Note that this Test Message format is only valid when the Interface_Id is either IPv4 or unnumbered. 0x02 DCCS: Capable of transmitting Test messages using the DCC Section Overhead bytes with an HDLC framing format. 0x04 DCCL: Capable of transmitting Test messges using the DCC Line Overhead bytes with an HDLC framing format. 0x08 Payload: Capable of transmitting Test messages in the payload using Packet over SONET framing using the encoding type specified in the EncType field. For GigE Encoding Type, the following flags are defined: TBD For 10GigE Encoding Type, the following flags are defined: TBD BitRate: 32 bits This is the bit rate of the data link over which the Test messages will be transmitted and is expressed in bytes per second. Wavelength: 32 bits When a data link is assigned to a port or component link that is capable of transmitting multiple wavelengths (e.g., a fiber or waveband-capable port), it is essential to know which wavelength the test messages will be transmitted over. This value corresponds to the wavelength at which the Test messages will be transmitted over and has local significance. If there is no ambiguity as to the wavelength over which the message will be sent, then this value SHOULD be set to 0. 14.10. BEGIN_VERIFY_ACK Class Class = 14. Lang et al [Page 53] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o C-Type = 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 | Verify_Transport_Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Verify_Transport_Response: 16 bits The recipient of the BeginVerify message (and the future recipient of the TEST messages) chooses the transport mechanism from the various types that are offered by the transmitter of the Test messages. One and only one bit MUST be set in the verification transport response. This Object is non-negotiable. 14.11. VERIFY_ID Class Class = 15. o C-Type = 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.12. TE_LINK Class Class = 16. o IPv4, C-Type = 1 0 1 2 3 Lang et al [Page 54] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined. All other values are reserved. 0x01 Fault Management Supported. 0x02 Link Verification Supported. Lang et al [Page 55] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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.13. DATA_LINK Class Class = 17. o IPv4, C-Type = 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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 56] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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. 0x01 Interface Type: If set, the data link is a port, otherwise it is a component link. 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. Local_Interface_Id: 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 consist of a series of variable-length data items called subobjects. The subobjects are defined in section 14.13.1 below. Lang et al [Page 57] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 A DATA_LINK object may contain more than one subobject. If more than one subobject of the same Type appears, only the first subobject of that Type is meaningful. Subsequent subobjects of the same Type MAY be ignored. 14.13.1. Data Link Subobjects 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. Currently defined values are: 1 Interface Switching Capability 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.13.1.1. Subobject 1: Interface Switching Capability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Switching Cap | EncType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Capability: 8 bits This is used to identify the local Interface Switching Capability of the TE link. See [LSP-HIER]. EncType: 8 bits This is the encoding type of the data link. The defined EncType values are consistent with the Link Encoding Type values of [GMPLSSIG]. Minimum Reservable Bandwidth: 32 bits Lang et al [Page 58] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 This is measured in bytes per second and represented in IEEE floating point format. Maximum Reservable Bandwidth: 32 bits This is measured in bytes per second and represented in IEEE floating point format. If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value. 14.14. CHANNEL_STATUS Class Class = 18 o IPv4, C-Type = 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | Lang et al [Page 59] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type = 3 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 Channel is allocated to user traffic and the data link should be actively monitored. Channel_Status: 32 bits This indicates the status condition of a data channel. The following values are defined. All other values are reserved. 1 Signal Okay (OK): Channel 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. Lang et al [Page 60] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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.15. CHANNEL_STATUS_REQUEST Class Class = 19 o IPv4, C-Type = 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 4 + 4N in bytes, where N is the number of Interface Ids. o IPv6, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | Lang et al [Page 61] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Object contains one or more Interface Ids. The Length of this object is 4 + 16N in bytes, where N is the number of Interface Ids. o Unnumbered, C-Type = 3 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 4 + 4N in bytes, where N is the number of Interface Ids. This Object is non-negotiable. 14.16. ERROR_CODE Class Class = 20. o CONFIG_ERROR, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. Lang et al [Page 62] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o BEGIN_VERIFY_ERROR, C-Type = 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 = Link Verification Procedure not supported for this TE Link. 0x02 = Unwilling to verify at this time 0x04 = Unsupported verification transport mechanism 0x08 = 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. o LINK_SUMMARY_ERROR, C-Type = 3 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 = Unacceptable non-negotiable LINK_SUMMARY parameters 0x02 = Renegotiate LINK_SUMMARY parameters 0x04 = Bad Received Remote_Link_Id All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. 15. Security Considerations LMP exchanges may be authenticated using the Cryptographic authentication option. MD5 is currently the only message digest algorithm specified. Lang et al [Page 63] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ôLink Management Protocol (LMP) for WDM Transmission Systems,ö Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in progress), March 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. [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. Lang et al [Page 64] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 17. Acknowledgments The authors would like to thank Ayan Banerjee, George Swallow, Andre Fredette, Adrian Farrel, and Vinay Ravuri for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability. 18. Author's Addresses Jonathan P. Lang Krishna Mitra Calient Networks Calient Networks 25 Castilian Drive 5853 Rue Ferrari Goleta, CA 93117 San Jose, CA 95138 Email: jplang@calient.net email: krishna@calient.net John Drake Kireeti Kompella Calient Networks Juniper Networks, Inc. 5853 Rue Ferrari 385 Ravendale Drive San Jose, CA 95138 Mountain View, CA 94043 email: jdrake@calient.net email: kireeti@juniper.net Yakov Rekhter Lou Berger Juniper Networks, Inc. Movaz Networks 385 Ravendale Drive email: lberger@movaz.com Mountain View, CA 94043 email: yakov@juniper.net Debanjan Saha Debashis Basak Tellium Optical Systems Accelight Networks 2 Crescent Place 70 Abele Road, Suite 1201 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 email:dsaha@tellium.com email: dbasak@accelight.com Hal Sandick Alex Zinin Nortel Networks Nexsi Systems email: hsandick@nortelnetworks.com 1959 Concourse Drive San Jose, CA 95131 email: azinin@nexsi.com Bala Rajagopalan Tellium Optical Systems 2 Crescent Place Oceanport, NJ 07757-0901 email: braja@tellium.com Lang et al [Page 65] --------------080401080800090005080500-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 07:02:23 -0800 Cc: ccamp , q11/15 , "t1x1.5" , "'bwijnen@lucent.com'" , "'sob@harvard.edu'" , "'sjtrowbridge@lucent.com'" , "'Kireeti Kompella'" Message-ID: <3C0257E9.9AC36932@lucent.com> Date: Mon, 26 Nov 2001 15:55:37 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: ccamp , q11/15 , "t1x1.5" , "'bwijnen@lucent.com'" , "'sob@harvard.edu'" , "'sjtrowbridge@lucent.com'" , "'Kireeti Kompella'" Subject: Re: draft-bellato-ccamp-g709-framework-01.txt Content-Type: multipart/mixed; boundary="------------9033EAE5F44A0863CA7F5FAC" This is a multi-part message in MIME format. --------------9033EAE5F44A0863CA7F5FAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, "Mannie, Eric" wrote: > > Hello Maarten, > > > I had a look at draft-bellato-ccamp-g709-framework-01.txt and must > conclude that > >this document redescribes G.709. > > > As such we should not progress draft-bellato-ccamp-g709-framework-01.txt. > > This draft started some time ago (and version 01 is not published yet). I > saw private e-mail exchanges between the co-authors in which you are > involved. Do I have to understand that there are new stuffs that you don't > like ? Did the scope of the draft changed ? As I indicated in my follow up email I should have referred to the generic "G.709 Framework" item, rather than the latest (unpublished) draft. > > Could you tell us why you are co-author of this draft ? I don't know. My name was put onto the document, most likely as I had commented on it before. I don't know what the rules are in the IETF to be co-author. I was told that as co-author you can influence a document as you will be part of a closed editor's group who prepares the next draft. As such I hadn't taken any action to get my name removed, despite I did not agree with e.g. proposed extensions to G.709. I.e. similar situation exists with respect to the sonet-sdh document, where I have never agreed with the SUKLM numbering or AUG-X issues. > > And why such a statement now ? Driven by the same things as Juergen described in his email this afternoon; i.e. the new I-Ds that came out last week, my question to ccamp, Randy's answer, my recognition of the wider implication of that answer, and then the normal drive for action (don't wait; learned something new, then share it). Choice of words on Friday's is not always the best (try to do too many things before the weekend kind of syndrome). > > >Reading this document and other contributions redescribing aspects of > SDH/SONET > >caused the following titles to appear in to my mind :-) > > "OTN for dummies" or "OTN explained" by the IETF > > "SDH/SONET for dummies" or "SDH/SONET explained" by the IETF > > I'll try to interpret these previous sentences in a non negative way for all > the people involved in SONET, SDH and OTN at the IETF (and I am not the guy > that was the most surprised - I am used to it now :-). Thanks. Concerning the titles, I tried to be very careful stating that they appeared in MY mind when I looked at the recent I-Ds. I.e. I tried to stay away from generalizing. Underlying this all is my understanding/assumption that it is not within the scope of IETF to write documents explaining other standards. > Quoting a guy called Maarten Vissers: > > "I had hoped that the time in which IETF characters are looking for > confrontations with ITU-T characters was left behind." I wasn't looking for confrontation when I wrote the email... just a follow up of a statement/direction I consider to come from a top IETF person. Regards, Maarten > > I hope that the character that some of us are playing are not coming from > popular books. This issue reminds me a novel of Stevenson published in 1886: > "The Strange Case of Dr Jekyll and Mister Hide". > > Kind regards, > > Eric > > Eric Mannie > > (or Dr. Lanyon should I say :-) > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, November 23, 2001 11:26 AM > To: ccamp; q11/15; t1x1.5 > Subject: draft-bellato-ccamp-g709-framework-01.txt > > All, > > I had a look at draft-bellato-ccamp-g709-framework-01.txt and must conclude > that > this document redescribes G.709. > > Reading this document and other contributions redescribing aspects of > SDH/SONET > caused the following titles to appear in to my mind :-) > "OTN for dummies" or "OTN explained" by the IETF > "SDH/SONET for dummies" or "SDH/SONET explained" by the IETF > > As indicated earlier this week, IETF should not redescribe SDH/SONET or OTN. > ITU-T has a complete set of specifications, which are available to anybody. > > Those who contribute to the GMPLS work related to the OTN should base their > work > on the ITU-T OTN specifications. Necessary references from the GMPLS OTN > specifications are to be made to the ITU-T OTN recommendations and not to > any > interpretation of those recommendations. > > FYI, the list of OTN related recommendations is: > > G.872 (version 2) > G.709 + G.709 ammendment 1 > G.7041 > G.7042 > G.798 > G.806 > G.7710 > G.874 > G.874.1 > G.7712 > G.8251 > G.959.1 > G.664 > > Furthermore work is ongoing on the following draft recommendations: > G.optperf > G.875 > G.gps > G.otnprot > M.24otn > > As such we should not progress draft-bellato-ccamp-g709-framework-01.txt. > > Regards, > > Maarten --------------9033EAE5F44A0863CA7F5FAC 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 --------------9033EAE5F44A0863CA7F5FAC-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 06:07:16 -0800 Message-ID: <3C024CF2.8040904@lucent.com> Date: Mon, 26 Nov 2001 09:08:50 -0500 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: Jonathan Lang CC: Sudheer Dharanikota , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan, Actually the OTN involves more recommendations than G.709 (e.g., G.872, G.798, etc.). That is why I didn't specifically call out G.709. However, it seems that more people are familiar with the term G.709 rather then standard OTN and therefore I will make the changes you suggest. I think this should be okay, especially since G.709 itself refers to other recommendations and therefore by pointing directly to G.709, implicitely points to other recommendations as well. Thanks Carmine Jonathan Lang wrote: >Carmine, > To be precise, when you refer to "standard OTN" and "non-standard DWDM", >are you referring to G.709? If so, I would suggest you do a global >search-replace of your proposed text to read "G.709" and "non-G.709", >respectively. > >Thanks, >Jonathan > >-----Original Message----- >From: Carmine Daloia [mailto:daloia@lucent.com] >Sent: Wednesday, November 21, 2001 9:51 AM >To: Sudheer Dharanikota >Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org >Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... > > >Hi Sudheer, > >My last comment wasn't meant to be an argument :-) > >Maybe if I propose some text specific to the suppression of downstream >alarms that would help clarify the scope of applicability. The text would >state that when client devices (e.g., SONET/SDH cross-connects, IP routers) >are interconnected via a standard OTN network then the suppression of >downstream alarms is already handled in the transport/user plane via the OTN >overhead (both in-band via the digitial overhead as well as out-of-band via >non-associated overhead). Also the text would address PXCs within a standard >OTN network. In this case, again the suppression of downstream alarms is >handled via the OTN overhead. > >The implementation proposed in LMP for suppression of downstream alarms >applies to PXCs or client devices (e.g, SONET/SDH cross-connects or IP >routers) interconnected via a non-standard DWDM network. In this case, it is >assummed that the non-standard DWDM network does not provide the neccesary >overhead within the transport/user plane to suppress alarms on PXCs and >client devices and therefore LMP provides a mechanism to carry such alarm >suppression messages in the control plane. > >I'll take a crack at specific text so that the group can review it. Does >this sound like something that would be helpful. > >Thanks >Carmine > >Sudheer Dharanikota wrote: > >Hi again: >Carmine Daloia wrote: > >I am not assuming inband communication is supported between the >cross-connect and the line system. That is why I said that when the PXC and >line system are from different vendors such OAM signals would have to be >carried over a separate channel (e.g., LMP-WDM control channel). However, I >don't see why such signals would have to be carried over an LMP control >channel between cross-connects. Also, my point about performance was that we >would have to see if the LMP control channel would meet the performance >requirements for such OAM signals. It very well might. If not, a >bit-oriented signaling interface may be needed between the PXC and the line >system. > >Ok Let us address the issues separately... >1. Communication between Line System and Cross connect >Defining a bit-oriented (physical) interface and protocol is not really the >task (in my opinion) >of IETF. >I am not sure if are creating a problem to solve with the alarm suppression. > >Let me explain... >Let us assume we can correlate and suppress the alarms between the Line >systems >and corss connects. Then we donot need an elaborate bit-oriented protocol. >This >has an assumption that we are talking about not hundereds of failures but a >couple of >failures (for example fiber cuts). >As I said, I am not suggesting that we need a bit-oriented protocol. My main >point was that for the communication between the line-system and >cross-connect, we need to understand the applications that require such >communication and the requirements for those applications. It may be that >the requirements can be met by carrying messages over IP (e.g., LMP-WDM). >This is an issue for LMP-WDM and not for LMP (i.e., running between >cross-connects) anyway. So for the sake of focusing some of this discussion >let me suggest we focus on communication between the adjacent cross-connects >and we can even assume that LMP-WDM handles the Cross-connect and Line >System communication. >Agreed we need to focus on LMP not DWDM-LMP :-) But... >the intention of the OLI document was to underdstand the requirements. >I thought most of us vouch for these requirements. Let us put the >requirements in the back-burner. If it is bit-oriented protocol it >does not interest most of us :-) > >2. Communication between cross connects >THis is needed to localize a fault which in turn can be used as a trigger >for local >restoration. >Localize a fault for what reason? To understand if the fault is within the >protection/restoration domain. For span protection/restoration the >end-points of the domain coincide with the LMP end-points. For end-to-end >protection/restoration the end-points do not coincide with the LMP >end-points. Because the end-points of a protection/restoration domain do not >always coincide with the end-points of a LMP protocol, I don't think it is a >good idea to lump messages related to protection/restoration in LMP. It will >result in similar messages having to be defined in other protocols and >therefore a duplication of work and processing. > >Again... span protection can be performed easily with the current >mechanisms supported by LMP in out-of-band communication >scenarios. >In case of overlaping restoration scenarios such as span and end-to-end >it is required to have a localization + an attempt to recover + (if this >fails) >report to end-to-end entities for recovery. THis also vouch for the >inclusion of such mechanisms in LMP. > >Will this duplication cause major issues in a network. I doubt it... but it >just doesn't seem right from an architecture perspective. > >Well I guess I cannot buy this argument :-) >Cheers, >sudheer > > >- sudheer > >Thanks >Carmine >Sudheer Dharanikota wrote: >Carmine... >Again can you suggest a way to communicate such signals >between line systems and cross connects when inband >communication is not supported between these two systems? >Cheers, >sudheer >Carmine Daloia wrote: >Jonathan, >Forgot to mention, that the performance aspects of carrying OAM type signals >over an IP based control channel in LMP-WDM would have to be analyzed. It is >possible that the IP Control Channel will not provide fast enough transfer >to actually suppress downstream alarms, however that needs to be analyzed as >part of LMP-WDM. >Thanks >Carmine >Carmine Daloia wrote: >Jonathan, >The LMP-WDM document specifies the signaling between the Cross-connect and >OLS, assuming they are from different vendors. If they are from different >vendors, then a standard interface is needed to exchange some information. >One type of information that would need to be exchanged is some OAM signals. >Maarten described some of these signals in his VBI document. However, I >don't see why OAM signals would have to be exchanged directly between the >cross-connects themselves via LMP. >Let's look at the following network. >OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical >Amplifiers. >Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses >alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be >carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward >the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB >will then forward these FDI signals over its OSC and then over the LMP-WDM >control channel to OXC3..... etc... >Note that OXC2 does not need to directly forward these FDI signals to OXC3. >So it is possible, that in LMP-WDM, we may need to define messages >corresponding to FDI signals to suppress downstream alarms, however we don't >need to define such messages in LMP. >Thanks >Carmine >Jonathan Lang wrote: >Carmine, Please see inline.Thanks,Jonathan >-----Original Message-----From: Carmine Daloia >[mailto:daloia@lucent.com]Sent: Monday, November 19, 2001 6:44 AMTo: >ccamp@ops.ietf.orgCc: tsg15q11@itu.int; t1x15@t1.orgSubject: LMP: >Suppression of Downstream Alarms...Hi all,As I read through Section 6 "Fault >Management", one issue that it seems to be addressing is "Suppression of >Downstream Alarms".In section 6.2, it states that "If data links fail >between two PXCs, the power monitoring system in all of the downstream nodes >may detect LOL and indicate a failure. To avoid multiple alarms stemming >from the same failure, LMP > provides a failure notification through the ChannelStatus message...".I >agree that the suppression of downstream alarms is an important issue. >great! >If we look at standard networks (both SONET/SDH and OTN), this capability is >already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN >handles suppression of alarms in both all-optical networks as well as opaque >networks. I don't think we need to burden the control plane with such >functions when the transport plane handles this in standard networks. In >fact the transport plane handles suppression of alarms on all equipment in >the network (not just cross-connects).If we look at a pre-OTN >("non-standard") scenario consisting of Cross-connects, Optical Line >Systems, and Optical Amplifiers supporting a DWDM networked solution, we can >analyze two scenarios. One scenario is an opaque network (e.g., the OLS >supports 3R). In this scenario, the downstream Cross-connects would not >detect LOL upon faults occurring upstr >eam. The 3R points on the OLS Line Systems would insert some type of signal >downstream. Therefore the mechanism described in Section 6.2 does not apply. >Another scenario is an all-optical pre-OTN network. Note that other >equipment besides Cross-connects (e.g., Optical Amplifiers) in an >all-optical network may alarm due to upstream faults. These alarms also need >to be suppressed. LMP seems to only address the suppression of downstream >alarms on cross-connects without taking into consideration the network that >sits between the cross-connects. Is LMP also expected to have to be >processed on Optical Amplifiers? This seems to be undesirable, especially >given all the various applications that seem to be included into the LMP >protocol that would not have anything to do with Optical Amplifieris. >For interaction between cross-connects and Line Systems, please see >OLIRequirements >document(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) >andcorresponding LMP-WDM protocol document (new version to be >uploadedtomorrow, but old version can be found >athttp://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >Any other views?Carmine > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 05:37:29 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' Cc: ccamp , q11/15 , "t1x1.5" , "'bwijnen@lucent.com'" , "'sob@harvard.edu'" , "'sjtrowbridge@lucent.com'" , 'Kireeti Kompella' Subject: RE: draft-bellato-ccamp-g709-framework-01.txt Date: Mon, 26 Nov 2001 14:25:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, > I had a look at draft-bellato-ccamp-g709-framework-01.txt and must conclude that >this document redescribes G.709. > As such we should not progress draft-bellato-ccamp-g709-framework-01.txt. This draft started some time ago (and version 01 is not published yet). I saw private e-mail exchanges between the co-authors in which you are involved. Do I have to understand that there are new stuffs that you don't like ? Did the scope of the draft changed ? Could you tell us why you are co-author of this draft ? And why such a statement now ? >Reading this document and other contributions redescribing aspects of SDH/SONET >caused the following titles to appear in to my mind :-) > "OTN for dummies" or "OTN explained" by the IETF > "SDH/SONET for dummies" or "SDH/SONET explained" by the IETF I'll try to interpret these previous sentences in a non negative way for all the people involved in SONET, SDH and OTN at the IETF (and I am not the guy that was the most surprised - I am used to it now :-). Quoting a guy called Maarten Vissers: "I had hoped that the time in which IETF characters are looking for confrontations with ITU-T characters was left behind." I hope that the character that some of us are playing are not coming from popular books. This issue reminds me a novel of Stevenson published in 1886: "The Strange Case of Dr Jekyll and Mister Hide". Kind regards, Eric Eric Mannie (or Dr. Lanyon should I say :-) -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 23, 2001 11:26 AM To: ccamp; q11/15; t1x1.5 Subject: draft-bellato-ccamp-g709-framework-01.txt All, I had a look at draft-bellato-ccamp-g709-framework-01.txt and must conclude that this document redescribes G.709. Reading this document and other contributions redescribing aspects of SDH/SONET caused the following titles to appear in to my mind :-) "OTN for dummies" or "OTN explained" by the IETF "SDH/SONET for dummies" or "SDH/SONET explained" by the IETF As indicated earlier this week, IETF should not redescribe SDH/SONET or OTN. ITU-T has a complete set of specifications, which are available to anybody. Those who contribute to the GMPLS work related to the OTN should base their work on the ITU-T OTN specifications. Necessary references from the GMPLS OTN specifications are to be made to the ITU-T OTN recommendations and not to any interpretation of those recommendations. FYI, the list of OTN related recommendations is: G.872 (version 2) G.709 + G.709 ammendment 1 G.7041 G.7042 G.798 G.806 G.7710 G.874 G.874.1 G.7712 G.8251 G.959.1 G.664 Furthermore work is ongoing on the following draft recommendations: G.optperf G.875 G.gps G.otnprot M.24otn As such we should not progress draft-bellato-ccamp-g709-framework-01.txt. Regards, Maarten Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Nov 2001 04:19:46 -0800 To: ccamp , q11/15 , "t1x1.5" Message-ID: <3C023290.E0E1836A@lucent.com> Date: Mon, 26 Nov 2001 13:16:16 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: ccamp , q11/15 , "t1x1.5" Subject: Re: draft-bellato-ccamp-g709-framework-01.txt Content-Type: multipart/mixed; boundary="------------B0EC171901AA9B843E6B9162" This is a multi-part message in MIME format. --------------B0EC171901AA9B843E6B9162 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, It seems that I have caused an upset with my last email on G.709 Framework document. Sorry for that. I am told that "OTN for dummies" has been negatively interpreted by at least one of you. I used this phrase "for dummies" in reference to a series of popular books introducing all kind of subjects in a readable format to none experts. I have used such books myself in the past. I have a positive association with such books and their authors. At the moment the "for dummies" thought came up in my mind, I noticed that the G.709 framework document has strong similarities (explain OTN to non-experts developing GMPLS for OTN). Combining this then with the reactions on earlier questions on redescriptions of SDH within IETF documents (not to be done), I could only conclude that this applies as well to OTN. Then I made a mistake... I thought that version 01 of the document was aleady published... it isn't of course. As the version isn't relevant to the issue I was addressing, I should have referred to "G.709 Framework" in general instead. Regards, Maarten --------------B0EC171901AA9B843E6B9162 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 --------------B0EC171901AA9B843E6B9162-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Nov 2001 04:08:45 -0800 Message-ID: <3BFE3CC9.C5B2E290@npd.hcltech.com> Date: Fri, 23 Nov 2001 17:40:49 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: "ccamp@ops.ietf.org" Subject: LMP doubts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Data links are tested in the transmit direction as they are unidirectional, and therefore, it may be possible for both nodes to (independently) exchange the Test messages simultaneously." If so we need to maintain two FSM ( Active & Passive ) for a single data channel or what. But it is given "Data-bearing links can either be in the active (transmitting) mode, where Test messages are transmitted from them, or the passive (receiving) mode, where Test messages are received through them. For clarity, separate FSMs are defined for the active/passive data-bearing links; however, a single set of data link states and events are defined." So when a node sends a Testmessage will it be possible for the same data link to receive a Test message.( since simultaneous testing is possible - as given ). If so what will be the action for this event. Should it is pointing to the Pasv DataLink FSM. Does it mean that we need to have two FSM's for a single data Link. Thanks, Ramesh Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Nov 2001 02:26:59 -0800 To: ccamp , q11/15 , "t1x1.5" Message-ID: <3BFE243A.D88F8EAF@lucent.com> Date: Fri, 23 Nov 2001 11:26:02 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: ccamp , q11/15 , "t1x1.5" Subject: draft-bellato-ccamp-g709-framework-01.txt Content-Type: multipart/mixed; boundary="------------18DEEAFAEA70A85612240B46" This is a multi-part message in MIME format. --------------18DEEAFAEA70A85612240B46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I had a look at draft-bellato-ccamp-g709-framework-01.txt and must conclude that this document redescribes G.709. Reading this document and other contributions redescribing aspects of SDH/SONET caused the following titles to appear in to my mind :-) "OTN for dummies" or "OTN explained" by the IETF "SDH/SONET for dummies" or "SDH/SONET explained" by the IETF As indicated earlier this week, IETF should not redescribe SDH/SONET or OTN. ITU-T has a complete set of specifications, which are available to anybody. Those who contribute to the GMPLS work related to the OTN should base their work on the ITU-T OTN specifications. Necessary references from the GMPLS OTN specifications are to be made to the ITU-T OTN recommendations and not to any interpretation of those recommendations. FYI, the list of OTN related recommendations is: G.872 (version 2) G.709 + G.709 ammendment 1 G.7041 G.7042 G.798 G.806 G.7710 G.874 G.874.1 G.7712 G.8251 G.959.1 G.664 Furthermore work is ongoing on the following draft recommendations: G.optperf G.875 G.gps G.otnprot M.24otn As such we should not progress draft-bellato-ccamp-g709-framework-01.txt. Regards, Maarten --------------18DEEAFAEA70A85612240B46 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 --------------18DEEAFAEA70A85612240B46-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Nov 2001 01:51:34 -0800 Cc: ccamp , q14/15 Message-ID: <3BFE1B79.A9C5B95E@lucent.com> Date: Fri, 23 Nov 2001 10:48:41 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: ccamp , q14/15 Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Content-Type: multipart/mixed; boundary="------------7DDE1A8B9FA61F6BD9639C67" This is a multi-part message in MIME format. --------------7DDE1A8B9FA61F6BD9639C67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, These differences are not specifically between SDH and SONET, you will also find a number of those between SDH and SDH or between SONET and SONET. Furthermore there are many more items that may require negotiation between elements in the connection. If you look into the items you will notice that they are associated with the ports at the end of the connection or at intermediate points along the connection. As such a generic mechanism is required that establishes interworking for the case two ports (monitoring points) have different options selected. Port types to be considered (just a first quick list; still very incomplete): VC-m (m=11,12,2) port - Path Trace Identifier (J2): 16-byte and 64-byte path trace identifier strings - performance monitoring: BIP violation counting, Errored Block (EB) counting VC-m (m=11,12,2) SNC protected port - all kind of SNC protection related parameters; e.g. SNC protection type, operation type, holdoff timer, etc. VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) port - Path Trace Identifier (J1): 16-byte and 64-byte path trace identifier strings - Path Trace Identifier (J1): 64-byte path trace identifier formats - performance monitoring: BIP violation counting, Errored Block (EB) counting - user channel support: none/F2/F2F3/F3 VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) TCM port - Tandem connection monitoring: option I and II VC-n (n=3,4,4-4c,4-16c,4-64c,4-256c) SNC protected port - all kind of SNC protection related parameters; e.g. SNC protection type, operation type, holdoff timer, etc. STM-N (N=0,1,4,16,64,256) RS port - Regenerator Section Trace Identifier (J0): 1-byte and 16-byte section trace identifier strings - RS-DCC support - RS orderwire support - RS user channel support STM-N MS port - older AU/STS pointer processors: ss-bits source processing: generation of "10" or "00" pattern, sink processing: verify presence of ss-bit pattern or ignore ss-bit pattern - newer AU/STS pointer processors: source generates ss-bits "10", sink ignores ss-bits ==> i.e. no interworking issue - Synchronisation Status Message (SSM) code set: option I, II or III (see G.781) - MS-REI: MS-REI supported/not-supported - STM-64 MS-REI: M0M1 or M1 only - MS-DCC support - RS orderwire support STM-N (N=0,1,4,16,64,256) MS protected port - K1K2 MSP-APS switching type codes (uni-/bi-directional) in K2[6-8] for case of 1:n - all kind of MS protection related parameters (see G.841 and G.783); e.g. switching type, operation type, architecture type, etc. STM-N (N=16,64,256) MS SPRing protected port - all kind of MS SPring protection related parameters In general, the setup of the connection may have more than one phase associated: 1) connection bearer setup 2) connection monitoring setup 3) connection protection setup The latter two phases require a detailed review of the MI_XXX parameters in the atomic functions in G.705, G.781, G.783, G.798 as well as a review of the set of atomic functions that represent normally optional functionality. Everything that allows selectivity on a per connection basis needs to be identified and allocated to connection monitoring and protection service signalling. As you can see the few specific SONET/SDH differences are like noise and don't deserve separate LSP encoding types. Different LSP encoding types will complicate things more than help. Regards, Maarten Dimitri Papadimitriou wrote: > > Hi Maarten, > > Thanks for these comments, it has been left for further consideration > within this document, but you know that they are "differences" between > Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are > mainly J0 at RS/SOH and K2 MS/LOH. > > Nevertheless, the key question is does it impact the control plane > specification ? And this is one of the purpose of this document (again > at a first stage). > > So, prior to propose a merge of the control plane code-points i would > like first to ask you if the current proposals made in order to provide > interoperability have been accepted and integrated. Knowing that we can > then evaluate the impact on the control plane and after we could > consider > your proposal. > > Many thanks, > - dimitri. > > Maarten Vissers wrote: > > > > All, > > > > I had a look on contribution > > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to provide > > some comment. > > > > 1) I "liked" :-( the first sentence in section 2: "This section describes how > > SDH and SONET can interwork at the transport plane level." I only thought that > > this was already defined for many years in G.707. :-) > > A reference to section 6.4/G.707 seems more appropriate, as it will show > > interconnection in general between VC-3 transport in multiplex sections (AU-3, > > STS-1) and VC-4 paths (TU-3). > > It will also show interconnection between VC-11 transport in VC-11 link > > connections (TU-11, VT1.5) and VC-12 link connections (TU-12). > > > > 2) From a connection management perspective (scope of the control plane), the > > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one signal type. > > Interworking happens simply within the VC-3 layer network by means of connecting > > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP. > > It is unimportant how the VC-3/STS-1 arrives/departs at/from the VC-3/STS-1 SNP; > > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3. > > > > Links (link bundles) which support VC-3/STS-1 link connections will simply > > advertise this capability via their LSAs. A VC-3 fabric having two VC-3 > > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP within > > the first link to a VC-3/STS-1 SNP within the second link. > > > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary due to the > > fact that two LSP Encoding Types were allocated. If just one LSP Encoding Type > > would be allocated for both SDH and SONET, we would not require any GMPLS > > SDH-SONET interworking functionality. > > > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one > > codepoint referred to as SDH/SONET. > > > > Regards, > > > > Maarten --------------7DDE1A8B9FA61F6BD9639C67 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 --------------7DDE1A8B9FA61F6BD9639C67-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Nov 2001 09:39:02 -0800 Message-Id: <1BA26ABC57F3D41191390003470C0FD93481D6@U8PM9> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Roese, Josef" To: Eric.Mannie@ebone.com, dimitri.papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: AW: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Thu, 22 Nov 2001 16:23:45 +0100 Eric, Dimitri It took same time to read all the emails about LMB versus LCAS. I will not restart the discussion on pro and con of LMB and LCAS. In all the emails I missed a network and operator view. For the following scenario I assume that LMB works hitlessly. GMPLS, ASON, LMB and LCAS will be introduced in the network. Operators make their choice which technology they want to use inside their domain. Later, circuit switched services will be also used between operators. Interworking between domains using different signalling and routing protocols can be achieved by translation to inter-domain protocols (e. g. BGP). This is a proven technique. With such techniques we can easily move from local switched services to global ones, when we exclude virtual concatenated circuits. For sure, some ends will use LCAS others LMB. Sinks that operate both LCAS and LMB protocol may achieve interworking between circuit ends. However, first generation circuit ends will use either LCAS or LMB and will, therfore, not inter-work. A translation of a real time LCAS to a real time LMB protocol and vice versa at domain borders will not work, too. Conclusion: Different end to end protocols for bandwidth adjustment is the worst solution we could get in a network. Whether LMB may be simpler or more powerful than LCAS is not the issue. In any case we would loose with the introduction of a second protocol that is incompatible with LCAS. Josef Roese T-Systems Nova Technologiezentrum, E531g Am Kavalleriesand 3, 6429 5 Darmstadt Tel: +49 6151 83 5188 Fax: +49 6151 83 19875 mailto:Josef.Roese@t-systems.de http://www.t-nova.de Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Nov 2001 08:10:28 -0800 Message-ID: <3BFD2160.20354896@alcatel.be> Date: Thu, 22 Nov 2001 17:01:36 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: ccamp Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Content-Type: multipart/mixed; boundary="------------4DB29A324E9913D393DB7446" This is a multi-part message in MIME format. --------------4DB29A324E9913D393DB7446 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Maarten, Thanks for these comments, it has been left for further consideration within this document, but you know that they are "differences" between Sonet and SDH OH in particular at the POH: J1/J2, B3, G3/K4 others are mainly J0 at RS/SOH and K2 MS/LOH. Nevertheless, the key question is does it impact the control plane specification ? And this is one of the purpose of this document (again at a first stage). So, prior to propose a merge of the control plane code-points i would like first to ask you if the current proposals made in order to provide interoperability have been accepted and integrated. Knowing that we can then evaluate the impact on the control plane and after we could consider your proposal. Many thanks, - dimitri. Maarten Vissers wrote: > > All, > > I had a look on contribution > "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to provide > some comment. > > 1) I "liked" :-( the first sentence in section 2: "This section describes how > SDH and SONET can interwork at the transport plane level." I only thought that > this was already defined for many years in G.707. :-) > A reference to section 6.4/G.707 seems more appropriate, as it will show > interconnection in general between VC-3 transport in multiplex sections (AU-3, > STS-1) and VC-4 paths (TU-3). > It will also show interconnection between VC-11 transport in VC-11 link > connections (TU-11, VT1.5) and VC-12 link connections (TU-12). > > 2) From a connection management perspective (scope of the control plane), the > STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one signal type. > Interworking happens simply within the VC-3 layer network by means of connecting > a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP. > It is unimportant how the VC-3/STS-1 arrives/departs at/from the VC-3/STS-1 SNP; > i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3. > > Links (link bundles) which support VC-3/STS-1 link connections will simply > advertise this capability via their LSAs. A VC-3 fabric having two VC-3 > supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP within > the first link to a VC-3/STS-1 SNP within the second link. > > 3) SONET/SDH interworking GMPLS gateway function seems only necessary due to the > fact that two LSP Encoding Types were allocated. If just one LSP Encoding Type > would be allocated for both SDH and SONET, we would not require any GMPLS > SDH-SONET interworking functionality. > > Therefore my proposal to merge SDH and SONET LSP Encoding types into one > codepoint referred to as SDH/SONET. > > Regards, > > Maarten --------------4DB29A324E9913D393DB7446 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------4DB29A324E9913D393DB7446-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Nov 2001 07:40:43 -0800 Message-ID: <3BFD1BF2.50D1B5F2@lucent.com> Date: Thu, 22 Nov 2001 16:38:26 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Content-Type: multipart/mixed; boundary="------------419EEF471916DE923261A926" This is a multi-part message in MIME format. --------------419EEF471916DE923261A926 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I had a look on contribution "draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt" and would like to provide some comment. 1) I "liked" :-( the first sentence in section 2: "This section describes how SDH and SONET can interwork at the transport plane level." I only thought that this was already defined for many years in G.707. :-) A reference to section 6.4/G.707 seems more appropriate, as it will show interconnection in general between VC-3 transport in multiplex sections (AU-3, STS-1) and VC-4 paths (TU-3). It will also show interconnection between VC-11 transport in VC-11 link connections (TU-11, VT1.5) and VC-12 link connections (TU-12). 2) From a connection management perspective (scope of the control plane), the STS-1, Higher Order VC-3 and Lower Order VC-3 can be treated as one signal type. Interworking happens simply within the VC-3 layer network by means of connecting a (HO)VC-3/STS-1/(LO)VC-3 SNP with another (HO)VC-3/STS-1/(LO)VC-3 SNP. It is unimportant how the VC-3/STS-1 arrives/departs at/from the VC-3/STS-1 SNP; i.e. it could be within a STM-N/OC-N multiplex section, VC-4, E4 or E3. Links (link bundles) which support VC-3/STS-1 link connections will simply advertise this capability via their LSAs. A VC-3 fabric having two VC-3 supporting links (link bundles) can "blindly" connect a VC-3/STS-1 SNP within the first link to a VC-3/STS-1 SNP within the second link. 3) SONET/SDH interworking GMPLS gateway function seems only necessary due to the fact that two LSP Encoding Types were allocated. If just one LSP Encoding Type would be allocated for both SDH and SONET, we would not require any GMPLS SDH-SONET interworking functionality. Therefore my proposal to merge SDH and SONET LSP Encoding types into one codepoint referred to as SDH/SONET. Regards, Maarten --------------419EEF471916DE923261A926 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 --------------419EEF471916DE923261A926-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Nov 2001 06:39:27 -0800 Cc: Dimitri Papadimitriou , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Message-ID: <3BFD0D84.E5CCAED0@lucent.com> Date: Thu, 22 Nov 2001 15:36:52 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Randy Bush Original-CC: Dimitri Papadimitriou , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------CFDD26A007FC597E65893EE3" This is a multi-part message in MIME format. --------------CFDD26A007FC597E65893EE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, > it feels to me that too much of the recent sdh/sonet discussion really > belongs in the itu. There is much more SDH/SONET and OTN discussions to come... Performing connection management for SDH/SONET and OTN requires a detailed knowledge/understanding of their principles and behaviour. That knowledge/understanding is present in ITU-T and has to be build up in IETF if IETF continues its GMPLS development work. Within the development of IP and MPLS, the cloud below those two layers could be viewed as a black box realising "layer 1/2" functionality, which provides the pipes between the IP/MPLS processing elements. Within the development of GMPLS, the focus is on the details in that "layer 1/2" cloud. GMPLS for this cloud is not related in any sense as such to IP or MPLS. It deals with connection management for LOVC/VT (VC-11/VT1.5, VC-12/VT-2, VC-3), HOVC/STS (VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, ..), ODUk (ODU1, ODU2, ODU3), OCh and today also "STM-N/OC-N" layers. If one does not understand the details of those layers, it is very difficult to develop correct/complete connection management specification; the devil is in the details... One could say that GMPLS developpers need to have good knowledge of ITU-T SDH and OTN and T1 SONET standards; especially the transport architecture, rates and formats, equipment and management ones. Regards, Maarten Randy Bush wrote: > > > I don't know if it is necessary to redescribe SDH/SONET processing in an > > IETF document. I would prefer references to the appropriate SDH standards; > > otherwise you get different specifications and people get confused. > > you are being too polite. it is anethema to redocument sdh/sonet here. > > it feels to me that too much of the recent sdh/sonet discussion really > belongs in the itu. > > randy --------------CFDD26A007FC597E65893EE3 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 --------------CFDD26A007FC597E65893EE3-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Nov 2001 05:34:47 -0800 Message-ID: <009301c17359$8825d970$d7217283@meta.cpr.it> From: "Gino Carrozzo" To: "ccamp" Subject: relationship between adjacency and link Date: Thu, 22 Nov 2001 14:28:11 +0100 Organization: Dip. Ingegneria della Informazione MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I would like to have some clarification about the relationship between adjacency and link (link = either interface or link bundle or link component, I think this does not matter in this discussion). I see 3 alternatives in the Adjacency->link relationship: 1:1, N:1, 1:N. As far as I understood, OSPFv2 and OSPFv3 explicitly support 1:1 and N:1. draft-ietf-mpls-lsp-hierarchy-02.txt seems to support a 1:1relationship, since it suggests to aggregate various links into a single link bundle before building an adjacency on them: "If there are multiple LSPs that all originate on one LSR and all terminate on another LSR, then at one end of the spectrum all these LSPs could be merged (under control of the head-end LSR) into a single forwarding adjacency using the concept of Link Bundling (see [BUNDLE]), while at the other end of the spectrum each such LSP could be advertised as its own adjacency." So, is there any support for an 1:N relationship? thanks for any advice. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 23:32:47 -0800 Message-ID: <3BFCAAAA.E107A656@npd.hcltech.com> Date: Thu, 22 Nov 2001 13:05:06 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: Jonathan Lang CC: "'George Young'" , ccamp@ops.ietf.org Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Kindly clarify me on the following: 1. Is Link verification has to be done before Link property correlation procedure. Because with Link verification procedure only ( out of fiber case ) the neighbour interface mappings can be identified. But in Link property correlation procedure it is given that Link Property correlation MUST be done before the link is brought UP and MAY be done when the link is UP and not in the verification process. Here a Link will be brought UP only when TEST messages are sent through the data link ( out of fiber case ). If so during the first LinkSummary message we cannot identify the interface mappings right, only the TE links parameters are exchanged. Am i right. Kindly clarify me. 2. Is that a data link between the two neighbours must participate as a member of any of the TE link? if not how it will be tested. 3. In the BeginVerify message, there are LOCAL_LINK_ID class and Begin verify class. It is given that "To limit the scope of Link Verification to a particular TE Link, the LOCAL_LINK_ID SHOULD be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. " IF local link id field is ZERO means the data link can span multiple TE link. So how to test this Data Link. Because in the BeginVerify Class, the Flags filed cointains " 0x01 Verify all Links If this bit is set, the verification process checks all unallocated links; else it only verifies new ports or component links that are to be added to this TE link. " If this bit is set means it will check all unallocated datalinks of the Node right. if not set means the port or component links that are to be added to this TE LINK ( means Local Link ID present ) has to be verified. If this is the case how a data link that span multiple TE link can be tested. or a datalink that does not participate in any TE link ( if possible ) can be tested . Kindly clarify me. Thanks, Ramesh Jonathan Lang wrote: > George, > Event 2 can be removed. We will need to reword events 7 & 8. My proposal > below: > > 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. > > -Jonathan > > > -----Original Message----- > > From: George Young [mailto:george.young@meriton.com] > > Sent: Wednesday, November 21, 2001 5:41 AM > > To: Jonathan Lang > > Cc: ccamp@ops.ietf.org > > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > > Hello Jonathan, > > > > See below: > > > > Regards, > > George R. Young > > Meriton Networks Inc. > > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > phone: +1 613-270-9279 Ext 287 > > fax: +1 613-270-9268 > > > > > > >-----Original Message----- > > >From: Jonathan Lang [mailto:jplang@calient.net] > > >Sent: Tuesday, November 20, 2001 11:49 AM > > >To: George Young > > >Cc: ccamp@ops.ietf.org > > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > > > > >George, > > > Please see inline. > > > > > >Thanks, > > >Jonathan > > > > > >> -----Original Message----- > > >> From: George Young [mailto:george.young@meriton.com] > > >> Sent: Tuesday, November 20, 2001 8:34 AM > > >> To: Jonathan Lang > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > >> > > >> > > >> Hello Jonathan, > > >> > > >> Comments/question below. Also please note, edgeFlow has > > >> changed its name > > >> to Meriton Networks Inc., and as a result the email address > > >changes to > > >> george.young@meriton.com. > > >> > > >> Regards, > > >> George R. Young > > >> Meriton Networks Inc. > > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > >> phone: +1 613-270-9279 Ext 287 > > >> fax: +1 613-270-9268 > > >> > > >> > > >> >-----Original Message----- > > >> >From: Jonathan Lang [mailto:jplang@calient.net] > > >> >Sent: Monday, November 19, 2001 5:21 PM > > >> >To: 'S Ramesh'; George Young > > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang > > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > > and 12.3.4) > > >> > > > >> > > > >> >Ramesh, > > >> > Please see inline. > > >> > > > >> >Thanks, > > >> >Jonathan > > >> > > > >> >> -----Original Message----- > > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > > >> >> Sent: Thursday, November 15, 2001 11:15 PM > > >> >> To: George Young > > >> >> Cc: ccamp@ops.ietf.org > > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 > > >and 12.3.4) > > >> >> > > >> >> > > >> >> Hi Young, > > >> >> > > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the > > >> >> Data Link FSM's in the down state also. Agreed. > > >> >I would actually propose that we remove the degraded state > > >> >altogether from > > >> >the data link fsms. This is already captured at the TE > > link level. > > >> >Comments? > > >> > > >> If I understand your response to messrs Ramesh and moi, > > transition 10 > > >> should be retained from Deg to Down. > > >> If you then remove the Deg state, implying that in the > > Up/Alloc state > > >> you may not have a control channel, where would transition 10 go? > > >> > > >> Transition 13 'fault localization' seems to need a control channel. > > >> Without the Deg state, how would you represent the idea that > > >sometimes > > >> transition 13 can't take place? > > >What I'm proposing is that we decouple the notion of a control > > >channel with > > >the data link FSMs. As Ramesh said in an email, some of these > > >events can be > > >generated through management interface also. For active data > > >link, the FSM > > >would be: > > > > > > +------+ > > > | |<-------+ > > > +--------->| Down | | > > > | +----| |<-----+ | > > > | | +------+ | | > > > | |5b 3| ^ | | > > > | | | |2,7 | | > > > | | v | | | > > > | | +------+ | | > > > | | | |<-+ | | > > > | | | Test | |11 | | > > > | | | |--+ | | > > > | | +------+ | | > > > | | 5a| 3^ | | > > > | | | | | | > > > | | v | | | > > > |2,12 | +---------+ | | > > > | +-->| |14 | | > > > | | Up/Free |----+ | > > > +---------| | | > > > +---------+ | > > > 9| ^ | > > > | | | > > > v |10 | > > > +---------+ | > > > | |13 | > > > |Up/Alloc |------+ > > > | | > > > +---------+ > > > > > > > Removing the Deg state simplifies the Link FSM as it's present in > > the TE FSM. Editorially then (I think), transition 2 would not take > > place from Test/PasvTest to Down. > > > > > > > >> > > >> > > > >> >> > > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in > > >> >the degraded > > >> >> state. Yeah a control channel is needed, but this event > > >> can also be a > > >> >> external event know, from the user or a network management > > >> >event. If this > > >> >> is possible then this event is required in this state. Kindly > > >> >> clarify me. > > >> >agreed. > > >> > > > >> >> > > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv > > >> >Test state. Since > > >> >> to send a Test message or to receive a Test message we > > need a data > > >> >channel. > > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will > > >> >pose the next > > >> >> state to Test & Pasv Test state from Up/Free state. So the event > > >> >> 14.evdcDown is also possible on both the states and hence the > > >> >> next state in both the case will be down. > > >> >ok. > > >> > > > >> >> > > >> >> Thanks, > > >> >> Ramesh > > >> >> > > >> >> George Young wrote: > > >> >> > > >> >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > > >> >> > draft-ietf-ccamp-lmp-02.txt: > > >> >> > > > >> >> > 1) It appears that in the Down state, the control channel > > >> >> can be either > > >> >> > up or > > >> >> > down. That being the case, there should be transitions > > >> for events 1 > > >> >> > :evCCUp: > > >> >> > and 2 :evCCDown: from Down to Down. > > >> >> > > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > > >> appear to be > > >> >> > impossible, > > >> >> > as there is no control channel available, and the control > > >> >channel is > > >> >> > required to coordinate taking the channel down at both > > >> >> ends. I believe > > >> >> > this > > >> >> > transition should be removed. > > >> >> > > > >> >> > With these changes, the FSMs would look like: > > >> >> > > > >> >> > 12.3.3. Active Data Link FSM Description > > >> >> > > > >> >> > Figure 5 illustrates operation of the LMP active data > > >> >> link FSM in a > > >> >> > form of FSM state transition diagram. > > >> >> > > > >> >> > 1,2 > > >> >> > +------+ > > >> >> > | | > > >> >> > | +------+ > > >> >> > +-->| |<-------+ > > >> >> > +--------->| Down | | > > >> >> > | +----| |<-----+ | > > >> >> > | | +------+ | | > > >> >> > | |5b 3| ^ | | > > >> >> > | | | |2,7 | | > > >> >> > | | v | | | > > >> >> > | | +------+ | | > > >> >> > | | | |<-+ | | > > >> >> > | | | Test | |11 | | > > >> >> > | | | |--+ | | > > >> >> > | | +------+ | | > > >> >> > | | 5a| 3^ | | > > >> >> > | | | | | | > > >> >> > | | v | | | > > >> >> > |2,12 | +---------+ | | > > >> >> > | +-->| |14 | | > > >> >> > | | Up/Free |----+ | > > >> >> > +---------| | | > > >> >> > +---------+ | > > >> >> > 9| ^ | > > >> >> > | | | > > >> >> > v |10 | > > >> >> > +-----+ 2 +---------+ | > > >> >> > | |<--------| |13 | > > >> >> > | Deg | |Up/Alloc |------+ > > >> >> > | |-------->| | > > >> >> > +-----+ 1 +---------+ > > >> >> > > > >> >> > Figure 5: Active LMP Data Link FSM > > >> >> > > > >> >> > 12.3.4. Passive Data Link FSM Description > > >> >> > > > >> >> > Figure 6 illustrates operation of the LMP passive data > > >> >> link FSM in a > > >> >> > form of FSM state transition diagram. > > >> >> > > > >> >> > 1,2 > > >> >> > +------+ > > >> >> > | | > > >> >> > | +------+ > > >> >> > +-->| |<------+ > > >> >> > +---------->| Down | | > > >> >> > | +-----| |<----+ | > > >> >> > | | +------+ | | > > >> >> > | |5b 4| ^ | | > > >> >> > | | | |2,8 | | > > >> >> > | | v | | | > > >> >> > | | +----------+ | | > > >> >> > | | | PasvTest | | | > > >> >> > | | +----------+ | | > > >> >> > | | 6| 4^ | | > > >> >> > | | | | | | > > >> >> > | | v | | | > > >> >> > |2,12 | +---------+ | | > > >> >> > | +--->| Up/Free |14 | | > > >> >> > | | |---+ | > > >> >> > +----------| | | > > >> >> > +---------+ | > > >> >> > 9| ^ | > > >> >> > | | | > > >> >> > v |10 | > > >> >> > +-----+ +---------+ | > > >> >> > | | 2 | |13 | > > >> >> > | Deg |<--------|Up/Alloc |-----+ > > >> >> > | |-------->| | > > >> >> > +-----+ 1 +---------+ > > >> >> > > > >> >> > Figure 6: Passive LMP Data Link FSM > > >> >> > > > >> >> > Regards, > > >> >> > George R. Young > > >> >> > edgeflow Inc. > > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > >> >> > phone: +1 613-270-9279 Ext 287 > > >> >> > fax: +1 613-270-9268 > > >> >> > > > >> >> > >-----Original Message----- > > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM > > >> >> > >To: ccamp@ops.ietf.org > > >> >> > >Subject: Two week Last Call on LMP > > >> >> > > > > >> >> > > > > >> >> > >Hi All, > > >> >> > > > > >> >> > >This is to announce a two week Last Call on the LMP draft: > > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > > >> Wed Nov 28. > > >> >> > > > > >> >> > >Please send questions, comments and requests for > > clarifications > > >> >> > >to the CCAMP list. > > >> >> > > > > >> >> > >Kireeti. > > >> >> > > > > >> >> > > > > >> >> > > >> >> > > >> > > > >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 21:49:02 -0800 Message-ID: <3BFC91FC.89D75EBC@npd.hcltech.com> Date: Thu, 22 Nov 2001 11:19:48 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: Jonathan Lang CC: "'George Young'" , ccamp@ops.ietf.org Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, As editorially speaking since Test/Pasv Test state is sending or receiving Test messages alone event 2:ecdcDown is not needed in the state. But in Test/Pasv Test state event 7:evTestfail and 8:evPsvTestFail are possible. Actually these two events need a control channel in order to receive a TestStatusFailure message or EndVerify message in the first case ( Test sate ) and to receive a EndVerify in the later case also ( PasvTest state ). So a control channel is needed in these states even we send or receive a Test message alone ( as per editorial definition of these states ). If this is the case then event 2:evCCdown is possible in these two states and hence the resulting state will be down. Also Jonathan as i already said 14.evdcDown is possible in Test/Pasv Test state. Thanks, Ramesh Jonathan Lang wrote: > George, > Event 2 can be removed. We will need to reword events 7 & 8. My proposal > below: > > 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. > > -Jonathan > > > -----Original Message----- > > From: George Young [mailto:george.young@meriton.com] > > Sent: Wednesday, November 21, 2001 5:41 AM > > To: Jonathan Lang > > Cc: ccamp@ops.ietf.org > > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > > Hello Jonathan, > > > > See below: > > > > Regards, > > George R. Young > > Meriton Networks Inc. > > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > phone: +1 613-270-9279 Ext 287 > > fax: +1 613-270-9268 > > > > > > >-----Original Message----- > > >From: Jonathan Lang [mailto:jplang@calient.net] > > >Sent: Tuesday, November 20, 2001 11:49 AM > > >To: George Young > > >Cc: ccamp@ops.ietf.org > > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > > > > >George, > > > Please see inline. > > > > > >Thanks, > > >Jonathan > > > > > >> -----Original Message----- > > >> From: George Young [mailto:george.young@meriton.com] > > >> Sent: Tuesday, November 20, 2001 8:34 AM > > >> To: Jonathan Lang > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > >> > > >> > > >> Hello Jonathan, > > >> > > >> Comments/question below. Also please note, edgeFlow has > > >> changed its name > > >> to Meriton Networks Inc., and as a result the email address > > >changes to > > >> george.young@meriton.com. > > >> > > >> Regards, > > >> George R. Young > > >> Meriton Networks Inc. > > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > >> phone: +1 613-270-9279 Ext 287 > > >> fax: +1 613-270-9268 > > >> > > >> > > >> >-----Original Message----- > > >> >From: Jonathan Lang [mailto:jplang@calient.net] > > >> >Sent: Monday, November 19, 2001 5:21 PM > > >> >To: 'S Ramesh'; George Young > > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang > > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > > and 12.3.4) > > >> > > > >> > > > >> >Ramesh, > > >> > Please see inline. > > >> > > > >> >Thanks, > > >> >Jonathan > > >> > > > >> >> -----Original Message----- > > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > > >> >> Sent: Thursday, November 15, 2001 11:15 PM > > >> >> To: George Young > > >> >> Cc: ccamp@ops.ietf.org > > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 > > >and 12.3.4) > > >> >> > > >> >> > > >> >> Hi Young, > > >> >> > > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the > > >> >> Data Link FSM's in the down state also. Agreed. > > >> >I would actually propose that we remove the degraded state > > >> >altogether from > > >> >the data link fsms. This is already captured at the TE > > link level. > > >> >Comments? > > >> > > >> If I understand your response to messrs Ramesh and moi, > > transition 10 > > >> should be retained from Deg to Down. > > >> If you then remove the Deg state, implying that in the > > Up/Alloc state > > >> you may not have a control channel, where would transition 10 go? > > >> > > >> Transition 13 'fault localization' seems to need a control channel. > > >> Without the Deg state, how would you represent the idea that > > >sometimes > > >> transition 13 can't take place? > > >What I'm proposing is that we decouple the notion of a control > > >channel with > > >the data link FSMs. As Ramesh said in an email, some of these > > >events can be > > >generated through management interface also. For active data > > >link, the FSM > > >would be: > > > > > > +------+ > > > | |<-------+ > > > +--------->| Down | | > > > | +----| |<-----+ | > > > | | +------+ | | > > > | |5b 3| ^ | | > > > | | | |2,7 | | > > > | | v | | | > > > | | +------+ | | > > > | | | |<-+ | | > > > | | | Test | |11 | | > > > | | | |--+ | | > > > | | +------+ | | > > > | | 5a| 3^ | | > > > | | | | | | > > > | | v | | | > > > |2,12 | +---------+ | | > > > | +-->| |14 | | > > > | | Up/Free |----+ | > > > +---------| | | > > > +---------+ | > > > 9| ^ | > > > | | | > > > v |10 | > > > +---------+ | > > > | |13 | > > > |Up/Alloc |------+ > > > | | > > > +---------+ > > > > > > > Removing the Deg state simplifies the Link FSM as it's present in > > the TE FSM. Editorially then (I think), transition 2 would not take > > place from Test/PasvTest to Down. > > > > > > > >> > > >> > > > >> >> > > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in > > >> >the degraded > > >> >> state. Yeah a control channel is needed, but this event > > >> can also be a > > >> >> external event know, from the user or a network management > > >> >event. If this > > >> >> is possible then this event is required in this state. Kindly > > >> >> clarify me. > > >> >agreed. > > >> > > > >> >> > > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv > > >> >Test state. Since > > >> >> to send a Test message or to receive a Test message we > > need a data > > >> >channel. > > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will > > >> >pose the next > > >> >> state to Test & Pasv Test state from Up/Free state. So the event > > >> >> 14.evdcDown is also possible on both the states and hence the > > >> >> next state in both the case will be down. > > >> >ok. > > >> > > > >> >> > > >> >> Thanks, > > >> >> Ramesh > > >> >> > > >> >> George Young wrote: > > >> >> > > >> >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > > >> >> > draft-ietf-ccamp-lmp-02.txt: > > >> >> > > > >> >> > 1) It appears that in the Down state, the control channel > > >> >> can be either > > >> >> > up or > > >> >> > down. That being the case, there should be transitions > > >> for events 1 > > >> >> > :evCCUp: > > >> >> > and 2 :evCCDown: from Down to Down. > > >> >> > > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > > >> appear to be > > >> >> > impossible, > > >> >> > as there is no control channel available, and the control > > >> >channel is > > >> >> > required to coordinate taking the channel down at both > > >> >> ends. I believe > > >> >> > this > > >> >> > transition should be removed. > > >> >> > > > >> >> > With these changes, the FSMs would look like: > > >> >> > > > >> >> > 12.3.3. Active Data Link FSM Description > > >> >> > > > >> >> > Figure 5 illustrates operation of the LMP active data > > >> >> link FSM in a > > >> >> > form of FSM state transition diagram. > > >> >> > > > >> >> > 1,2 > > >> >> > +------+ > > >> >> > | | > > >> >> > | +------+ > > >> >> > +-->| |<-------+ > > >> >> > +--------->| Down | | > > >> >> > | +----| |<-----+ | > > >> >> > | | +------+ | | > > >> >> > | |5b 3| ^ | | > > >> >> > | | | |2,7 | | > > >> >> > | | v | | | > > >> >> > | | +------+ | | > > >> >> > | | | |<-+ | | > > >> >> > | | | Test | |11 | | > > >> >> > | | | |--+ | | > > >> >> > | | +------+ | | > > >> >> > | | 5a| 3^ | | > > >> >> > | | | | | | > > >> >> > | | v | | | > > >> >> > |2,12 | +---------+ | | > > >> >> > | +-->| |14 | | > > >> >> > | | Up/Free |----+ | > > >> >> > +---------| | | > > >> >> > +---------+ | > > >> >> > 9| ^ | > > >> >> > | | | > > >> >> > v |10 | > > >> >> > +-----+ 2 +---------+ | > > >> >> > | |<--------| |13 | > > >> >> > | Deg | |Up/Alloc |------+ > > >> >> > | |-------->| | > > >> >> > +-----+ 1 +---------+ > > >> >> > > > >> >> > Figure 5: Active LMP Data Link FSM > > >> >> > > > >> >> > 12.3.4. Passive Data Link FSM Description > > >> >> > > > >> >> > Figure 6 illustrates operation of the LMP passive data > > >> >> link FSM in a > > >> >> > form of FSM state transition diagram. > > >> >> > > > >> >> > 1,2 > > >> >> > +------+ > > >> >> > | | > > >> >> > | +------+ > > >> >> > +-->| |<------+ > > >> >> > +---------->| Down | | > > >> >> > | +-----| |<----+ | > > >> >> > | | +------+ | | > > >> >> > | |5b 4| ^ | | > > >> >> > | | | |2,8 | | > > >> >> > | | v | | | > > >> >> > | | +----------+ | | > > >> >> > | | | PasvTest | | | > > >> >> > | | +----------+ | | > > >> >> > | | 6| 4^ | | > > >> >> > | | | | | | > > >> >> > | | v | | | > > >> >> > |2,12 | +---------+ | | > > >> >> > | +--->| Up/Free |14 | | > > >> >> > | | |---+ | > > >> >> > +----------| | | > > >> >> > +---------+ | > > >> >> > 9| ^ | > > >> >> > | | | > > >> >> > v |10 | > > >> >> > +-----+ +---------+ | > > >> >> > | | 2 | |13 | > > >> >> > | Deg |<--------|Up/Alloc |-----+ > > >> >> > | |-------->| | > > >> >> > +-----+ 1 +---------+ > > >> >> > > > >> >> > Figure 6: Passive LMP Data Link FSM > > >> >> > > > >> >> > Regards, > > >> >> > George R. Young > > >> >> > edgeflow Inc. > > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > >> >> > phone: +1 613-270-9279 Ext 287 > > >> >> > fax: +1 613-270-9268 > > >> >> > > > >> >> > >-----Original Message----- > > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM > > >> >> > >To: ccamp@ops.ietf.org > > >> >> > >Subject: Two week Last Call on LMP > > >> >> > > > > >> >> > > > > >> >> > >Hi All, > > >> >> > > > > >> >> > >This is to announce a two week Last Call on the LMP draft: > > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > > >> Wed Nov 28. > > >> >> > > > > >> >> > >Please send questions, comments and requests for > > clarifications > > >> >> > >to the CCAMP list. > > >> >> > > > > >> >> > >Kireeti. > > >> >> > > > > >> >> > > > > >> >> > > >> >> > > >> > > > >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 12:04:47 -0800 Message-ID: From: Jonathan Lang To: 'Carmine Daloia' , Sudheer Dharanikota Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... Date: Wed, 21 Nov 2001 11:57:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Carmine, To be precise, when you refer to "standard OTN" and "non-standard DWDM", are you referring to G.709? If so, I would suggest you do a global search-replace of your proposed text to read "G.709" and "non-G.709", respectively. Thanks, Jonathan -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 9:51 AM To: Sudheer Dharanikota Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Hi Sudheer, My last comment wasn't meant to be an argument :-) Maybe if I propose some text specific to the suppression of downstream alarms that would help clarify the scope of applicability. The text would state that when client devices (e.g., SONET/SDH cross-connects, IP routers) are interconnected via a standard OTN network then the suppression of downstream alarms is already handled in the transport/user plane via the OTN overhead (both in-band via the digitial overhead as well as out-of-band via non-associated overhead). Also the text would address PXCs within a standard OTN network. In this case, again the suppression of downstream alarms is handled via the OTN overhead. The implementation proposed in LMP for suppression of downstream alarms applies to PXCs or client devices (e.g, SONET/SDH cross-connects or IP routers) interconnected via a non-standard DWDM network. In this case, it is assummed that the non-standard DWDM network does not provide the neccesary overhead within the transport/user plane to suppress alarms on PXCs and client devices and therefore LMP provides a mechanism to carry such alarm suppression messages in the control plane. I'll take a crack at specific text so that the group can review it. Does this sound like something that would be helpful. Thanks Carmine Sudheer Dharanikota wrote: Hi again: Carmine Daloia wrote: I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system. Ok Let us address the issues separately... 1. Communication between Line System and Cross connect Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion) of IETF. I am not sure if are creating a problem to solve with the alarm suppression. Let me explain... Let us assume we can correlate and suppress the alarms between the Line systems and corss connects. Then we donot need an elaborate bit-oriented protocol. This has an assumption that we are talking about not hundereds of failures but a couple of failures (for example fiber cuts). As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication. Agreed we need to focus on LMP not DWDM-LMP :-) But... the intention of the OLI document was to underdstand the requirements. I thought most of us vouch for these requirements. Let us put the requirements in the back-burner. If it is bit-oriented protocol it does not interest most of us :-) 2. Communication between cross connects THis is needed to localize a fault which in turn can be used as a trigger for local restoration. Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing. Again... span protection can be performed easily with the current mechanisms supported by LMP in out-of-band communication scenarios. In case of overlaping restoration scenarios such as span and end-to-end it is required to have a localization + an attempt to recover + (if this fails) report to end-to-end entities for recovery. THis also vouch for the inclusion of such mechanisms in LMP. Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective. Well I guess I cannot buy this argument :-) Cheers, sudheer - sudheer Thanks Carmine Sudheer Dharanikota wrote: Carmine... Again can you suggest a way to communicate such signals between line systems and cross connects when inband communication is not supported between these two systems? Cheers, sudheer Carmine Daloia wrote: Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline.Thanks,Jonathan -----Original Message-----From: Carmine Daloia [mailto:daloia@lucent.com]Sent: Monday, November 19, 2001 6:44 AMTo: ccamp@ops.ietf.orgCc: tsg15q11@itu.int; t1x15@t1.orgSubject: LMP: Suppression of Downstream Alarms...Hi all,As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms".In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message...".I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects).If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstr eam. The 3R points on the OLS Line Systems would insert some type of signal downstream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLIRequirements document(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) andcorresponding LMP-WDM protocol document (new version to be uploadedtomorrow, but old version can be found athttp://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views?Carmine Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 11:03:16 -0800 Message-ID: From: Jonathan Lang To: 'George Young' Cc: ccamp@ops.ietf.org Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Wed, 21 Nov 2001 10:57:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, Event 2 can be removed. We will need to reword events 7 & 8. My proposal below: 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. -Jonathan > -----Original Message----- > From: George Young [mailto:george.young@meriton.com] > Sent: Wednesday, November 21, 2001 5:41 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > Hello Jonathan, > > See below: > > Regards, > George R. Young > Meriton Networks Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > > >-----Original Message----- > >From: Jonathan Lang [mailto:jplang@calient.net] > >Sent: Tuesday, November 20, 2001 11:49 AM > >To: George Young > >Cc: ccamp@ops.ietf.org > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > >George, > > Please see inline. > > > >Thanks, > >Jonathan > > > >> -----Original Message----- > >> From: George Young [mailto:george.young@meriton.com] > >> Sent: Tuesday, November 20, 2001 8:34 AM > >> To: Jonathan Lang > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > >> > >> > >> Hello Jonathan, > >> > >> Comments/question below. Also please note, edgeFlow has > >> changed its name > >> to Meriton Networks Inc., and as a result the email address > >changes to > >> george.young@meriton.com. > >> > >> Regards, > >> George R. Young > >> Meriton Networks Inc. > >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 > >> phone: +1 613-270-9279 Ext 287 > >> fax: +1 613-270-9268 > >> > >> > >> >-----Original Message----- > >> >From: Jonathan Lang [mailto:jplang@calient.net] > >> >Sent: Monday, November 19, 2001 5:21 PM > >> >To: 'S Ramesh'; George Young > >> >Cc: ccamp@ops.ietf.org; Jonathan Lang > >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 > and 12.3.4) > >> > > >> > > >> >Ramesh, > >> > Please see inline. > >> > > >> >Thanks, > >> >Jonathan > >> > > >> >> -----Original Message----- > >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > >> >> Sent: Thursday, November 15, 2001 11:15 PM > >> >> To: George Young > >> >> Cc: ccamp@ops.ietf.org > >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 > >and 12.3.4) > >> >> > >> >> > >> >> Hi Young, > >> >> > >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the > >> >> Data Link FSM's in the down state also. Agreed. > >> >I would actually propose that we remove the degraded state > >> >altogether from > >> >the data link fsms. This is already captured at the TE > link level. > >> >Comments? > >> > >> If I understand your response to messrs Ramesh and moi, > transition 10 > >> should be retained from Deg to Down. > >> If you then remove the Deg state, implying that in the > Up/Alloc state > >> you may not have a control channel, where would transition 10 go? > >> > >> Transition 13 'fault localization' seems to need a control channel. > >> Without the Deg state, how would you represent the idea that > >sometimes > >> transition 13 can't take place? > >What I'm proposing is that we decouple the notion of a control > >channel with > >the data link FSMs. As Ramesh said in an email, some of these > >events can be > >generated through management interface also. For active data > >link, the FSM > >would be: > > > > +------+ > > | |<-------+ > > +--------->| Down | | > > | +----| |<-----+ | > > | | +------+ | | > > | |5b 3| ^ | | > > | | | |2,7 | | > > | | v | | | > > | | +------+ | | > > | | | |<-+ | | > > | | | Test | |11 | | > > | | | |--+ | | > > | | +------+ | | > > | | 5a| 3^ | | > > | | | | | | > > | | v | | | > > |2,12 | +---------+ | | > > | +-->| |14 | | > > | | Up/Free |----+ | > > +---------| | | > > +---------+ | > > 9| ^ | > > | | | > > v |10 | > > +---------+ | > > | |13 | > > |Up/Alloc |------+ > > | | > > +---------+ > > > > Removing the Deg state simplifies the Link FSM as it's present in > the TE FSM. Editorially then (I think), transition 2 would not take > place from Test/PasvTest to Down. > > > > >> > >> > > >> >> > >> >> 2. Transtition 10:evLnkDealloc can be possible know even in > >> >the degraded > >> >> state. Yeah a control channel is needed, but this event > >> can also be a > >> >> external event know, from the user or a network management > >> >event. If this > >> >> is possible then this event is required in this state. Kindly > >> >> clarify me. > >> >agreed. > >> > > >> >> > >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv > >> >Test state. Since > >> >> to send a Test message or to receive a Test message we > need a data > >> >channel. > >> >> If you see both the FSM's ( Data link ) event 3 & 4 will > >> >pose the next > >> >> state to Test & Pasv Test state from Up/Free state. So the event > >> >> 14.evdcDown is also possible on both the states and hence the > >> >> next state in both the case will be down. > >> >ok. > >> > > >> >> > >> >> Thanks, > >> >> Ramesh > >> >> > >> >> George Young wrote: > >> >> > >> >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > >> >> > draft-ietf-ccamp-lmp-02.txt: > >> >> > > >> >> > 1) It appears that in the Down state, the control channel > >> >> can be either > >> >> > up or > >> >> > down. That being the case, there should be transitions > >> for events 1 > >> >> > :evCCUp: > >> >> > and 2 :evCCDown: from Down to Down. > >> >> > > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > >> appear to be > >> >> > impossible, > >> >> > as there is no control channel available, and the control > >> >channel is > >> >> > required to coordinate taking the channel down at both > >> >> ends. I believe > >> >> > this > >> >> > transition should be removed. > >> >> > > >> >> > With these changes, the FSMs would look like: > >> >> > > >> >> > 12.3.3. Active Data Link FSM Description > >> >> > > >> >> > Figure 5 illustrates operation of the LMP active data > >> >> link FSM in a > >> >> > form of FSM state transition diagram. > >> >> > > >> >> > 1,2 > >> >> > +------+ > >> >> > | | > >> >> > | +------+ > >> >> > +-->| |<-------+ > >> >> > +--------->| Down | | > >> >> > | +----| |<-----+ | > >> >> > | | +------+ | | > >> >> > | |5b 3| ^ | | > >> >> > | | | |2,7 | | > >> >> > | | v | | | > >> >> > | | +------+ | | > >> >> > | | | |<-+ | | > >> >> > | | | Test | |11 | | > >> >> > | | | |--+ | | > >> >> > | | +------+ | | > >> >> > | | 5a| 3^ | | > >> >> > | | | | | | > >> >> > | | v | | | > >> >> > |2,12 | +---------+ | | > >> >> > | +-->| |14 | | > >> >> > | | Up/Free |----+ | > >> >> > +---------| | | > >> >> > +---------+ | > >> >> > 9| ^ | > >> >> > | | | > >> >> > v |10 | > >> >> > +-----+ 2 +---------+ | > >> >> > | |<--------| |13 | > >> >> > | Deg | |Up/Alloc |------+ > >> >> > | |-------->| | > >> >> > +-----+ 1 +---------+ > >> >> > > >> >> > Figure 5: Active LMP Data Link FSM > >> >> > > >> >> > 12.3.4. Passive Data Link FSM Description > >> >> > > >> >> > Figure 6 illustrates operation of the LMP passive data > >> >> link FSM in a > >> >> > form of FSM state transition diagram. > >> >> > > >> >> > 1,2 > >> >> > +------+ > >> >> > | | > >> >> > | +------+ > >> >> > +-->| |<------+ > >> >> > +---------->| Down | | > >> >> > | +-----| |<----+ | > >> >> > | | +------+ | | > >> >> > | |5b 4| ^ | | > >> >> > | | | |2,8 | | > >> >> > | | v | | | > >> >> > | | +----------+ | | > >> >> > | | | PasvTest | | | > >> >> > | | +----------+ | | > >> >> > | | 6| 4^ | | > >> >> > | | | | | | > >> >> > | | v | | | > >> >> > |2,12 | +---------+ | | > >> >> > | +--->| Up/Free |14 | | > >> >> > | | |---+ | > >> >> > +----------| | | > >> >> > +---------+ | > >> >> > 9| ^ | > >> >> > | | | > >> >> > v |10 | > >> >> > +-----+ +---------+ | > >> >> > | | 2 | |13 | > >> >> > | Deg |<--------|Up/Alloc |-----+ > >> >> > | |-------->| | > >> >> > +-----+ 1 +---------+ > >> >> > > >> >> > Figure 6: Passive LMP Data Link FSM > >> >> > > >> >> > Regards, > >> >> > George R. Young > >> >> > edgeflow Inc. > >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > >> >> > phone: +1 613-270-9279 Ext 287 > >> >> > fax: +1 613-270-9268 > >> >> > > >> >> > >-----Original Message----- > >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> >> > >Sent: Monday, November 12, 2001 9:00 PM > >> >> > >To: ccamp@ops.ietf.org > >> >> > >Subject: Two week Last Call on LMP > >> >> > > > >> >> > > > >> >> > >Hi All, > >> >> > > > >> >> > >This is to announce a two week Last Call on the LMP draft: > >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > >> Wed Nov 28. > >> >> > > > >> >> > >Please send questions, comments and requests for > clarifications > >> >> > >to the CCAMP list. > >> >> > > > >> >> > >Kireeti. > >> >> > > > >> >> > > > >> >> > >> >> > >> > > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:58:55 -0800 From: "manoj juneja" To: jplang@calient.net, ccamp@ops.ietf.org Bcc: Subject: RE: Notify Message in GMPLS Date: Wed, 21 Nov 2001 11:57:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi Jonathan, Before deleting the LSP, GMPLS is using path message to set the admin_staus to down on all the nodes. Instead of using path message why can't GMPLS use notify message. What is the reason for transmitting the complete path message ? I think notify message is the better option. If Ingress node wants to delete the already establsihed LSP then we can assume it has to send some notification event to all the nodes in the path. The purpose of notify should not be related to error. It should have some generic purpose i.e. notification of events. In future, u may have more events where notify message can be useful. Regards, manoj. >From: Jonathan Lang >To: 'manoj juneja' , "'ccamp@ops.ietf.org'" > >Subject: RE: Notify Message in GMPLS >Date: Wed, 21 Nov 2001 10:33:40 -0800 > >Manoj, > The OIF is using a subset of the GMPLS signaling for their O-UNI. The >Notify message is still included in the GMPLS Signaling drafts. > >Thanks, >Jonathan > > > -----Original Message----- > > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > > Sent: Tuesday, November 20, 2001 5:09 PM > > To: ccamp@ops.ietf.org > > Subject: Notify Message in GMPLS > > > > > > Hi All, > > There is a notify message defined for GMPLS in gmpls-rsvp-te > > -05.txt draft. The OIF's O-UNI has removed this message from the UNI > > specification. What about GMPLS ? Are the owners of this document > > thinking of removing it from here ? > > > > Regards, > > manoj. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:42:35 -0800 Message-ID: From: Jonathan Lang To: 'manoj juneja' , "'ccamp@ops.ietf.org'" Subject: RE: Notify Message in GMPLS Date: Wed, 21 Nov 2001 10:33:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Manoj, The OIF is using a subset of the GMPLS signaling for their O-UNI. The Notify message is still included in the GMPLS Signaling drafts. Thanks, Jonathan > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Tuesday, November 20, 2001 5:09 PM > To: ccamp@ops.ietf.org > Subject: Notify Message in GMPLS > > > Hi All, > There is a notify message defined for GMPLS in gmpls-rsvp-te > -05.txt draft. The OIF's O-UNI has removed this message from the UNI > specification. What about GMPLS ? Are the owners of this document > thinking of removing it from here ? > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:30:16 -0800 Message-ID: From: Jonathan Lang To: 'Carmine Daloia' , Sudheer Dharanikota Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... Date: Wed, 21 Nov 2001 10:20:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Carmine, Please see comments inline. Thanks, Jonathan Carmine Daloia wrote: Sudheer, I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system. [Sudheer] Ok Let us address the issues separately... 1. Communication between Line System and Cross connect Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion) of IETF. I am not sure if are creating a problem to solve with the alarm suppression. Let me explain... Let us assume we can correlate and suppress the alarms between the Line systems and corss connects. Then we donot need an elaborate bit-oriented protocol. This has an assumption that we are talking about not hundereds of failures but a couple of failures (for example fiber cuts). [Carmine] As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication. [Jonathan] LMP fault management can stand on its own without LMP-WDM. My point in bringing up LMP-WDM was to address the question you had a couple (hundred?) emails ago about interaction with line systems. In fact, there are applications where LMP can be run between switches on the trunk side as well (with no OLS in between). [Sudheer] 2. Communication between cross connects THis is needed to localize a fault which in turn can be used as a trigger for local restoration. [Carmine] Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing. Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective. [Jonathan] I'm not sure there is the architectural overlap that you claim. There are many protection domains involved. There are protection domains within the OLS. There are protection domains between OXC and OLS. There are protection domains between adjacent OXCs. There are protection domains between non-adjacent OXCs. Each domain has it's own requirements (transport, timing, etc.), so I don't think it's appropriate to define protection in only one protocol. - sudheer Thanks Carmine Sudheer Dharanikota wrote: Carmine... Again can you suggest a way to communicate such signals between line systems and cross connects when inband communication is not supported between these two systems? Cheers, sudheer Carmine Daloia wrote: Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline.Thanks,Jonathan -----Original Message-----From: Carmine Daloia [mailto:daloia@lucent.com]Sent: Monday, November 19, 2001 6:44 AMTo: ccamp@ops.ietf.orgCc: tsg15q11@itu.int; t1x15@t1.orgSubject: LMP: Suppression of Downstream Alarms...Hi all,As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms".In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message...".I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects).If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstream. The 3R points on the OLS Line Systems would insert some type of signal downstream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLIRequirements document(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) andcorresponding LMP-WDM protocol document (new version to be uploadedtomorrow, but old version can be found athttp://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views?Carmine Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:09:11 -0800 Message-ID: <3BFBECBB.D6C3B39C@nayna.com> Date: Wed, 21 Nov 2001 10:04:43 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------6B93A34D6F014244D3C132E7" This is a multi-part message in MIME format. --------------6B93A34D6F014244D3C132E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carmine Daloia wrote: > Hi Sudheer, > > My last comment wasn't meant to be an argument :-) > > Maybe if I propose some text specific to the suppression > of downstream alarms that would help clarify the scope of > applicability. The text would state that when client > devices (e.g., SONET/SDH cross-connects, IP routers) are > interconnected via a standard OTN network then the > suppression of downstream alarms is already handled in the > transport/user plane via the OTN overhead (both in-band > via the digitial overhead as well as out-of-band via > non-associated overhead). Also the text would address PXCs > within a standard OTN network. In this case, again the > suppression of downstream alarms is handled via the OTN > overhead. > > The implementation proposed in LMP for suppression of > downstream alarms applies to PXCs or client devices (e.g, > SONET/SDH cross-connects or IP routers) interconnected via > a non-standard DWDM network. In this case, it is assummed > that the non-standard DWDM network does not provide the > neccesary overhead within the transport/user plane to > suppress alarms on PXCs and client devices and therefore > LMP provides a mechanism to carry such alarm suppression > messages in the control plane. > > I'll take a crack at specific text so that the group can > review it. Does this sound like something that would be > helpful. > > Sure. Regards, sudheer > > --------------6B93A34D6F014244D3C132E7 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------6B93A34D6F014244D3C132E7-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:02:25 -0800 Message-Id: <200111211748.SAA08689@uabs31c015> Date: Wed, 21 Nov 2001 06:58:48 -0500 From: Internet-Drafts@ietf.org Reply-To: =?iso-8859-1?Q?Mats_Bergstr=F6m?= Subject: I-D ACTION:draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt To: Mats Bergstrom cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="-2133890903-1144747756-1006364899=:15031" Content-Transfer-Encoding: BINARY ---2133890903-1144747756-1006364899=:15031 Content-Type: TEXT/plain; charset=us-ascii A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS Interworking between Sonet and SDH Author(s) : E. Mannie, D. Papadimitriou Filename : draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Pages : 8 Date : 20-Nov-01 This document is a companion to the GMPLS extensions to control SONET/SDH networks as defined in [GMPLS-SONET-SDH], [GMPLS-SONET- SDH-EXT] and [GMPLS-SONET-SDH-RTG]. They define the SONET and SDH technology specific information needed when using GMPLS signaling. This informational memo details the GMPLS signalling and some routing specific considerations to control the interworking between SONET and SDH networks. It results from this, that interworking issues from the control plane viewpoint are well covered by the current definition of the Sonet/SDH extensions to the GMPLS protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-papadim-ccamp-gmpls-sonet-sdh-interwork-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-papadim-ccamp-gmpls-sonet-sdh-interwork-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-papadim-ccamp-gmpls-sonet-sdh-interwork-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. ---2133890903-1144747756-1006364899=:15031 Content-Type: APPLICATION/octet-stream; BOUNDARY=OtherAccess Content-Transfer-Encoding: BASE64 LS1PdGhlckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFs LWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9 Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxh aW4NCkNvbnRlbnQtSUQ6CTwyMDAxMTEyMDE1MTU0Mi5JLURAaWV0Zi5vcmc+ DQoNCkVOQ09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1wYXBhZGltLWNjYW1wLWdtcGxzLXNvbmV0LXNkaC1pbnRlcndvcmstMDAu dHh0DQoNCi0tT3RoZXJBY2Nlc3MNCkNvbnRlbnQtVHlwZTogTWVzc2FnZS9F eHRlcm5hbC1ib2R5Ow0KCW5hbWU9ImRyYWZ0LXBhcGFkaW0tY2NhbXAtZ21w bHMtc29uZXQtc2RoLWludGVyd29yay0wMC50eHQiOw0KCXNpdGU9ImZ0cC5p ZXRmLm9yZyI7DQoJYWNjZXNzLXR5cGU9ImFub24tZnRwIjsNCglkaXJlY3Rv cnk9ImludGVybmV0LWRyYWZ0cyINCg0KQ29udGVudC1UeXBlOiB0ZXh0L3Bs YWluDQpDb250ZW50LUlEOgk8MjAwMTExMjAxNTE1NDIuSS1EQGlldGYub3Jn Pg0KDQotLU90aGVyQWNjZXNzLS0NCg== ---2133890903-1144747756-1006364899=:15031-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 10:01:43 -0800 Message-Id: <200111211747.SAA08543@uabs31c015> Date: Wed, 21 Nov 2001 06:58:14 -0500 From: Internet-Drafts@ietf.org Reply-To: =?iso-8859-1?Q?Mats_Bergstr=F6m?= Subject: I-D ACTION:draft-venkatachalam-interarea-mpls-te-02.txt To: Mats Bergstrom cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="-2133890903-824023566-1006364845=:15031" Content-Transfer-Encoding: BINARY ---2133890903-824023566-1006364845=:15031 Content-Type: TEXT/plain; charset=us-ascii A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering Author(s) : S. Venkatachalam, D. Papadimitriou, S. Dharanikota Filename : draft-venkatachalam-interarea-mpls-te-02.txt Pages : 15 Date : 20-Nov-01 In this draft, we propose an architecture for the inter-area LSP setup based on a combination of constraints. We derive the architectural requirements for the routing protocols, signaling protocols and the MIBs to support such an idea. We also demonstrate how such a mechanism will reduce the crankback during LSP setup. A possible outline of the modifications to the CSPF algorithm and examples are presented. In the companion document [INTER_AREA_EXT] we elaborate on the extensions required for such architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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. ---2133890903-824023566-1006364845=:15031 Content-Type: APPLICATION/octet-stream; BOUNDARY=OtherAccess Content-Transfer-Encoding: BASE64 LS1PdGhlckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFs LWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9 Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxh aW4NCkNvbnRlbnQtSUQ6CTwyMDAxMTEyMDE1MTQyNi5JLURAaWV0Zi5vcmc+ DQoNCkVOQ09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC12ZW5rYXRhY2hhbGFtLWludGVyYXJlYS1tcGxzLXRlLTAyLnR4dA0KDQot LU90aGVyQWNjZXNzDQpDb250ZW50LVR5cGU6IE1lc3NhZ2UvRXh0ZXJuYWwt Ym9keTsNCgluYW1lPSJkcmFmdC12ZW5rYXRhY2hhbGFtLWludGVyYXJlYS1t cGxzLXRlLTAyLnR4dCI7DQoJc2l0ZT0iZnRwLmlldGYub3JnIjsNCglhY2Nl c3MtdHlwZT0iYW5vbi1mdHAiOw0KCWRpcmVjdG9yeT0iaW50ZXJuZXQtZHJh ZnRzIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtSUQ6 CTwyMDAxMTEyMDE1MTQyNi5JLURAaWV0Zi5vcmc+DQoNCi0tT3RoZXJBY2Nl c3MtLQ0K ---2133890903-824023566-1006364845=:15031-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 09:59:20 -0800 Message-ID: <3BFBE985.8090408@lucent.com> Date: Wed, 21 Nov 2001 12:51:01 -0500 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: Sudheer Dharanikota CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------040804030604040308000406" --------------040804030604040308000406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, My last comment wasn't meant to be an argument :-) Maybe if I propose some text specific to the suppression of downstream alarms that would help clarify the scope of applicability. The text would state that when client devices (e.g., SONET/SDH cross-connects, IP routers) are interconnected via a standard OTN network then the suppression of downstream alarms is already handled in the transport/user plane via the OTN overhead (both in-band via the digitial overhead as well as out-of-band via non-associated overhead). Also the text would address PXCs within a standard OTN network. In this case, again the suppression of downstream alarms is handled via the OTN overhead. The implementation proposed in LMP for suppression of downstream alarms applies to PXCs or client devices (e.g, SONET/SDH cross-connects or IP routers) interconnected via a non-standard DWDM network. In this case, it is assummed that the non-standard DWDM network does not provide the neccesary overhead within the transport/user plane to suppress alarms on PXCs and client devices and therefore LMP provides a mechanism to carry such alarm suppression messages in the control plane. I'll take a crack at specific text so that the group can review it. Does this sound like something that would be helpful. Thanks Carmine Sudheer Dharanikota wrote: > Hi again: > > Carmine Daloia wrote: > >>>> >>>> I am not assuming inband communication is supported between the >>>> cross-connect and the line system. That is why I said that when the >>>> PXC and line system are from different vendors such OAM signals >>>> would have to be carried over a separate channel (e.g., LMP-WDM >>>> control channel). However, I don't see why such signals would have >>>> to be carried over an LMP control channel between cross-connects. >>>> Also, my point about performance was that we would have to see if >>>> the LMP control channel would meet the performance requirements for >>>> such OAM signals. It very well might. If not, a bit-oriented >>>> signaling interface may be needed between the PXC and the line system. >>>> >>> >>> Ok Let us address the issues separately... >>> >>> 1. Communication between Line System and Cross connect >>> >>> Defining a bit-oriented (physical) interface and protocol is not >>> really the task (in my opinion) >>> of IETF. >>> I am not sure if are creating a problem to solve with the alarm >>> suppression. >>> Let me explain... >>> >>> Let us assume we can correlate and suppress the alarms between the >>> Line systems >>> and corss connects. Then we donot need an elaborate bit-oriented >>> protocol. This >>> has an assumption that we are talking about not hundereds of >>> failures but a couple of >>> failures (for example fiber cuts). >> >> As I said, I am not suggesting that we need a bit-oriented protocol. >> My main point was that for the communication between the line-system >> and cross-connect, we need to understand the applications that >> require such communication and the requirements for those >> applications. It may be that the requirements can be met by carrying >> messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and >> not for LMP (i.e., running between cross-connects) anyway. So for the >> sake of focusing some of this discussion let me suggest we focus on >> communication between the adjacent cross-connects and we can even >> assume that LMP-WDM handles the Cross-connect and Line System >> communication. > > Agreed we need to focus on LMP not DWDM-LMP :-) But... > the intention of the OLI document was to underdstand the requirements. > I thought most of us vouch for these requirements. Let us put the > requirements in the back-burner. If it is bit-oriented protocol it > does not interest most of us :-) > >> >> >>> 2. Communication between cross connects >>> >>> THis is needed to localize a fault which in turn can be used as a >>> trigger for local >>> restoration. >>> >> Localize a fault for what reason? To understand if the fault is >> within the protection/restoration domain. For span >> protection/restoration the end-points of the domain coincide with the >> LMP end-points. For end-to-end protection/restoration the end-points >> do not coincide with the LMP end-points. Because the end-points of a >> protection/restoration domain do not always coincide with the >> end-points of a LMP protocol, I don't think it is a good idea to lump >> messages related to protection/restoration in LMP. It will result in >> similar messages having to be defined in other protocols and >> therefore a duplication of work and processing. >> > > Again... span protection can be performed easily with the current > mechanisms supported by LMP in out-of-band communication > scenarios. > > In case of overlaping restoration scenarios such as span and end-to-end > it is required to have a localization + an attempt to recover + (if > this fails) > report to end-to-end entities for recovery. THis also vouch for the > inclusion of such mechanisms in LMP. > >> >> Will this duplication cause major issues in a network. I doubt it... >> but it just doesn't seem right from an architecture perspective. >> >>> >> > Well I guess I cannot buy this argument :-) > > Cheers, > > sudheer > >>> >>> >>> >>> - sudheer >>> >>>> >>>> Thanks >>>> Carmine >>>> >>>> Sudheer Dharanikota wrote: >>>> >>>>> Carmine... >>>>> >>>>> Again can you suggest a way to communicate such signals >>>>> between line systems and cross connects when inband >>>>> communication is not supported between these two systems? >>>>> >>>>> Cheers, >>>>> >>>>> sudheer >>>>> >>>>> Carmine Daloia wrote: >>>>> >>>>>> Jonathan, >>>>>> >>>>>> Forgot to mention, that the performance aspects of carrying OAM >>>>>> type signals over an IP based control channel in LMP-WDM would >>>>>> have to be analyzed. It is possible that the IP Control Channel >>>>>> will not provide fast enough transfer to actually suppress >>>>>> downstream alarms, however that needs to be analyzed as part of >>>>>> LMP-WDM. >>>>>> >>>>>> Thanks >>>>>> Carmine >>>>>> >>>>>> Carmine Daloia wrote: >>>>>> >>>>>>> Jonathan, >>>>>>> >>>>>>> The LMP-WDM document specifies the signaling between the >>>>>>> Cross-connect and OLS, assuming they are from different vendors. >>>>>>> If they are from different vendors, then a standard interface is >>>>>>> needed to exchange some information. One type of information >>>>>>> that would need to be exchanged is some OAM signals. Maarten >>>>>>> described some of these signals in his VBI document. However, I >>>>>>> don't see why OAM signals would have to be exchanged directly >>>>>>> between the cross-connects themselves via LMP. >>>>>>> >>>>>>> Let's look at the following network. >>>>>>> >>>>>>> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >>>>>>> >>>>>>> Note that the OLS consists of DWDM Mux/Dmux Terminals and >>>>>>> Optical Amplifiers. >>>>>>> >>>>>>> Let's assume a failure on OLSA. OLSA via overhead within an OSC >>>>>>> suppresses alarms within OLSA. OAM messages (e.g., Optical >>>>>>> Channel FDI) could be carried over the LMP-WDM control channel >>>>>>> to OXC2. OXC2 will have to forward the FDI signals downstream >>>>>>> over the LMP-WDM control channel to OLSB. OLSB will then forward >>>>>>> these FDI signals over its OSC and then over the LMP-WDM control >>>>>>> channel to OXC3..... etc... >>>>>>> >>>>>>> Note that OXC2 does not need to directly forward these FDI >>>>>>> signals to OXC3. So it is possible, that in LMP-WDM, we may need >>>>>>> to define messages corresponding to FDI signals to suppress >>>>>>> downstream alarms, however we don't need to define such messages >>>>>>> in LMP. >>>>>>> >>>>>>> Thanks >>>>>>> Carmine >>>>>>> >>>>>>> Jonathan Lang wrote: >>>>>>> >>>>>>>>Carmine, >>>>>>>> Please see inline. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Jonathan >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>>>>>>Sent: Monday, November 19, 2001 6:44 AM >>>>>>>>>To: ccamp@ops.ietf.org >>>>>>>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>>>>>>Subject: LMP: Suppression of Downstream Alarms... >>>>>>>>> >>>>>>>>> >>>>>>>>>Hi all, >>>>>>>>> >>>>>>>>>As I read through Section 6 "Fault Management", one issue that it seems >>>>>>>>>to be addressing is "Suppression of Downstream Alarms". >>>>>>>>> >>>>>>>>>In section 6.2, it states that "If data links fail between two PXCs, the >>>>>>>>>power monitoring system in all of the downstream nodes may detect LOL >>>>>>>>>and indicate a failure. To avoid multiple alarms stemming from the same >>>>>>>>>failure, LMP provides a >>>>>>>>>failure noti >>>>>>>>>fication through the Cha >>>>>>>>>nn >>>>>>>>>elStatus >>>>>>>>>message...". >>>>>>>>> >>>>>>>>>I agree that the suppression of downstream alarms is an important issue. >>>>>>>>> >>>>>>>>great! >>>>>>>> >>>>>>>>>If we look at standard networks (both SONET/SDH and OTN), this >>>>>>>>>capability is already provided by the overhead in SDH/SONET and G.709 >>>>>>>>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>>>>>>>networks as well as opaque networks. I don't think we need to burden the >>>>>>>>>control plane with such functions when the transport plane handles this >>>>>>>>>in standard networks. In fact the transport plane handles suppression of >>>>>>>>>alarms on all equipment in the network (not just cross-connects). >>>>>>>>> >>>>>>>>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>>>>>>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>>>>>>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>>>>>>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>>>>>>>downstream Cross-connects would not detect LOL upon faults occurring >>>>>>>>>upstream. The 3R >>>>>>>>>points on th >>>>>>>>>e OLS Line Systems would insert some type >>>>>>>>>of signal dow >>>>>>>>>ns >>>>>>>>>tream. Therefore the mechanism described in Section 6.2 >>>>>>>>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>>>>>>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>>>>>>>in an all-optical network may alarm due to upstream faults. These alarms >>>>>>>>>also need to be suppressed. LMP seems to only address the suppression of >>>>>>>>>downstream alarms on cross-connects without taking into consideration >>>>>>>>>the network that sits between the cross-connects. Is LMP also expected >>>>>>>>>to have to be processed on Optical Amplifiers? This seems to be >>>>>>>>>undesirable, especially given all the various applications that seem to >>>>>>>>>be included into the LMP protocol that would not have anything to do >>>>>>>>>with Optical Amplifieris. >>>>>>>>> >>>>>>>>For interaction between cross-connects and Line Systems, please see OLI >>>>>>>>Requirements document >>>>>>>>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>>>>>>>corresponding LMP-WDM protocol document (new version to be uploaded >>>>>>>>tomorrow, but old version can be found at >>>>>>>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >>>>>>>> >>>>>>>>>Any other views? >>>>>>>>> >>>>>>>>>Carmine >>>>>>>>> --------------040804030604040308000406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sudheer,

My last comment wasn't meant to be an argument :-)

Maybe if I propose some text specific to the suppression of downstream alarms that would help clarify the scope of applicability. The text would state that when client devices (e.g., SONET/SDH cross-connects, IP routers) are interconnected via a standard OTN network then the suppression of downstream alarms is already handled in the transport/user plane via the OTN overhead (both in-band via the digitial overhead as well as out-of-band via non-associated overhead). Also the text would address PXCs within a standard OTN network. In this case, again the suppression of downstream alarms is handled via the OTN overhead.

The implementation proposed in LMP for suppression of downstream alarms applies to PXCs or client devices (e.g, SONET/SDH cross-connects or IP routers) interconnected via a non-standard DWDM network. In this case, it is assummed that the non-standard DWDM network does not provide the neccesary overhead within the transport/user plane to suppress alarms on PXCs and client devices and therefore LMP provides a mechanism to carry such alarm suppression messages in the control plane.

I'll take a crack at specific text so that the group can review it. Does this sound like something that would be helpful.

Thanks
Carmine

Sudheer Dharanikota wrote:
Hi again:

Carmine Daloia wrote:

 
I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system.
 
Ok Let us address the issues separately...

1. Communication between Line System and Cross connect

Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion)
of IETF.
I am not sure if are creating a problem to solve with the alarm suppression.
Let me explain...

Let us assume we can correlate and suppress the alarms between the Line systems
and corss connects. Then we donot need an elaborate bit-oriented protocol. This
has an assumption that we are talking about not hundereds of failures but a couple of
failures (for example fiber cuts).
As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication.
Agreed we need to focus on LMP not DWDM-LMP :-) But...
the intention of the OLI document was to underdstand the requirements.
I thought most of us vouch for these requirements. Let us put the
requirements in the back-burner. If it is bit-oriented protocol it
does not interest most of us :-)
 
2. Communication between cross connects

THis is needed to localize a fault which in turn can be used as a trigger for local
restoration.

Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing.
 
Again... span protection can be performed easily with the current
mechanisms supported by LMP in out-of-band communication
scenarios.

In case of overlaping restoration scenarios such as span and end-to-end
it is required to have a localization + an attempt to recover + (if this fails)
report to end-to-end entities for recovery. THis also vouch for the
inclusion of such mechanisms in LMP.

 
Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective.
 
Well I guess I cannot buy this argument :-)

Cheers,

sudheer

 
 

- sudheer

 
Thanks
Carmine

Sudheer Dharanikota wrote:

Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP
 provides a 
failure noti
fication through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstr
eam. The 3R 
points on th
e OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine


--------------040804030604040308000406-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 09:40:55 -0800 Message-ID: <3BFBE4F0.A0F63471@nayna.com> Date: Wed, 21 Nov 2001 09:31:28 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------8078553F7B350F317A94E247" This is a multi-part message in MIME format. --------------8078553F7B350F317A94E247 Content-Type: multipart/alternative; boundary="------------25CAED12D6C487CA9EB86067" --------------25CAED12D6C487CA9EB86067 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi again: Carmine Daloia wrote: >> > >> > I am not assuming inband communication is supported >> > between the cross-connect and the line system. That is >> > why I said that when the PXC and line system are from >> > different vendors such OAM signals would have to be >> > carried over a separate channel (e.g., LMP-WDM control >> > channel). However, I don't see why such signals would >> > have to be carried over an LMP control channel between >> > cross-connects. Also, my point about performance was >> > that we would have to see if the LMP control channel >> > would meet the performance requirements for such OAM >> > signals. It very well might. If not, a bit-oriented >> > signaling interface may be needed between the PXC and >> > the line system. >> > >> >> Ok Let us address the issues separately... >> >> 1. Communication between Line System and Cross connect >> >> Defining a bit-oriented (physical) interface and >> protocol is not really the task (in my opinion) >> of IETF. >> I am not sure if are creating a problem to solve with >> the alarm suppression. >> Let me explain... > >> Let us assume we can correlate and suppress the alarms >> between the Line systems >> and corss connects. Then we donot need an elaborate >> bit-oriented protocol. This >> has an assumption that we are talking about not >> hundereds of failures but a couple of >> failures (for example fiber cuts). > > As I said, I am not suggesting that we need a bit-oriented > protocol. My main point was that for the communication > between the line-system and cross-connect, we need to > understand the applications that require such > communication and the requirements for those applications. > It may be that the requirements can be met by carrying > messages over IP (e.g., LMP-WDM). This is an issue for > LMP-WDM and not for LMP (i.e., running between > cross-connects) anyway. So for the sake of focusing some > of this discussion let me suggest we focus on > communication between the adjacent cross-connects and we > can even assume that LMP-WDM handles the Cross-connect and > Line System communication. Agreed we need to focus on LMP not DWDM-LMP :-) But... the intention of the OLI document was to underdstand the requirements. I thought most of us vouch for these requirements. Let us put the requirements in the back-burner. If it is bit-oriented protocol it does not interest most of us :-) > > >> 2. Communication between cross connects >> >> THis is needed to localize a fault which in turn can be >> used as a trigger for local >> restoration. > > Localize a fault for what reason? To understand if the > fault is within the protection/restoration domain. For > span protection/restoration the end-points of the domain > coincide with the LMP end-points. For end-to-end > protection/restoration the end-points do not coincide with > the LMP end-points. Because the end-points of a > protection/restoration domain do not always coincide with > the end-points of a LMP protocol, I don't think it is a > good idea to lump messages related to > protection/restoration in LMP. It will result in similar > messages having to be defined in other protocols and > therefore a duplication of work and processing. > Again... span protection can be performed easily with the current mechanisms supported by LMP in out-of-band communication scenarios. In case of overlaping restoration scenarios such as span and end-to-end it is required to have a localization + an attempt to recover + (if this fails) report to end-to-end entities for recovery. THis also vouch for the inclusion of such mechanisms in LMP. > > Will this duplication cause major issues in a network. I > doubt it... but it just doesn't seem right from an > architecture perspective. > >> > Well I guess I cannot buy this argument :-) Cheers, sudheer >> >> >> >> - sudheer >> >> > >> > Thanks >> > Carmine >> > >> > Sudheer Dharanikota wrote: >> > >> >> Carmine... >> >> >> >> Again can you suggest a way to communicate such >> >> signals >> >> between line systems and cross connects when inband >> >> communication is not supported between these two >> >> systems? >> >> >> >> Cheers, >> >> >> >> sudheer >> >> >> >> Carmine Daloia wrote: >> >> >> >> > Jonathan, >> >> > >> >> > Forgot to mention, that the performance aspects of >> >> > carrying OAM type signals over an IP based control >> >> > channel in LMP-WDM would have to be analyzed. It is >> >> > possible that the IP Control Channel will not >> >> > provide fast enough transfer to actually suppress >> >> > downstream alarms, however that needs to be >> >> > analyzed as part of LMP-WDM. >> >> > >> >> > Thanks >> >> > Carmine >> >> > >> >> > Carmine Daloia wrote: >> >> > >> >> >> Jonathan, >> >> >> >> >> >> The LMP-WDM document specifies the signaling >> >> >> between the Cross-connect and OLS, assuming they >> >> >> are from different vendors. If they are from >> >> >> different vendors, then a standard interface is >> >> >> needed to exchange some information. One type of >> >> >> information that would need to be exchanged is >> >> >> some OAM signals. Maarten described some of these >> >> >> signals in his VBI document. However, I don't see >> >> >> why OAM signals would have to be exchanged >> >> >> directly between the cross-connects themselves via >> >> >> LMP. >> >> >> >> >> >> Let's look at the following network. >> >> >> >> >> >> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC >> >> >> --- OXC4 >> >> >> >> >> >> Note that the OLS consists of DWDM Mux/Dmux >> >> >> Terminals and Optical Amplifiers. >> >> >> >> >> >> Let's assume a failure on OLSA. OLSA via overhead >> >> >> within an OSC suppresses alarms within OLSA. OAM >> >> >> messages (e.g., Optical Channel FDI) could be >> >> >> carried over the LMP-WDM control channel to OXC2. >> >> >> OXC2 will have to forward the FDI signals >> >> >> downstream over the LMP-WDM control channel to >> >> >> OLSB. OLSB will then forward these FDI signals >> >> >> over its OSC and then over the LMP-WDM control >> >> >> channel to OXC3..... etc... >> >> >> >> >> >> Note that OXC2 does not need to directly forward >> >> >> these FDI signals to OXC3. So it is possible, that >> >> >> in LMP-WDM, we may need to define messages >> >> >> corresponding to FDI signals to suppress >> >> >> downstream alarms, however we don't need to define >> >> >> such messages in LMP. >> >> >> >> >> >> Thanks >> >> >> Carmine >> >> >> >> >> >> Jonathan Lang wrote: >> >> >> >> >> >> > Carmine, >> >> >> > Please see inline. >> >> >> > >> >> >> > Thanks, >> >> >> > Jonathan >> >> >> > >> >> >> > >> >> >> > > -----Original Message----- >> >> >> > > From: Carmine Daloia [mailto:daloia@lucent.com] >> >> >> > > Sent: Monday, November 19, 2001 6:44 AM >> >> >> > > To: ccamp@ops.ietf.org >> >> >> > > Cc: tsg15q11@itu.int; t1x15@t1.org >> >> >> > > Subject: LMP: Suppression of Downstream >> >> >> > > Alarms... >> >> >> > > >> >> >> > > >> >> >> > > Hi all, >> >> >> > > >> >> >> > > As I read through Section 6 "Fault Management", >> >> >> > > one issue that it seems >> >> >> > > to be addressing is "Suppression of Downstream >> >> >> > > Alarms". >> >> >> > > >> >> >> > > In section 6.2, it states that "If data links >> >> >> > > fail between two PXCs, the >> >> >> > > power monitoring system in all of the >> >> >> > > downstream nodes may detect LOL >> >> >> > > and indicate a failure. To avoid multiple >> >> >> > > alarms stemming from the same >> >> >> > > failure, LMP provides a >> >> >> > > failure noti >> >> >> > > fication through the Cha >> >> >> > > nn >> >> >> > > elStatus >> >> >> > > message...". >> >> >> > > >> >> >> > > I agree that the suppression of downstream >> >> >> > > alarms is an important issue. >> >> >> > > >> >> >> > great! >> >> >> > >> >> >> > >> >> >> > > If we look at standard networks (both SONET/SDH >> >> >> > > and OTN), this >> >> >> > > capability is already provided by the overhead >> >> >> > > in SDH/SONET and G.709 >> >> >> > > OTN. G.709 OTN handles suppression of alarms in >> >> >> > > both all-optical >> >> >> > > networks as well as opaque networks. I don't >> >> >> > > think we need to burden the >> >> >> > > control plane with such functions when the >> >> >> > > transport plane handles this >> >> >> > > in standard networks. In fact the transport >> >> >> > > plane handles suppression of >> >> >> > > alarms on all equipment in the network (not >> >> >> > > just cross-connects). >> >> >> > > >> >> >> > > If we look at a pre-OTN ("non-standard") >> >> >> > > scenario consisting of >> >> >> > > Cross-connects, Optical Line Systems, and >> >> >> > > Optical Amplifiers supporting >> >> >> > > a DWDM networked solution, we can analyze two >> >> >> > > scenarios. One scenario is >> >> >> > > an opaque network (e.g., the OLS supports 3R). >> >> >> > > In this scenario, the >> >> >> > > downstream Cross-connects would not detect LOL >> >> >> > > upon faults occurring >> >> >> > > upstream. The 3R >> >> >> > > points on th >> >> >> > > e OLS Line Systems would insert some type >> >> >> > > of signal dow >> >> >> > > ns >> >> >> > > tream. Therefore the mechanism described in >> >> >> > > Section 6.2 >> >> >> > > does not apply. Another scenario is an >> >> >> > > all-optical pre-OTN network. Note >> >> >> > > that other equipment besides Cross-connects >> >> >> > > (e.g., Optical Amplifiers) >> >> >> > > in an all-optical network may alarm due to >> >> >> > > upstream faults. These alarms >> >> >> > > also need to be suppressed. LMP seems to only >> >> >> > > address the suppression of >> >> >> > > downstream alarms on cross-connects without >> >> >> > > taking into consideration >> >> >> > > the network that sits between the >> >> >> > > cross-connects. Is LMP also expected >> >> >> > > to have to be processed on Optical Amplifiers? >> >> >> > > This seems to be >> >> >> > > undesirable, especially given all the various >> >> >> > > applications that seem to >> >> >> > > be included into the LMP protocol that would >> >> >> > > not have anything to do >> >> >> > > with Optical Amplifieris. >> >> >> > > >> >> >> > For interaction between cross-connects and Line >> >> >> > Systems, please see OLI >> >> >> > Requirements document >> >> >> > ( >> >> >> > http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> >> >> > ) and >> >> >> > corresponding LMP-WDM protocol document (new >> >> >> > version to be uploaded >> >> >> > tomorrow, but old version can be found at >> >> >> > http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> >> >> > ). >> >> >> > >> >> >> > >> >> >> > > Any other views? >> >> >> > > >> >> >> > > Carmine >> >> >> > > >> >> >> > > --------------25CAED12D6C487CA9EB86067 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi again:

Carmine Daloia wrote:

 
I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system.
 
Ok Let us address the issues separately...

1. Communication between Line System and Cross connect

Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion)
of IETF.
I am not sure if are creating a problem to solve with the alarm suppression.
Let me explain...

Let us assume we can correlate and suppress the alarms between the Line systems
and corss connects. Then we donot need an elaborate bit-oriented protocol. This
has an assumption that we are talking about not hundereds of failures but a couple of
failures (for example fiber cuts).
As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication.
Agreed we need to focus on LMP not DWDM-LMP :-) But...
the intention of the OLI document was to underdstand the requirements.
I thought most of us vouch for these requirements. Let us put the
requirements in the back-burner. If it is bit-oriented protocol it
does not interest most of us :-)
 
2. Communication between cross connects

THis is needed to localize a fault which in turn can be used as a trigger for local
restoration.

Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing.
 
Again... span protection can be performed easily with the current
mechanisms supported by LMP in out-of-band communication
scenarios.

In case of overlaping restoration scenarios such as span and end-to-end
it is required to have a localization + an attempt to recover + (if this fails)
report to end-to-end entities for recovery. THis also vouch for the
inclusion of such mechanisms in LMP.

 
Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective.
 
Well I guess I cannot buy this argument :-)

Cheers,

sudheer

 
 

- sudheer

 
Thanks
Carmine

Sudheer Dharanikota wrote:

Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan


-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a 
failure noti
fication through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!


If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R 
points on th
e OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).


Any other views?

Carmine
--------------25CAED12D6C487CA9EB86067-- --------------8078553F7B350F317A94E247 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------8078553F7B350F317A94E247-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 09:29:21 -0800 Message-ID: From: Jonathan Lang To: 'George Young' , Carmine Daloia Cc: ccamp@ops.ietf.org Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... Date: Wed, 21 Nov 2001 09:20:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, This note makes a lot of sense. Thanks, Jonathan > -----Original Message----- > From: George Young [mailto:george.young@meriton.com] > Sent: Wednesday, November 21, 2001 6:37 AM > To: Carmine Daloia > Cc: ccamp@ops.ietf.org > Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... > > > Hello Carmine, > > For span protection, LMP can stand on its own, localizing the fault, making sure > that both ends of the fault span know about the failure. > > In a transparent network (which is where my company is focused), the node at the receive > end of a faulty link, and any nodes downstream (in the data flow direction) become aware > of the fault, so one end of the path knows almost immediately. > > For path protection, there would still be a need for signalling to the other end. The benefit > of using LMP to localize the fault, is that only one node need initiate > the signalling to the > head and the tail of the connection to toggle to the backup path. > > Regards, > George R. Young > Meriton Networks Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > -----Original Message----- > From: Carmine Daloia [mailto:daloia@lucent.com] > Sent: Wednesday, November 21, 2001 9:23 AM > To: George Young > Cc: ccamp@ops.ietf.org > Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... > > > Hi George, > > Thanks for the pointer to your draft. I will definitely read over it. > Just looking at it quickly and understanding what is in LMP, it seems > that even under path protection/restoration, there is an intermediate > node that detects a failure (and localizes the failure to ensure that > the failure occured on that particular link) and then signals over the > control plane to the head-end and tail-end nodes of the > protection/restoration domain to initiate protection/restoration. > > It seems to me that the tail-end and head-end nodes > themselves would be > able to detect the defect in the transport/user plane since the defect > occured between the two ends and they can then coordinate > switching for > protection/restoration without having to wait for any notification > message sent from an intermediate NE. This should improve the > protection/restoration time since the head-end and tail-end won't need > to wait for intermediate nodes to localize a fault and then > signal over > a control plane requesting a proteciton/restoration switch. Any > thoughts? > > Thanks > Carmine > > George Young wrote: > > > Hello Carmine, > > Meriton Networks intends to use LMP as a fault localization > mechanism in > a network of > our transparent optical switches, currently in the > pre-production phase. > > I've done some discrete event simulation work to characterize the > performance of an IP > network in support LMP management signals, and the resulting > signalling > messages needed > to initiate protection/restoration, and based on the results, have not > seen any need to change > our design direction. > > I've also written and submitted an IETF draft > http://search.ietf.org/internet-drafts/draft-young-opt-nni-pro > t-issues-0 > 0.txt > dealing with the importance of control network performance, > particularly > when extended across > multiple networks, and would appreciate any comments you might have. > > Regards, > George R. Young > Meriton Networks Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > -----Original Message----- > From: Carmine Daloia [ mailto:daloia@lucent.com] > Sent: Wednesday, November 21, 2001 8:29 AM > To: Carmine Daloia > Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org > Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... > > > Jonathan, > > Forgot to mention, that the performance aspects of carrying OAM type > signals over an IP based control channel in LMP-WDM would have to be > analyzed. It is possible that the IP Control Channel will not provide > fast enough transfer to actually suppress downstream alarms, however > that needs to be analyzed as part of LMP-WDM. > > Thanks > Carmine > > Carmine Daloia wrote: > > > Jonathan, > > The LMP-WDM document specifies the signaling between the Cross-connect > and OLS, assuming they are from different vendors. If they are from > different vendors, then a standard interface is needed to > exchange some > information. One type of information that would need to be > exchanged is > some OAM signals. Maarten described some of these signals in his VBI > document. However, I don't see why OAM signals would have to be > exchanged directly between the cross-connects themselves via LMP. > > Let's look at the following network. > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical > Amplifiers. > > Let's assume a failure on OLSA. OLSA via overhead within an OSC > suppresses alarms within OLSA. OAM messages (e.g., Optical > Channel FDI) > could be carried over the LMP-WDM control channel to OXC2. OXC2 will > have to forward the FDI signals downstream over the LMP-WDM control > channel to OLSB. OLSB will then forward these FDI signals over its OSC > and then over the LMP-WDM control channel to OXC3..... etc... > > Note that OXC2 does not need to directly forward these FDI signals to > OXC3. So it is possible, that in LMP-WDM, we may need to > define messages > corresponding to FDI signals to suppress downstream alarms, however we > don't need to define such messages in LMP. > > Thanks > Carmine > > Jonathan Lang wrote: > > > Carmine, > Please see inline. > > Thanks, > Jonathan > > > -----Original Message----- > From: Carmine Daloia [ mailto:daloia@lucent.com] > Sent: Monday, November 19, 2001 6:44 AM > To: ccamp@ops.ietf.org > Cc: tsg15q11@itu.int; t1x15@t1.org > Subject: LMP: Suppression of Downstream Alarms... > > > Hi all, > > As I read through Section 6 "Fault Management", one issue > that it seems > to be addressing is "Suppression of Downstream Alarms". > > In section 6.2, it states that "If data links fail between > two PXCs, the > > power monitoring system in all of the downstream nodes may detect LOL > and indicate a failure. To avoid multiple alarms stemming > from the same > failure, LMP provides a failure notification through the > > Cha > nn > elStatus > message...". > > I agree that the suppression of downstream alarms is an > important issue. > > great! > > > If we look at standard networks (both SONET/SDH and OTN), this > capability is already provided by the overhead in SDH/SONET and G.709 > OTN. G.709 OTN handles suppression of alarms in both all-optical > networks as well as opaque networks. I don't think we need to > burden the > > control plane with such functions when the transport plane > handles this > in standard networks. In fact the transport plane handles > suppression of > > alarms on all equipment in the network (not just cross-connects). > > If we look at a pre-OTN ("non-standard") scenario consisting of > Cross-connects, Optical Line Systems, and Optical Amplifiers > supporting > a DWDM networked solution, we can analyze two scenarios. One > scenario is > > an opaque network (e.g., the OLS supports 3R). In this scenario, the > downstream Cross-connects would not detect LOL upon faults occurring > upstream. The 3R points on the OLS Line Systems would insert > some type > of signal > > dow > ns > tream. Therefore the mechanism described in Section 6.2 > does not apply. Another scenario is an all-optical pre-OTN > network. Note > > that other equipment besides Cross-connects (e.g., Optical > Amplifiers) > in an all-optical network may alarm due to upstream faults. > These alarms > > also need to be suppressed. LMP seems to only address the > suppression of > > downstream alarms on cross-connects without taking into consideration > the network that sits between the cross-connects. Is LMP also > expected > to have to be processed on Optical Amplifiers? This seems to be > undesirable, especially given all the various applications > that seem to > be included into the LMP protocol that would not have anything to do > with Optical Amplifieris. > > For interaction between cross-connects and Line Systems, > please see OLI > Requirements document > ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) > and > corresponding LMP-WDM protocol document (new version to be uploaded > tomorrow, but old version can be found at > http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). > > > Any other views? > > Carmine > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 09:04:20 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dimitri Papadimitriou Cc: Maarten Vissers , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Message-Id: Date: Wed, 21 Nov 2001 09:03:53 -0800 > We know it, and updated version will be free from "re-documentation" > of Sonet/SDH. This why we call such a document a draft isn't it ? i thought is was for the wonderful fresh air and light it let it randy Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 09:00:34 -0800 Message-ID: <3BFBDD43.F63ED64A@alcatel.be> Date: Wed, 21 Nov 2001 17:58:43 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Randy Bush CC: Maarten Vissers , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------44BF390032AB6CB4C1E3D139" This is a multi-part message in MIME format. --------------44BF390032AB6CB4C1E3D139 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, We know it, and updated version will be free from "re-documentation" of Sonet/SDH. This why we call such a document a draft isn't it ? - dimitri. Randy Bush wrote: > > > I don't know if it is necessary to redescribe SDH/SONET processing in an > > IETF document. I would prefer references to the appropriate SDH standards; > > otherwise you get different specifications and people get confused. > > you are being too polite. it is anethema to redocument sdh/sonet here. > > it feels to me that too much of the recent sdh/sonet discussion really > belongs in the itu. > > randy --------------44BF390032AB6CB4C1E3D139 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------44BF390032AB6CB4C1E3D139-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:52:32 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Maarten Vissers Cc: Dimitri Papadimitriou , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Message-Id: Date: Wed, 21 Nov 2001 08:51:16 -0800 > I don't know if it is necessary to redescribe SDH/SONET processing in an > IETF document. I would prefer references to the appropriate SDH standards; > otherwise you get different specifications and people get confused. you are being too polite. it is anethema to redocument sdh/sonet here. it feels to me that too much of the recent sdh/sonet discussion really belongs in the itu. randy Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:47:24 -0800 Message-ID: <3BFBDB04.4050106@lucent.com> Date: Wed, 21 Nov 2001 11:49:08 -0500 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: Sudheer Dharanikota CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------060407020908050009020402" --------------060407020908050009020402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, See inline. Thanks Carmine Sudheer Dharanikota wrote: > Hi again: > > Carmine Daloia wrote: > >> Sudheer, >> >> I am not assuming inband communication is supported between the >> cross-connect and the line system. That is why I said that when the >> PXC and line system are from different vendors such OAM signals would >> have to be carried over a separate channel (e.g., LMP-WDM control >> channel). However, I don't see why such signals would have to be >> carried over an LMP control channel between cross-connects. Also, my >> point about performance was that we would have to see if the LMP >> control channel would meet the performance requirements for such OAM >> signals. It very well might. If not, a bit-oriented signaling >> interface may be needed between the PXC and the line system. >> >> > Ok Let us address the issues separately... > > 1. Communication between Line System and Cross connect > > Defining a bit-oriented (physical) interface and protocol is not > really the task (in my opinion) > of IETF. > I am not sure if are creating a problem to solve with the alarm > suppression. > Let me explain... > > Let us assume we can correlate and suppress the alarms between the > Line systems > and corss connects. Then we donot need an elaborate bit-oriented > protocol. This > has an assumption that we are talking about not hundereds of failures > but a couple of > failures (for example fiber cuts). > As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication. > 2. Communication between cross connects > > THis is needed to localize a fault which in turn can be used as a > trigger for local > restoration. > Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing. Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective. > > > > - sudheer > >> >> Thanks >> Carmine >> >> Sudheer Dharanikota wrote: >> >>> Carmine... >>> >>> Again can you suggest a way to communicate such signals >>> between line systems and cross connects when inband >>> communication is not supported between these two systems? >>> >>> Cheers, >>> >>> sudheer >>> >>> Carmine Daloia wrote: >>> >>>> Jonathan, >>>> >>>> Forgot to mention, that the performance aspects of carrying OAM >>>> type signals over an IP based control channel in LMP-WDM would have >>>> to be analyzed. It is possible that the IP Control Channel will not >>>> provide fast enough transfer to actually suppress downstream >>>> alarms, however that needs to be analyzed as part of LMP-WDM. >>>> >>>> Thanks >>>> Carmine >>>> >>>> Carmine Daloia wrote: >>>> >>>>> Jonathan, >>>>> >>>>> The LMP-WDM document specifies the signaling between the >>>>> Cross-connect and OLS, assuming they are from different vendors. >>>>> If they are from different vendors, then a standard interface is >>>>> needed to exchange some information. One type of information that >>>>> would need to be exchanged is some OAM signals. Maarten described >>>>> some of these signals in his VBI document. However, I don't see >>>>> why OAM signals would have to be exchanged directly between the >>>>> cross-connects themselves via LMP. >>>>> >>>>> Let's look at the following network. >>>>> >>>>> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >>>>> >>>>> Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical >>>>> Amplifiers. >>>>> >>>>> Let's assume a failure on OLSA. OLSA via overhead within an OSC >>>>> suppresses alarms within OLSA. OAM messages (e.g., Optical Channel >>>>> FDI) could be carried over the LMP-WDM control channel to OXC2. >>>>> OXC2 will have to forward the FDI signals downstream over the >>>>> LMP-WDM control channel to OLSB. OLSB will then forward these FDI >>>>> signals over its OSC and then over the LMP-WDM control channel to >>>>> OXC3..... etc... >>>>> >>>>> Note that OXC2 does not need to directly forward these FDI signals >>>>> to OXC3. So it is possible, that in LMP-WDM, we may need to define >>>>> messages corresponding to FDI signals to suppress downstream >>>>> alarms, however we don't need to define such messages in LMP. >>>>> >>>>> Thanks >>>>> Carmine >>>>> >>>>> Jonathan Lang wrote: >>>>> >>>>>>Carmine, >>>>>> Please see inline. >>>>>> >>>>>>Thanks, >>>>>>Jonathan >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>>>>Sent: Monday, November 19, 2001 6:44 AM >>>>>>>To: ccamp@ops.ietf.org >>>>>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>>>>Subject: LMP: Suppression of Downstream Alarms... >>>>>>> >>>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>As I read through Section 6 "Fault Management", one issue that it seems >>>>>>>to be addressing is "Suppression of Downstream Alarms". >>>>>>> >>>>>>>In section 6.2, it states that "If data links fail between two PXCs, the >>>>>>>power monitoring system in all of the downstream nodes may detect LOL >>>>>>>and indicate a failure. To avoid multiple alarms stemming from the same >>>>>>>failure, LMP provides a failure noti >>>>>>>fication through the Cha >>>>>>>nn >>>>>>>elStatus >>>>>>>message...". >>>>>>> >>>>>>>I agree that the suppression of downstream alarms is an important issue. >>>>>>> >>>>>>great! >>>>>> >>>>>>>If we look at standard networks (both SONET/SDH and OTN), this >>>>>>>capability is already provided by the overhead in SDH/SONET and G.709 >>>>>>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>>>>>networks as well as opaque networks. I don't think we need to burden the >>>>>>>control plane with such functions when the transport plane handles this >>>>>>>in standard networks. In fact the transport plane handles suppression of >>>>>>>alarms on all equipment in the network (not just cross-connects). >>>>>>> >>>>>>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>>>>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>>>>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>>>>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>>>>>downstream Cross-connects would not detect LOL upon faults occurring >>>>>>>upstream. The 3R points on th >>>>>>>e OLS Line Systems would insert some type >>>>>>>of signal dow >>>>>>>ns >>>>>>>tream. Therefore the mechanism described in Section 6.2 >>>>>>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>>>>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>>>>>in an all-optical network may alarm due to upstream faults. These alarms >>>>>>>also need to be suppressed. LMP seems to only address the suppression of >>>>>>>downstream alarms on cross-connects without taking into consideration >>>>>>>the network that sits between the cross-connects. Is LMP also expected >>>>>>>to have to be processed on Optical Amplifiers? This seems to be >>>>>>>undesirable, especially given all the various applications that seem to >>>>>>>be included into the LMP protocol that would not have anything to do >>>>>>>with Optical Amplifieris. >>>>>>> >>>>>>For interaction between cross-connects and Line Systems, please see OLI >>>>>>Requirements document >>>>>>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>>>>>corresponding LMP-WDM protocol document (new version to be uploaded >>>>>>tomorrow, but old version can be found at >>>>>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >>>>>> >>>>>>>Any other views? >>>>>>> >>>>>>>Carmine >>>>>>> --------------060407020908050009020402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sudheer,

See inline.

Thanks
Carmine

Sudheer Dharanikota wrote:
Hi again:

Carmine Daloia wrote:

Sudheer,

I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system.
 

Ok Let us address the issues separately...

1. Communication between Line System and Cross connect

Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion)
of IETF.
I am not sure if are creating a problem to solve with the alarm suppression.
Let me explain...

Let us assume we can correlate and suppress the alarms between the Line systems
and corss connects. Then we donot need an elaborate bit-oriented protocol. This
has an assumption that we are talking about not hundereds of failures but a couple of
failures (for example fiber cuts).

As I said, I am not suggesting that we need a bit-oriented protocol. My main point was that for the communication between the line-system and cross-connect, we need to understand the applications that require such communication and the requirements for those applications. It may be that the requirements can be met by carrying messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and not for LMP (i.e., running between cross-connects) anyway. So for the sake of focusing some of this discussion let me suggest we focus on communication between the adjacent cross-connects and we can even assume that LMP-WDM handles the Cross-connect and Line System communication.

2. Communication between cross connects

THis is needed to localize a fault which in turn can be used as a trigger for local
restoration.

Localize a fault for what reason? To understand if the fault is within the protection/restoration domain. For span protection/restoration the end-points of the domain coincide with the LMP end-points. For end-to-end protection/restoration the end-points do not coincide with the LMP end-points. Because the end-points of a protection/restoration domain do not always coincide with the end-points of a LMP protocol, I don't think it is a good idea to lump messages related to protection/restoration in LMP. It will result in similar messages having to be defined in other protocols and therefore a duplication of work and processing.

Will this duplication cause major issues in a network. I doubt it... but it just doesn't seem right from an architecture perspective.


 

- sudheer

 
Thanks
Carmine

Sudheer Dharanikota wrote:

Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a 
failure noti
fication through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R 
points on th
e OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine


--------------060407020908050009020402-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:21:25 -0800 content-class: urn:content-classes:message Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C172A8.1633987C" Date: Wed, 21 Nov 2001 11:17:59 -0500 Message-ID: Thread-Topic: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Thread-Index: AcFyqBYm7VoWu/+hRNG5zLRMlsK7JQ== From: "George Young" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C172A8.1633987C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This posting may have been bounced while my email address was changing. 1 attachment: <>=20 ------_=_NextPart_001_01C172A8.1633987C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2001 08:41:13 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Thread-Index: AcFx46GEpjxwbmQHSJ2CW6NVysfwIAArWvGg From: "George Young" To: "Jonathan Lang" Cc: Hello Jonathan, See below: Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: Jonathan Lang [mailto:jplang@calient.net] >Sent: Tuesday, November 20, 2001 11:49 AM >To: George Young >Cc: ccamp@ops.ietf.org >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > >George, > Please see inline. > >Thanks, >Jonathan > >> -----Original Message----- >> From: George Young [mailto:george.young@meriton.com] >> Sent: Tuesday, November 20, 2001 8:34 AM >> To: Jonathan Lang >> Cc: ccamp@ops.ietf.org >> Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) >>=20 >>=20 >> Hello Jonathan, >>=20 >> Comments/question below. Also please note, edgeFlow has=20 >> changed its name >> to Meriton Networks Inc., and as a result the email address=20 >changes to >> george.young@meriton.com. >>=20 >> Regards, >> George R. Young >> Meriton Networks Inc. >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> phone: +1 613-270-9279 Ext 287 >> fax: +1 613-270-9268 >>=20 >>=20 >> >-----Original Message----- >> >From: Jonathan Lang [mailto:jplang@calient.net] >> >Sent: Monday, November 19, 2001 5:21 PM >> >To: 'S Ramesh'; George Young >> >Cc: ccamp@ops.ietf.org; Jonathan Lang >> >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) >> > >> > >> >Ramesh, >> > Please see inline. >> > >> >Thanks, >> >Jonathan >> > >> >> -----Original Message----- >> >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] >> >> Sent: Thursday, November 15, 2001 11:15 PM >> >> To: George Young >> >> Cc: ccamp@ops.ietf.org >> >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3=20 >and 12.3.4) >> >>=20 >> >>=20 >> >> Hi Young, >> >>=20 >> >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the=20 >> >> Data Link FSM's in the down state also. Agreed. >> >I would actually propose that we remove the degraded state=20 >> >altogether from >> >the data link fsms. This is already captured at the TE link level. >> >Comments? >>=20 >> If I understand your response to messrs Ramesh and moi, transition 10 >> should be retained from Deg to Down. >> If you then remove the Deg state, implying that in the Up/Alloc state >> you may not have a control channel, where would transition 10 go? >>=20 >> Transition 13 'fault localization' seems to need a control channel. >> Without the Deg state, how would you represent the idea that=20 >sometimes >> transition 13 can't take place? >What I'm proposing is that we decouple the notion of a control=20 >channel with >the data link FSMs. As Ramesh said in an email, some of these=20 >events can be >generated through management interface also. For active data=20 >link, the FSM >would be: > > +------+ > | |<-------+ > +--------->| Down | | > | +----| |<-----+ | > | | +------+ | | > | |5b 3| ^ | | > | | | |2,7 | | > | | v | | | > | | +------+ | | > | | | |<-+ | | > | | | Test | |11 | | > | | | |--+ | | > | | +------+ | | > | | 5a| 3^ | | > | | | | | | > | | v | | | > |2,12 | +---------+ | | > | +-->| |14 | | > | | Up/Free |----+ | > +---------| | | > +---------+ | > 9| ^ | > | | | > v |10 | > +---------+ | > | |13 | > |Up/Alloc |------+ > | | > +---------+ > Removing the Deg state simplifies the Link FSM as it's present in=20 the TE FSM. Editorially then (I think), transition 2 would not take=20 place from Test/PasvTest to Down. > >>=20 >> > >> >>=20 >> >> 2. Transtition 10:evLnkDealloc can be possible know even in=20 >> >the degraded >> >> state. Yeah a control channel is needed, but this event=20 >> can also be a >> >> external event know, from the user or a network management=20 >> >event. If this >> >> is possible then this event is required in this state. Kindly=20 >> >> clarify me. >> >agreed. >> > >> >>=20 >> >> 3. Also event 14.evdcDown can also possible in Test/Pasv=20 >> >Test state. Since >> >> to send a Test message or to receive a Test message we need a data >> >channel. >> >> If you see both the FSM's ( Data link ) event 3 & 4 will=20 >> >pose the next >> >> state to Test & Pasv Test state from Up/Free state. So the event >> >> 14.evdcDown is also possible on both the states and hence the=20 >> >> next state in both the case will be down. >> >ok. >> > >> >>=20 >> >> Thanks, >> >> Ramesh >> >>=20 >> >> George Young wrote: >> >>=20 >> >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of >> >> > draft-ietf-ccamp-lmp-02.txt: >> >> > >> >> > 1) It appears that in the Down state, the control channel=20 >> >> can be either >> >> > up or >> >> > down. That being the case, there should be transitions=20 >> for events 1 >> >> > :evCCUp: >> >> > and 2 :evCCDown: from Down to Down. >> >> > >> >> > 2) Transition 10:evLnkDealloc: from Deg to Down would=20 >> appear to be >> >> > impossible, >> >> > as there is no control channel available, and the control=20 >> >channel is >> >> > required to coordinate taking the channel down at both=20 >> >> ends. I believe >> >> > this >> >> > transition should be removed. >> >> > >> >> > With these changes, the FSMs would look like: >> >> > >> >> > 12.3.3. Active Data Link FSM Description >> >> > >> >> > Figure 5 illustrates operation of the LMP active data=20 >> >> link FSM in a >> >> > form of FSM state transition diagram. >> >> > >> >> > 1,2 >> >> > +------+ >> >> > | | >> >> > | +------+ >> >> > +-->| |<-------+ >> >> > +--------->| Down | | >> >> > | +----| |<-----+ | >> >> > | | +------+ | | >> >> > | |5b 3| ^ | | >> >> > | | | |2,7 | | >> >> > | | v | | | >> >> > | | +------+ | | >> >> > | | | |<-+ | | >> >> > | | | Test | |11 | | >> >> > | | | |--+ | | >> >> > | | +------+ | | >> >> > | | 5a| 3^ | | >> >> > | | | | | | >> >> > | | v | | | >> >> > |2,12 | +---------+ | | >> >> > | +-->| |14 | | >> >> > | | Up/Free |----+ | >> >> > +---------| | | >> >> > +---------+ | >> >> > 9| ^ | >> >> > | | | >> >> > v |10 | >> >> > +-----+ 2 +---------+ | >> >> > | |<--------| |13 | >> >> > | Deg | |Up/Alloc |------+ >> >> > | |-------->| | >> >> > +-----+ 1 +---------+ >> >> > >> >> > Figure 5: Active LMP Data Link FSM >> >> > >> >> > 12.3.4. Passive Data Link FSM Description >> >> > >> >> > Figure 6 illustrates operation of the LMP passive data=20 >> >> link FSM in a >> >> > form of FSM state transition diagram. >> >> > >> >> > 1,2 >> >> > +------+ >> >> > | | >> >> > | +------+ >> >> > +-->| |<------+ >> >> > +---------->| Down | | >> >> > | +-----| |<----+ | >> >> > | | +------+ | | >> >> > | |5b 4| ^ | | >> >> > | | | |2,8 | | >> >> > | | v | | | >> >> > | | +----------+ | | >> >> > | | | PasvTest | | | >> >> > | | +----------+ | | >> >> > | | 6| 4^ | | >> >> > | | | | | | >> >> > | | v | | | >> >> > |2,12 | +---------+ | | >> >> > | +--->| Up/Free |14 | | >> >> > | | |---+ | >> >> > +----------| | | >> >> > +---------+ | >> >> > 9| ^ | >> >> > | | | >> >> > v |10 | >> >> > +-----+ +---------+ | >> >> > | | 2 | |13 | >> >> > | Deg |<--------|Up/Alloc |-----+ >> >> > | |-------->| | >> >> > +-----+ 1 +---------+ >> >> > >> >> > Figure 6: Passive LMP Data Link FSM >> >> > >> >> > Regards, >> >> > George R. Young >> >> > edgeflow Inc. >> >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> >> > phone: +1 613-270-9279 Ext 287 >> >> > fax: +1 613-270-9268 >> >> > >> >> > >-----Original Message----- >> >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] >> >> > >Sent: Monday, November 12, 2001 9:00 PM >> >> > >To: ccamp@ops.ietf.org >> >> > >Subject: Two week Last Call on LMP >> >> > > >> >> > > >> >> > >Hi All, >> >> > > >> >> > >This is to announce a two week Last Call on the LMP draft: >> >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB=20 >> Wed Nov 28. >> >> > > >> >> > >Please send questions, comments and requests for clarifications >> >> > >to the CCAMP list. >> >> > > >> >> > >Kireeti. >> >> > > >> >> > > >> >>=20 >> >>=20 >> > >>=20 > ------_=_NextPart_001_01C172A8.1633987C-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:18:46 -0800 content-class: urn:content-classes:message Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C172A7.ACBA2C53" Date: Wed, 21 Nov 2001 11:15:02 -0500 Message-ID: Thread-Topic: RE: [T1X1.5] Re: Suppression of Downstream Alarms... Thread-Index: AcFyp6yhQ3WgSQEYQkWPvZogP+25sw== From: "George Young" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C172A7.ACBA2C53 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A couple of my mail message on this subject were bounced whilst I was=20 in the process of changing email address to correspond with my company's new name. 2 Attachments: <> <>=20 ------_=_NextPart_001_01C172A7.ACBA2C53 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2001 09:37:26 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [T1X1.5] Re: Suppression of Downstream Alarms... Thread-Index: AcFylyxmxl9RZbk6R4mY7dcutTroHgAAFQrQ From: "George Young" To: "Carmine Daloia" Cc: Hello Carmine, =20 For span protection, LMP can stand on its own, localizing the fault, making sure that both ends of the fault span know about the failure. =20 In a transparent network (which is where my company is focused), the node at the receive end of a faulty link, and any nodes downstream (in the data flow direction) become aware=20 of the fault, so one end of the path knows almost immediately. =20 For path protection, there would still be a need for signalling to the other end. The benefit=20 of using LMP to localize the fault, is that only one node need initiate the signalling to the=20 head and the tail of the connection to toggle to the backup path. =20 Regards, George R. Young Meriton Networks Inc.=20 329 March Rd., Kanata, ON, Canada, K2K 2E1=20 phone: +1 613-270-9279 Ext 287=20 fax: +1 613-270-9268=20 -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 9:23 AM To: George Young Cc: ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Hi George, Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration. It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE. This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts? Thanks Carmine George Young wrote: Hello Carmine, =20 Meriton Networks intends to use LMP as a fault localization mechanism in a network of our transparent optical switches, currently in the pre-production phase. =20 I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change=20 our design direction. =20 I've also written and submitted an IETF draft=20 http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-0 0.txt=20 dealing with the importance of control network performance, particularly when extended across=20 multiple networks, and would appreciate any comments you might have. =20 Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 8:29 AM To: Carmine Daloia Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline. Thanks, Jonathan -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Monday, November 19, 2001 6:44 AM To: ccamp@ops.ietf.org Cc: tsg15q11@itu.int; t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Hi all, As I read through Section 6 "Fault Management", one issue that it seems=20 to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL=20 and indicate a failure. To avoid multiple alarms stemming from the same=20 failure, LMP provides a failure notification through the Cha nn elStatus=20 message...". I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this=20 capability is already provided by the overhead in SDH/SONET and G.709=20 OTN. G.709 OTN handles suppression of alarms in both all-optical=20 networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this=20 in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of=20 Cross-connects, Optical Line Systems, and Optical Amplifiers supporting=20 a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the=20 downstream Cross-connects would not detect LOL upon faults occurring=20 upstream. The 3R points on the OLS Line Systems would insert some type=20 of signal dow ns tream. Therefore the mechanism described in Section 6.2=20 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers)=20 in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration=20 the network that sits between the cross-connects. Is LMP also expected=20 to have to be processed on Optical Amplifiers? This seems to be=20 undesirable, especially given all the various applications that seem to=20 be included into the LMP protocol that would not have anything to do=20 with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLI Requirements document ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and corresponding LMP-WDM protocol document (new version to be uploaded tomorrow, but old version can be found at http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views? Carmine ------_=_NextPart_001_01C172A7.ACBA2C53 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2001 08:58:26 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [T1X1.5] Re: Suppression of Downstream Alarms... Thread-Index: AcFykUmchufyQivzTViN9MAk/SqzcQAAP8ng From: "George Young" To: "Carmine Daloia" Cc: Hello Carmine, =20 Meriton Networks intends to use LMP as a fault localization mechanism in a network of our transparent optical switches, currently in the pre-production phase. =20 I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change=20 our design direction. =20 I've also written and submitted an IETF draft=20 http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-0 0.txt dealing with the importance of control network performance, particularly when extended across=20 multiple networks, and would appreciate any comments you might have. =20 Regards, George R. Young Meriton Networks Inc.=20 329 March Rd., Kanata, ON, Canada, K2K 2E1=20 phone: +1 613-270-9279 Ext 287=20 fax: +1 613-270-9268=20 -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 8:29 AM To: Carmine Daloia Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline. Thanks, Jonathan -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Monday, November 19, 2001 6:44 AM To: ccamp@ops.ietf.org Cc: tsg15q11@itu.int; t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Hi all, As I read through Section 6 "Fault Management", one issue that it seems=20 to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL=20 and indicate a failure. To avoid multiple alarms stemming from the same=20 failure, LMP provides a failure notification through the Cha nn elStatus=20 message...". I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this=20 capability is already provided by the overhead in SDH/SONET and G.709=20 OTN. G.709 OTN handles suppression of alarms in both all-optical=20 networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this=20 in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of=20 Cross-connects, Optical Line Systems, and Optical Amplifiers supporting=20 a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the=20 downstream Cross-connects would not detect LOL upon faults occurring=20 upstream. The 3R points on the OLS Line Systems would insert some type=20 of signal dow ns tream. Therefore the mechanism described in Section 6.2=20 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers)=20 in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration=20 the network that sits between the cross-connects. Is LMP also expected=20 to have to be processed on Optical Amplifiers? This seems to be=20 undesirable, especially given all the various applications that seem to=20 be included into the LMP protocol that would not have anything to do=20 with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLI Requirements document ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and corresponding LMP-WDM protocol document (new version to be uploaded tomorrow, but old version can be found at http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views? Carmine ------_=_NextPart_001_01C172A7.ACBA2C53-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:05:19 -0800 Message-ID: <3BFBCFC6.D0E3DAD7@alcatel.be> Date: Wed, 21 Nov 2001 17:01:10 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------37D4C642377700967AB87A75" This is a multi-part message in MIME format. --------------37D4C642377700967AB87A75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, I wasn't aware that we can not use "non-standard" acronyms please provide me the ITU dictionary of standard acronyms ;-) Also this is a first version of a -00.txt draft. Changes will be provided as needed. Thanks, - dimitri. Maarten Vissers wrote: > > Dimitri, > > I don't know if it is necessary to redescribe SDH/SONET processing in an IETF > document. I would prefer references to the appropriate SDH standards; otherwise > you get different specifications and people get confused. > > Quickly scanning the text I already hit a few places where text is not > consistent with SDH standards. You are also introducing terminology that is > non-existing in SDH; e.g. LTE, SGE, AGE, SME, multiplexer types, POM. > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Hi folks, > > > > In order to re-inforce the message sent by Germano > > concerning our full support to LMP, i would like to > > point out here that we have submitted together with > > Jonathan an I-D dealing with Sonet/SDH extensions > > for LMP. > > > > This I-D can be found at (IETF website of course ;-) > > http://search.ietf.org/internet-drafts/draft-ansorge-ccamp-lmp-sonet-sdh-00.txt > > > > Any feedback is highly appreciated. > > > > Thanks, > > - dimitri. > > --------------37D4C642377700967AB87A75 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------37D4C642377700967AB87A75-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:03:47 -0800 Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Message-ID: <3BFBCE86.F48DC420@lucent.com> Date: Wed, 21 Nov 2001 16:55:50 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Content-Type: multipart/mixed; boundary="------------3EA1B2AC5F860653F20B7B5F" This is a multi-part message in MIME format. --------------3EA1B2AC5F860653F20B7B5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, I don't know if it is necessary to redescribe SDH/SONET processing in an IETF document. I would prefer references to the appropriate SDH standards; otherwise you get different specifications and people get confused. Quickly scanning the text I already hit a few places where text is not consistent with SDH standards. You are also introducing terminology that is non-existing in SDH; e.g. LTE, SGE, AGE, SME, multiplexer types, POM. Regards, Maarten Dimitri Papadimitriou wrote: > > Hi folks, > > In order to re-inforce the message sent by Germano > concerning our full support to LMP, i would like to > point out here that we have submitted together with > Jonathan an I-D dealing with Sonet/SDH extensions > for LMP. > > This I-D can be found at (IETF website of course ;-) > http://search.ietf.org/internet-drafts/draft-ansorge-ccamp-lmp-sonet-sdh-00.txt > > Any feedback is highly appreciated. > > Thanks, > - dimitri. > --------------3EA1B2AC5F860653F20B7B5F 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 --------------3EA1B2AC5F860653F20B7B5F-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 08:02:43 -0800 Message-ID: <3BFBCD9E.DFCEC57E@alcatel.be> Date: Wed, 21 Nov 2001 16:51:58 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------B4CBE31CB61BED0EACE832CB" This is a multi-part message in MIME format. --------------B4CBE31CB61BED0EACE832CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, This is an important point that i would like to mention here: since "pre-OTN" are not fully standardized the assumption is let's take the following approach: let's assume that there are no "transport plane" capabilities so that we can define a complete set of mechanism. Then if the standardized transport plane technology provides the capability, customize (profile the LMP configuraion) and complete the picture with some additional discovery and testing capabilities as we did in the I-D i mentioned previously. That's it. If Carmine doesn't like the Alarm suppression section of the LMP document for G.709 or SDH/Sonet she has the capability to not configure this module in her LMP profile. Hope this clarifies, - dimitri. Maarten Vissers wrote: > > Dimitri, > > It looks like we should separate the generic part of LMP from the technology > specific parts. > > One of the technology specific parts is pre-OTN/WDM transporting STM-N/OC-N > signals. If the specification for this technology would be present in a separate > document, it would be much better understood that those requirements are only > bound to that technology, not to any of the other technologies (e.g. SDH/SONET, > OTN). > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Hi Sudheer, > > > > Of course, the scope is broader than strictly G.709 > > based XC, and supportive equipment. This is why we > > can really benefit from the generic definition of this > > promising protocol while customizing it for specific > > technologies like SDH/Sonet, etc. that supports "in-band" > > it would be more accurate to say "transport plane" defect > > indication. > > > > Cheers, > > - dimitri. > > > > Sudheer Dharanikota wrote: > > > > > > Hi Carmine: > > > > > > Couple of observations... > > > > > > It seems you are assuming only G.709 based cross connects > > > only. > > > Please let me know if I am not correct. > > > > > > LMP-DWDM works for PXC and other crossconencts which does > > > not > > > use inband fault notification. > > > > > > Cheers, > > > > > > sudheer > > > > > > Carmine Daloia wrote: > > > > > > > Jonathan, > > > > > > > > The LMP-WDM document specifies the signaling between the > > > > Cross-connect and OLS, assuming they are from different > > > > vendors. If they are from different vendors, then a > > > > standard interface is needed to exchange some information. > > > > One type of information that would need to be exchanged is > > > > some OAM signals. Maarten described some of these signals > > > > in his VBI document. However, I don't see why OAM signals > > > > would have to be exchanged directly between the > > > > cross-connects themselves via LMP. > > > > > > > > Let's look at the following network. > > > > > > > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > > > > > > > Note that the OLS consists of DWDM Mux/Dmux Terminals and > > > > Optical Amplifiers. > > > > > > > > Let's assume a failure on OLSA. OLSA via overhead within > > > > an OSC suppresses alarms within OLSA. OAM messages (e.g., > > > > Optical Channel FDI) could be carried over the LMP-WDM > > > > control channel to OXC2. OXC2 will have to forward the FDI > > > > signals downstream over the LMP-WDM control channel to > > > > OLSB. OLSB will then forward these FDI signals over its > > > > OSC and then over the LMP-WDM control channel to OXC3..... > > > > etc... > > > > > > > > Note that OXC2 does not need to directly forward these FDI > > > > signals to OXC3. So it is possible, that in LMP-WDM, we > > > > may need to define messages corresponding to FDI signals > > > > to suppress downstream alarms, however we don't need to > > > > define such messages in LMP. > > > > > > > > Thanks > > > > Carmine > > > > > > > > Jonathan Lang wrote: > > > > > > > >> Carmine, > > > >> Please see inline. > > > >> > > > >> Thanks, > > > >> Jonathan > > > >> > > > >> > > > >> > -----Original Message----- > > > >> > From: Carmine Daloia [mailto:daloia@lucent.com] > > > >> > Sent: Monday, November 19, 2001 6:44 AM > > > >> > To: ccamp@ops.ietf.org > > > >> > Cc: tsg15q11@itu.int; t1x15@t1.org > > > >> > Subject: LMP: Suppression of Downstream Alarms... > > > >> > > > > >> > > > > >> > Hi all, > > > >> > > > > >> > As I read through Section 6 "Fault Management", one > > > >> > issue that it seems > > > >> > to be addressing is "Suppression of Downstream Alarms". > > > >> > > > > >> > In section 6.2, it states that "If data links fail > > > >> > between two PXCs, the > > > >> > power monitoring system in all of the downstream nodes > > > >> > may detect LOL > > > >> > and indicate a failure. To avoid multiple alarms > > > >> > stemming from the same > > > >> > failure, LMP provides a failure notification through > > > >> > the Chann > > > >> > elStatus > > > >> > message...". > > > >> > > > > >> > I agree that the suppression of downstream alarms is an > > > >> > important issue. > > > >> > > > > >> great! > > > >> > > > >> > > > >> > If we look at standard networks (both SONET/SDH and > > > >> > OTN), this > > > >> > capability is already provided by the overhead in > > > >> > SDH/SONET and G.709 > > > >> > OTN. G.709 OTN handles suppression of alarms in both > > > >> > all-optical > > > >> > networks as well as opaque networks. I don't think we > > > >> > need to burden the > > > >> > control plane with such functions when the transport > > > >> > plane handles this > > > >> > in standard networks. In fact the transport plane > > > >> > handles suppression of > > > >> > alarms on all equipment in the network (not just > > > >> > cross-connects). > > > >> > > > > >> > If we look at a pre-OTN ("non-standard") scenario > > > >> > consisting of > > > >> > Cross-connects, Optical Line Systems, and Optical > > > >> > Amplifiers supporting > > > >> > a DWDM networked solution, we can analyze two > > > >> > scenarios. One scenario is > > > >> > an opaque network (e.g., the OLS supports 3R). In this > > > >> > scenario, the > > > >> > downstream Cross-connects would not detect LOL upon f > > > >> > aults occurring > > > >> > upstream. The 3R points on the OLS Line Systems would > > > >> > insert some type > > > >> > of signal downs > > > >> > tream. Therefore the mechanism described in Section > > > >> > 6.2 > > > >> > does not apply. Another scenario is an all-optical > > > >> > pre-OTN network. Note > > > >> > that other equipment besides Cross-connects (e.g., > > > >> > Optical Amplifiers) > > > >> > in an all-optical network may alarm due to upstream > > > >> > faults. These alarms > > > >> > also need to be suppressed. LMP seems to only address > > > >> > the suppression of > > > >> > downstream alarms on cross-connects without taking into > > > >> > consideration > > > >> > the network that sits between the cross-connects. Is > > > >> > LMP also expected > > > >> > to have to be processed on Optical Amplifiers? This > > > >> > seems to be > > > >> > undesirable, especially given all the various > > > >> > applications that seem to > > > >> > be included into the LMP protocol that would not have > > > >> > anything to do > > > >> > with Optical Amplifieris. > > > >> > > > > >> For interaction between cross-connects and Line Systems, > > > >> please see OLI > > > >> Requirements document > > > >> ( > > > >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > > > >> ) and > > > >> corresponding LMP-WDM protocol document (new version to > > > >> be uploaded > > > >> tomorrow, but old version can be found at > > > >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt > > > >> ). > > > >> > > > >> > > > >> > Any other views? > > > >> > > > > >> > Carmine > > > >> > > > > >> > --------------B4CBE31CB61BED0EACE832CB Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------B4CBE31CB61BED0EACE832CB-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:48:33 -0800 Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Message-ID: <3BFBCAEE.B0F13D2E@lucent.com> Date: Wed, 21 Nov 2001 16:40:30 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------0D2C7E7D2BC98E00F06AFEB6" This is a multi-part message in MIME format. --------------0D2C7E7D2BC98E00F06AFEB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, It looks like we should separate the generic part of LMP from the technology specific parts. One of the technology specific parts is pre-OTN/WDM transporting STM-N/OC-N signals. If the specification for this technology would be present in a separate document, it would be much better understood that those requirements are only bound to that technology, not to any of the other technologies (e.g. SDH/SONET, OTN). Regards, Maarten Dimitri Papadimitriou wrote: > > Hi Sudheer, > > Of course, the scope is broader than strictly G.709 > based XC, and supportive equipment. This is why we > can really benefit from the generic definition of this > promising protocol while customizing it for specific > technologies like SDH/Sonet, etc. that supports "in-band" > it would be more accurate to say "transport plane" defect > indication. > > Cheers, > - dimitri. > > Sudheer Dharanikota wrote: > > > > Hi Carmine: > > > > Couple of observations... > > > > It seems you are assuming only G.709 based cross connects > > only. > > Please let me know if I am not correct. > > > > LMP-DWDM works for PXC and other crossconencts which does > > not > > use inband fault notification. > > > > Cheers, > > > > sudheer > > > > Carmine Daloia wrote: > > > > > Jonathan, > > > > > > The LMP-WDM document specifies the signaling between the > > > Cross-connect and OLS, assuming they are from different > > > vendors. If they are from different vendors, then a > > > standard interface is needed to exchange some information. > > > One type of information that would need to be exchanged is > > > some OAM signals. Maarten described some of these signals > > > in his VBI document. However, I don't see why OAM signals > > > would have to be exchanged directly between the > > > cross-connects themselves via LMP. > > > > > > Let's look at the following network. > > > > > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > > > > > Note that the OLS consists of DWDM Mux/Dmux Terminals and > > > Optical Amplifiers. > > > > > > Let's assume a failure on OLSA. OLSA via overhead within > > > an OSC suppresses alarms within OLSA. OAM messages (e.g., > > > Optical Channel FDI) could be carried over the LMP-WDM > > > control channel to OXC2. OXC2 will have to forward the FDI > > > signals downstream over the LMP-WDM control channel to > > > OLSB. OLSB will then forward these FDI signals over its > > > OSC and then over the LMP-WDM control channel to OXC3..... > > > etc... > > > > > > Note that OXC2 does not need to directly forward these FDI > > > signals to OXC3. So it is possible, that in LMP-WDM, we > > > may need to define messages corresponding to FDI signals > > > to suppress downstream alarms, however we don't need to > > > define such messages in LMP. > > > > > > Thanks > > > Carmine > > > > > > Jonathan Lang wrote: > > > > > >> Carmine, > > >> Please see inline. > > >> > > >> Thanks, > > >> Jonathan > > >> > > >> > > >> > -----Original Message----- > > >> > From: Carmine Daloia [mailto:daloia@lucent.com] > > >> > Sent: Monday, November 19, 2001 6:44 AM > > >> > To: ccamp@ops.ietf.org > > >> > Cc: tsg15q11@itu.int; t1x15@t1.org > > >> > Subject: LMP: Suppression of Downstream Alarms... > > >> > > > >> > > > >> > Hi all, > > >> > > > >> > As I read through Section 6 "Fault Management", one > > >> > issue that it seems > > >> > to be addressing is "Suppression of Downstream Alarms". > > >> > > > >> > In section 6.2, it states that "If data links fail > > >> > between two PXCs, the > > >> > power monitoring system in all of the downstream nodes > > >> > may detect LOL > > >> > and indicate a failure. To avoid multiple alarms > > >> > stemming from the same > > >> > failure, LMP provides a failure notification through > > >> > the Chann > > >> > elStatus > > >> > message...". > > >> > > > >> > I agree that the suppression of downstream alarms is an > > >> > important issue. > > >> > > > >> great! > > >> > > >> > > >> > If we look at standard networks (both SONET/SDH and > > >> > OTN), this > > >> > capability is already provided by the overhead in > > >> > SDH/SONET and G.709 > > >> > OTN. G.709 OTN handles suppression of alarms in both > > >> > all-optical > > >> > networks as well as opaque networks. I don't think we > > >> > need to burden the > > >> > control plane with such functions when the transport > > >> > plane handles this > > >> > in standard networks. In fact the transport plane > > >> > handles suppression of > > >> > alarms on all equipment in the network (not just > > >> > cross-connects). > > >> > > > >> > If we look at a pre-OTN ("non-standard") scenario > > >> > consisting of > > >> > Cross-connects, Optical Line Systems, and Optical > > >> > Amplifiers supporting > > >> > a DWDM networked solution, we can analyze two > > >> > scenarios. One scenario is > > >> > an opaque network (e.g., the OLS supports 3R). In this > > >> > scenario, the > > >> > downstream Cross-connects would not detect LOL upon f > > >> > aults occurring > > >> > upstream. The 3R points on the OLS Line Systems would > > >> > insert some type > > >> > of signal downs > > >> > tream. Therefore the mechanism described in Section > > >> > 6.2 > > >> > does not apply. Another scenario is an all-optical > > >> > pre-OTN network. Note > > >> > that other equipment besides Cross-connects (e.g., > > >> > Optical Amplifiers) > > >> > in an all-optical network may alarm due to upstream > > >> > faults. These alarms > > >> > also need to be suppressed. LMP seems to only address > > >> > the suppression of > > >> > downstream alarms on cross-connects without taking into > > >> > consideration > > >> > the network that sits between the cross-connects. Is > > >> > LMP also expected > > >> > to have to be processed on Optical Amplifiers? This > > >> > seems to be > > >> > undesirable, especially given all the various > > >> > applications that seem to > > >> > be included into the LMP protocol that would not have > > >> > anything to do > > >> > with Optical Amplifieris. > > >> > > > >> For interaction between cross-connects and Line Systems, > > >> please see OLI > > >> Requirements document > > >> ( > > >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > > >> ) and > > >> corresponding LMP-WDM protocol document (new version to > > >> be uploaded > > >> tomorrow, but old version can be found at > > >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt > > >> ). > > >> > > >> > > >> > Any other views? > > >> > > > >> > Carmine > > >> > > > >> > --------------0D2C7E7D2BC98E00F06AFEB6 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 --------------0D2C7E7D2BC98E00F06AFEB6-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:48:24 -0800 Message-ID: <3BFBCAC2.10081E80@nayna.com> Date: Wed, 21 Nov 2001 07:39:46 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: George Young , ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------E7360CBE9EF382D223DB7C3C" This is a multi-part message in MIME format. --------------E7360CBE9EF382D223DB7C3C Content-Type: multipart/alternative; boundary="------------9E58427A9ACDCC3DDBD2CCF6" --------------9E58427A9ACDCC3DDBD2CCF6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carmen: It is common to deploy a local restoration for faster recovery for some faults (such as fiber cut) and end-to-end recovery for little slower recovery for faults such as node failures. In such a scenario... what do you mean by head-end and tail-end :-) Cheers, sudheer Carmine Daloia wrote: > Hi Sudheer, > > See inline. > > Thanks > Carmine > > Sudheer Dharanikota wrote: > >> Hi Carmine: >> >> Carmine Daloia wrote: >> >> > Hi George, >> > >> > Thanks for the pointer to your draft. I will definitely >> > read over it. Just looking at it quickly and >> > understanding what is in LMP, it seems that even under >> > path protection/restoration, there is an intermediate >> > node that detects a failure (and localizes the failure >> > to ensure that the failure occured on that particular >> > link) and then signals over the control plane to the >> > head-end and tail-end nodes of the >> > protection/restoration domain to initiate >> > protection/restoration. >> > >> > It seems to me that the tail-end and head-end nodes >> > themselves would be able to detect the defect in the >> > transport/user plane since the defect occured between >> > the two ends and they can then coordinate switching for >> > protection/restoration without having to wait for any >> > notification message sent from an intermediate NE. >> > This should improve the protection/restoration time >> > since the head-end and tail-end won't need to wait for >> > intermediate nodes to localize a fault and then signal >> > over a control plane requesting a >> > proteciton/restoration switch. Any thoughts? >> > >> >> YOur solution precludes local restoration options. > > > No it doesn't. For local restoration options (I assume you > mean span/link restoration) the tail-end and head-end > nodes of the protection/restoration domain are the > adjacent cross-connects. So as I said before, the > signaling to determine if a fault occurred within a > protection/restoration domain and then initiate a switch > takes place between the head-end and tail-end nodes of a > protection/restoration domain. This domain could be a > span/link or an end-to-end path. > >> Cheers, >> >> sudheer >> >> > >> > Thanks >> > Carmine >> > >> > George Young wrote: >> > >> >> Hello Carmine, Meriton Networks intends to use LMP as >> >> a fault localization mechanism in a network of our >> >> transparent optical switches, currently in the >> >> pre-production phase. I've done some discrete event >> >> simulation work to characterize the performance of an >> >> IP network in support LMP management signals, and the >> >> resulting signalling messages needed to initiate >> >> protection/restoration, and based on the results, >> >> have not seen any need to change our design >> >> direction. I've also written and submitted an IETF >> >> draft >> >> http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txtdealing >> >> with the importance of control network performance, >> >> particularly when extended across multiple >> >> networks, and would appreciate any comments you might >> >> have. Regards, George R. Young Meriton Networks Inc. >> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> >> phone: +1 613-270-9279 Ext 287 >> >> fax: +1 613-270-9268 >> >> >> >> -----Original Message----- >> >> From: Carmine Daloia >> >> [mailto:daloia@lucent.com ] >> >> Sent: Wednesday, November 21, 2001 8:29 AM >> >> To: Carmine Daloia >> >> Cc: Jonathan Lang; ccamp@ops.ietf.org ; >> >> tsg15q11@itu.int ; t1x15@t1.org >> >> Subject: Re: [T1X1.5] Re: Suppression of >> >> Downstream Alarms... >> >> Jonathan, >> >> >> >> Forgot to mention, that the performance >> >> aspects of carrying OAM type signals over >> >> an IP based control channel in LMP-WDM >> >> would have to be analyzed. It is possible >> >> that the IP Control Channel will not >> >> provide fast enough transfer to actually >> >> suppress downstream alarms, however that >> >> needs to be analyzed as part of LMP-WDM. >> >> >> >> Thanks >> >> Carmine >> >> >> >> Carmine Daloia wrote: >> >> >> >> > Jonathan, >> >> > >> >> > The LMP-WDM document specifies the >> >> > signaling between the Cross-connect and >> >> > OLS, assuming they are from different >> >> > vendors. If they are from different >> >> > vendors, then a standard interface is >> >> > needed to exchange some information. One >> >> > type of information that would need to be >> >> > exchanged is some OAM signals. Maarten >> >> > described some of these signals in his >> >> > VBI document. However, I don't see why >> >> > OAM signals would have to be exchanged >> >> > directly between the cross-connects >> >> > themselves via LMP. >> >> > >> >> > Let's look at the following network. >> >> > >> >> > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 >> >> > --- OLSC --- OXC4 >> >> > >> >> > Note that the OLS consists of DWDM >> >> > Mux/Dmux Terminals and Optical >> >> > Amplifiers. >> >> > >> >> > Let's assume a failure on OLSA. OLSA via >> >> > overhead within an OSC suppresses alarms >> >> > within OLSA. OAM messages (e.g., Optical >> >> > Channel FDI) could be carried over the >> >> > LMP-WDM control channel to OXC2. OXC2 >> >> > will have to forward the FDI signals >> >> > downstream over the LMP-WDM control >> >> > channel to OLSB. OLSB will then forward >> >> > these FDI signals over its OSC and then >> >> > over the LMP-WDM control channel to >> >> > OXC3..... etc... >> >> > >> >> > Note that OXC2 does not need to directly >> >> > forward these FDI signals to OXC3. So it >> >> > is possible, that in LMP-WDM, we may need >> >> > to define messages corresponding to FDI >> >> > signals to suppress downstream alarms, >> >> > however we don't need to define such >> >> > messages in LMP. >> >> > >> >> > Thanks >> >> > Carmine >> >> > >> >> > Jonathan Lang wrote: >> >> > >> >> >> Carmine, >> >> >> Please see inline. >> >> >> >> >> >> Thanks, >> >> >> Jonathan >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: Carmine Daloia [ >> >> >> > mailto:daloia@lucent.com] >> >> >> > Sent: Monday, November 19, 2001 6:44 >> >> >> > AM >> >> >> > To: ccamp@ops.ietf.org >> >> >> > Cc: tsg15q11@itu.int; t1x15@t1.org >> >> >> > Subject: LMP: Suppression of Do >> >> >> > wnstream Alarms... >> >> >> > >> >> >> > >> >> >> > Hi all, >> >> >> > >> >> >> > As I read through Section 6 "Fault >> >> >> > Management", one issue that it seems >> >> >> > to be addressing is "Suppression of >> >> >> > Downstream Alarms". >> >> >> > >> >> >> > In section 6.2, it states that "If >> >> >> > data links fail between two PXCs, the >> >> >> > power monitoring system in all of the >> >> >> > downstream nodes may detect LOL >> >> >> > and indicate a failure. To avoid >> >> >> > multiple alarms stemming from the >> >> >> > same >> >> >> > failure, LMP provides a fail >> >> >> > ure notification through the >> >> >> > Cha >> >> >> > nn >> >> >> > elStatus >> >> >> > message...". >> >> >> > >> >> >> > I agree that the suppression of >> >> >> > downstream alarms is an important >> >> >> > issue. >> >> >> > >> >> >> great! >> >> >> >> >> >> >> >> >> > If we look at standard networks (both >> >> >> > SONET/SDH and OTN), this >> >> >> > capability is already provided by the >> >> >> > overhead in SDH/SONET and G.709 >> >> >> > OTN. G.709 OTN handles suppression of >> >> >> > alarms in both all-optical >> >> >> > networks as well as opaque networks. I >> >> >> > don't think we need to burden the >> >> >> > control plane with such functions when >> >> >> > the transport plane handles this >> >> >> > in standard networks. In fact the >> >> >> > transport plane handles suppression >> >> >> > of >> >> >> > alarms on all equipment in the network >> >> >> > (not just cross-connects). >> >> >> > >> >> >> > If we look at a pre-OTN >> >> >> > ("non-standard") scenario consisting >> >> >> > of >> >> >> > Cross-connects, Optical Line Systems, >> >> >> > and Optical Amplifiers supporting >> >> >> > a DWDM networked solution, we can >> >> >> > analyze two scenarios. One scenario >> >> >> > is >> >> >> > an opaque network (e.g., the OLS >> >> >> > supports 3R). In this scenario, the >> >> >> > downstream Cross-connects would not >> >> >> > detect LOL upon faults occurring >> >> >> > upstream. The 3R poin >> >> >> > ts on the OLS Line Systems would >> >> >> > insert some type >> >> >> > of signal >> >> >> > dow >> >> >> > ns >> >> >> > tream. Therefore the mechanism >> >> >> > described in Section 6.2 >> >> >> > does not apply. Another scenario is an >> >> >> > all-optical pre-OTN network. Note >> >> >> > that other equipment besides >> >> >> > Cross-connects (e.g., Optical >> >> >> > Amplifiers) >> >> >> > in an all-optical network may alarm >> >> >> > due to upstream faults. These alarms >> >> >> > also need to be suppressed. LMP seems >> >> >> > to only address the suppression of >> >> >> > downstream alarms on cross-connects >> >> >> > without taking into consideration >> >> >> > the network that sits between the >> >> >> > cross-connects. Is LMP also expected >> >> >> > to have to be processed on Optical >> >> >> > Amplifiers? This seems to be >> >> >> > undesirable, especially given all the >> >> >> > various applications that seem to >> >> >> > be included into the LMP protocol that >> >> >> > would not have anything to do >> >> >> > with Optical Amplifieris. >> >> >> > >> >> >> For interaction between cross-connects >> >> >> and Line Systems, please see OLI >> >> >> Requirements document >> >> >> ( >> >> >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> >> >> ) and >> >> >> corresponding LMP-WDM protocol document >> >> >> (new version to be uploaded >> >> >> tomorrow, but old version can be found >> >> >> at >> >> >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> >> >> ). >> >> >> >> >> >> >> >> >> > Any other views? >> >> >> > >> >> >> > Carmine >> >> >> > >> >> >> > --------------9E58427A9ACDCC3DDBD2CCF6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carmen:

It is common to deploy a local restoration for faster recovery for some faults
(such as fiber cut) and end-to-end recovery for little slower recovery for
faults such as node failures.

In such a scenario... what do you mean by head-end and tail-end :-)

Cheers,

sudheer
 

Carmine Daloia wrote:

Hi Sudheer,

See inline.

Thanks
Carmine

Sudheer Dharanikota wrote:

Hi Carmine:

Carmine Daloia wrote:

Hi George,

Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration.

It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE.  This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts?
 

YOur solution precludes local restoration options.


No it doesn't. For local restoration options (I assume you mean span/link restoration) the tail-end and head-end nodes of the protection/restoration domain are the adjacent cross-connects. So as I said before, the signaling to determine if a fault occurred within a protection/restoration domain and then initiate a switch takes place between the head-end and tail-end nodes of a protection/restoration domain. This domain could be a span/link or an end-to-end path.

Cheers,

sudheer

 
Thanks
Carmine

George Young wrote:

Hello Carmine, Meriton Networks intends to use LMP as a fault localization mechanism in a network of our  transparent optical switches, currently in the pre-production phase. I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change  our design direction. I've also written and submitted an IETF draft  http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txtdealing with the importance of control network performance, particularly when extended across  multiple  networks, and would appreciate any comments you might have. Regards, George R. Young Meriton Networks Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268
-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com ]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; ccamp@ops.ietf.org ; tsg15q11@itu.int ; t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan


-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a fail
ure notification through the
 Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!


If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R poin
ts on the OLS Line Systems would insert some type 
of signal
 dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).


Any other views?

Carmine
--------------9E58427A9ACDCC3DDBD2CCF6-- --------------E7360CBE9EF382D223DB7C3C Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------E7360CBE9EF382D223DB7C3C-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:44:22 -0800 Message-ID: <3BFBC9D9.98103AF7@nayna.com> Date: Wed, 21 Nov 2001 07:35:53 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Dimitri Papadimitriou CC: Carmine Daloia , Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------5FA23FC1629C90D7D707D4CD" This is a multi-part message in MIME format. --------------5FA23FC1629C90D7D707D4CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am in agreement wih you Dimitri. - sudheer Dimitri Papadimitriou wrote: > Hi Sudheer, > > Of course, the scope is broader than strictly G.709 > based XC, and supportive equipment. This is why we > can really benefit from the generic definition of this > promising protocol while customizing it for specific > technologies like SDH/Sonet, etc. that supports "in-band" > it would be more accurate to say "transport plane" defect > indication. > > Cheers, > - dimitri. > > Sudheer Dharanikota wrote: > > > > Hi Carmine: > > > > Couple of observations... > > > > It seems you are assuming only G.709 based cross connects > > only. > > Please let me know if I am not correct. > > > > LMP-DWDM works for PXC and other crossconencts which does > > not > > use inband fault notification. > > > > Cheers, > > > > sudheer > > > > Carmine Daloia wrote: > > > > > Jonathan, > > > > > > The LMP-WDM document specifies the signaling between the > > > Cross-connect and OLS, assuming they are from different > > > vendors. If they are from different vendors, then a > > > standard interface is needed to exchange some information. > > > One type of information that would need to be exchanged is > > > some OAM signals. Maarten described some of these signals > > > in his VBI document. However, I don't see why OAM signals > > > would have to be exchanged directly between the > > > cross-connects themselves via LMP. > > > > > > Let's look at the following network. > > > > > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > > > > > Note that the OLS consists of DWDM Mux/Dmux Terminals and > > > Optical Amplifiers. > > > > > > Let's assume a failure on OLSA. OLSA via overhead within > > > an OSC suppresses alarms within OLSA. OAM messages (e.g., > > > Optical Channel FDI) could be carried over the LMP-WDM > > > control channel to OXC2. OXC2 will have to forward the FDI > > > signals downstream over the LMP-WDM control channel to > > > OLSB. OLSB will then forward these FDI signals over its > > > OSC and then over the LMP-WDM control channel to OXC3..... > > > etc... > > > > > > Note that OXC2 does not need to directly forward these FDI > > > signals to OXC3. So it is possible, that in LMP-WDM, we > > > may need to define messages corresponding to FDI signals > > > to suppress downstream alarms, however we don't need to > > > define such messages in LMP. > > > > > > Thanks > > > Carmine > > > > > > Jonathan Lang wrote: > > > > > >> Carmine, > > >> Please see inline. > > >> > > >> Thanks, > > >> Jonathan > > >> > > >> > > >> > -----Original Message----- > > >> > From: Carmine Daloia [mailto:daloia@lucent.com] > > >> > Sent: Monday, November 19, 2001 6:44 AM > > >> > To: ccamp@ops.ietf.org > > >> > Cc: tsg15q11@itu.int; t1x15@t1.org > > >> > Subject: LMP: Suppression of Downstream Alarms... > > >> > > > >> > > > >> > Hi all, > > >> > > > >> > As I read through Section 6 "Fault Management", one > > >> > issue that it seems > > >> > to be addressing is "Suppression of Downstream Alarms". > > >> > > > >> > In section 6.2, it states that "If data links fail > > >> > between two PXCs, the > > >> > power monitoring system in all of the downstream nodes > > >> > may detect LOL > > >> > and indicate a failure. To avoid multiple alarms > > >> > stemming from the same > > >> > failure, LMP provides a failure notification through > > >> > the Chann > > >> > elStatus > > >> > message...". > > >> > > > >> > I agree that the suppression of downstream alarms is an > > >> > important issue. > > >> > > > >> great! > > >> > > >> > > >> > If we look at standard networks (both SONET/SDH and > > >> > OTN), this > > >> > capability is already provided by the overhead in > > >> > SDH/SONET and G.709 > > >> > OTN. G.709 OTN handles suppression of alarms in both > > >> > all-optical > > >> > networks as well as opaque networks. I don't think we > > >> > need to burden the > > >> > control plane with such functions when the transport > > >> > plane handles this > > >> > in standard networks. In fact the transport plane > > >> > handles suppression of > > >> > alarms on all equipment in the network (not just > > >> > cross-connects). > > >> > > > >> > If we look at a pre-OTN ("non-standard") scenario > > >> > consisting of > > >> > Cross-connects, Optical Line Systems, and Optical > > >> > Amplifiers supporting > > >> > a DWDM networked solution, we can analyze two > > >> > scenarios. One scenario is > > >> > an opaque network (e.g., the OLS supports 3R). In this > > >> > scenario, the > > >> > downstream Cross-connects would not detect LOL upon f > > >> > aults occurring > > >> > upstream. The 3R points on the OLS Line Systems would > > >> > insert some type > > >> > of signal downs > > >> > tream. Therefore the mechanism described in Section > > >> > 6.2 > > >> > does not apply. Another scenario is an all-optical > > >> > pre-OTN network. Note > > >> > that other equipment besides Cross-connects (e.g., > > >> > Optical Amplifiers) > > >> > in an all-optical network may alarm due to upstream > > >> > faults. These alarms > > >> > also need to be suppressed. LMP seems to only address > > >> > the suppression of > > >> > downstream alarms on cross-connects without taking into > > >> > consideration > > >> > the network that sits between the cross-connects. Is > > >> > LMP also expected > > >> > to have to be processed on Optical Amplifiers? This > > >> > seems to be > > >> > undesirable, especially given all the various > > >> > applications that seem to > > >> > be included into the LMP protocol that would not have > > >> > anything to do > > >> > with Optical Amplifieris. > > >> > > > >> For interaction between cross-connects and Line Systems, > > >> please see OLI > > >> Requirements document > > >> ( > > >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > > >> ) and > > >> corresponding LMP-WDM protocol document (new version to > > >> be uploaded > > >> tomorrow, but old version can be found at > > >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt > > >> ). > > >> > > >> > > >> > Any other views? > > >> > > > >> > Carmine > > >> > > > >> > --------------5FA23FC1629C90D7D707D4CD Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------5FA23FC1629C90D7D707D4CD-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:43:00 -0800 Message-ID: <3BFBC983.D84D3696@nayna.com> Date: Wed, 21 Nov 2001 07:34:27 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------BBFA08C5A8B1E8B78CEF630F" This is a multi-part message in MIME format. --------------BBFA08C5A8B1E8B78CEF630F Content-Type: multipart/alternative; boundary="------------60A4DCEC35F31FF27F24B179" --------------60A4DCEC35F31FF27F24B179 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi again: Carmine Daloia wrote: > Sudheer, > > I am not assuming inband communication is supported > between the cross-connect and the line system. That is why > I said that when the PXC and line system are from > different vendors such OAM signals would have to be > carried over a separate channel (e.g., LMP-WDM control > channel). However, I don't see why such signals would have > to be carried over an LMP control channel between > cross-connects. Also, my point about performance was that > we would have to see if the LMP control channel would meet > the performance requirements for such OAM signals. It very > well might. If not, a bit-oriented signaling interface may > be needed between the PXC and the line system. > Ok Let us address the issues separately... 1. Communication between Line System and Cross connect Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion) of IETF. I am not sure if are creating a problem to solve with the alarm suppression. Let me explain... Let us assume we can correlate and suppress the alarms between the Line systems and corss connects. Then we donot need an elaborate bit-oriented protocol. This has an assumption that we are talking about not hundereds of failures but a couple of failures (for example fiber cuts). 2. Communication between cross connects THis is needed to localize a fault which in turn can be used as a trigger for local restoration. - sudheer > > Thanks > Carmine > > Sudheer Dharanikota wrote: > >> Carmine... >> >> Again can you suggest a way to communicate such signals >> between line systems and cross connects when inband >> communication is not supported between these two >> systems? >> >> Cheers, >> >> sudheer >> >> Carmine Daloia wrote: >> >> > Jonathan, >> > >> > Forgot to mention, that the performance aspects of >> > carrying OAM type signals over an IP based control >> > channel in LMP-WDM would have to be analyzed. It is >> > possible that the IP Control Channel will not provide >> > fast enough transfer to actually suppress downstream >> > alarms, however that needs to be analyzed as part of >> > LMP-WDM. >> > >> > Thanks >> > Carmine >> > >> > Carmine Daloia wrote: >> > >> >> Jonathan, >> >> >> >> The LMP-WDM document specifies the signaling between >> >> the Cross-connect and OLS, assuming they are from >> >> different vendors. If they are from different >> >> vendors, then a standard interface is needed to >> >> exchange some information. One type of information >> >> that would need to be exchanged is some OAM signals. >> >> Maarten described some of these signals in his VBI >> >> document. However, I don't see why OAM signals would >> >> have to be exchanged directly between the >> >> cross-connects themselves via LMP. >> >> >> >> Let's look at the following network. >> >> >> >> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- >> >> OXC4 >> >> >> >> Note that the OLS consists of DWDM Mux/Dmux Terminals >> >> and Optical Amplifiers. >> >> >> >> Let's assume a failure on OLSA. OLSA via overhead >> >> within an OSC suppresses alarms within OLSA. OAM >> >> messages (e.g., Optical Channel FDI) could be carried >> >> over the LMP-WDM control channel to OXC2. OXC2 will >> >> have to forward the FDI signals downstream over the >> >> LMP-WDM control channel to OLSB. OLSB will then >> >> forward these FDI signals over its OSC and then over >> >> the LMP-WDM control channel to OXC3..... etc... >> >> >> >> Note that OXC2 does not need to directly forward >> >> these FDI signals to OXC3. So it is possible, that in >> >> LMP-WDM, we may need to define messages corresponding >> >> to FDI signals to suppress downstream alarms, however >> >> we don't need to define such messages in LMP. >> >> >> >> Thanks >> >> Carmine >> >> >> >> Jonathan Lang wrote: >> >> >> >> > Carmine, >> >> > Please see inline. >> >> > >> >> > Thanks, >> >> > Jonathan >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Carmine Daloia [mailto:daloia@lucent.com] >> >> >> Sent: Monday, November 19, 2001 6:44 AM >> >> >> To: ccamp@ops.ietf.org >> >> >> Cc: tsg15q11@itu.int; t1x15@t1.org >> >> >> Subject: LMP: Suppression of Downstream Alarms... >> >> >> >> >> >> >> >> >> Hi all, >> >> >> >> >> >> As I read through Section 6 "Fault Management", >> >> >> one issue that it seems >> >> >> to be addressing is "Suppression of Downstream >> >> >> Alarms". >> >> >> >> >> >> In section 6.2, it states that "If data links fail >> >> >> between two PXCs, the >> >> >> power monitoring system in all of the downstream >> >> >> nodes may detect LOL >> >> >> and indicate a failure. To avoid multiple alarms >> >> >> stemming from the same >> >> >> failure, LMP provides a failure noti >> >> >> fication through the Cha >> >> >> nn >> >> >> elStatus >> >> >> message...". >> >> >> >> >> >> I agree that the suppression of downstream alarms >> >> >> is an important issue. >> >> >> >> >> > great! >> >> > >> >> > >> >> >> If we look at standard networks (both SONET/SDH >> >> >> and OTN), this >> >> >> capability is already provided by the overhead in >> >> >> SDH/SONET and G.709 >> >> >> OTN. G.709 OTN handles suppression of alarms in >> >> >> both all-optical >> >> >> networks as well as opaque networks. I don't think >> >> >> we need to burden the >> >> >> control plane with such functions when the >> >> >> transport plane handles this >> >> >> in standard networks. In fact the transport plane >> >> >> handles suppression of >> >> >> alarms on all equipment in the network (not just >> >> >> cross-connects). >> >> >> >> >> >> If we look at a pre-OTN ("non-standard") scenario >> >> >> consisting of >> >> >> Cross-connects, Optical Line Systems, and Optical >> >> >> Amplifiers supporting >> >> >> a DWDM networked solution, we can analyze two >> >> >> scenarios. One scenario is >> >> >> an opaque network (e.g., the OLS supports 3R). In >> >> >> this scenario, the >> >> >> downstream Cross-connects would not detect LOL >> >> >> upon faults occurring >> >> >> upstream. The 3R points on th >> >> >> e OLS Line Systems would insert some type >> >> >> of signal dow >> >> >> ns >> >> >> tream. Therefore the mechanism described in >> >> >> Section 6.2 >> >> >> does not apply. Another scenario is an all-optical >> >> >> pre-OTN network. Note >> >> >> that other equipment besides Cross-connects (e.g., >> >> >> Optical Amplifiers) >> >> >> in an all-optical network may alarm due to >> >> >> upstream faults. These alarms >> >> >> also need to be suppressed. LMP seems to only >> >> >> address the suppression of >> >> >> downstream alarms on cross-connects without taking >> >> >> into consideration >> >> >> the network that sits between the cross-connects. >> >> >> Is LMP also expected >> >> >> to have to be processed on Optical Amplifiers? >> >> >> This seems to be >> >> >> undesirable, especially given all the various >> >> >> applications that seem to >> >> >> be included into the LMP protocol that would not >> >> >> have anything to do >> >> >> with Optical Amplifieris. >> >> >> >> >> > For interaction between cross-connects and Line >> >> > Systems, please see OLI >> >> > Requirements document >> >> > ( >> >> > http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> >> > ) and >> >> > corresponding LMP-WDM protocol document (new >> >> > version to be uploaded >> >> > tomorrow, but old version can be found at >> >> > http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> >> > ). >> >> > >> >> > >> >> >> Any other views? >> >> >> >> >> >> Carmine >> >> >> >> >> >> --------------60A4DCEC35F31FF27F24B179 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi again:

Carmine Daloia wrote:

Sudheer,

I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system.
 

Ok Let us address the issues separately...

1. Communication between Line System and Cross connect

Defining a bit-oriented (physical) interface and protocol is not really the task (in my opinion)
of IETF. I am not sure if are creating a problem to solve with the alarm suppression.
Let me explain...

Let us assume we can correlate and suppress the alarms between the Line systems
and corss connects. Then we donot need an elaborate bit-oriented protocol. This
has an assumption that we are talking about not hundereds of failures but a couple of
failures (for example fiber cuts).

2. Communication between cross connects

THis is needed to localize a fault which in turn can be used as a trigger for local
restoration.
 

- sudheer

 
Thanks
Carmine

Sudheer Dharanikota wrote:

Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan


-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure noti
fication through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!


If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on th
e OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).


Any other views?

Carmine
--------------60A4DCEC35F31FF27F24B179-- --------------BBFA08C5A8B1E8B78CEF630F Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------BBFA08C5A8B1E8B78CEF630F-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:36:09 -0800 Message-ID: <3BFBC79B.56754164@alcatel.be> Date: Wed, 21 Nov 2001 16:26:19 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Sudheer Dharanikota CC: Carmine Daloia , Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------41EB337E149FDCA3F6913650" This is a multi-part message in MIME format. --------------41EB337E149FDCA3F6913650 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sudheer, Of course, the scope is broader than strictly G.709 based XC, and supportive equipment. This is why we can really benefit from the generic definition of this promising protocol while customizing it for specific technologies like SDH/Sonet, etc. that supports "in-band" it would be more accurate to say "transport plane" defect indication. Cheers, - dimitri. Sudheer Dharanikota wrote: > > Hi Carmine: > > Couple of observations... > > It seems you are assuming only G.709 based cross connects > only. > Please let me know if I am not correct. > > LMP-DWDM works for PXC and other crossconencts which does > not > use inband fault notification. > > Cheers, > > sudheer > > Carmine Daloia wrote: > > > Jonathan, > > > > The LMP-WDM document specifies the signaling between the > > Cross-connect and OLS, assuming they are from different > > vendors. If they are from different vendors, then a > > standard interface is needed to exchange some information. > > One type of information that would need to be exchanged is > > some OAM signals. Maarten described some of these signals > > in his VBI document. However, I don't see why OAM signals > > would have to be exchanged directly between the > > cross-connects themselves via LMP. > > > > Let's look at the following network. > > > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > > > Note that the OLS consists of DWDM Mux/Dmux Terminals and > > Optical Amplifiers. > > > > Let's assume a failure on OLSA. OLSA via overhead within > > an OSC suppresses alarms within OLSA. OAM messages (e.g., > > Optical Channel FDI) could be carried over the LMP-WDM > > control channel to OXC2. OXC2 will have to forward the FDI > > signals downstream over the LMP-WDM control channel to > > OLSB. OLSB will then forward these FDI signals over its > > OSC and then over the LMP-WDM control channel to OXC3..... > > etc... > > > > Note that OXC2 does not need to directly forward these FDI > > signals to OXC3. So it is possible, that in LMP-WDM, we > > may need to define messages corresponding to FDI signals > > to suppress downstream alarms, however we don't need to > > define such messages in LMP. > > > > Thanks > > Carmine > > > > Jonathan Lang wrote: > > > >> Carmine, > >> Please see inline. > >> > >> Thanks, > >> Jonathan > >> > >> > >> > -----Original Message----- > >> > From: Carmine Daloia [mailto:daloia@lucent.com] > >> > Sent: Monday, November 19, 2001 6:44 AM > >> > To: ccamp@ops.ietf.org > >> > Cc: tsg15q11@itu.int; t1x15@t1.org > >> > Subject: LMP: Suppression of Downstream Alarms... > >> > > >> > > >> > Hi all, > >> > > >> > As I read through Section 6 "Fault Management", one > >> > issue that it seems > >> > to be addressing is "Suppression of Downstream Alarms". > >> > > >> > In section 6.2, it states that "If data links fail > >> > between two PXCs, the > >> > power monitoring system in all of the downstream nodes > >> > may detect LOL > >> > and indicate a failure. To avoid multiple alarms > >> > stemming from the same > >> > failure, LMP provides a failure notification through > >> > the Chann > >> > elStatus > >> > message...". > >> > > >> > I agree that the suppression of downstream alarms is an > >> > important issue. > >> > > >> great! > >> > >> > >> > If we look at standard networks (both SONET/SDH and > >> > OTN), this > >> > capability is already provided by the overhead in > >> > SDH/SONET and G.709 > >> > OTN. G.709 OTN handles suppression of alarms in both > >> > all-optical > >> > networks as well as opaque networks. I don't think we > >> > need to burden the > >> > control plane with such functions when the transport > >> > plane handles this > >> > in standard networks. In fact the transport plane > >> > handles suppression of > >> > alarms on all equipment in the network (not just > >> > cross-connects). > >> > > >> > If we look at a pre-OTN ("non-standard") scenario > >> > consisting of > >> > Cross-connects, Optical Line Systems, and Optical > >> > Amplifiers supporting > >> > a DWDM networked solution, we can analyze two > >> > scenarios. One scenario is > >> > an opaque network (e.g., the OLS supports 3R). In this > >> > scenario, the > >> > downstream Cross-connects would not detect LOL upon f > >> > aults occurring > >> > upstream. The 3R points on the OLS Line Systems would > >> > insert some type > >> > of signal downs > >> > tream. Therefore the mechanism described in Section > >> > 6.2 > >> > does not apply. Another scenario is an all-optical > >> > pre-OTN network. Note > >> > that other equipment besides Cross-connects (e.g., > >> > Optical Amplifiers) > >> > in an all-optical network may alarm due to upstream > >> > faults. These alarms > >> > also need to be suppressed. LMP seems to only address > >> > the suppression of > >> > downstream alarms on cross-connects without taking into > >> > consideration > >> > the network that sits between the cross-connects. Is > >> > LMP also expected > >> > to have to be processed on Optical Amplifiers? This > >> > seems to be > >> > undesirable, especially given all the various > >> > applications that seem to > >> > be included into the LMP protocol that would not have > >> > anything to do > >> > with Optical Amplifieris. > >> > > >> For interaction between cross-connects and Line Systems, > >> please see OLI > >> Requirements document > >> ( > >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt > >> ) and > >> corresponding LMP-WDM protocol document (new version to > >> be uploaded > >> tomorrow, but old version can be found at > >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt > >> ). > >> > >> > >> > Any other views? > >> > > >> > Carmine > >> > > >> > --------------41EB337E149FDCA3F6913650 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------41EB337E149FDCA3F6913650-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:34:49 -0800 Message-ID: <3BFBC86F.8020804@lucent.com> Date: Wed, 21 Nov 2001 10:29:51 -0500 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: Sudheer Dharanikota CC: George Young , ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------010807000000030807010105" --------------010807000000030807010105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, See inline. Thanks Carmine Sudheer Dharanikota wrote: > Hi Carmine: > > Carmine Daloia wrote: > >> Hi George, >> >> Thanks for the pointer to your draft. I will definitely read over it. >> Just looking at it quickly and understanding what is in LMP, it seems >> that even under path protection/restoration, there is an intermediate >> node that detects a failure (and localizes the failure to ensure that >> the failure occured on that particular link) and then signals over >> the control plane to the head-end and tail-end nodes of the >> protection/restoration domain to initiate protection/restoration. >> >> It seems to me that the tail-end and head-end nodes themselves would >> be able to detect the defect in the transport/user plane since the >> defect occured between the two ends and they can then coordinate >> switching for protection/restoration without having to wait for any >> notification message sent from an intermediate NE. This should >> improve the protection/restoration time since the head-end and >> tail-end won't need to wait for intermediate nodes to localize a >> fault and then signal over a control plane requesting a >> proteciton/restoration switch. Any thoughts? >> >> > YOur solution precludes local restoration options. No it doesn't. For local restoration options (I assume you mean span/link restoration) the tail-end and head-end nodes of the protection/restoration domain are the adjacent cross-connects. So as I said before, the signaling to determine if a fault occurred within a protection/restoration domain and then initiate a switch takes place between the head-end and tail-end nodes of a protection/restoration domain. This domain could be a span/link or an end-to-end path. > Cheers, > > sudheer > >> >> Thanks >> Carmine >> >> George Young wrote: >> >>> Hello Carmine, Meriton Networks intends to use LMP as a fault >>> localization mechanism in a network of our transparent optical >>> switches, currently in the pre-production phase. I've done some >>> discrete event simulation work to characterize the performance of an >>> IP network in support LMP management signals, and the resulting >>> signalling messages needed to initiate protection/restoration, and >>> based on the results, have not seen any need to change our design >>> direction. I've also written and submitted an IETF draft >>> http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt >>> dealing with the importance of control network performance, >>> particularly when extended across multiple networks, and would >>> appreciate any comments you might have. Regards, George R. Young >>> Meriton Networks Inc. >>> 329 March Rd., Kanata, ON, Canada, K2K 2E1 >>> phone: +1 613-270-9279 Ext 287 >>> fax: +1 613-270-9268 >>> >>> -----Original Message----- >>> From: Carmine Daloia [mailto:daloia@lucent.com ] >>> Sent: Wednesday, November 21, 2001 8:29 AM >>> To: Carmine Daloia >>> Cc: Jonathan Lang; ccamp@ops.ietf.org ; tsg15q11@itu.int ; >>> t1x15@t1.org >>> Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... >>> >>> >>> Jonathan, >>> >>> Forgot to mention, that the performance aspects of carrying OAM >>> type signals over an IP based control channel in LMP-WDM would >>> have to be analyzed. It is possible that the IP Control Channel >>> will not provide fast enough transfer to actually suppress >>> downstream alarms, however that needs to be analyzed as part of >>> LMP-WDM. >>> >>> Thanks >>> Carmine >>> >>> Carmine Daloia wrote: >>> >>>> Jonathan, >>>> >>>> The LMP-WDM document specifies the signaling between the >>>> Cross-connect and OLS, assuming they are from different >>>> vendors. If they are from different vendors, then a standard >>>> interface is needed to exchange some information. One type of >>>> information that would need to be exchanged is some OAM >>>> signals. Maarten described some of these signals in his VBI >>>> document. However, I don't see why OAM signals would have to be >>>> exchanged directly between the cross-connects themselves via LMP. >>>> >>>> Let's look at the following network. >>>> >>>> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >>>> >>>> Note that the OLS consists of DWDM Mux/Dmux Terminals and >>>> Optical Amplifiers. >>>> >>>> Let's assume a failure on OLSA. OLSA via overhead within an OSC >>>> suppresses alarms within OLSA. OAM messages (e.g., Optical >>>> Channel FDI) could be carried over the LMP-WDM control channel >>>> to OXC2. OXC2 will have to forward the FDI signals downstream >>>> over the LMP-WDM control channel to OLSB. OLSB will then >>>> forward these FDI signals over its OSC and then over the >>>> LMP-WDM control channel to OXC3..... etc... >>>> >>>> Note that OXC2 does not need to directly forward these FDI >>>> signals to OXC3. So it is possible, that in LMP-WDM, we may >>>> need to define messages corresponding to FDI signals to >>>> suppress downstream alarms, however we don't need to define >>>> such messages in LMP. >>>> >>>> Thanks >>>> Carmine >>>> >>>> Jonathan Lang wrote: >>>> >>>>>Carmine, >>>>> Please see inline. >>>>> >>>>>Thanks, >>>>>Jonathan >>>>> >>>>>>-----Original Message----- >>>>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>>>Sent: Monday, November 19, 2001 6:44 AM >>>>>>To: ccamp@ops.ietf.org >>>>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>>>Subject: LMP: Suppression of Downstream Alarms... >>>>>> >>>>>> >>>>>>Hi all, >>>>>> >>>>>>As I read through Section 6 "Fault Management", one issue that it seems >>>>>>to be addressing is "Suppression of Downstream Alarms". >>>>>> >>>>>>In section 6.2, it states that "If data links fail between two PXCs, the >>>>>>power monitoring system in all of the downstream nodes may detect LOL >>>>>>and indicate a failure. To avoid multiple alarms stemming from the same >>>>>>failure, LMP provides a failure notification through the >>>>>> Cha >>>>>>nn >>>>>>elStatus >>>>>>message...". >>>>>> >>>>>>I agree that the suppression of downstream alarms is an important issue. >>>>>> >>>>>great! >>>>> >>>>>>If we look at standard networks (both SONET/SDH and OTN), this >>>>>>capability is already provided by the overhead in SDH/SONET and G.709 >>>>>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>>>>networks as well as opaque networks. I don't think we need to burden the >>>>>>control plane with such functions when the transport plane handles this >>>>>>in standard networks. In fact the transport plane handles suppression of >>>>>>alarms on all equipment in the network (not just cross-connects). >>>>>> >>>>>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>>>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>>>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>>>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>>>>downstream Cross-connects would not detect LOL upon faults occurring >>>>>>upstream. The 3R points on the OLS Line Systems would insert some type >>>>>>of signal >>>>>> dow >>>>>>ns >>>>>>tream. Therefore the mechanism described in Section 6.2 >>>>>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>>>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>>>>in an all-optical network may alarm due to upstream faults. These alarms >>>>>>also need to be suppressed. LMP seems to only address the suppression of >>>>>>downstream alarms on cross-connects without taking into consideration >>>>>>the network that sits between the cross-connects. Is LMP also expected >>>>>>to have to be processed on Optical Amplifiers? This seems to be >>>>>>undesirable, especially given all the various applications that seem to >>>>>>be included into the LMP protocol that would not have anything to do >>>>>>with Optical Amplifieris. >>>>>> >>>>>For interaction between cross-connects and Line Systems, please see OLI >>>>>Requirements document >>>>>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>>>>corresponding LMP-WDM protocol document (new version to be uploaded >>>>>tomorrow, but old version can be found at >>>>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >>>>> >>>>>>Any other views? >>>>>> >>>>>>Carmine >>>>>> --------------010807000000030807010105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sudheer,

See inline.

Thanks
Carmine

Sudheer Dharanikota wrote:
Hi Carmine:

Carmine Daloia wrote:

Hi George,

Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration.

It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE.  This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts?
 

YOur solution precludes local restoration options.

No it doesn't. For local restoration options (I assume you mean span/link restoration) the tail-end and head-end nodes of the protection/restoration domain are the adjacent cross-connects. So as I said before, the signaling to determine if a fault occurred within a protection/restoration domain and then initiate a switch takes place between the head-end and tail-end nodes of a protection/restoration domain. This domain could be a span/link or an end-to-end path.

Cheers,

sudheer

 
Thanks
Carmine

George Young wrote:

Hello Carmine,  Meriton Networks intends to use LMP as a fault localization mechanism in a network of our  transparent optical switches, currently in the pre-production phase.   I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change  our design direction.  I've also written and submitted an IETF draft  http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt dealing with the importance of control network performance, particularly when extended across  multiple  networks, and would appreciate any comments you might have.   Regards, George R. Young Meriton Networks Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268
-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com ]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; ccamp@ops.ietf.org ; tsg15q11@itu.int ; t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
 
Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a fail
ure notification through the
 Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R poin
ts on the OLS Line Systems would insert some type 
of signal
 dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine


--------------010807000000030807010105-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:23:07 -0800 Message-ID: <3BFBC727.6030506@lucent.com> Date: Wed, 21 Nov 2001 10:24:23 -0500 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: Sudheer Dharanikota CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------010708010306060809020607" --------------010708010306060809020607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sudheer, I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system. Thanks Carmine Sudheer Dharanikota wrote: > Carmine... > > Again can you suggest a way to communicate such signals > between line systems and cross connects when inband > communication is not supported between these two systems? > > Cheers, > > sudheer > > Carmine Daloia wrote: > >> Jonathan, >> >> Forgot to mention, that the performance aspects of carrying OAM type >> signals over an IP based control channel in LMP-WDM would have to be >> analyzed. It is possible that the IP Control Channel will not provide >> fast enough transfer to actually suppress downstream alarms, however >> that needs to be analyzed as part of LMP-WDM. >> >> Thanks >> Carmine >> >> Carmine Daloia wrote: >> >>> Jonathan, >>> >>> The LMP-WDM document specifies the signaling between the >>> Cross-connect and OLS, assuming they are from different vendors. If >>> they are from different vendors, then a standard interface is needed >>> to exchange some information. One type of information that would >>> need to be exchanged is some OAM signals. Maarten described some of >>> these signals in his VBI document. However, I don't see why OAM >>> signals would have to be exchanged directly between the >>> cross-connects themselves via LMP. >>> >>> Let's look at the following network. >>> >>> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >>> >>> Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical >>> Amplifiers. >>> >>> Let's assume a failure on OLSA. OLSA via overhead within an OSC >>> suppresses alarms within OLSA. OAM messages (e.g., Optical Channel >>> FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 >>> will have to forward the FDI signals downstream over the LMP-WDM >>> control channel to OLSB. OLSB will then forward these FDI signals >>> over its OSC and then over the LMP-WDM control channel to OXC3..... >>> etc... >>> >>> Note that OXC2 does not need to directly forward these FDI signals >>> to OXC3. So it is possible, that in LMP-WDM, we may need to define >>> messages corresponding to FDI signals to suppress downstream alarms, >>> however we don't need to define such messages in LMP. >>> >>> Thanks >>> Carmine >>> >>> Jonathan Lang wrote: >>> >>>>Carmine, >>>> Please see inline. >>>> >>>>Thanks, >>>>Jonathan >>>> >>>>>-----Original Message----- >>>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>>Sent: Monday, November 19, 2001 6:44 AM >>>>>To: ccamp@ops.ietf.org >>>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>>Subject: LMP: Suppression of Downstream Alarms... >>>>> >>>>> >>>>>Hi all, >>>>> >>>>>As I read through Section 6 "Fault Management", one issue that it seems >>>>>to be addressing is "Suppression of Downstream Alarms". >>>>> >>>>>In section 6.2, it states that "If data links fail between two PXCs, the >>>>>power monitoring system in all of the downstream nodes may detect LOL >>>>>and indicate a failure. To avoid multiple alarms stemming from the same >>>>>failure, LMP provides a failure notification through the Cha >>>>>nn >>>>>elStatus >>>>>message...". >>>>> >>>>>I agree that the suppression of downstream alarms is an important issue. >>>>> >>>>great! >>>> >>>>>If we look at standard networks (both SONET/SDH and OTN), this >>>>>capability is already provided by the overhead in SDH/SONET and G.709 >>>>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>>>networks as well as opaque networks. I don't think we need to burden the >>>>>control plane with such functions when the transport plane handles this >>>>>in standard networks. In fact the transport plane handles suppression of >>>>>alarms on all equipment in the network (not just cross-connects). >>>>> >>>>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>>>downstream Cross-connects would not detect LOL upon faults occurring >>>>>upstream. The 3R points on the OLS Line Systems would insert some type >>>>>of signal dow >>>>>ns >>>>>tream. Therefore the mechanism described in Section 6.2 >>>>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>>>in an all-optical network may alarm due to upstream faults. These alarms >>>>>also need to be suppressed. LMP seems to only address the suppression of >>>>>downstream alarms on cross-connects without taking into consideration >>>>>the network that sits between the cross-connects. Is LMP also expected >>>>>to have to be processed on Optical Amplifiers? This seems to be >>>>>undesirable, especially given all the various applications that seem to >>>>>be included into the LMP protocol that would not have anything to do >>>>>with Optical Amplifieris. >>>>> >>>>For interaction between cross-connects and Line Systems, please see OLI >>>>Requirements document >>>>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>>>corresponding LMP-WDM protocol document (new version to be uploaded >>>>tomorrow, but old version can be found at >>>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >>>> >>>>>Any other views? >>>>> >>>>>Carmine >>>>> --------------010708010306060809020607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sudheer,

I am not assuming inband communication is supported between the cross-connect and the line system. That is why I said that when the PXC and line system are from different vendors such OAM signals would have to be carried over a separate channel (e.g., LMP-WDM control channel). However, I don't see why such signals would have to be carried over an LMP control channel between cross-connects. Also, my point about performance was that we would have to see if the LMP control channel would meet the performance requirements for such OAM signals. It very well might. If not, a bit-oriented signaling interface may be needed between the PXC and the line system.

Thanks
Carmine

Sudheer Dharanikota wrote:
Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure noti
fication through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on th
e OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine


--------------010708010306060809020607-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:17:55 -0800 Message-ID: <3BFBC4D4.24C77151@nayna.com> Date: Wed, 21 Nov 2001 07:14:28 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: George Young , ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------A54F2507737F464180A10D77" This is a multi-part message in MIME format. --------------A54F2507737F464180A10D77 Content-Type: multipart/alternative; boundary="------------BCAA430C513D2B3FB633306C" --------------BCAA430C513D2B3FB633306C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carmine: Carmine Daloia wrote: > Hi George, > > Thanks for the pointer to your draft. I will definitely > read over it. Just looking at it quickly and understanding > what is in LMP, it seems that even under path > protection/restoration, there is an intermediate node that > detects a failure (and localizes the failure to ensure > that the failure occured on that particular link) and then > signals over the control plane to the head-end and > tail-end nodes of the protection/restoration domain to > initiate protection/restoration. > > It seems to me that the tail-end and head-end nodes > themselves would be able to detect the defect in the > transport/user plane since the defect occured between the > two ends and they can then coordinate switching for > protection/restoration without having to wait for any > notification message sent from an intermediate NE. This > should improve the protection/restoration time since the > head-end and tail-end won't need to wait for intermediate > nodes to localize a fault and then signal over a control > plane requesting a proteciton/restoration switch. Any > thoughts? > YOur solution precludes local restoration options. Cheers, sudheer > > Thanks > Carmine > > George Young wrote: > >> Hello Carmine, Meriton Networks intends to use LMP as a >> fault localization mechanism in a network >> ofour transparent optical switches, currently in the >> pre-production phase. I've done some discrete event >> simulation work to characterize the performance of an >> IPnetwork in support LMP management signals, and the >> resulting signalling messages neededto initiate >> protection/restoration, and based on the results, have >> not seen any need to change our design direction. I've >> also written and submitted an IETF >> draft http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txtdealing >> with the importance of control network performance, >> particularly when extended across multiple networks, and >> would appreciate any comments you might >> have. Regards,George R. YoungMeriton Networks Inc. >> 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> phone: +1 613-270-9279 Ext 287 >> fax: +1 613-270-9268 >> >> -----Original Message----- >> From: Carmine Daloia >> [mailto:daloia@lucent.com] >> Sent: Wednesday, November 21, 2001 8:29 AM >> To: Carmine Daloia >> Cc: Jonathan Lang; ccamp@ops.ietf.org; >> tsg15q11@itu.int; t1x15@t1.org >> Subject: Re: [T1X1.5] Re: Suppression of >> Downstream Alarms... >> >> Jonathan, >> >> Forgot to mention, that the performance >> aspects of carrying OAM type signals over an >> IP based control channel in LMP-WDM would have >> to be analyzed. It is possible that the IP >> Control Channel will not provide fast enough >> transfer to actually suppress downstream >> alarms, however that needs to be analyzed as >> part of LMP-WDM. >> >> Thanks >> Carmine >> >> Carmine Daloia wrote: >> >> > Jonathan, >> > >> > The LMP-WDM document specifies the signaling >> > between the Cross-connect and OLS, assuming >> > they are from different vendors. If they are >> > from different vendors, then a standard >> > interface is needed to exchange some >> > information. One type of information that >> > would need to be exchanged is some OAM >> > signals. Maarten described some of these >> > signals in his VBI document. However, I don't >> > see why OAM signals would have to be >> > exchanged directly between the cross-connects >> > themselves via LMP. >> > >> > Let's look at the following network. >> > >> > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- >> > OLSC --- OXC4 >> > >> > Note that the OLS consists of DWDM Mux/Dmux >> > Terminals and Optical Amplifiers. >> > >> > Let's assume a failure on OLSA. OLSA via >> > overhead within an OSC suppresses alarms >> > within OLSA. OAM messages (e.g., Optical >> > Channel FDI) could be carried over the >> > LMP-WDM control channel to OXC2. OXC2 will >> > have to forward the FDI signals downstream >> > over the LMP-WDM control channel to OLSB. >> > OLSB will then forward these FDI signals over >> > its OSC and then over the LMP-WDM control >> > channel to OXC3..... etc... >> > >> > Note that OXC2 does not need to directly >> > forward these FDI signals to OXC3. So it is >> > possible, that in LMP-WDM, we may need to >> > define messages corresponding to FDI signals >> > to suppress downstream alarms, however we >> > don't need to define such messages in LMP. >> > >> > Thanks >> > Carmine >> > >> > Jonathan Lang wrote: >> > >> >> Carmine, >> >> Please see inline. >> >> >> >> Thanks, >> >> Jonathan >> >> >> >> >> >> > -----Original Message----- >> >> > From: Carmine Daloia [ >> >> > mailto:daloia@lucent.com] >> >> > Sent: Monday, November 19, 2001 6:44 AM >> >> > To: ccamp@ops.ietf.org >> >> > Cc: tsg15q11@itu.int; t1x15@t1.org >> >> > Subject: LMP: Suppression of Downstream >> >> > Alarms... >> >> > >> >> > >> >> > Hi all, >> >> > >> >> > As I read through Section 6 "Fault >> >> > Management", one issue that it seems >> >> > to be addressing is "Suppression of >> >> > Downstream Alarms". >> >> > >> >> > In section 6.2, it states that "If data >> >> > links fail between two PXCs, the >> >> > power monitoring system in all of the >> >> > downstream nodes may detect LOL >> >> > and indicate a failure. To avoid multiple >> >> > alarms stemming from the same >> >> > failure, LMP provides a failure >> >> > notification through the >> >> > Cha >> >> > nn >> >> > elStatus >> >> > message...". >> >> > >> >> > I agree that the suppression of >> >> > downstream alarms is an important issue. >> >> > >> >> great! >> >> >> >> >> >> > If we look at standard networks (both >> >> > SONET/SDH and OTN), this >> >> > capability is already provided by the >> >> > overhead in SDH/SONET and G.709 >> >> > OTN. G.709 OTN handles suppression of >> >> > alarms in both all-optical >> >> > networks as well as opaque networks. I >> >> > don't think we need to burden the >> >> > control plane with such functions when >> >> > the transport plane handles this >> >> > in standard networks. In fact the >> >> > transport plane handles suppression of >> >> > alarms on all equipment in the network >> >> > (not just cross-connects). >> >> > >> >> > If we look at a pre-OTN ("non-standard") >> >> > scenario consisting of >> >> > Cross-connects, Optical Line Systems, and >> >> > Optical Amplifiers supporting >> >> > a DWDM networked solution, we can analyze >> >> > two scenarios. One scenario is >> >> > an opaque network (e.g., the OLS supports >> >> > 3R). In this scenario, the >> >> > downstream Cross-connects would not >> >> > detect LOL upon faults occurring >> >> > upstream. The 3R points on the OLS Line >> >> > Systems would insert some type >> >> > of signal >> >> > dow >> >> > ns >> >> > tream. Therefore the mechanism described >> >> > in Section 6.2 >> >> > does not apply. Another scenario is an >> >> > all-optical pre-OTN network. Note >> >> > that other equipment besides >> >> > Cross-connects (e.g., Optical >> >> > Amplifiers) >> >> > in an all-optical network may alarm due >> >> > to upstream faults. These alarms >> >> > also need to be suppressed. LMP seems to >> >> > only address the suppression of >> >> > downstream alarms on cross-connects >> >> > without taking into consideration >> >> > the network that sits between the >> >> > cross-connects. Is LMP also expected >> >> > to have to be processed on Optical >> >> > Amplifiers? This seems to be >> >> > undesirable, especially given all the >> >> > various applications that seem to >> >> > be included into the LMP protocol that >> >> > would not have anything to do >> >> > with Optical Amplifieris. >> >> > >> >> For interaction between cross-connects and >> >> Line Systems, please see OLI >> >> Requirements document >> >> ( >> >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> >> ) and >> >> corresponding LMP-WDM protocol document >> >> (new version to be uploaded >> >> tomorrow, but old version can be found at >> >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> >> ). >> >> >> >> >> >> > Any other views? >> >> > >> >> > Carmine >> >> > >> >> > --------------BCAA430C513D2B3FB633306C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carmine:

Carmine Daloia wrote:

Hi George,

Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration.

It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE.  This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts?
 

YOur solution precludes local restoration options.

Cheers,

sudheer

 
Thanks
Carmine

George Young wrote:

Hello Carmine, Meriton Networks intends to use LMP as a fault localization mechanism in a network ofour transparent optical switches, currently in the pre-production phase. I've done some discrete event simulation work to characterize the performance of an IPnetwork in support LMP management signals, and the resulting signalling messages neededto initiate protection/restoration, and based on the results, have not seen any need to change our design direction. I've also written and submitted an IETF draft http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txtdealing with the importance of control network performance, particularly when extended across multiple networks, and would appreciate any comments you might have. Regards,George R. YoungMeriton Networks Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268
-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
 
Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan


-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure notification through the
 Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!


If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on the OLS Line Systems would insert some type 
of signal
 dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).


Any other views?

Carmine
--------------BCAA430C513D2B3FB633306C-- --------------A54F2507737F464180A10D77 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------A54F2507737F464180A10D77-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:17:37 -0800 Message-ID: <3BFBC5E8.4000109@lucent.com> Date: Wed, 21 Nov 2001 10:19:04 -0500 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: Sudheer Dharanikota CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Sudheer, I was assuming PXCs and not necessarily support for G.709. Carmine Sudheer Dharanikota wrote: >Hi Carmine: > >Couple of observations... > >It seems you are assuming only G.709 based cross connects >only. >Please let me know if I am not correct. > >LMP-DWDM works for PXC and other crossconencts which does >not >use inband fault notification. > >Cheers, > >sudheer > >Carmine Daloia wrote: > >>Jonathan, >> >>The LMP-WDM document specifies the signaling between the >>Cross-connect and OLS, assuming they are from different >>vendors. If they are from different vendors, then a >>standard interface is needed to exchange some information. >>One type of information that would need to be exchanged is >>some OAM signals. Maarten described some of these signals >>in his VBI document. However, I don't see why OAM signals >>would have to be exchanged directly between the >>cross-connects themselves via LMP. >> >>Let's look at the following network. >> >>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >> >>Note that the OLS consists of DWDM Mux/Dmux Terminals and >>Optical Amplifiers. >> >>Let's assume a failure on OLSA. OLSA via overhead within >>an OSC suppresses alarms within OLSA. OAM messages (e.g., >>Optical Channel FDI) could be carried over the LMP-WDM >>control channel to OXC2. OXC2 will have to forward the FDI >>signals downstream over the LMP-WDM control channel to >>OLSB. OLSB will then forward these FDI signals over its >>OSC and then over the LMP-WDM control channel to OXC3..... >>etc... >> >>Note that OXC2 does not need to directly forward these FDI >>signals to OXC3. So it is possible, that in LMP-WDM, we >>may need to define messages corresponding to FDI signals >>to suppress downstream alarms, however we don't need to >>define such messages in LMP. >> >>Thanks >>Carmine >> >>Jonathan Lang wrote: >> >>>Carmine, >>> Please see inline. >>> >>>Thanks, >>>Jonathan >>> >>> >>>>-----Original Message----- >>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>Sent: Monday, November 19, 2001 6:44 AM >>>>To: ccamp@ops.ietf.org >>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>Subject: LMP: Suppression of Downstream Alarms... >>>> >>>> >>>>Hi all, >>>> >>>>As I read through Section 6 "Fault Management", one >>>>issue that it seems >>>>to be addressing is "Suppression of Downstream Alarms". >>>> >>>>In section 6.2, it states that "If data links fail >>>>between two PXCs, the >>>>power monitoring system in all of the downstream nodes >>>>may detect LOL >>>>and indicate a failure. To avoid multiple alarms >>>>stemming from the same >>>>failure, LMP provides a failure notification through >>>>the Chann >>>>elStatus >>>>message...". >>>> >>>>I agree that the suppression of downstream alarms is an >>>>important issue. >>>> >>>great! >>> >>> >>>>If we look at standard networks (both SONET/SDH and >>>>OTN), this >>>>capability is already provided by the overhead in >>>>SDH/SONET and G.709 >>>>OTN. G.709 OTN handles suppression of alarms in both >>>>all-optical >>>>networks as well as opaque networks. I don't think we >>>>need to burden the >>>>control plane with such functions when the transport >>>>plane handles this >>>>in standard networks. In fact the transport plane >>>>handles suppression of >>>>alarms on all equipment in the network (not just >>>>cross-connects). >>>> >>>>If we look at a pre-OTN ("non-standard") scenario >>>>consisting of >>>>Cross-connects, Optical Line Systems, and Optical >>>>Amplifiers supporting >>>>a DWDM networked solution, we can analyze two >>>>scenarios. One scenario is >>>>an opaque network (e.g., the OLS supports 3R). In this >>>>scenario, the >>>>downstream Cross-connects would not detect LOL upon f >>>>aults occurring >>>>upstream. The 3R points on the OLS Line Systems would >>>>insert some type >>>>of signal downs >>>>tream. Therefore the mechanism described in Section >>>>6.2 >>>>does not apply. Another scenario is an all-optical >>>>pre-OTN network. Note >>>>that other equipment besides Cross-connects (e.g., >>>>Optical Amplifiers) >>>>in an all-optical network may alarm due to upstream >>>>faults. These alarms >>>>also need to be suppressed. LMP seems to only address >>>>the suppression of >>>>downstream alarms on cross-connects without taking into >>>>consideration >>>>the network that sits between the cross-connects. Is >>>>LMP also expected >>>>to have to be processed on Optical Amplifiers? This >>>>seems to be >>>>undesirable, especially given all the various >>>>applications that seem to >>>>be included into the LMP protocol that would not have >>>>anything to do >>>>with Optical Amplifieris. >>>> >>>For interaction between cross-connects and Line Systems, >>>please see OLI >>>Requirements document >>>( >>>http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >>>) and >>>corresponding LMP-WDM protocol document (new version to >>>be uploaded >>>tomorrow, but old version can be found at >>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >>>). >>> >>> >>>>Any other views? >>>> >>>>Carmine >>>> >>>> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:14:48 -0800 Message-ID: <3BFBC412.E5FC940B@nayna.com> Date: Wed, 21 Nov 2001 07:11:14 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------FAFAD5E10173C32B6E34E4CB" This is a multi-part message in MIME format. --------------FAFAD5E10173C32B6E34E4CB Content-Type: multipart/alternative; boundary="------------C1F7110C5A99508CC865CAE8" --------------C1F7110C5A99508CC865CAE8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carmine... Again can you suggest a way to communicate such signals between line systems and cross connects when inband communication is not supported between these two systems? Cheers, sudheer Carmine Daloia wrote: > Jonathan, > > Forgot to mention, that the performance aspects of > carrying OAM type signals over an IP based control channel > in LMP-WDM would have to be analyzed. It is possible that > the IP Control Channel will not provide fast enough > transfer to actually suppress downstream alarms, however > that needs to be analyzed as part of LMP-WDM. > > Thanks > Carmine > > Carmine Daloia wrote: > >> Jonathan, >> >> The LMP-WDM document specifies the signaling between the >> Cross-connect and OLS, assuming they are from different >> vendors. If they are from different vendors, then a >> standard interface is needed to exchange some >> information. One type of information that would need to >> be exchanged is some OAM signals. Maarten described some >> of these signals in his VBI document. However, I don't >> see why OAM signals would have to be exchanged directly >> between the cross-connects themselves via LMP. >> >> Let's look at the following network. >> >> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- >> OXC4 >> >> Note that the OLS consists of DWDM Mux/Dmux Terminals >> and Optical Amplifiers. >> >> Let's assume a failure on OLSA. OLSA via overhead within >> an OSC suppresses alarms within OLSA. OAM messages >> (e.g., Optical Channel FDI) could be carried over the >> LMP-WDM control channel to OXC2. OXC2 will have to >> forward the FDI signals downstream over the LMP-WDM >> control channel to OLSB. OLSB will then forward these >> FDI signals over its OSC and then over the LMP-WDM >> control channel to OXC3..... etc... >> >> Note that OXC2 does not need to directly forward these >> FDI signals to OXC3. So it is possible, that in LMP-WDM, >> we may need to define messages corresponding to FDI >> signals to suppress downstream alarms, however we don't >> need to define such messages in LMP. >> >> Thanks >> Carmine >> >> Jonathan Lang wrote: >> >> > Carmine, >> > Please see inline. >> > >> > Thanks, >> > Jonathan >> > >> > >> >> -----Original Message----- >> >> From: Carmine Daloia [mailto:daloia@lucent.com] >> >> Sent: Monday, November 19, 2001 6:44 AM >> >> To: ccamp@ops.ietf.org >> >> Cc: tsg15q11@itu.int; t1x15@t1.org >> >> Subject: LMP: Suppression of Downstream Alarms... >> >> >> >> >> >> Hi all, >> >> >> >> As I read through Section 6 "Fault Management", one >> >> issue that it seems >> >> to be addressing is "Suppression of Downstream >> >> Alarms". >> >> >> >> In section 6.2, it states that "If data links fail >> >> between two PXCs, the >> >> power monitoring system in all of the downstream >> >> nodes may detect LOL >> >> and indicate a failure. To avoid multiple alarms >> >> stemming from the same >> >> failure, LMP provides a failure notification through >> >> the Cha >> >> nn >> >> elStatus >> >> message...". >> >> >> >> I agree that the suppression of downstream alarms is >> >> an important issue. >> >> >> > great! >> > >> > >> >> If we look at standard networks (both SONET/SDH and >> >> OTN), this >> >> capability is already provided by the overhead in >> >> SDH/SONET and G.709 >> >> OTN. G.709 OTN handles suppression of alarms in both >> >> all-optical >> >> networks as well as opaque networks. I don't think we >> >> need to burden the >> >> control plane with such functions when the transport >> >> plane handles this >> >> in standard networks. In fact the transport plane >> >> handles suppression of >> >> alarms on all equipment in the network (not just >> >> cross-connects). >> >> >> >> If we look at a pre-OTN ("non-standard") scenario >> >> consisting of >> >> Cross-connects, Optical Line Systems, and Optical >> >> Amplifiers supporting >> >> a DWDM networked solution, we can analyze two >> >> scenarios. One scenario is >> >> an opaque network (e.g., the OLS supports 3R). In >> >> this scenario, the >> >> downstream Cross-connects would not detect LOL upon >> >> faults occurring >> >> upstream. The 3R points on the OLS Line Systems would >> >> insert some type >> >> of signal dow >> >> ns >> >> tream. Therefore the mechanism described in Section >> >> 6.2 >> >> does not apply. Another scenario is an all-optical >> >> pre-OTN network. Note >> >> that other equipment besides Cross-connects (e.g., >> >> Optical Amplifiers) >> >> in an all-optical network may alarm due to upstream >> >> faults. These alarms >> >> also need to be suppressed. LMP seems to only address >> >> the suppression of >> >> downstream alarms on cross-connects without taking >> >> into consideration >> >> the network that sits between the cross-connects. Is >> >> LMP also expected >> >> to have to be processed on Optical Amplifiers? This >> >> seems to be >> >> undesirable, especially given all the various >> >> applications that seem to >> >> be included into the LMP protocol that would not have >> >> anything to do >> >> with Optical Amplifieris. >> >> >> > For interaction between cross-connects and Line >> > Systems, please see OLI >> > Requirements document >> > ( >> > http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> > ) and >> > corresponding LMP-WDM protocol document (new version to >> > be uploaded >> > tomorrow, but old version can be found at >> > http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> > ). >> > >> > >> >> Any other views? >> >> >> >> Carmine >> >> >> >> --------------C1F7110C5A99508CC865CAE8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Carmine...

Again can you suggest a way to communicate such signals
between line systems and cross connects when inband
communication is not supported between these two systems?

Cheers,

sudheer

Carmine Daloia wrote:

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:

Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote: 

Carmine,
  Please see inline.

Thanks,
Jonathan


-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure notification through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!


If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on the OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).


Any other views?

Carmine
--------------C1F7110C5A99508CC865CAE8-- --------------FAFAD5E10173C32B6E34E4CB Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------FAFAD5E10173C32B6E34E4CB-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 07:14:21 -0800 Message-ID: <3BFBC37A.6A9CEE91@nayna.com> Date: Wed, 21 Nov 2001 07:08:42 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: multipart/mixed; boundary="------------F691D07249C14E7CE3B827C5" This is a multi-part message in MIME format. --------------F691D07249C14E7CE3B827C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carmine: Couple of observations... It seems you are assuming only G.709 based cross connects only. Please let me know if I am not correct. LMP-DWDM works for PXC and other crossconencts which does not use inband fault notification. Cheers, sudheer Carmine Daloia wrote: > Jonathan, > > The LMP-WDM document specifies the signaling between the > Cross-connect and OLS, assuming they are from different > vendors. If they are from different vendors, then a > standard interface is needed to exchange some information. > One type of information that would need to be exchanged is > some OAM signals. Maarten described some of these signals > in his VBI document. However, I don't see why OAM signals > would have to be exchanged directly between the > cross-connects themselves via LMP. > > Let's look at the following network. > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > Note that the OLS consists of DWDM Mux/Dmux Terminals and > Optical Amplifiers. > > Let's assume a failure on OLSA. OLSA via overhead within > an OSC suppresses alarms within OLSA. OAM messages (e.g., > Optical Channel FDI) could be carried over the LMP-WDM > control channel to OXC2. OXC2 will have to forward the FDI > signals downstream over the LMP-WDM control channel to > OLSB. OLSB will then forward these FDI signals over its > OSC and then over the LMP-WDM control channel to OXC3..... > etc... > > Note that OXC2 does not need to directly forward these FDI > signals to OXC3. So it is possible, that in LMP-WDM, we > may need to define messages corresponding to FDI signals > to suppress downstream alarms, however we don't need to > define such messages in LMP. > > Thanks > Carmine > > Jonathan Lang wrote: > >> Carmine, >> Please see inline. >> >> Thanks, >> Jonathan >> >> >> > -----Original Message----- >> > From: Carmine Daloia [mailto:daloia@lucent.com] >> > Sent: Monday, November 19, 2001 6:44 AM >> > To: ccamp@ops.ietf.org >> > Cc: tsg15q11@itu.int; t1x15@t1.org >> > Subject: LMP: Suppression of Downstream Alarms... >> > >> > >> > Hi all, >> > >> > As I read through Section 6 "Fault Management", one >> > issue that it seems >> > to be addressing is "Suppression of Downstream Alarms". >> > >> > In section 6.2, it states that "If data links fail >> > between two PXCs, the >> > power monitoring system in all of the downstream nodes >> > may detect LOL >> > and indicate a failure. To avoid multiple alarms >> > stemming from the same >> > failure, LMP provides a failure notification through >> > the Chann >> > elStatus >> > message...". >> > >> > I agree that the suppression of downstream alarms is an >> > important issue. >> > >> great! >> >> >> > If we look at standard networks (both SONET/SDH and >> > OTN), this >> > capability is already provided by the overhead in >> > SDH/SONET and G.709 >> > OTN. G.709 OTN handles suppression of alarms in both >> > all-optical >> > networks as well as opaque networks. I don't think we >> > need to burden the >> > control plane with such functions when the transport >> > plane handles this >> > in standard networks. In fact the transport plane >> > handles suppression of >> > alarms on all equipment in the network (not just >> > cross-connects). >> > >> > If we look at a pre-OTN ("non-standard") scenario >> > consisting of >> > Cross-connects, Optical Line Systems, and Optical >> > Amplifiers supporting >> > a DWDM networked solution, we can analyze two >> > scenarios. One scenario is >> > an opaque network (e.g., the OLS supports 3R). In this >> > scenario, the >> > downstream Cross-connects would not detect LOL upon f >> > aults occurring >> > upstream. The 3R points on the OLS Line Systems would >> > insert some type >> > of signal downs >> > tream. Therefore the mechanism described in Section >> > 6.2 >> > does not apply. Another scenario is an all-optical >> > pre-OTN network. Note >> > that other equipment besides Cross-connects (e.g., >> > Optical Amplifiers) >> > in an all-optical network may alarm due to upstream >> > faults. These alarms >> > also need to be suppressed. LMP seems to only address >> > the suppression of >> > downstream alarms on cross-connects without taking into >> > consideration >> > the network that sits between the cross-connects. Is >> > LMP also expected >> > to have to be processed on Optical Amplifiers? This >> > seems to be >> > undesirable, especially given all the various >> > applications that seem to >> > be included into the LMP protocol that would not have >> > anything to do >> > with Optical Amplifieris. >> > >> For interaction between cross-connects and Line Systems, >> please see OLI >> Requirements document >> ( >> http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt >> ) and >> corresponding LMP-WDM protocol document (new version to >> be uploaded >> tomorrow, but old version can be found at >> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt >> ). >> >> >> > Any other views? >> > >> > Carmine >> > >> > --------------F691D07249C14E7CE3B827C5 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------F691D07249C14E7CE3B827C5-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 06:51:22 -0800 Message-ID: <3BFBBE79.DE6698C1@alcatel.be> Date: Wed, 21 Nov 2001 15:47:21 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Germano Gasparini CC: neil.2.harrison@bt.com, betts01@nortelnetworks.com, daloia@lucent.com, ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... and more Content-Type: multipart/mixed; boundary="------------7BE596F8CF1DB4A964583FF5" This is a multi-part message in MIME format. --------------7BE596F8CF1DB4A964583FF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, In order to re-inforce the message sent by Germano concerning our full support to LMP, i would like to point out here that we have submitted together with Jonathan an I-D dealing with Sonet/SDH extensions for LMP. This I-D can be found at (IETF website of course ;-) http://search.ietf.org/internet-drafts/draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Any feedback is highly appreciated. Thanks, - dimitri. Germano Gasparini wrote: > > Hello everybody > > I realized after sending the message that I expressed myself in a > potentially misleading way. > > Just to explain the meaning of my posting: > - When I said I am "new in the exploder" I was simply meaning that > that was the first time I was sending directly a message to the mailing list. > Actually, I'm not new in the standardization activity (mainly ITU) > and I cooperate to some IETF drafts as well. > > - The position I expressed was not meaning that I am against LMP > nor LMP-WDM, nor it shall be absolutely interpreted in that sense. > I was simply noticing that in transport networks there could be a > redundancy if alarm suppression indications are transferred both > on signalling and transport plane. However, it is also clear to me > (it was not in my posting) this redundancy does not cause any harm. > > - Additionaly, also in transport network (real networks) there could be > situations when the alarm suppression indication is not embedded > (G.709 pre-OTN without non-associated overhead is a typical example). > In this case, alarm suppression in the signalling control plane would bring > a significant added value. > > Hope this will help clarifying the picture. > > Best regards > Germano Gasparini > > -- > Germano Gasparini - A-Optics Network Management Systems > ========================================================== > Phone: 2-210.(3)4910 Fax: 2-210.(3)4185 > Please reply at: mailto:germano.gasparini@alcatel.it --------------7BE596F8CF1DB4A964583FF5 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------7BE596F8CF1DB4A964583FF5-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 06:20:52 -0800 Message-ID: <3BFBB8B9.9000302@lucent.com> Date: Wed, 21 Nov 2001 09:22:49 -0500 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: George Young CC: ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------020802070302010102080307" --------------020802070302010102080307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi George, Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration. It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE. This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts? Thanks Carmine George Young wrote: > Hello Carmine, > > > > Meriton Networks intends to use LMP as a fault localization > mechanism in a network of > > our transparent optical switches, currently in the pre-production phase. > > > > I've done some discrete event simulation work to characterize the > performance of an IP > > network in support LMP management signals, and the resulting > signalling messages needed > > to initiate protection/restoration, and based on the results, have not > seen any need to change > > our design direction. > > > > I've also written and submitted an IETF draft > > http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt > > > dealing with the importance of control network performance, > particularly when extended across > > multiple networks, and would appreciate any comments you might have. > > > > Regards, > > George R. Young > > Meriton Networks Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > -----Original Message----- > From: Carmine Daloia [mailto:daloia@lucent.com] > Sent: Wednesday, November 21, 2001 8:29 AM > To: Carmine Daloia > Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org > Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... > > Jonathan, > > Forgot to mention, that the performance aspects of carrying OAM > type signals over an IP based control channel in LMP-WDM would > have to be analyzed. It is possible that the IP Control Channel > will not provide fast enough transfer to actually suppress > downstream alarms, however that needs to be analyzed as part of > LMP-WDM. > > Thanks > Carmine > > Carmine Daloia wrote: > >> Jonathan, >> >> The LMP-WDM document specifies the signaling between the >> Cross-connect and OLS, assuming they are from different vendors. >> If they are from different vendors, then a standard interface is >> needed to exchange some information. One type of information that >> would need to be exchanged is some OAM signals. Maarten described >> some of these signals in his VBI document. However, I don't see >> why OAM signals would have to be exchanged directly between the >> cross-connects themselves via LMP. >> >> Let's look at the following network. >> >> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 >> >> Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical >> Amplifiers. >> >> Let's assume a failure on OLSA. OLSA via overhead within an OSC >> suppresses alarms within OLSA. OAM messages (e.g., Optical >> Channel FDI) could be carried over the LMP-WDM control channel to >> OXC2. OXC2 will have to forward the FDI signals downstream over >> the LMP-WDM control channel to OLSB. OLSB will then forward these >> FDI signals over its OSC and then over the LMP-WDM control >> channel to OXC3..... etc... >> >> Note that OXC2 does not need to directly forward these FDI >> signals to OXC3. So it is possible, that in LMP-WDM, we may need >> to define messages corresponding to FDI signals to suppress >> downstream alarms, however we don't need to define such messages >> in LMP. >> >> Thanks >> Carmine >> >> Jonathan Lang wrote: >> >>>Carmine, >>> Please see inline. >>> >>>Thanks, >>>Jonathan >>> >>>>-----Original Message----- >>>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>>Sent: Monday, November 19, 2001 6:44 AM >>>>To: ccamp@ops.ietf.org >>>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>>Subject: LMP: Suppression of Downstream Alarms... >>>> >>>> >>>>Hi all, >>>> >>>>As I read through Section 6 "Fault Management", one issue that it seems >>>>to be addressing is "Suppression of Downstream Alarms". >>>> >>>>In section 6.2, it states that "If data links fail between two PXCs, the >>>>power monitoring system in all of the downstream nodes may detect LOL >>>>and indicate a failure. To avoid multiple alarms stemming from the same >>>>failure, LMP provides a failure notification through the Cha >>>>nn >>>>elStatus >>>>message...". >>>> >>>>I agree that the suppression of downstream alarms is an important issue. >>>> >>>great! >>> >>>>If we look at standard networks (both SONET/SDH and OTN), this >>>>capability is already provided by the overhead in SDH/SONET and G.709 >>>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>>networks as well as opaque networks. I don't think we need to burden the >>>>control plane with such functions when the transport plane handles this >>>>in standard networks. In fact the transport plane handles suppression of >>>>alarms on all equipment in the network (not just cross-connects). >>>> >>>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>>downstream Cross-connects would not detect LOL upon faults occurring >>>>upstream. The 3R points on the OLS Line Systems would insert some type >>>>of signal dow >>>>ns >>>>tream. Therefore the mechanism described in Section 6.2 >>>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>>in an all-optical network may alarm due to upstream faults. These alarms >>>>also need to be suppressed. LMP seems to only address the suppression of >>>>downstream alarms on cross-connects without taking into consideration >>>>the network that sits between the cross-connects. Is LMP also expected >>>>to have to be processed on Optical Amplifiers? This seems to be >>>>undesirable, especially given all the various applications that seem to >>>>be included into the LMP protocol that would not have anything to do >>>>with Optical Amplifieris. >>>> >>>For interaction between cross-connects and Line Systems, please see OLI >>>Requirements document >>>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>>corresponding LMP-WDM protocol document (new version to be uploaded >>>tomorrow, but old version can be found at >>>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >>> >>>>Any other views? >>>> >>>>Carmine >>>> >> > --------------020802070302010102080307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration.

It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE.  This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts?

Thanks
Carmine

George Young wrote:
Hello Carmine,
 
Meriton Networks intends to use LMP as a fault localization mechanism in a network of
our transparent optical switches, currently in the pre-production phase.
 
I've done some discrete event simulation work to characterize the performance of an IP
network in support LMP management signals, and the resulting signalling messages needed
to initiate protection/restoration, and based on the results, have not seen any need to change
our design direction.
 
I've also written and submitted an IETF draft
dealing with the importance of control network performance, particularly when extended across
multiple networks, and would appreciate any comments you might have.
 
Regards,
George R. Young
Meriton Networks Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9268
-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:
Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote:
Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure notification through the
 Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on the OLS Line Systems would insert some type 
of signal
 dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine




--------------020802070302010102080307-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 05:27:01 -0800 Message-ID: <3BFBAC19.9050909@lucent.com> Date: Wed, 21 Nov 2001 08:28:57 -0500 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: Carmine Daloia CC: Jonathan Lang , ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------060201060807070400080503" --------------060201060807070400080503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: > Jonathan, > > The LMP-WDM document specifies the signaling between the Cross-connect > and OLS, assuming they are from different vendors. If they are from > different vendors, then a standard interface is needed to exchange > some information. One type of information that would need to be > exchanged is some OAM signals. Maarten described some of these signals > in his VBI document. However, I don't see why OAM signals would have > to be exchanged directly between the cross-connects themselves via LMP. > > Let's look at the following network. > > OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 > > Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical > Amplifiers. > > Let's assume a failure on OLSA. OLSA via overhead within an OSC > suppresses alarms within OLSA. OAM messages (e.g., Optical Channel > FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 > will have to forward the FDI signals downstream over the LMP-WDM > control channel to OLSB. OLSB will then forward these FDI signals over > its OSC and then over the LMP-WDM control channel to OXC3..... etc... > > Note that OXC2 does not need to directly forward these FDI signals to > OXC3. So it is possible, that in LMP-WDM, we may need to define > messages corresponding to FDI signals to suppress downstream alarms, > however we don't need to define such messages in LMP. > > Thanks > Carmine > > Jonathan Lang wrote: > >>Carmine, >> Please see inline. >> >>Thanks, >>Jonathan >> >>>-----Original Message----- >>>From: Carmine Daloia [mailto:daloia@lucent.com] >>>Sent: Monday, November 19, 2001 6:44 AM >>>To: ccamp@ops.ietf.org >>>Cc: tsg15q11@itu.int; t1x15@t1.org >>>Subject: LMP: Suppression of Downstream Alarms... >>> >>> >>>Hi all, >>> >>>As I read through Section 6 "Fault Management", one issue that it seems >>>to be addressing is "Suppression of Downstream Alarms". >>> >>>In section 6.2, it states that "If data links fail between two PXCs, the >>>power monitoring system in all of the downstream nodes may detect LOL >>>and indicate a failure. To avoid multiple alarms stemming from the same >>>failure, LMP provides a failure notification through the Chann >>>elStatus >>>message...". >>> >>>I agree that the suppression of downstream alarms is an important issue. >>> >>great! >> >>>If we look at standard networks (both SONET/SDH and OTN), this >>>capability is already provided by the overhead in SDH/SONET and G.709 >>>OTN. G.709 OTN handles suppression of alarms in both all-optical >>>networks as well as opaque networks. I don't think we need to burden the >>>control plane with such functions when the transport plane handles this >>>in standard networks. In fact the transport plane handles suppression of >>>alarms on all equipment in the network (not just cross-connects). >>> >>>If we look at a pre-OTN ("non-standard") scenario consisting of >>>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>>a DWDM networked solution, we can analyze two scenarios. One scenario is >>>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>>downstream Cross-connects would not detect LOL upon faults occurring >>>upstream. The 3R points on the OLS Line Systems would insert some type >>>of signal downs >>>tream. Therefore the mechanism described in Section 6.2 >>>does not apply. Another scenario is an all-optical pre-OTN network. Note >>>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>>in an all-optical network may alarm due to upstream faults. These alarms >>>also need to be suppressed. LMP seems to only address the suppression of >>>downstream alarms on cross-connects without taking into consideration >>>the network that sits between the cross-connects. Is LMP also expected >>>to have to be processed on Optical Amplifiers? This seems to be >>>undesirable, especially given all the various applications that seem to >>>be included into the LMP protocol that would not have anything to do >>>with Optical Amplifieris. >>> >>For interaction between cross-connects and Line Systems, please see OLI >>Requirements document >>(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >>corresponding LMP-WDM protocol document (new version to be uploaded >>tomorrow, but old version can be found at >>http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). >> >>>Any other views? >>> >>>Carmine >>> > --------------060201060807070400080503 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan,

Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM.

Thanks
Carmine

Carmine Daloia wrote:
Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote:
Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure notification through the Cha
nn
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on the OLS Line Systems would insert some type 
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine



--------------060201060807070400080503-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 05:20:15 -0800 Message-ID: <3BFBA9CC.1060609@lucent.com> Date: Wed, 21 Nov 2001 08:19:08 -0500 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: Jonathan Lang CC: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: multipart/alternative; boundary="------------050006010208070300030502" --------------050006010208070300030502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: >Carmine, > Please see inline. > >Thanks, >Jonathan > >>-----Original Message----- >>From: Carmine Daloia [mailto:daloia@lucent.com] >>Sent: Monday, November 19, 2001 6:44 AM >>To: ccamp@ops.ietf.org >>Cc: tsg15q11@itu.int; t1x15@t1.org >>Subject: LMP: Suppression of Downstream Alarms... >> >> >>Hi all, >> >>As I read through Section 6 "Fault Management", one issue that it seems >>to be addressing is "Suppression of Downstream Alarms". >> >>In section 6.2, it states that "If data links fail between two PXCs, the >>power monitoring system in all of the downstream nodes may detect LOL >>and indicate a failure. To avoid multiple alarms stemming from the same >>failure, LMP provides a failure notification through the ChannelStatus >>message...". >> >>I agree that the suppression of downstream alarms is an important issue. >> >great! > >>If we look at standard networks (both SONET/SDH and OTN), this >>capability is already provided by the overhead in SDH/SONET and G.709 >>OTN. G.709 OTN handles suppression of alarms in both all-optical >>networks as well as opaque networks. I don't think we need to burden the >>control plane with such functions when the transport plane handles this >>in standard networks. In fact the transport plane handles suppression of >>alarms on all equipment in the network (not just cross-connects). >> >>If we look at a pre-OTN ("non-standard") scenario consisting of >>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting >>a DWDM networked solution, we can analyze two scenarios. One scenario is >>an opaque network (e.g., the OLS supports 3R). In this scenario, the >>downstream Cross-connects would not detect LOL upon faults occurring >>upstream. The 3R points on the OLS Line Systems would insert some type >>of signal downstream. Therefore the mechanism described in Section 6.2 >>does not apply. Another scenario is an all-optical pre-OTN network. Note >>that other equipment besides Cross-connects (e.g., Optical Amplifiers) >>in an all-optical network may alarm due to upstream faults. These alarms >>also need to be suppressed. LMP seems to only address the suppression of >>downstream alarms on cross-connects without taking into consideration >>the network that sits between the cross-connects. Is LMP also expected >>to have to be processed on Optical Amplifiers? This seems to be >>undesirable, especially given all the various applications that seem to >>be included into the LMP protocol that would not have anything to do >>with Optical Amplifieris. >> >For interaction between cross-connects and Line Systems, please see OLI >Requirements document >(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and >corresponding LMP-WDM protocol document (new version to be uploaded >tomorrow, but old version can be found at >http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). > >>Any other views? >> >>Carmine >> --------------050006010208070300030502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan,

The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP.

Let's look at the following network.

OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4

Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.

Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc...

Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP.

Thanks
Carmine

Jonathan Lang wrote:
Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 6:44 AM
To: ccamp@ops.ietf.org
Cc: tsg15q11@itu.int; t1x15@t1.org
Subject: LMP: Suppression of Downstream Alarms...


Hi all,

As I read through Section 6 "Fault Management", one issue that it seems 
to be addressing is "Suppression of Downstream Alarms".

In section 6.2, it states that "If data links fail between two PXCs, the 
power monitoring system in all of the downstream nodes may detect LOL 
and indicate a failure. To avoid multiple alarms stemming from the same 
failure, LMP provides a failure notification through the Chann
elStatus 
message...".

I agree that the suppression of downstream alarms is an important issue.
great!

If we look at standard networks (both SONET/SDH and OTN), this 
capability is already provided by the overhead in SDH/SONET and G.709 
OTN. G.709 OTN handles suppression of alarms in both all-optical 
networks as well as opaque networks. I don't think we need to burden the 
control plane with such functions when the transport plane handles this 
in standard networks. In fact the transport plane handles suppression of 
alarms on all equipment in the network (not just cross-connects).

If we look at a pre-OTN ("non-standard") scenario consisting of 
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting 
a DWDM networked solution, we can analyze two scenarios. One scenario is 
an opaque network (e.g., the OLS supports 3R). In this scenario, the 
downstream Cross-connects would not detect LOL upon faults occurring 
upstream. The 3R points on the OLS Line Systems would insert some type 
of signal downs
tream. Therefore the mechanism described in Section 6.2 
does not apply. Another scenario is an all-optical pre-OTN network. Note 
that other equipment besides Cross-connects (e.g., Optical Amplifiers) 
in an all-optical network may alarm due to upstream faults. These alarms 
also need to be suppressed. LMP seems to only address the suppression of 
downstream alarms on cross-connects without taking into consideration 
the network that sits between the cross-connects. Is LMP also expected 
to have to be processed on Optical Amplifiers? This seems to be 
undesirable, especially given all the various applications that seem to 
be included into the LMP protocol that would not have anything to do 
with Optical Amplifieris.
For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).

Any other views?

Carmine


--------------050006010208070300030502-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 04:54:36 -0800 Message-ID: <3BFB9D95.587AE260@alcatel.it> Date: Wed, 21 Nov 2001 13:27:01 +0100 From: Germano Gasparini MIME-Version: 1.0 To: neil.2.harrison@bt.com, betts01@nortelnetworks.com, daloia@lucent.com, ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re2: Precisation on Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello everybody I realized after sending the message that I expressed myself in a potentially misleading way. Just to explain the meaning of my posting: - When I said I am "new in the exploder" I was simply meaning that that was the first time I was sending directly a message to the mailing list. Actually, I'm not new in the standardization activity (mainly ITU) and I cooperate to some IETF drafts as well. - The position I expressed was not meaning that I am against LMP nor LMP-WDM, nor it shall be absolutely interpreted in that sense. I was simply noticing that in transport networks there could be a redundancy if alarm suppression indications are transferred both on signalling and transport plane. However, it is also clear to me (it was not in my posting) this redundancy does not cause any harm. - Additionaly, also in transport network (real networks) there could be situations when the alarm suppression indication is not embedded (G.709 pre-OTN without non-associated overhead is a typical example). In this case, alarm suppression in the signalling control plane would bring a significant added value. Hope this will help clarifying the picture. Best regards Germano Gasparini -- Germano Gasparini - A-Optics Network Management Systems ========================================================== Phone: 2-210.(3)4910 Fax: 2-210.(3)4185 Please reply at: mailto:germano.gasparini@alcatel.it Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 04:11:57 -0800 Message-Id: <200111211158.GAA09743@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-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Date: Wed, 21 Nov 2001 06:58:48 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS Interworking between Sonet and SDH Author(s) : E. Mannie, D. Papadimitriou Filename : draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt Pages : 8 Date : 20-Nov-01 This document is a companion to the GMPLS extensions to control SONET/SDH networks as defined in [GMPLS-SONET-SDH], [GMPLS-SONET- SDH-EXT] and [GMPLS-SONET-SDH-RTG]. They define the SONET and SDH technology specific information needed when using GMPLS signaling. This informational memo details the GMPLS signalling and some routing specific considerations to control the interworking between SONET and SDH networks. It results from this, that interworking issues from the control plane viewpoint are well covered by the current definition of the Sonet/SDH extensions to the GMPLS protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-papadim-ccamp-gmpls-sonet-sdh-interwork-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-papadim-ccamp-gmpls-sonet-sdh-interwork-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-papadim-ccamp-gmpls-sonet-sdh-interwork-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: <20011120151542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011120151542.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 04:11:50 -0800 Message-Id: <200111211158.GAA09612@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-venkatachalam-interarea-mpls-te-02.txt Date: Wed, 21 Nov 2001 06:58:14 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering Author(s) : S. Venkatachalam, D. Papadimitriou, S. Dharanikota Filename : draft-venkatachalam-interarea-mpls-te-02.txt Pages : 15 Date : 20-Nov-01 In this draft, we propose an architecture for the inter-area LSP setup based on a combination of constraints. We derive the architectural requirements for the routing protocols, signaling protocols and the MIBs to support such an idea. We also demonstrate how such a mechanism will reduce the crankback during LSP setup. A possible outline of the modifications to the CSPF algorithm and examples are presented. In the companion document [INTER_AREA_EXT] we elaborate on the extensions required for such architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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-venkatachalam-interarea-mpls-te-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: <20011120151426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-venkatachalam-interarea-mpls-te-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-venkatachalam-interarea-mpls-te-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011120151426.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 04:07:15 -0800 From: "Joe Dumont" To: , Subject: Position of Rsvp DIFFSERV in Rsvp Path Messages Date: Wed, 21 Nov 2001 22:56:30 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, While I was reading draft-ietf-mpls-generalized-rsvp-te-05.txt, I did not see a reference to the Rsvp DIFFSERV object in the Path message BNF figure. In draft-ietf-mpls-diff-ext-09.txt it precedes the POLICY_DATA object. Where would it appear with respect to the new gMPLS objects like PROTECTION, NOTIFY_REQUEST and ADMIN_STATUS? thanks, Joe Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 02:09:10 -0800 Message-ID: <3BFB7930.B69D95D4@alcatel.it> Date: Wed, 21 Nov 2001 10:51:44 +0100 From: Germano Gasparini MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: betts01@nortelnetworks.com, daloia@lucent.com, ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org Subject: Re: Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello everybody This is my first intervention on this exploder, so a brief self-introduction. My name is Germano Gasparini. Currently I'm an Alcatel Italia employee in the Network Management System and Architecture team for transport network (SDH/WDM). My personal position on the subject is that there is no need to duplicate on the signalling alarm suppression indications (such as AIS and FDI) already provided by the transport plane. Normally AIS and FDI are processed by the transport hardware logic and therefore they are supposedly faster than a corresponding processing in the signalling layer - thus making redundant having the same information carried over there. Best regards Germano Gasparini neil.2.harrison@bt.com wrote: > Absolutely right Malcolm....and that's also why you will see the function > FDI (Forward Defect Indicator) proposed for MPLS OAM also in the user-plane. > This basic and important principle (ie suppression of downstream and client > layer alarms) is well understood by operators and most manufacturers. > > I am glad to see that (in Jonathan's response to Carmine's mail) this > principle is recognised and agreed with. > > regards, Neil > > > -----Original Message----- > > From: Malcolm Betts [mailto:betts01@nortelnetworks.com] > > Sent: 20 November 2001 21:04 > > To: 'Carmine Daloia'; ccamp@ops.ietf.org > > Cc: tsg15q11@itu.int; t1x15@t1.org > > Subject: RE: Suppression of Downstream Alarms... > > > > > > Carmine, I agree, the suppression of down stream alarms (AIS) > > should be > > provided by the transport equipment and should not rely on > > the use of a > > signalling protocol. Since as you indicated not all of the > > network elements > > on the links between the OXCs (e.g. Amplifiers) will have > > access to the > > signalling network. > > > > Malcolm Betts > > > > Advanced Network Technology > > Nortel Networks > > Phone: +1 613 763 7860 (ESN 393) > > FAX: +1 613 763 6608 (ESN 393) > > email: betts01@nortelnetworks.com > > > > > > -----Original Message----- > > From: Carmine Daloia [mailto:daloia@lucent.com] > > Sent: Monday, 19 November, 2001 09:44 > > To: ccamp@ops.ietf.org > > Cc: tsg15q11@itu.int; t1x15@t1.org > > Subject: LMP: Suppression of Downstream Alarms... > > > > > > Hi all, > > > > As I read through Section 6 "Fault Management", one issue > > that it seems > > to be addressing is "Suppression of Downstream Alarms". > > > > In section 6.2, it states that "If data links fail between > > two PXCs, the > > power monitoring system in all of the downstream nodes may detect LOL > > and indicate a failure. To avoid multiple alarms stemming > > from the same > > failure, LMP provides a failure notification through the > > ChannelStatus > > message...". > > > > I agree that the suppression of downstream alarms is an > > important issue. > > > > If we look at standard networks (both SONET/SDH and OTN), this > > capability is already provided by the overhead in SDH/SONET and G.709 > > OTN. G.709 OTN handles suppression of alarms in both all-optical > > networks as well as opaque networks. I don't think we need to > > burden the > > control plane with such functions when the transport plane > > handles this > > in standard networks. In fact the transport plane handles > > suppression of > > alarms on all equipment in the network (not just cross-connects). > > > > If we look at a pre-OTN ("non-standard") scenario consisting of > > Cross-connects, Optical Line Systems, and Optical Amplifiers > > supporting > > a DWDM networked solution, we can analyze two scenarios. One > > scenario is > > an opaque network (e.g., the OLS supports 3R). In this scenario, the > > downstream Cross-connects would not detect LOL upon faults occurring > > upstream. The 3R points on the OLS Line Systems would insert > > some type > > of signal downstream. Therefore the mechanism described in > > Section 6.2 > > does not apply. Another scenario is an all-optical pre-OTN > > network. Note > > that other equipment besides Cross-connects (e.g., Optical > > Amplifiers) > > in an all-optical network may alarm due to upstream faults. > > These alarms > > also need to be suppressed. LMP seems to only address the > > suppression of > > downstream alarms on cross-connects without taking into consideration > > the network that sits between the cross-connects. Is LMP also > > expected > > to have to be processed on Optical Amplifiers? This seems to be > > undesirable, especially given all the various applications > > that seem to > > be included into the LMP protocol that would not have anything to do > > with Optical Amplifieris. > > > > Any other views? > > > > Carmine > > > > -- Germano Gasparini - A-Optics Network Management Systems ========================================================== Phone: 2-210.(3)4910 Fax: 2-210.(3)4185 Please reply at: mailto:germano.gasparini@alcatel.it Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Nov 2001 00:01:20 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , ccamp@ops.ietf.org Subject: RE: SDH Concatenation Date: Wed, 21 Nov 2001 08:59:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Manoj, yes in most cases. VC-4 contiguous concatenation is widely supported, while VC-2 contiguous concatenation seems to be rarely supported, if at all. Even non concatenated VC-2s are some times not supported by lower order VC (4/1) SDH equipment as VC-2s are rarely used in networks. Juergen > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Wednesday, November 21, 2001 12:11 AM > To: ccamp@ops.ietf.org > Subject: SDH Concatenation > > > Hi All, > Is it possible that a SDH equipment support the contiguous > concatenation of VC-4s but not of VC-2s ? > > 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, 20 Nov 2001 23:30:43 -0800 Message-ID: From: neil.2.harrison@bt.com To: betts01@nortelnetworks.com, daloia@lucent.com, ccamp@ops.ietf.org Cc: tsg15q11@itu.int, t1x15@t1.org Subject: RE: Suppression of Downstream Alarms... Date: Wed, 21 Nov 2001 07:28:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Absolutely right Malcolm....and that's also why you will see the function FDI (Forward Defect Indicator) proposed for MPLS OAM also in the user-plane. This basic and important principle (ie suppression of downstream and client layer alarms) is well understood by operators and most manufacturers. I am glad to see that (in Jonathan's response to Carmine's mail) this principle is recognised and agreed with. regards, Neil > -----Original Message----- > From: Malcolm Betts [mailto:betts01@nortelnetworks.com] > Sent: 20 November 2001 21:04 > To: 'Carmine Daloia'; ccamp@ops.ietf.org > Cc: tsg15q11@itu.int; t1x15@t1.org > Subject: RE: Suppression of Downstream Alarms... > > > Carmine, I agree, the suppression of down stream alarms (AIS) > should be > provided by the transport equipment and should not rely on > the use of a > signalling protocol. Since as you indicated not all of the > network elements > on the links between the OXCs (e.g. Amplifiers) will have > access to the > signalling network. > > Malcolm Betts > > Advanced Network Technology > Nortel Networks > Phone: +1 613 763 7860 (ESN 393) > FAX: +1 613 763 6608 (ESN 393) > email: betts01@nortelnetworks.com > > > -----Original Message----- > From: Carmine Daloia [mailto:daloia@lucent.com] > Sent: Monday, 19 November, 2001 09:44 > To: ccamp@ops.ietf.org > Cc: tsg15q11@itu.int; t1x15@t1.org > Subject: LMP: Suppression of Downstream Alarms... > > > Hi all, > > As I read through Section 6 "Fault Management", one issue > that it seems > to be addressing is "Suppression of Downstream Alarms". > > In section 6.2, it states that "If data links fail between > two PXCs, the > power monitoring system in all of the downstream nodes may detect LOL > and indicate a failure. To avoid multiple alarms stemming > from the same > failure, LMP provides a failure notification through the > ChannelStatus > message...". > > I agree that the suppression of downstream alarms is an > important issue. > > If we look at standard networks (both SONET/SDH and OTN), this > capability is already provided by the overhead in SDH/SONET and G.709 > OTN. G.709 OTN handles suppression of alarms in both all-optical > networks as well as opaque networks. I don't think we need to > burden the > control plane with such functions when the transport plane > handles this > in standard networks. In fact the transport plane handles > suppression of > alarms on all equipment in the network (not just cross-connects). > > If we look at a pre-OTN ("non-standard") scenario consisting of > Cross-connects, Optical Line Systems, and Optical Amplifiers > supporting > a DWDM networked solution, we can analyze two scenarios. One > scenario is > an opaque network (e.g., the OLS supports 3R). In this scenario, the > downstream Cross-connects would not detect LOL upon faults occurring > upstream. The 3R points on the OLS Line Systems would insert > some type > of signal downstream. Therefore the mechanism described in > Section 6.2 > does not apply. Another scenario is an all-optical pre-OTN > network. Note > that other equipment besides Cross-connects (e.g., Optical > Amplifiers) > in an all-optical network may alarm due to upstream faults. > These alarms > also need to be suppressed. LMP seems to only address the > suppression of > downstream alarms on cross-connects without taking into consideration > the network that sits between the cross-connects. Is LMP also > expected > to have to be processed on Optical Amplifiers? This seems to be > undesirable, especially given all the various applications > that seem to > be included into the LMP protocol that would not have anything to do > with Optical Amplifieris. > > Any other views? > > Carmine > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 17:17:27 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Notify Message in GMPLS Date: Tue, 20 Nov 2001 18:09:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, There is a notify message defined for GMPLS in gmpls-rsvp-te -05.txt draft. The OIF's O-UNI has removed this message from the UNI specification. What about GMPLS ? Are the owners of this document thinking of removing it from here ? 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, 20 Nov 2001 17:07:40 -0800 Date: Tue, 20 Nov 2001 17:01:34 -0800 (PST) From: Kireeti Kompella Message-Id: <200111210101.RAA22544@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: CCAMP presentations Hi All, Those who are planning on talking at the upcoming CCAMP WG meeting: 1) Only those IDs that have been posted to the IETF will be considered. (If you posted a new ID (individual contribution version -00), please send an ID summary to idsummary@subip.ietf.org .) 2) ASSUME the audience HAS READ the ID. 3) If you are talking about your ID for the first time, please say BRIEFLY where your ID fits in, and what technical problems it solves. Focus primarily on issues raised on the mailing list. If you have spoken before, just give the deltas from the earlier version, and issues and resolutions. 4) No presentations, please. Please send your material ("presentations") to Vijay and myself before the meeting. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 16:33:06 -0800 Message-ID: From: Jonathan Lang To: 'Carmine Daloia' , ccamp@ops.ietf.org Cc: tsg15q11@itu.int, t1x15@t1.org Subject: RE: Suppression of Downstream Alarms... Date: Tue, 20 Nov 2001 16:23:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Carmine, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Carmine Daloia [mailto:daloia@lucent.com] > Sent: Monday, November 19, 2001 6:44 AM > To: ccamp@ops.ietf.org > Cc: tsg15q11@itu.int; t1x15@t1.org > Subject: LMP: Suppression of Downstream Alarms... > > > Hi all, > > As I read through Section 6 "Fault Management", one issue that it seems > to be addressing is "Suppression of Downstream Alarms". > > In section 6.2, it states that "If data links fail between two PXCs, the > power monitoring system in all of the downstream nodes may detect LOL > and indicate a failure. To avoid multiple alarms stemming from the same > failure, LMP provides a failure notification through the ChannelStatus > message...". > > I agree that the suppression of downstream alarms is an important issue. great! > > If we look at standard networks (both SONET/SDH and OTN), this > capability is already provided by the overhead in SDH/SONET and G.709 > OTN. G.709 OTN handles suppression of alarms in both all-optical > networks as well as opaque networks. I don't think we need to burden the > control plane with such functions when the transport plane handles this > in standard networks. In fact the transport plane handles suppression of > alarms on all equipment in the network (not just cross-connects). > > If we look at a pre-OTN ("non-standard") scenario consisting of > Cross-connects, Optical Line Systems, and Optical Amplifiers supporting > a DWDM networked solution, we can analyze two scenarios. One scenario is > an opaque network (e.g., the OLS supports 3R). In this scenario, the > downstream Cross-connects would not detect LOL upon faults occurring > upstream. The 3R points on the OLS Line Systems would insert some type > of signal downstream. Therefore the mechanism described in Section 6.2 > does not apply. Another scenario is an all-optical pre-OTN network. Note > that other equipment besides Cross-connects (e.g., Optical Amplifiers) > in an all-optical network may alarm due to upstream faults. These alarms > also need to be suppressed. LMP seems to only address the suppression of > downstream alarms on cross-connects without taking into consideration > the network that sits between the cross-connects. Is LMP also expected > to have to be processed on Optical Amplifiers? This seems to be > undesirable, especially given all the various applications that seem to > be included into the LMP protocol that would not have anything to do > with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLI Requirements document (http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and corresponding LMP-WDM protocol document (new version to be uploaded tomorrow, but old version can be found at http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). > > Any other views? > > Carmine > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 16:03:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <710197BD5AF9D4119E4400508BCFA136014F4169@zcard04u.ca.nortel.com> From: "Malcolm Betts" To: "'Carmine Daloia'" , ccamp@ops.ietf.org Cc: tsg15q11@itu.int, t1x15@t1.org Subject: RE: Suppression of Downstream Alarms... Date: Tue, 20 Nov 2001 16:03:59 -0500 Carmine, I agree, the suppression of down stream alarms (AIS) should be provided by the transport equipment and should not rely on the use of a signalling protocol. Since as you indicated not all of the network elements on the links between the OXCs (e.g. Amplifiers) will have access to the signalling network. Malcolm Betts Advanced Network Technology Nortel Networks Phone: +1 613 763 7860 (ESN 393) FAX: +1 613 763 6608 (ESN 393) email: betts01@nortelnetworks.com -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Monday, 19 November, 2001 09:44 To: ccamp@ops.ietf.org Cc: tsg15q11@itu.int; t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Hi all, As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message...". I agree that the suppression of downstream alarms is an important issue. If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstream. The 3R points on the OLS Line Systems would insert some type of signal downstream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. Any other views? Carmine Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 15:14:36 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: SDH Concatenation Date: Tue, 20 Nov 2001 16:10:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, Is it possible that a SDH equipment support the contiguous concatenation of VC-4s but not of VC-2s ? 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, 20 Nov 2001 11:29:28 -0800 Message-Id: <4.3.2.7.2.20011120135612.018c1018@funnel.cisco.com> Date: Tue, 20 Nov 2001 14:21:58 -0500 To: ccamp@ops.ietf.org From: Baktha Muralidharan Subject: Comments on LMP Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22429171==_.ALT" --=====================_22429171==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hello, Please find attached my comments; Beside the few I list=20 immediately below, I have embedded most of my comments in the document, to make it easier= =20 to read. My comments are prefixed BM> Thanks, /Baktha ----------------------------------------------------------------------------= ------------------- 1. Remove all references to TLVs. We have changed over to Objects. 2. Draft requires that link summary be sent periodically until an ack/nack= =20 or timeout. Whenever a link summary is sent, the expected outcomes are either a=20 timeout or an ack/nack, isn't it? It is not clear then as to whether we recommend that the "periodic=20 transmission of link summary" to be stopped upon a timeout. If that is not what we=20 are recommending, i.e. we are recommending sending of link summary regardless of=20 whether we get a response or not, the above statement is unnecessary and I believe is actually= =20 confusing. 3. [Parameter] Negotiability is described in terms of objects. Some objects= =20 have subobjects and/or several attributes. Negotiability at these "lower=20 granularities" need to be spelt out. For example, consider the DATA LINK object; it is negotiable. And so,=20 are its subobjects. The data link sub-object carry interface switching capability,=20 bandwidth and encoding type. Can we interpret then that ALL of these are negotiable parameters?. If= =20 they are, spelling them out would help. 4. Under TE Link FSM, evDCDown is interpreted as "Last data channel of TE=20 Link has been removed Under data bearing link evDCDown is described as "data link is no=20 longer available". Administratively shutting down a data bearing link could fit the "no=20 longer available" description. Yet, the data bearing link could well be a member of a TE= =20 Link (i.e. might not have been removed). Suggest using the same description. Please see rest of the comments to be embedded; look for lines starting=20 with BM> =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 Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Network Working Group Jonathan P. Lang (Calient Networks) Internet Draft Krishna Mitra (Calient Networks) Expiration Date: May 2002 John Drake (Calient Networks) Kireeti Kompella (Juniper Networks) Yakov Rekhter (Juniper Networks) Lou Berger (Movaz Networks) Debanjan Saha (Tellium) Debashis Basak (Accelight Networks) Hal Sandick (Nortel Networks) Alex Zinin (Nexsi Systems) Bala Rajagopalan (Tellium) November 2001 Link Management Protocol (LMP) draft-ietf-ccamp-lmp-02.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 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data-bearing channels, correlate the link property information, and manage link failures. A unique feature of the fault management technique is that it is able to localize failures in both opaque and transparent networks, independent of the encoding scheme used for the data. Lang et al [Page 1] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Table of Contents 1 Introduction ................................................ 3 2 LMP Overview ................................................ 4 3 Control Channel Management ................................... 6 3.1 Parameter Negotiation ................................... 7 3.2 Hello Protocol .......................................... 8 3.2.1 Hello Parameter Negotiation ...................... 8 3.2.2 Fast Keep-alive .................................. 9 3.2.3 Control Channel Down ............................. 10 3.2.4 Degraded (DEG) State ............................. 10 4 Link Property Correlation ................................... 10 5 Verifying Link Connectivity ................................. 12 5.1 Example of Link Connectivity Verification ............... 14 6 Fault Management ............................................ 15 6.1 Fault Detection ......................................... 15 6.2 Fault Localization Procedure ............................ 15 6.3 Examples of Fault Localization .......................... 16 6.4 Channel Activation Indication ........................... 17 6.5 Channel Deactivation Indication ......................... 18 7 Message_Id Usage ............................................ 18 8 Graceful Restart ............................................ 19 9 Addressing .................................................. 20 10 LMP Authentication .......................................... 20 11 IANA Considerations ......................................... 21 12 LMP Finite State Machine .................................... 22 12.1 Control Channel FSM .................................... 22 12.1.1 Control Channel States .......................... 22 12.1.2 Control Channel Events .......................... 22 12.1.3 Control Channel FSM Description ................. 25 12.2 TE Link FSM ............................................ 26 12.2.1 TE link States .................................. 26 12.2.2 TE link Events .................................. 26 12.2.3 TE link FSM Description ......................... 27 12.3 Data Link FSM .......................................... 27 12.3.1 Data Link States ................................ 28 12.3.2 Data Link Events ................................ 28 12.3.3 Active Data Link FSM Description ................ 30 12.3.4 Passive Data Link FSM Description ............... 31 13 LMP Message Formats ......................................... 32 13.1 Common Header .......................................... 32 13.2 LMP Object Format ...................................... 34 13.3Authentication .......................................... 34 13.4 Parameter Negotiation .................................. 37 13.5 Hello .................................................. 38 13.6 Link Verification ...................................... 39 13.7 Link Summary ........................................... 42 13.8 Fault Management ....................................... 43 14 LMP Object Definitions ...................................... 45 15 Security Conderations ....................................... 63 16 References .................................................. 64 17 Acknowledgments ............................................. 65 18 Authors' Addresses ......................................... 65 Lang et al [Page 2] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Changes from previous version: o Added IANI Considerations section. BM> Should be IANA o Added clarifying text to the MessageId section. o Added clarifying text to the ChannelStatus section for fault localization. o Added Data Link Subobject to DATA_LINK object. 1. Introduction Future networks will consist of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM systems, and add-drop multiplexors (ADMs) that use a common control plane [e.g., Generalized MPLS (GMPLS)] to dynamically allocate resources and to provide network survivability using protection and restoration techniques. A pair of nodes (e.g., two PXCs) may be connected by thousands of fibers, and each fiber may be used to transmit multiple wavelengths if DWDM is used. Furthermore, multiple fibers and/or multiple wavelengths may be combined into a single traffic- engineering (TE) link for routing purposes. To enable communication between nodes for routing, signaling, and link management, control channels must be established between the node pair; however, the interface over which the control messages are sent/received may not be the same interface over which the data flows. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. In this draft, the naming convention of [LAMBDA] is followed, and OXC is used to refer to all categories of optical crossconnects, irrespective of the internal switching fabric. Furthermore, a distinction is made between crossconnects that require opto- electronic conversion, called digital crossconnects (DXCs), and those that are all-optical, called photonic switches or photonic crossconnects (PXCs) - referred to as pure crossconnects in [LAMBDA], because the transparent nature of PXCs introduces new restrictions for monitoring and managing the data links. LMP can be used for any type of node, enhancing the functionality of traditional DXCs and routers, while enabling PXCs and DWDMs to intelligently interoperate in heterogeneous optical networks. In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network. A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data links is that the health of a control channel does not necessarily correlate to the health of the data links, and vice-versa. Therefore, a clean separation between the fate of the control channel and data-bearing links must be made. New mechanisms must be developed to manage the data-bearing links, both in terms of link provisioning and fault management. Lang et al [Page 3] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 For the purposes of this document, a data-bearing link may be either a "port" or a "component link" depending on its multiplexing capability; component links are multiplex capable, whereas ports are not multiplex capable. This distinction is important since the management of such links (including, for example, resource allocation, label assignment, and their physical verification) is different based on their multiplexing capability. For example, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams. If multiple interfaces are grouped together into a single TE link using link bundling [BUNDLE], then the link resources must be identified using three levels: TE link Id, component interface Id, and timeslot label. Resource allocation happens at the lowest level (timeslots), but physical connectivity happens at the component link level. As another example, consider the case where a PXC transparently switches OC-192 lightpaths. If multiple interfaces are once again grouped together into a single TE link, then link bundling [BUNDLE] is not required and only two levels of identification are required: TE link Id and port Id. In this case, both resource allocation and physical connectivity happen at the lowest level (i.e. port level). BM> It looks like a TE Link is a "group of interfaces", regardless BM> of whether they are bundled. BM> Why "group" multiple interfaces (into a TE Link), if bundling BM> and the associated benefits are the not the objective? To ensure interworking between data links with different multiplexing capabilities, LMP capable devices SHOULD allow sub- channels of a component link to be locally configured as (logical) data links. For example, if a Router with 4 OC-48 interfaces is connected through a 4:1 MUX to an OXC with OC-192c interfaces, the OXC SHOULD be able to configure each OC-48 sub-channel as a data link. 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). BM> BM> An example of "unbundled aggregation of data links into a BM> TE Link" would greatly help to clear up BM> 2. LMP Overview The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify configuration. LMP requires that a pair of nodes have at least one active bi- directional control channel between them. The two directions of the BM> Aren't control channels always bidirectional?. The successful BM> config message exchange always marks the "bidirectional BM> control channel establishment", isn't it? BM> Suggest removing the word bidirectional from references to IPCC. control channel are coupled together using the LMP Config message exchange. All LMP messages are IP encoded [except in some cases, the Test Message which may be limited by the transport mechanism for in-band messaging]. The link level encoding of the control channel is outside the scope of this document. Lang et al [Page 4] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 An =93LMP adjacency=94 is formed between two nodes when at least one bi- directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged by the adjacent nodes over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes. BM> This (the concept of logical control channel) applies to an=20 implementation's BM> treatment of multiple control channels and should be removed to avoid=20 confusion. BM> Logical control channels are not discussed elsewhere in the document. The link property correlation function of LMP is designed to aggregate multiple data links (ports or component 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 glinks that comprise the TE BM> links 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. LMP messages are transmitted reliably 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. For control channel specific messages, the Message Id is within the scope of the control channel over which is the message is sent. For TE link specific messages, the Message Id is within the scope of the LMP adjacency. This value of the Message Id is incremented and only decreases when the value wraps. In this draft, two additional LMP procedures are defined: link connectivity verification and fault management. These procedures are particularly useful when the control channels are physically diverse from the data-bearing links. Link connectivity verification is used to verify the physical connectivity of the data-bearing links between the nodes and exchange the Interface Ids; Interface Ids are used in GMPLS signaling, either as Port labels or Component Interface Ids, depending on the configuration. The link verification procedure uses in-band Test messages that are sent over the data-bearing links and TestStatus messages that are transmitted back over the control channel. Note that the Test message is the only LMP message that must be transmitted over the data-bearing link. The fault management scheme uses ChannelStatus message exchanges between adjacent nodes to localize failures in both opaque and transparent networks, independent of the encoding scheme used for the data. As a result, both local span and end-to-end path protection/restoration procedures can be initiated. Lang et al [Page 5] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 For the LMP link connectivity verification procedure, the free (unallocated) data-bearing links MUST be opaque (i.e., able to be terminated); however, once a data link is allocated, it may become transparent. The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various degrees of transparency (e.g., examining overhead bytes, terminating the payload, etc.), and hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data-bearing links must be terminated simultaneously, but at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST terminate on the same two nodes that the TE link spans. Since the BeginVerify BM> This is true for ALL LMP procedures, not just for connectivity BM> verification. i.e. CC, by definition, is between a pair of neighbors. message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links between opaque and transparent mode. 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 channels of a TE link. The ChannelStatusAck message is used to acknowledge 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. Upon receipt of the ChannelStatusRequest message, a node MUST send a ChannelStatusResponse message indicating the states of the queried data links. The organization of the remainder of this document is as follows. In Section 3, the role of the control channel and the messages used to establish and maintain link connectivity is discussed. 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 will be used to isolate link and channel failures within the optical network. Several finite state machines (FSMs) are given in Section 8, and the message formats are defined in Section 9. 3. Control Channel Management To initiate an LMP adjacency between two nodes, one or more bi- directional control channels MUST be activated. The control channels can be used to exchange control-plane information such as link provisioning and fault management information (implemented using a messaging protocol such as LMP, proposed in this draft), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP [CR- LDP]), and network topology and state distribution information Lang et al [Page 6] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 (implemented using traffic engineering extensions of protocols such as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). For the purposes of LMP, the exact implementation of the control channel is not specified; it could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, or the overhead bytes of a data-bearing link. Rather, a node-wide unique 32-bit non-zero integer control channel identifier (CCId) is assigned at each end of the control channel. This identifier comes from the same space as the unnumbered interface Id. Furthermore, LMP is run directly over IP. Thus, the link level encoding of the control channel is not part of the LMP specification. The control channel can be either explicitly configured or automatically selected, however, for the purpose of this document the control channel is assumed to be explicitly configured. Note that for in-band signaling, a control channel could be explicitly configured on a particular data-bearing link. Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. As such, control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH). There are four LMP messages that are used to manage individual control channels. They are the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel to which they refer. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes. In order to maintain an LMP adjacency, it is necessary to have at least one active control channel between a pair of adjacent nodes (recall that multiple control channels can be active simultaneously between a pair of nodes). In the event of a control channel failure, alternate active control channels can be used and it may be possible to activate additional control channels as mentioned below. 3.1. Parameter Negotiation Control channel activation begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N bit in the Lang et al [Page 7] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 object header). Negotiable objects can be used to let LMP peers agree on certain values. Non-negotiable objects are used for the announcement of specific values that do not need, or do not allow, negotiation. To begin control channel activation, a node MUST transmit a Config message to the remote node. The Config message contains the Control Channel ID (CCID), the sender=92s Node ID, a MessageId for reliable messaging, and a CONFIG Object. It is possible that both the local and remote nodes initiate the configuration procedure at the same time. To avoid ambiguities, the node with the higher Node Id wins the contention; the node with the lower Node Id MUST stop transmitting the Config message and respond to the Config message it received. The ConfigAck message is used to acknowledge receipt of the Config message and express agreement on ALL of the configured parameters (both negotiable and non-negotiable). The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable CONFIG objects are unacceptable, and propose alternate values for the negotiable parameters. If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters. If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages. Note that the problem may be solved by an operator changing parameters. In the case where multiple control channels use the same physical interface, the parameter negotiation exchange is performed for each control channel. The various LMP parameter negotiation messages are associated with their corresponding control channels by their node- wide unique identifiers (CCIds). 3.2. Hello Protocol Once a control channel is activated between two adjacent nodes, the LMP Hello protocol can be used to maintain control channel connectivity between the nodes and to detect control channel failures. The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link- state adjacencies are not removed unnecessarily. 3.2.1. Hello Parameter Negotiation Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will Lang et al [Page 8] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 be sent, and is measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has both sent and received a Hello message, the control channel moves to the UP state. (It is also possible to move to the UP state without sending Hellos if other methods are used to indicate bi-directional control-channel connectivity.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages and the control channel SHOULD NOT move to the UP state. See Section 8.1 for the complete control channel FSM. 3.2.2. Fast Keep-alive Each Hello message contains two sequence numbers: the first sequence number (TxSeqNum) is the sequence number for the Hello message being sent and the second sequence number (RcvSeqNum) is the sequence number of the last Hello message received over this control channel from the adjacent node. Each node increments its sequence number when it sees its current sequence number reflected in Hellos received from its peer. The sequence numbers start at 1 and wrap around back to 2; 0 is used in the RcvSeqNum to indicate that a Hello has not yet been seen. Under normal operation, the difference between the RcvSeqNum in a Hello message that is received and the local TxSeqNum that is generated will be at most 1. This difference can be more than one only when a control channel restarts or when the values wrap. Note that the 32-bit sequence numbers MAY wrap. The following expression may be used to test if a newly received TxSeqNum value is less than a previously received value: If ((int) old_id =96 (int) new_id > 0) { New value is less than old value; } Having sequence numbers in the Hello messages allows each node to verify that its peer is receiving its Hello messages. By including the RcvSeqNum in Hello packets, the local node will know which Hello packets the remote node has received. Lang et al [Page 9] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The following example illustrates how the sequence numbers operate. Note that only the operation at one node is shown: 1) After completing the configuration stage, Node A sends Hello messages to Node B with {TxSeqNum=3D1;RcvSeqNum=3D0}. 2) When Node A receives a Hello from Node B with {TxSeqNum=3D1;RcvSeqNum=3D1}, it sends Hellos to Node B with {TxSeqNum=3D2;RcvSeqNum=3D1}. 3) When Node A receives a Hello from Node B with {TxSeqNum=3D2;RcvSeqNum=3D2}, it sends Hellos to Node B with {TxSeqNum=3D3;RcvSeqNum=3D2}. 3.2.3. Control Channel Down To allow bringing a control channel DOWN gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links. When bringing a control channel DOWN administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set. When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the Down state. BM> On the receiving node, suggest transitioning to CONFSND state rather BM> than DOWN state.. otherwise, it could not automatically get into BM> config procedure- i.e. would need a trigger/event BM> On the sending side, the trigger is the operator command to bring up BM> the control channel 3.2.4. Degraded State A consequence of allowing the control channels to be physically diverse from the associated data links is that there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down a link that is carrying user traffic simply because the control channel is no longer available; however, the traffic that is using the data links may no longer be guaranteed the same level of service. Hence the TE link is in a Degraded state. When a TE link is in the Degraded state, routing and signaling SHOULD be notified so that new connections are not accepted and the TE link is advertised with no unreserved resources. 4. Link Property Correlation As part of LMP, a link property correlation exchange is defined using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which Lang et al [Page 10] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 can be either negotiable or non-negotiable (identified by the N flag in the TLV 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. Link property correlation MUST be done before the link is brought up and MAY be done at any time a link is UP and not in the Verification process. The LinkSummary message is used to verify for consistency the TE and data bearing link information on both sides. Link Summary messages are also used to aggregate multiple data links (either ports or component links) into a TE link; exchange, correlate (to determine inconsistencies), or change TE link parameters; and exchange, correlate (to determine inconsistencies), or change Interface Ids (either Port Ids or Component Interface Ids). Each TE link has an identifier (Link_Id) that is assigned at each end of the link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. Similarly, each interface is assigned an identifier (Interface_Id) at each end. These identifiers MUST be the same type at both ends. BM> Why the restriction that both ends of a TE Link have to use the same BM> identification? 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). 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. 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 an allocated data link has a mapping mismatch, it SHOULD be flagged and verified when it becomes free. 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 MUST 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. It is possible that the LinkSummary message could grow quite large due to the number of Data Link TLVs. Since the LinkSummary message is IP encoded, normal IP fragmentation should be used if the resulting PDU exceeds the MTU. Lang et al [Page 11] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 5. Verifying 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 when establishing a TE link, and subsequently, on a periodic basis for all unallocated (free) data links of the TE link. If the link connectivity procedure is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code =3D1, =93Link Verification Procedure not supported for this TE Link=94. A unique characteristic of all-optical PXCs is that the data-bearing links are transparent when allocated to user traffic. This characteristic of PXCs poses a challenge for validating the connectivity of the data links since shining unmodulated light through a link may not result in received light at the next PXC. This is because there may be terminating (or opaque) elements, such as DWDM equipment, between the PXCs. Therefore, to ensure proper verification of data link connectivity, it is required that until the links are allocated for user traffic, they must be opaque. To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), and hence different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages. There is no requirement that all data links be terminated simultaneously, but at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for DXCs (and OEO devices in general) since each data link is terminated and processed electronically before being forwarded to the next OEO device, but that in PXCs (and transparent devices in general) this is an additional requirement. To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link. Once a control channel has been established between the two nodes, data link connectivity can be verified by exchanging Test messages over each of the data links specified in the TE link. It should be noted that all LMP messages except the Test message are exchanged over the control channels and that Hello messages continue to be exchanged over each control channel during the data link verification process. The Test message is sent over the data link that is being verified. Data links are tested in the transmit direction as they are unidirectional, and therefore, it may be Lang et al [Page 12] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 possible for both nodes to (independently) exchange the Test messages simultaneously. To initiate the link verification procedure, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the LINK_ID MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. The BeginVerify message also contains the number of data links that are to be verified; the interval (called VerifyInterval) at which the Test messages will be sent; the encoding scheme and transport mechanisms that are supported; the data rate for Test messages; and, when the data links correspond to fibers, the wavelength identifier over which the Test messages will be transmitted. 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 specifying the desired transport mechanism for the TEST messages. The remote node includes a 32-bit node unique VerifyId in the BeginVerifyAck message. The VerifyId is then used in all corresponding verification messages to differentiate them from different LMP peers and/or parallel Test procedures. When the local node receives a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the VerifyId and the local Interface Id for the associated 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 without receiving a TestStatusSuccess or TestStatusFailure message by sending an EndVerify message. Message correlation is done using message identifiers and the Verify Id; this enables verification of data links, belonging to different link bundles or LMP sessions, in parallel. When the Test message is received, the received Interface Id (used in GMPLS as either a Port/Wavelength label or Component Interface Identifier depending on the configuration) 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), along with the VerifyId received in the Test message. The receipt of a TestStatusSuccess message indicates that the Test message was detected at the remote node and the physical connectivity of the data link has been verified. When the TestStatusSuccess message is received, the local node SHOULD mark Lang et al [Page 13] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the data link as UP and send a TestStatusAck message to the remote node. If, however, the Test message 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 channel 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 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 SHOULD 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 1 shows an example of the link verification scenario that is executed when a link between PXC A and PXC B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows: PXC A sends a BeginVerify message over the control channel =93c=94 to PXC B indicating it will begin verifying the ports. PXC B receives the BeginVerify message, assigns a VerifyId to the Test procedure, and returns the BeginVerifyAck message over the control channel to PXC A. When PXC A receives the BeginVerifyAck message, it begins transmitting periodic Test messages over the first port (Interface Id=3D1). When PXC B receives the Test messages, it maps the received Interface Id to its own local Interface Id =3D 10 and transmits a TestStatusSuccess message over the control channel back to PXC A. The TestStatusSuccess message includes both the local and received Interface Ids for the port as well as the VerifyId. PXC A will send a TestStatusAck message over the control channel back to PXC B indicating it received the TestStatusSuccess message. The process is repeated until all of the ports are verified. At this point, PXC A will send an EndVerify message over the control channel to PXC B to indicate that testing is complete; PXC B will respond by sending an EndVerifyAck message over the control channel back to PXC A. +---------------------+ +---------------------+ + + + + + PXC A +<-------- c --------->+ PXC B + + + + + + + + + + 1 +--------------------->+ 10 + Lang et al [Page 14] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 + + + + + + + + + 2 + /---->+ 11 + + + /----/ + + + + /---/ + + + 3 +----/ + 12 + + + + + + + + + + 4 +--------------------->+ 14 + + + + + +---------------------+ +---------------------+ Figure 1: Example of link connectivity between PXC A and PXC B. 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 channels 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 LSPs. An important implication of using PXCs is that traditional methods that are used to monitor the health of allocated data links in OEO nodes (e.g., DXCs) may no longer be appropriate, since PXCs are transparent to the bit-rate, format, and wavelength. Instead, fault detection is delegated to the physical layer (i.e., loss of light or optical monitoring of the data) instead of layer 2 or layer 3. Recall that a TE link connecting two nodes may consist of a number of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification so that appropriate protection/restoration mechanisms can be initiated. If the failure is subsequently cleared, then a mechanism must be used to notify that the failure is clear and the channel status is OK. 6.1. Fault Detection Fault detection should be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is detecting loss of light (LOL). Other techniques for monitoring optical signals are still being developed and will not be further considered in this document. However, it should be clear that the mechanism used for fault notification in LMP is independent of the mechanism used to detect the failure, but simply relies on the fact that a failure is detected. 6.2. Fault Localization Procedure Lang et al [Page 15] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message. This message may be used to indicate that a single data channel has failed, multiple data channels have failed, or an entire TE link has failed. Failure correlation is done locally at each node upon receipt of the failure notification. As part of the fault localization, 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 (including ingress side) for the corresponding LSP(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. Once the failure is correlated, the upstream node SHOULD send a ChannelStatus message to the downstream node indicating that the channel is failed or is ok. If a ChannelStatus message is not received by the downstream node, it SHOULD send a ChannelStatusRequest message for the channel in question. Once the failure has been localized, the 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 Fig. 2, a sample network is shown where four PXCs are connected in a linear array configuration. The control channels are bi- directional and are labeled with a "c". All LSPs are also bi- directional. In the first example [see Fig. 2(a)], there is a failure on one direction of the bi-directional LSP. PXC 4 will detect the failure and will send a ChannelStatus message to PXC3 indicating the failure (e.g., LOL) to the corresponding upstream node. When PXC3 receives the ChannelStatus message from PXC4, it returns a ChannelStatusAck message back to PXC4 and correlates the failure locally. When PXC3 correlates the failure and verifies that it is CLEAR, it has localized the failure to the data link between PXC3 and PXC4. Lang et al [Page 16] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 In the second example [see Fig. 2(b)], a single failure (e.g., fiber cut) affects both directions of the bi-directional LSP. PXC2 (PXC3) will detect the failure of the upstream (downstream) direction and send a ChannelStatus message to the upstream (in terms of data flow) node indicating the failure (e.g., LOL). Simultaneously (ignoring propagation delays), PXC1 (PXC4) will detect the failure on the upstream (downstream) direction, and will send a ChannelStatus message to the corresponding upstream (in terms of data flow) node indicating the failure. PXC2 and PXC3 will have localized the two directions of the failure. +-------+ +-------+ +-------+ +-------+ + PXC 1 + + PXC 2 + + PXC 3 + + PXC 4 + + +-- c ---+ +-- c ---+ +-- c ---+ + ----+---\ + + + + + + + <---+---\\--+--------+-------+---\ + + + /--+---> + \--+--------+-------+---\\---+-------+---##---+---//--+---- + + + + \---+-------+--------+---/ + + + + + + + (a) + + ----+-------+--------+---\ + + + + + <---+-------+--------+---\\--+---##---+--\ + + + + + + \--+---##---+--\\ + + + + + + + (b) + \\--+--------+-------+---> + + + + + \--+--------+-------+---- + + + + + + + + +-------+ +-------+ +-------+ +-------+ Figure 2: Two types of data link failures are shown (indicated by ## in the figure): (A) a data link corresponding to the downstream direction of a bi-directional LSP fails, (B) two data links corresponding to both directions of a bi-directional LSP fail. The control channel connecting two PXCs is indicated with a "c". 6.4. Channel 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 Channel Activation Indication. This is particularly useful in networks with transparent nodes where the status of data links may need to be triggered using control channel messages. For example, if a data link is pre-provisioned and the physical link fails after verification and before inserting user traffic, a mechanism is needed to indicate the data link should be active or they may not be able to detect the failure. The ChannelStatus message is used to indicate that a channel or group of channels are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message. When a ChannelStatus message is received, the corresponding data link(s) MUST be put into the Active state. If upon putting them into the Lang et al [Page 17] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Active state, a failure is detected, the ChannelStatus message MUST be transmitted as described in Section 6.2. 6.5. Channel Deactivation Indication The ChannelStatus message may also be used to notify an LMP neighbor that the data link no longer needs to be monitored. This is the counterpart to the Channel Active Indication. When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state. 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. For control channel specific messages, the Message_Id field is within the scope of the CCID. For TE link specific messages, the Message_Id field is within the scope of the LMP adjacency. The Message_Id field of the MESSAGE_ID object contains a generator selected value. This value MUST be greater than any other value previously used. A value is considered to be previously used when it has been sent in an LMP message with the same CCID (for control channel specific messages) or LMP adjacency (for TE Link specific messages). 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. Note that the 32-bit Message_Id value MAY wrap. The following expression may be used to test if a newly received Message_Id value is less than a previously received value: If ((int) old_id =96 (int) new_id > 0) { New value is less than old value; } 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 is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the Lang et al [Page 18] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 sender for the CCID, then the message SHOULD be treated as being out of order. If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out of order. BM> Isn't this logic true for link verification as well? If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel. All other messages MUST NOT be treated as out-of-order. 8. Graceful Restart This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after an LMP adjacency has failed, or as a result of an LMP component restart. The latter is detected by setting the =93Control Plane Restart=94 bit in the Common BM> Isn't the bit called LMP Restart? Header of the LMP messages. When the control plane fails due to the loss of the control channel (rather than an LMP component restart), the LMP Link information should be retained. It is possible that a node may be capable of retaining the LMP Link information across an LMP component restart. However, in both cases the status of the data channels MUST be synchronized. We assume the Local Interface Ids remain stable across a control plane restart. After the control plane of a node restarts, the control channel(s) must be re-established using the procedures of Section 3.1. If the control plane failure was the result of an LMP component restart, then the =93Control Plane Restart=94 flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is UP and the LMP neighbor has detected the restart. Once a control channel is UP, the LMP neighbor 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 Lang et al [Page 19] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 indicating that the parameters are non-negotiable. This provides the local/remote Link Id and Interace Id mappings, the associated Link/Data channel parameters, and indication of which data links are currently allocated to user traffic. When a node receives the LinkSummary message, it checks its local configuration. If the node is capable of retaining the LMP Link information across a restart, it must process the LinkSummary message 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 node was not capable of retaining the LMP Link information across a restart, the node MUST accept the Link/Data channel parameters of the received LinkSummary message and respond with a LinkSummaryAck message. Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels. 9. Addressing All LMP messages are sent directly over IP (except, in some cases, the Test messages are limited by the transport mechanism for in-band messaging). The destination address of the IP packet MUST be the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the received Config message). The manner in which a Config message is addressed may depend on the signaling transport mechanism. When the transport mechanism is a point-to-point link, Config messages SHOULD be sent to the Multicast address (224.0.0.1). Otherwise, Config messages MUST be sent to an IP address on the neighboring node. This is configured at both ends of the control channel. 10. LMP Authentication LMP authentication is optional (included in the Common Header) and, if used, MUST be supported by both sides of the control channel. 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 Lang et al [Page 20] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the data portion depend on the authentication type. Currently, only MD5 is supported for LMP. 11. IANA Considerations LMP defines the following name spaces which require management: - Message Type Name Space. - Class and class type name spaces for LMP objects. The following sections provide guidelines for managing these name spaces. 11.1. Message Type Name Space LMP divides the name space for message types into two ranges. The following are the guidelines for managing these ranges: - Message Types 0 - 49 and 60 - 255: These message types are part of the LMP base protocol. Following the policies outlined in [IANA], message types in this range are allocated through an IETF Consensus action. - Message Types 50 - 59: Message types in this range are reserved for UNI LMP extensions and the allocation in this range is the responsibility of the OIF for supporting UNI signaling. IANA management of this range of the Message Type name space is unnecessary. 11.2. Object Class Name Space LMP divides the name space for object classes into two ranges. The following are the guidelines for managing these ranges: - Classes 0 - 49 and 60 - 127: Object types in this range are part of the LMP base protocol. Following the policies outlined in [IANA], class types in this range are allocated through an IETF Consensus action. Within each class, 256 class types are possible. The allocation of class types for base LMP objects are described in this draft and these are subject to IETF consensus action. - Classes 50 - 59 are reserved for UNI LMP extensions and the allocation in this range is the responsibility of the OIF for supporting UNI signaling. IANA management of this range of the class name space, and the underlying class types, is unnecessary. Lang et al [Page 21] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12. LMP Finite State Machines 12.1. Control Channel FSM The control channel FSM defines the states and logics of operation of an LMP control channel. The description of FSM state transitions and associated actions is given in Section 3. 12.1.1. Control Channel States A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end. Down: This is the initial control channel state. In this state, no attempt is being made to bring the control channel up and no LMP messages are sent. The control channel parameters should be set to the initial values. ConfigSnd: The control channel is in the parameter negotiation state. In this state the node periodically sends a Config message, and is expecting the other side to reply with either a ConfigAck or ConfigNack message. The FSM does not transition into the Active state until the remote side positively acknowledges the parameters. ConfRcv: The control channel is in the parameter negotiation state. In this state, the node is waiting for acceptable configuration parameters from the remote side. Once such parameters are received and acknowledged, the FSM can transition to the Active state. Active: In this state the node periodically sends a Hello message and is waiting to receive a valid Hello message. Once a valid Hello message is received, it can transition to the UP state. Up: The CC is in an operational state. The node receives valid Hello messages and sends Hello messages. GoingDown: A CC may go into this state because of administrative action. While a CC is in this state, the node sets the ControlChannelDown bit in all the messages it sends. 12.1.2. Control Channel Events Operation of the LMP control channel is described in terms of FSM states and events. Control channel Events are generated by the underlying protocols and software modules, as well as by the packet processing routines and FSMs of associated TE links. Every event Lang et al [Page 22] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 has its number and a symbolic name. Description of possible control channel events is given below. 1 : evBringUp: This is an externally triggered event indicating that the control channel negotiation should begin. This event, for example, may be triggered by an operator command, by the successful completion of a control channel bootstrap procedure, or by configuration. Depending on the configuration, this will trigger either 1a) the sending of a Config message, 1b) a period of waiting to receive a Config message from the remote node. 2 : evCCDn: This event is generated when there is indication that the control channel is no longer available. 3 : evConfDone: This event indicates a ConfigAck message has been received, acknowledging the Config parameters. 4 : evConfErr: This event indicates a ConfigNack message has been received, rejecting the Config parameters. 5 : evNewConfOK: New Config message was received from neighbor and positively Acknowledged. 6 : evNewConfErr: New Config message was received from neighbor and rejected with a ConfigNack message. 7 : evContenWin: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The Local node wins the contention. As a result, the received Config message is ignored. 8 : evContenLost: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The Local node loses the contention. 8a) The Config message is positively Acknowledged. 8b) The Config message is negatively Acknowledged. 9 : evAdminDown: The administrator has requested that the control channel is brought down administratively. Hello messages (with ControlChannelDown flag set) SHOULD be sent for HelloDeadInterval seconds or until an LMP message is received over the control channel with the ControlChannelDown flag set. 10: evNbrGoesDn: A packet with ControlChannelDown flag is received from the neighbor. Lang et al [Page 23] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 11: evHelloRcvd: A Hello packet with expected SeqNum has been received. 12: evHoldTimer: The HelloDeadInterval timer has expired indicating that no Hello packet has been received. This moves the control channel back into the Negotiation state, and depending on the local configuration, this will trigger either 12a) the sending of periodic Config messages, 12b) a period of waiting to receive Config messages from the remote node. 13: evSeqNumErr: A Hello with unexpected SeqNum received and discarded. 14: evReconfig: Control channel parameters have been reconfigured and require renegotiation. 15: evConfRet: A retransmission timer has expired and a Config message is resent. 16: evHelloRet: The HelloInterval timer has expired and a Hello packet is sent. 17: evDownTimer: A timer has expired and no messages have been received with the ControlChannelDown flag set. Lang et al [Page 24] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.1.3. Control Channel FSM Description Figure 3 illustrates operation of the control channel FSM in a form of FSM state transition diagram. +--------+ +----------------->| |<--------------+ | +--------->| Down |<----------+ | | |+---------| |<-------+ | | | || +--------+ | | | | || | ^ 2,9,10| 2| 2| | ||1b 1a| | | | | | || v | 2,9,10 | | | | || +--------+ | | | | || +->| |<------+| | | | || 4,7,| |ConfSnd | || | | | || 14,15+--| |<----+ || | | | || +--------+ | || | | | || 3,8a| | | || | | | || +---------+ |8b 14,12a| || | | | || | v | || | | | |+-|------>+--------+ | || | | | | | +->| |-----|-|+ | | | | |6,14| |ConfRcv | | | | | | | | +--| |<--+ | | | | | | | +--------+ | | | | | | | | 5| ^ | | | | | | | +---------+ | | | | | | | | | | | | | | | | | | | v v |6,12b | | | | | | |10 +--------+ | | | | | | +----------| | | | | | | | | +--| Active |---|-+ | | | 10,17| | 5,16| | |-------|---+ | +-------+ 9 | 13 +->| | | | | | Going |<--|----------+--------+ | | | | Down | | 11| ^ | | | +-------+ | | |5 | | | ^ | v | 6,12b| | | |9 |10 +--------+ | |12a,14 | | +----------| |---+ | | | | Up |-------+ | +------------------| |---------------+ +--------+ | ^ | | +---+ 11,13,16 Figure 3: Control Channel FSM Lang et al [Page 25] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Event evCCDn always forces the FSM to the Down State. Events evHoldTimer evReconfig always force the FSM to the Negotiation state (either ConfigSnd or ConfigRcv). 12.2. TE Link FSM The TE Link FSM defines the states and logics of operation of an LMP TE Link. 12.2.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 and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links. 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. BM> I guess we are saying that once initially synchronized, subsequent= changes BM> to TE Links that cause link summary to run could happen whilst the TE= Link BM> is still in UP state. BM> In the middle of the day, is the IDs and/or other properties BM> of links are changed such that a TE Links go out of synchronization, BM> should we go back to "Init" state?, such that the above definition of BM> Init state is observed all the time? Up: This is the normal operational state of the TE link. At least one primary CC is required to be operational between the nodes sharing the TE link. Degraded: In this state, all primary CCs are down, but the TE link still includes some allocated data links. BM> Does the term "allocated" here refer to "allocated to data traffic"? BM> I don't think so.. but could we be explicit? BM> Related question. Whilst in Init state, if the last CC goes down, BM> Shouldn't the TE Link go into degraded? 12.2.2. TE Link Events Operation of the LMP TE link is described in terms of FSM states and events. TE Link events are generated by the packet processing routines and by the FSMs of the associated primary control channel(s) and the data links. Every event has its number and a symbolic name. Description of possible control channel events is given below. 1 : evDCUp: One or more data channels have been enabled and assigned to the TE Link. 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 : evCCUp: First active control channel goes up. 8 : evCCDown: Last active control channel goes down. Lang et al [Page 26] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 9 : evDCDown: Last data channel of TE Link has been removed. 12.2.3. TE Link FSM Description Figure 4 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram. 3,7,8 +--+ | | | v +--------+ | | +------------>| Down |<---------+ | | | | | +--------+ | | | ^ | | 1| |9 | | v | | | +--------+ | | | |<-+ | | | Init | |3,5,6 |9 | | |--+ 7,8 | 9| +--------+ | | | | | 2,4| | | v | +--------+ 7 +--------+ | | |------>| |----------+ | Deg | | Up | | |<------| | +--------+ 8 +--------+ | ^ | | +--+ 2,3,4,5,6 Figure 4: LMP TE Link FSM In the above FSM, the sub-states that may be implemented when the link verification procedure is used have been omitted. BM> Consider a TE Link that transitions to Down state via Degraded.. it BM> has no data links and no CCs either. If now a DC is added to the TE BM> Link, shouldn't it go [back] to degraded state, rather than Init. BM> When a TE Link in the Down state gets a new data link, it fits BM> the definition of the degraded state. 12.3. Data Link FSM The data link FSM defines the states and logics of operation of a port or component link within an LMP TE link. Operation of a data link is described in terms of FSM states and events. Data-bearing links can either be in the active (transmitting) mode, where Test messages are transmitted from them, or the passive (receiving) mode, where Test messages are received through them. For clarity, Lang et al [Page 27] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 separate FSMs are defined for the active/passive data-bearing links; however, a single set of data link states and events are defined. 12.3.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 link is not =91in service=92 Test: The data link is being tested. An LMP Test message is periodically sent through the link. PasvTest: The data link is being checked for incoming test messages. Up/Free: The 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. Degraded: The link was in the Up/Allocated state when the last CC associated with data link's TE Link has gone down. The link is put in the Degraded state, since it is still being used for data LSP. 12.3.2. Data Link Events Data bearing link events are generated by the packet processing routines and by the FSMs of the associated control channel and the TE link. Every event has its number and a symbolic name. Description of possible data link events is given below: 1 :evCCUp: CC has gone up. 2 :evCCDown: LMP neighbor connectivity is lost. This indicates the last LMP control channel has failed between neighboring nodes. 3 :evStartTst: This is an external event that triggers the sending of Test messages over the data bearing link. 4 :evStartPsv: This is an external event that triggers the listening for Test messages over the data bearing link. 5 :evTestOK: Link verification was successful and the link can be used for path establishment. (a) This event indicates the Link Verification procedure (see Section 5) was successful for this data link and a TestStatusSuccess Lang et al [Page 28] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 message was received over the control channel. (b) This event indicates the link is ready for path establishment, but the Link Verification procedure was not used. For in-band signaling of the control channel, the control channel establishment may be sufficient to verify the link. 6 :evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel. 7 :evTestFail: Link verification returned negative results. This could be because (a) a TestStatusFailure message was received, or (b) an EndVerifyAck message was received 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) an EndVerify messages has been received 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 message 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:evdcDown: The data channel is no longer available. Lang et al [Page 29] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.3.3. Active Data Link FSM Description Figure 5 illustrates operation of the LMP active data link FSM in a form of FSM state transition diagram. +------+ +------------->| |<-------+ | +--------->| Down | | | | +----| |<-----+ | | | | +------+ | | | | |5b 3| ^ | | | | | | |2,7 | | | | | v | | | | | | +------+ | | | | | | |<-+ | | | | | | Test | |11 | | | | | | |--+ | | | | | +------+ | | | | | 5a| 3^ | | | | | | | | | | | | v | | | | |2,12 | +---------+ | | | | +-->| |14 | | | | | Up/Free |----+ | | +---------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ 2 +---------+ | | |<--------| |13 | | Deg | |Up/Alloc |------+ | |-------->| | +-----+ 1 +---------+ Figure 5: Active LMP Data Link FSM Lang et al [Page 30] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 12.3.4. Passive Data Link FSM Description Figure 6 illustrates operation of the LMP passive data link FSM in a form of FSM state transition diagram. +------+ +------------->| |<------+ | +---------->| Down | | | | +-----| |<----+ | | | | +------+ | | | | |5b 4| ^ | | | | | | |2,8 | | | | | v | | | | | | +----------+ | | | | | | PasvTest | | | | | | +----------+ | | | | | 6| 4^ | | | | | | | | | | | | v | | | | |2,12 | +---------+ | | | | +--->| Up/Free |14 | | | | | |---+ | | +----------| | | | +---------+ | | 9| ^ | | | | | |10 v |10 | +-----+ +---------+ | | | 2 | |13 | | Deg |<--------|Up/Alloc |-----+ | |-------->| | +-----+ 1 +---------+ Figure 6: Passive LMP Data Link FSM Lang et al [Page 31] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 13. LMP Message Formats All LMP messages are IP encoded (except, in some cases, the Test messages are limited by the transport mechanism for in-band messaging) with protocol number xxx - TBA (to be assigned) by IANA. 13.1. Common Header In addition to the standard IP header, all LMP messages (except, in some cases, the Test messages which are limited by the transport mechanism for in-band messaging) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMP Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 4 bits Protocol version number. This is version 1. Flags: 8 bits. The following values are defined. All other values are reserved. 0x01: ControlChannelDown 0x02: LMP Restart This bit is set to indicate the LMP component has restarted. This flag may be reset to 0 when a Hello message is received with RcvSeqNum equal to the local TxSeqNum. 0x04: LMP-WDM Support When set, indicates that this node is willing and capable of receiving all the messages and objects described in [LMP-DWDM]. 0x08: Authentication When set, this bit indicates that an authentication block is attached at the end of the LMP message. See Sections 7 and 9.3 for more details. Msg Type: 8 bits. The following values are defined. All other values are reserved. 1 =3D Config Lang et al [Page 32] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 2 =3D ConfigAck 3 =3D ConfigNack 4 =3D Hello 5 =3D BeginVerify 6 =3D BeginVerifyAck 7 =3D BeginVerifyNack 8 =3D EndVerify 9 =3D EndVerifyAck 10 =3D Test 11 =3D TestStatusSuccess 12 =3D TestStatusFailure 13 =3D TestStatusAck 14 =3D LinkSummary 15 =3D LinkSummaryAck 16 =3D LinkSummaryNack 17 =3D ChannelStatus 18 =3D ChannelStatusAck 19 =3D ChannelStatusRequest 20 =3D ChannelStatusResponse All of the messages are sent over the control channel EXCEPT the Test message, which is sent over the data link that is being tested. LMP Length: 16 bits The total length of this LMP message in bytes, including the common header and any variable-length objects that follow. Checksum: 16 bits The standard IP checksum of the entire contents of the LMP message, starting with the LMP message header. This checksum is Lang et al [Page 33] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before calculating the checksum. BM> One thing that will be of great help for implementation is a "message BM> specific" field (perhaps a couple of them). An example use of such a= field BM> could be to store the number of data link objects in a link summary BM> and link summary ack message. 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 TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (TLV Object) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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. Length: 16 bits The Length field indicates the length of the Object in bytes. 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 Lang et al [Page 34] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 the LMP packet, but is transmitted in the same IP 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 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. Lang et al [Page 35] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 LMP authentication is performed on a per control channel basis. The 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 a control channel 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 on a control channel that is configured for authentication, it must be authenticated. The value of the Authentication field MUST match the authentication type configured for the control channel (if any). 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. Lang et al [Page 36] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 (1) Locate the receiving control channel's configured key having Key ID equal to that specified in the received LMP authentication block. If the key is not found, 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 control channel data structure, 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 control channel's data structure is set to the sequence number found in the packet's LMP header. 13.4. Parameter Negotiation Messages BM> Suggest changing to "Hello parameter negotiation messages". 13.4.1. Config Message (MsgType =3D 1) The Config message is used in the control channel negotiation phase of LMP. The contents of the Config message are built using LMP objects. The format of the Config message is as follows: ::=3D The above transmission order SHOULD be followed. BM> If order is to be followed for ALL messages, include it in one BM> place at beginning of section 13 The MESSAGE_ID is within the scope of the CCID. The Config message MUST be periodically transmitted until (1) it receives a ConfigAck or ConfigNack message, (2) a timeout expires and no ConfigAck or ConfigNack message has been received, or (3) it receives a Config message from the remote node and has lost the contention (e.g., the Node Id of the remote node is higher than the Node Id of the local node). Both the retransmission interval and the timeout period are local configuration parameters. 13.4.2. ConfigAck Message (MsgType =3D 2) The ConfigAck message is used to acknowledge receipt of the Config message and indicate agreement on all parameters. Lang et al [Page 37] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::=3D The above transmission order SHOULD be followed. The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged. 13.4.3. ConfigNack Message (MsgType =3D 3) The ConfigNack message is used to acknowledge receipt of the Config message and indicate disagreement on non-negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Message. The format of the ConfigNack message is as follows: ::=3D [] The above transmission order SHOULD be followed. The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged. The ConfigNack uses CONFIG_ERROR_ C-Type 1. It is possible that multiple parameters may be invalid in the Config message. As such, multiple bits may be set in the ERROR_CODE. If a negotiable CONFIG object is included in the ConfigNack message, it MUST include acceptable values for the parameters. The ERROR_CODE MUST indicate =93Renegotiate CONFIG parameter.=94 If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message. The ERROR_CODE MUST indicate =93Unacceptable non- negotiable CONFIG parameter.=94 If the ConfigNack message is received and only includes CONFIG objects that are negotiable, then a new Config message SHOULD be sent. The values in the CONFIG object of the new Config message SHOULD take into account the acceptable values included in the ConfigNack message. 13.5. Hello Message (MsgType =3D 4) The format of the Hello message is as follows: Lang et al [Page 38] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::=3D BM> ^^^^^^ Should be in=20 upper case The above transmission order SHOULD be followed. The Hello message MUST be periodically transmitted at least once every HelloInterval msec. If no Hello message is received within the HelloDeadInterval, the control channel is assumed to have failed. 13.6. Link Verification 13.6.1. BeginVerify Message (MsgType =3D 5) The BeginVerify message is sent over the control channel 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 SHOULD be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. The REMOTE_LINK_ID may be included if the local/remote Link Id mapping is known. The REMOTE_LINK_ID MUST be non-zero if included. 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.6.2. BeginVerifyAck Message (MsgType =3D 6) When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted. ::=3D [] The above transmission order SHOULD be followed. Lang et al [Page 39] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The LOCAL_LINK_ID may be included if the local/remote Link Id mapping is known or learned through the BeginVerify message. The LOCAL_LINK_ID MUST be non-zero if included. 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.6.3. BeginVerifyNack Message (MsgType =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 =93Link Verification Procedure not supported=94. If Verification is supported, but the node unable to begin the procedure, the ERROR_CODE MUST indicate =93Unwilling to verify=94. 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 =93Unsupported verification transport mechanism=94. If remote configuration of the TE Link Id is not supported and the REMOTE_LINK_ID object (included in the BeginVerify message) does not match any configured values, the ERROR_CODE MUST indicate =93TE Link Id configuration error=94. The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. 13.6.4. EndVerify Message (MsgType =3D 8) Lang et al [Page 40] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The EndVerify message is sent over the control channel and is used to terminate the link verification process. The EndVerify message may 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.6.5. EndVerifyAck Message (MsgType =3D9) The EndVerifyAck message is sent over the control channel 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.6.6. Test Message (MsgType =3D 10) The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated in the Verify Transport Mechanism description for the BEGIN_VERIFY class, this is transmitted as an IP packet with payload format as follows: ::=3D The above transmission order SHOULD be followed. Note that this message is sent over a data link and NOT over the control channel. The transport mechanism for the Test message is negotiated using Verify Transport Mechanism field of the BeginVerify Object and the Verify Transport Response field of the BeginVerifyAck Object (see Sections 14.9 and 14.10). The local (transmitting) node sends a given Test message periodically (at least once every VerifyInterval ms) on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node or (2) all active control channels between the two nodes have failed. The remote node will send a given TestStatus message periodically over the control Lang et al [Page 41] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 channel until it receives either a correlating TestStatusAck message or an EndVerify message is received over the control channel. 13.6.7. TestStatusSuccess Message (MsgType =3D 11) The TestStatusSuccess message is transmitted over the control channel 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 message being positively acknowledged. 13.6.8. TestStatusFailure Message (MsgType =3D 12) The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received. ::=3D The above transmission order SHOULD be followed. 13.6.9. TestStatusAck Message (MsgType =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.7. Link Summary Messages 13.7.1. LinkSummary Message (MsgType =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: Lang et al [Page 42] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 ::=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.7.2. LinkSummaryAck Message (MsgType =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.7.3. LinkSummaryNack Message (MsgType =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 [...] The above transmission order SHOULD be followed. The LinkSummary TLVs MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes LinkSummary TLVs for non-negotiable parameters, they MUST be copied from the LinkSummary TLVs 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. BM> It looks like sending a linksummarynack that includes both= non-negotiable BM> parameters as well as negotiable parameters is kind of useless.. BM> because the initiator will not resend a link summary in that case. Yes? The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3. 13.8. Fault Management Messages 13.8.1. ChannelStatus Message (MsgType =3D 17) Lang et al [Page 43] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The ChannelStatus message is sent over the control channel 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.8.2. ChannelStatusAck Message (MsgType =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.8.3. ChannelStatusRequest Message (MsgType =3D 19) The ChannelStatusRequest message is sent over the control channel 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: ::=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.8.4. ChannelStatusResponse Message (MsgType =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 channel(s). The format is as follows: ::=3D Lang et al [Page 44] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged. 14. LMP Object Definitions 14.1. CCID (Control Channel ID) Classes 14.1.1. LOCAL_CCID Class Class =3D 1. o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC_Id: 32 bits This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message. This Object is non-negotiable. BM> Suggestion: Why not reserve C-Type =3D 2 for OIF- OIF OUNI 125.7 allows BM> CCID to be either numbered (IPv4) or unnumbered. 14.1.2. REMOTE_CCID Class Class =3D 2. o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CC_Id: 32 bits This identifies the remote node=92s CC_Id and MUST be non-zero. This Object is non-negotiable. 14.2. NODE_ID Classes 14.2.1. LOCAL_NODE_ID Class Class =3D 3. Lang et al [Page 45] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identities the node that originated the LMP packet. This Object is non-negotiable. 14.2.2. REMOTE _NODE_ID Class Class =3D 4. o 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identities the remote node. This Object is non-negotiable. 14.3. LINK _ID Classes 14.3.1. LOCAL_LINK_ID Class Class =3D 5 o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 46] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 | | + + | | + Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Reserved for OIF, C-Type =3D 4 Link_Id: This identifies the sender=92s Link associated with the message. This Object is non-negotiable. 14.3.2. REMOTE _LINK_ID Class Class =3D 6 o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 47] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o Unnumbered, C-Type =3D 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Reserved for OIF, C-Type =3D 4 Link_Id: This identifies the remote node=92s Link Id and MUST be non-zero. This Object is non-negotiable. 14.4. INTERFACE_ID Classes 14.4.1. LOCAL_INTERFACE_ID Class Class =3D 7 o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 48] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Interface_Id: This identifies the data link (either port or component link). The Interface_Id MUST be node-wide unique and non-zero. This Object is non-negotiable. 14.4.2. REMOTE _INTERFACE_ID Class Class =3D 8. o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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=92s data link (either port or component link). The Interface Id MUST be non-zero. This Object is non-negotiable. 14.5. MESSAGE_ID Class Class =3D 9. Lang et al [Page 49] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.6. MESSAGE_ID_ACK Class Class =3D 10. o 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.7. CONFIG Class Class =3D 11. o HelloConfig, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | HelloDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloInterval: 16 bits. Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms). Lang et al [Page 50] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 HelloDeadInterval: 16 bits. If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero. BM> Given that the only parameters negotiated by Hello COnfig are BM> these two parameters, if fast keep-alive mechanism is not used, BM> why bother with Hello Config protocol? Why then say Hello Config BM> is mandatory? 14.8. HELLO Class Class =3D 12 o Type 1 Hello, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RcvSeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TxSeqNum: 32 bits This is the current sequence number for this Hello message. This sequence number will be incremented when the sequence number is reflected in the RcvSeqNum of a Hello packet that is received over the control channel. TxSeqNum=3D0 is not allowed. TxSeqNum=3D1 is reserved to indicate that the control channel has booted or restarted. RcvSeqNum: 32 bits This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=3D0 is reserved to indicate that a Hello message has not yet been received. This Object is non-negotiable. 14.9. BEGIN_VERIFY Class Class =3D 13. o C-Type =3D 1 Lang et al [Page 51] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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 | VerifyInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Data Links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EncType | (Reserved) | Verify Transport Mechanism | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 16 bits The following flags are defined: 0x01 Verify all Links If this bit is set, the verification process checks all unallocated links; else it only verifies new ports or component links that are to be added to this TE link. 0x02 Data Link Type If set, the data links to be verified are ports, otherwise they are component links VerifyInterval: 16 bits This is the interval between successive Test messages and is measured in milliseconds (ms). Number of Data Links: 32 bits This is the number of data links that will be verified. EncType: 8 bits This is the encoding type of the data link. The defined EncType values are consistent with the Link Encoding Type values of [GMPLSSIG] Verify Transport Mechanism: 16 bits This defines the transport mechanism for the Test Messages. The scope of this bit mask is restricted to each link encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting LMP test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message. For SONET/SDH Encoding Type, the following flags are defined: Lang et al [Page 52] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 0x01 J0-16: Capable of transmitting Test messages using J0 overhead bytes with string length of 16 bytes (with CRC-7). Note that Due to the byte limitation, a special Test message is defined as follows: The Test message is a 15-byte message, where the last 7 bits of each byte are usable. Due to the byte limitation, the LMP Header is not included. The first usable 32 bits MUST be the VerifyId that was received in the VERIFY_ID Object of the BeginVerifyAck message. The second usable 32 bits MUST be the Interface_Id. The next usable 8 bits are used to determine the address type of the Interface_Id. For IPv4, this value is 1. For unnumbered, this value is 3. The remaining bits are Reserved. Note that this Test Message format is only valid when the Interface_Id is either IPv4 or unnumbered. 0x02 DCCS: Capable of transmitting Test messages using the DCC Section Overhead bytes with an HDLC framing format. 0x04 DCCL: Capable of transmitting Test messges using the DCC Line Overhead bytes with an HDLC framing format. 0x08 Payload: Capable of transmitting Test messages in the payload using Packet over SONET framing using the encoding type specified in the EncType field. For GigE Encoding Type, the following flags are defined: TBD For 10GigE Encoding Type, the following flags are defined: TBD BitRate: 32 bits This is the bit rate of the data link over which the Test messages will be transmitted and is expressed in bytes per second. Wavelength: 32 bits When a data link is assigned to a port or component link that is capable of transmitting multiple wavelengths (e.g., a fiber or waveband-capable port), it is essential to know which wavelength the test messages will be transmitted over. This value corresponds to the wavelength at which the Test messages will be transmitted over and has local significance. If there is no ambiguity as to the wavelength over which the message will be sent, then this value SHOULD be set to 0. 14.10. BEGIN_VERIFY_ACK Class Class =3D 14. Lang et al [Page 53] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o 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 | Verify_Transport_Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Verify_Transport_Response: 16 bits The recipient of the BeginVerify message (and the future recipient of the TEST messages) chooses the transport mechanism from the various types that are offered by the transmitter of the Test messages. One and only one bit MUST be set in the verification transport response. This Object is non-negotiable. 14.11. VERIFY_ID Class Class =3D 15. o 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.12. TE_LINK Class Class =3D 16. o IPv4, C-Type =3D 1 0 1 2 3 Lang et al [Page 54] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Link_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined. All other values are reserved. 0x01 Fault Management Supported. 0x02 Link Verification Supported. Lang et al [Page 55] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 Local_Link_Id: This identifies the node=92s local Link Id and MUST be non-zero. Remote_Link_Id: This identifies the remote node=92s Link Id and MUST be non-zero. 14.13. DATA_LINK Class Class =3D 17. o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Local_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Remote_Interface_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lang et al [Page 56] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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. 0x01 Interface Type: If set, the data link is a port, otherwise it is a component link. 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. Local_Interface_Id: 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 consist of a series of variable-length data items called subobjects. The subobjects are defined in section 14.13.1 below. Lang et al [Page 57] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 A DATA_LINK object may contain more than one subobject. If more than one subobject of the same Type appears, only the first subobject of that Type is meaningful. Subsequent subobjects of the same Type MAY be ignored. 14.13.1. Data Link Subobjects 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. Currently defined values are: 1 Interface Switching Capability 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.13.1.1. Subobject 1: Interface Switching Capability +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Switching Cap | EncType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Switching Capability: 8 bits This is used to identify the local Interface Switching Capability of the TE link. See [LSP-HIER]. EncType: 8 bits This is the encoding type of the data link. The defined EncType values are consistent with the Link Encoding Type values of [GMPLSSIG]. Minimum Reservable Bandwidth: 32 bits Lang et al [Page 58] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 This is measured in bytes per second and represented in IEEE floating point format. Maximum Reservable Bandwidth: 32 bits This is measured in bytes per second and represented in IEEE floating point format. If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value. 14.14. CHANNEL_STATUS Class Class =3D 18 o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | Lang et al [Page 59] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Unnumbered, C-Type =3D 3 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 Channel is allocated to user traffic and the data link should be actively monitored. Channel_Status: 32 bits This indicates the status condition of a data channel. The following values are defined. All other values are reserved. 1 Signal Okay (OK): Channel 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. Lang et al [Page 60] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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.15. CHANNEL_STATUS_REQUEST Class Class =3D 19 o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Object contains one or more Interface Ids. The Length of this object is 4 + 4N in bytes, where N is the number of Interface Ids. o 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interface Id (16 bytes) + | | + + | | Lang et al [Page 61] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Object contains one or more Interface Ids. The Length of this object is 4 + 16N in bytes, where N is the number of Interface Ids. o Unnumbered, C-Type =3D 3 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 4 + 4N in bytes, where N is the number of Interface Ids. This Object is non-negotiable. 14.16. ERROR_CODE Class Class =3D 20. o CONFIG_ERROR, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 =3D Unacceptable non-negotiable CONFIG parameter 0x02 =3D Renegotiate CONFIG parameter 0x04 =3D Bad Received CCID All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. BM> How about adding a bit for "Ill-formed message" to cover BM> such cases as object-order-violations? BM> THese could be under a special C-Type, say, PROTOCOL_ERROR Lang et al [Page 62] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 o BEGIN_VERIFY_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 Link Verification Procedure not supported for this TE Link. 0x02 =3D Unwilling to verify at this time 0x04 =3D Unsupported verification transport mechanism 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. o LINK_SUMMARY_ERROR, C-Type =3D 3 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 All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. 15. Security Considerations LMP exchanges may be authenticated using the Cryptographic authentication option. MD5 is currently the only message digest algorithm specified. Lang et al [Page 63] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 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., =93Link Bundling in MPLS Traffic Engineering,=94 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-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, =93Link Management Protocol (LMP) for WDM Transmission Systems,=94 Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in progress), March 2001. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992. [GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, =93Generalized MPLS - Signaling Functional Description,=94 Internet Draft, draft-ietf-mpls-generalized-signaling-06.txt, (work in progress), October 2001. [LSP-HIER] Kompella, K. and Rekhter, Y., =93LSP Hierarchy with MPLS TE,=94 Internet Draft, draft-ietf-mpls-lsp-hierarchy- 02.txt, (work in progress), February 2001. Lang et al [Page 64] Internet Draft draft-ietf-ccamp-lmp-02.txt November 2001 17. Acknowledgments The authors would like to thank Ayan Banerjee, George Swallow, Andre Fredette, Adrian Farrel, and Vinay Ravuri for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability. 18. Author's Addresses Jonathan P. Lang Krishna Mitra Calient Networks Calient Networks 25 Castilian Drive 5853 Rue Ferrari Goleta, CA 93117 San Jose, CA 95138 Email: jplang@calient.net email: krishna@calient.net John Drake Kireeti Kompella Calient Networks Juniper Networks, Inc. 5853 Rue Ferrari 385 Ravendale Drive San Jose, CA 95138 Mountain View, CA 94043 email: jdrake@calient.net email: kireeti@juniper.net Yakov Rekhter Lou Berger Juniper Networks, Inc. Movaz Networks 385 Ravendale Drive email: lberger@movaz.com Mountain View, CA 94043 email: yakov@juniper.net Debanjan Saha Debashis Basak Tellium Optical Systems Accelight Networks 2 Crescent Place 70 Abele Road, Suite 1201 Oceanport, NJ 07757-0901 Bridgeville, PA 15017-3470 email:dsaha@tellium.com email: dbasak@accelight.com Hal Sandick Alex Zinin Nortel Networks Nexsi Systems email: hsandick@nortelnetworks.com 1959 Concourse Drive San Jose, CA 95131 email: azinin@nexsi.com Bala Rajagopalan Tellium Optical Systems 2 Crescent Place Oceanport, NJ 07757-0901 email: braja@tellium.com Lang et al [Page 65] --=====================_22429171==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,
         Please find attached my comments; Beside the few I list immediately below, I
      have embedded most of my comments in the document, to make it easier to read.

         My comments are prefixed BM>

Thanks,
/Baktha

----------------------------------------------------------------------------= -------------------
1. Remove all references to TLVs. We have changed over to Objects.

2. Draft requires that link summary be sent periodically until an ack/nack or timeout.

     Whenever a link summary is sent, the expected outcomes are either a timeout or an
     ack/nack, isn't it?
     It is not clear then as to whether we recommend that the "periodic transmission of
     link summary" to be stopped upon a timeout. If that is not what we are recommending,
     i.e. we are recommending sending of link summary regardless of whether we get a response
     or not, the above statement is unnecessary and I believe is actually confusing.

3. [Parameter] Negotiability is described in terms of objects. Some objects have subobjects
    and/or several attributes. Negotiability at these "lower granularities" need to be spelt out.

   For example, consider the DATA LINK object; it is negotiable. And so, are its subobjects.
   The data link sub-object carry interface switching capability, bandwidth and encoding type.
   Can we interpret then that ALL of these are negotiable parameters?. If they are, spelling
   them out would help.

4. Under TE Link FSM, evDCDown is interpreted as "Last data channel of TE Link has been removed
   Under data bearing link evDCDown is described as "data link is no longer available".
   Administratively shutting down a data bearing link could fit the "no longer available"
   description. Yet, the data bearing link could well be a member of a TE Link (i.e. might not
   have been removed). Suggest using the same=20 description.


Please see rest of the comments to be embedded; look for lines starting with BM>
=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

Internet Draft       draft-ietf-ccamp-lmp-02.txt        November 2001

Network Working Group            = ;   Jonathan P. Lang (Calient Networks)
Internet Draft            = ;             Krishna Mitra (Calient Networks)
Expiration Date: May 2002            =      John Drake (Calient Networks)
            &nbs= p;            &n= bsp;          Kireeti Kompella (Juniper Networks)
            &nbs= p;            &n= bsp;             Yakov Rekhter (Juniper Networks)
            &nbs= p;            &n= bsp;            =       Lou Berger (Movaz Networks)
            &nbs= p;            &n= bsp;            =           Debanjan Saha (Tellium)
            &nbs= p;            &n= bsp;          Debashis Basak (Accelight Networks)
            &nbs= p;            &n= bsp;            =     Hal Sandick (Nortel Networks)
            &nbs= p;            &n= bsp;            =        Alex Zinin (Nexsi Systems)
            &nbs= p;            &n= bsp;            =        Bala Rajagopalan (Tellium)
            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;       
            &nbs= p;            &n= bsp;            =             &nbs= p;       November 2001
            &nbs= p;        Link Management Protocol (LMP)
   
            &nbs= p;         draft-ietf-ccamp-lmp-02.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=20
   ht= tp://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
   
   Future networks will consist of photonic switches, optical
   crossconnects, and routers that may be configured with control=
   channels and data links.  Furthermore, multiple data links= may be
   combined to form a single traffic engineering (TE) link for= routing
   purposes. This draft specifies a link management protocol (LMP)= that
   runs between neighboring nodes and is used to manage TE= links. 
   Specifically, LMP will be used to maintain control channel
   connectivity, verify the physical connectivity of the= data-bearing
   channels, correlate the link property information, and manage= link
   failures.  A unique feature of the fault management= technique is
   that it is able to localize failures in both opaque and= transparent
   networks, independent of the encoding scheme used for the data.=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 1]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

Table of Contents
   1  Introduction= ................................................   3
   2  LMP Overview= ................................................   4
   3 Control Channel Management= ...................................   6
      3.1 Parameter Negotiation= ...................................   7
      3.2 Hello Protocol= ..........................................   8
          3.2.1  Hello= Parameter Negotiation ......................   8
          3.2.2  Fast= Keep-alive ..................................   9
          3.2.3  Control= Channel Down .............................  10
          3.2.4  Degraded= (DEG) State .............................  10
   4  Link Property Correlation= ...................................  10
   5  Verifying Link Connectivity= .................................  12
      5.1 Example of Link Connectivity Verification= ...............  14
   6  Fault Management= ............................................  15
      6.1 Fault Detection= .........................................  15
      6.2 Fault Localization Procedure= ............................  15
      6.3 Examples of Fault Localization= ..........................  16
      6.4 Channel Activation Indication= ...........................  17
      6.5 Channel Deactivation Indication= .........................  18
   7  Message_Id Usage= ............................................  18
   8  Graceful Restart= ............................................  19
   9  Addressing= ..................................................  20
   10 LMP Authentication= ..........................................  20
   11 IANA Considerations= .........................................  21
   12 LMP Finite State Machine= ....................................  22
      12.1 Control Channel FSM= ....................................  22
          12.1.1  Control= Channel States ..........................  22
          12.1.2  Control= Channel Events ..........................  22
          12.1.3  Control= Channel FSM Description .................  25
      12.2 TE Link FSM= ............................................  26
          12.2.1  TE link= States ..................................  26
          12.2.2  TE link= Events ..................................  26
          12.2.3  TE link= FSM Description .........................  27
      12.3 Data Link FSM= ..........................................  27
          12.3.1  Data= Link States ................................  28
          12.3.2  Data= Link Events ................................  28
          12.3.3  Active= Data Link FSM Description ................  30
          12.3.4  Passive= Data Link FSM Description ...............  31
   13 LMP Message Formats= .........................................  32
      13.1 Common Header= ..........................................  32
      13.2 LMP Object Format= ......................................  34
      13.3Authentication= ..........................................  34
      13.4 Parameter Negotiation= ..................................  37
      13.5 Hello= ..................................................  38
      13.6 Link Verification= ......................................  39
      13.7 Link Summary= ...........................................  42
      13.8 Fault Management= .......................................  43
   14 LMP Object Definitions= ......................................  45
   15 Security Conderations= .......................................  63
   16 References= ..................................................  64
   17 Acknowledgments= .............................................  65
   18 Authors' Addresses = .........................................  65
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 2]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   Changes from previous version:
   
   o  Added IANI Considerations section.

BM> Should be IANA

   o  Added clarifying text to the MessageId section.
   o  Added clarifying text to the ChannelStatus section for= fault
      localization.
   o  Added Data Link Subobject to DATA_LINK object.
   
1. Introduction
   
   Future networks will consist of photonic switches (PXCs),= optical
   crossconnects (OXCs), routers, switches, DWDM systems, and= add-drop
   multiplexors (ADMs) that use a common control plane [e.g.,
   Generalized MPLS (GMPLS)] to dynamically allocate resources and= to
   provide network survivability using protection and restoration=
   techniques.  A pair of nodes (e.g., two PXCs) may be= connected by
   thousands of fibers, and each fiber may be used to transmit= multiple
   wavelengths if DWDM is used.  Furthermore, multiple fibers= and/or
   multiple wavelengths may be combined into a single traffic-
   engineering (TE) link for routing purposes.  To enable= communication
   between nodes for routing, signaling, and link management,= control
   channels must be established between the node pair; however,= the
   interface over which the control messages are sent/received may= not
   be the same interface over which the data flows.  This= draft
   specifies a link management protocol (LMP) that runs between=
   neighboring nodes and is used to manage TE links.
   
   In this draft, the naming convention of [LAMBDA] is followed,= and
   OXC is used to refer to all categories of optical= crossconnects,
   irrespective of the internal switching fabric. Furthermore, a=
   distinction is made between crossconnects that require= opto-
   electronic conversion, called digital crossconnects (DXCs), and=
   those that are all-optical, called photonic switches or= photonic
   crossconnects (PXCs) - referred to as pure crossconnects in=
   [LAMBDA], because the transparent nature of PXCs introduces new=
   restrictions for monitoring and managing the data links. = LMP can be
   used for any type of node, enhancing the functionality of
   traditional DXCs and routers, while enabling PXCs and DWDMs to=
   intelligently interoperate in heterogeneous optical networks.=
   
   In GMPLS, the control channels between two adjacent nodes are= no
   longer required to use the same physical medium as the= data-bearing
   links between those nodes. For example, a control channel could= use
   a separate wavelength or fiber, an Ethernet link, or an IP= tunnel
   through a separate management network.  A consequence of= allowing
   the control channel(s) between two nodes to be physically= diverse
   from the associated data links is that the health of a control=
   channel does not necessarily correlate to the health of the= data
   links, and vice-versa.  Therefore, a clean separation= between the
   fate of the control channel and data-bearing links must be= made. 
   New mechanisms must be developed to manage the data-bearing= links,
   both in terms of link provisioning and fault management.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 3]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   For the purposes of this document, a data-bearing link may be= either
   a "port" or a "component link" depending on= its multiplexing
   capability; component links are multiplex capable, whereas= ports are
   not multiplex capable.  This distinction is important= since the
   management of such links (including, for example, resource
   allocation, label assignment, and their physical verification)= is
   different based on their multiplexing capability.  For= example, a
   SONET crossconnect with OC-192 interfaces may be able to= demultiplex
   the OC-192 stream into four OC-48 streams.  If multiple= interfaces
   are grouped together into a single TE link using link bundling=
   [BUNDLE], then the link resources must be identified using= three
   levels: TE link Id, component interface Id, and timeslot= label. 
   Resource allocation happens at the lowest level (timeslots),= but
   physical connectivity happens at the component link= level.  As
   another example, consider the case where a PXC transparently=
   switches OC-192 lightpaths.  If multiple interfaces are= once again
   grouped together into a single TE link, then link bundling= [BUNDLE]
   is not required and only two levels of identification are= required: 
   TE link Id and port Id.  In this case, both resource= allocation and
   physical connectivity happen at the lowest level (i.e. port= level).

BM> It looks like a TE Link is a "group of interfaces",= regardless
BM> of whether they are bundled.
BM> Why "group" multiple interfaces (into a TE Link), if= bundling
BM> and the associated benefits are the not the objective?

   To ensure interworking between data links with different
   multiplexing capabilities, LMP capable devices SHOULD allow= sub-
   channels of a component link to be locally configured as= (logical)
   data links.  For example, if a Router with 4 OC-48= interfaces is
   connected through a 4:1 MUX to an OXC with OC-192c interfaces,= the
   OXC SHOULD be able to configure each OC-48 sub-channel as a= data
   link.
   
   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).

BM>
BM> An example of "unbundled aggregation of data links into a
BM> TE Link" would greatly help to clear up
BM>

2. LMP Overview
   
   The two core procedures of LMP are control channel management= and
   link property correlation.  Control channel management is= used to
   establish and maintain control channels between adjacent= nodes. 
   This is done using a Config message exchange and a fast= keep-alive
   mechanism between the nodes.  The latter is required if= lower-level
   mechanisms are not available to detect control channel= failures. 
   Link property correlation is used to synchronize the TE link=
   properties and verify configuration.
   
   LMP requires that a pair of nodes have at least one active= bi-
   directional control channel between them.  The two= directions of the

BM> Aren't control channels always bidirectional?. The successful
BM> config message exchange always marks the "bidirectional
BM> control channel establishment", isn't it?
BM> Suggest removing the word bidirectional from references to IPCC.

   control channel are coupled together using the LMP Config= message
   exchange.  All LMP messages are IP encoded [except in some= cases,
   the Test Message which may be limited by the transport= mechanism for
   in-band messaging].  The link level encoding of the= control channel
   is outside the scope of this document.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 4]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   An =93LMP adjacency=94 is formed between two nodes when at= least one bi-
   directional control channel is established between them. = Multiple
   control channels may be active simultaneously for each= adjacency;
   control channel parameters, however, MUST be individually= negotiated
   for each control channel.  If the LMP fast keep-alive is= used over a
   control channel, LMP Hello messages MUST be exchanged by the=
   adjacent nodes over the control channel.  Other LMP= messages MAY be
   transmitted over any of the active control channels between a= pair
   of adjacent nodes.  One or more active control channels= may be
   grouped into a logical control channel for signaling, routing,= and
   link property correlation purposes.
  
BM> This (the concept of logical control channel) applies to an= implementation's
BM> treatment of multiple control channels and should be removed to avoid= confusion.
BM> Logical control channels are not discussed elsewhere in the= document.

   The link property correlation function of LMP is designed to=
   aggregate multiple data links (ports or component 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 glinks that comprise the= TE
BM>           &nbs= p;            &n= bsp;            =    links

   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.
   
   LMP messages are transmitted reliably 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. 
   For control channel specific messages, the Message Id is within= the
   scope of the control channel over which is the message is sent.= For
   TE link specific messages, the Message Id is within the scope= of the
   LMP adjacency.  This value of the Message Id is= incremented and only
   decreases when the value wraps.
   
   In this draft, two additional LMP procedures are defined: link=
   connectivity verification and fault management.  These= procedures
   are particularly useful when the control channels are= physically
   diverse from the data-bearing links.   Link= connectivity
   verification is used to verify the physical connectivity of the=
   data-bearing links between the nodes and exchange the Interface= Ids;
   Interface Ids are used in GMPLS signaling, either as Port= labels or
   Component Interface Ids, depending on the configuration. = The link
   verification procedure uses in-band Test messages that are sent= over
   the data-bearing links and TestStatus messages that are= transmitted
   back over the control channel.  Note that the Test message= is the
   only LMP message that must be transmitted over the data-bearing=
   link.  The fault management scheme uses ChannelStatus= message
   exchanges between adjacent nodes to localize failures in both= opaque
   and transparent networks, independent of the encoding scheme= used
   for the data.  As a result, both local span and end-to-end= path
   protection/restoration procedures can be initiated.
   

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 5]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   For the LMP link connectivity verification procedure, the free=
   (unallocated) data-bearing links MUST be opaque (i.e., able to= be
   terminated); however, once a data link is allocated, it may= become
   transparent.  The LMP link connectivity verification= procedure is
   coordinated using a BeginVerify message exchange over a control=
   channel.  To support various degrees of transparency= (e.g.,
   examining overhead bytes, terminating the payload, etc.), and= hence,
   different mechanisms to transport the Test messages, a Verify=
   Transport Mechanism is included in the BeginVerify and
   BeginVerifyAck messages.  Note that there is no= requirement that all
   data-bearing links must be terminated simultaneously, but at a=
   minimum, it must be possible to terminate them one at a= time.  There
   is also no requirement that the control channel and TE link use= the
   same physical medium; however, the control channel MUST= terminate on
   the same two nodes that the TE link spans.  Since the= BeginVerify

BM> This is true for ALL LMP procedures, not just for connectivity
BM> verification. i.e. CC, by definition, is between a pair of= neighbors.

   message exchange coordinates the Test procedure, it also= naturally
   coordinates the transition of the data links between opaque and=
   transparent mode.
   
   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= channels
   of a TE link.  The ChannelStatusAck message is used to= acknowledge 
   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.  Upon receipt of the
   ChannelStatusRequest message, a node MUST send a
   ChannelStatusResponse message indicating the states of the= queried
   data links.
   
   The organization of the remainder of this document is as= follows. 
   In Section 3, the role of the control channel and the messages= used
   to establish and maintain link connectivity is discussed. = 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 will be used to isolate link and channel failures within= the
   optical network.  Several finite state machines (FSMs) are= given in
   Section 8, and the message formats are defined in Section 9.=
   
3. Control Channel Management
   
   To initiate an LMP adjacency between two nodes, one or more= bi-
   directional control channels MUST be activated.  The= control
   channels can be used to exchange control-plane information such= as
   link provisioning and fault management information (implemented=
   using a messaging protocol such as LMP, proposed in this= draft),
   path management and label distribution information (implemented=
   using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP= [CR-
   LDP]), and network topology and state distribution information=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 6]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   (implemented using traffic engineering extensions of protocols= such
   as OSPF [OSPF-TE] and IS-IS [ISIS-TE]).
   
   For the purposes of LMP, the exact implementation of the= control
   channel is not specified; it could be, for example, a separate=
   wavelength or fiber, an Ethernet link, an IP tunnel through a=
   separate management network, or the overhead bytes of a= data-bearing
   link.  Rather, a node-wide unique 32-bit non-zero integer= control
   channel identifier (CCId) is assigned at each end of the= control
   channel.  This identifier comes from the same space as the=
   unnumbered interface Id.  Furthermore, LMP is run directly= over IP. 
   Thus, the link level encoding of the control channel is not= part of
   the LMP specification.
   
   The control channel can be either explicitly configured or
   automatically selected, however, for the purpose of this= document
   the control channel is assumed to be explicitly configured.= Note
   that for in-band signaling, a control channel could be= explicitly
   configured on a particular data-bearing link.
   
   Control channels exist independently of TE links and multiple=
   control channels may be active simultaneously between a pair of=
   nodes.  Individual control channels can be realized in= different
   ways; one might be implemented in-fiber while another one may= be
   implemented out-of-fiber.  As such, control channel= parameters MUST
   be negotiated over each individual control channel, and LMP= Hello
   packets MUST be exchanged over each control channel to maintain= LMP
   connectivity if other mechanisms are not available.  Since= control
   channels are electrically terminated at each node, it may be=
   possible to detect control channel failures using lower layers=
   (e.g., SONET/SDH).
   
   There are four LMP messages that are used to manage individual=
   control channels.  They are the Config, ConfigAck,= ConfigNack, and
   Hello messages. These messages MUST be transmitted on the= channel to
   which they refer.  All other LMP messages may be= transmitted over
   any of the active control channels between a pair of LMP= adjacent
   nodes.
   
   In order to maintain an LMP adjacency, it is necessary to have= at
   least one active control channel between a pair of adjacent= nodes
   (recall that multiple control channels can be active= simultaneously
   between a pair of nodes).  In the event of a control= channel
   failure, alternate active control channels can be used and it= may be
   possible to activate additional control channels as mentioned= below.
   
3.1. Parameter Negotiation
   
   Control channel activation begins with a parameter negotiation=
   exchange using Config, ConfigAck, and ConfigNack= messages.  The
   contents of these messages are built using LMP objects, which= can be
   either negotiable or non-negotiable (identified by the N bit in= the
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 7]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   object header).  Negotiable objects can be used to let LMP= peers
   agree on certain values.  Non-negotiable objects are used= for the
   announcement of specific values that do not need, or do not= allow,
   negotiation.
   
   To begin control channel activation, a node MUST transmit a= Config
   message to the remote node.  The Config message contains= the Control
   Channel ID (CCID), the sender=92s Node ID, a MessageId for= reliable
   messaging, and a CONFIG Object.  It is possible that both= the local
   and remote nodes initiate the configuration procedure at the= same
   time.  To avoid ambiguities, the node with the higher Node= Id wins
   the contention; the node with the lower Node Id MUST stop
   transmitting the Config message and respond to the Config= message it
   received.
   
   The ConfigAck message is used to acknowledge receipt of the= Config
   message and express agreement on ALL of the configured= parameters
   (both negotiable and non-negotiable).  The ConfigNack= message is
   used to acknowledge receipt of the Config message, indicate= which
   (if any) non-negotiable CONFIG objects are unacceptable, and= propose
   alternate values for the negotiable parameters.
   
   If a node receives a ConfigNack message with acceptable= alternate
   values for negotiable parameters, the node SHOULD transmit a= Config
   message using these values for those parameters. 
   
   If a node receives a ConfigNack message with unacceptable= alternate
   values, the node MAY continue to retransmit Config= messages.  Note
   that the problem may be solved by an operator changing= parameters.
   
   In the case where multiple control channels use the same= physical
   interface, the parameter negotiation exchange is performed for= each
   control channel.  The various LMP parameter negotiation= messages are
   associated with their corresponding control channels by their= node-
   wide unique identifiers (CCIds).
   
3.2. Hello Protocol
   
   Once a control channel is activated between two adjacent nodes,= the
   LMP Hello protocol can be used to maintain control channel
   connectivity between the nodes and to detect control channel=
   failures.  The LMP Hello protocol is intended to be a= lightweight
   keep-alive mechanism that will react to control channel= failures
   rapidly so that IGP Hellos are not lost and the associated= link-
   state adjacencies are not removed unnecessarily.
   
3.2.1. Hello Parameter Negotiation
   
   Before sending Hello messages, the HelloInterval and
   HelloDeadInterval parameters MUST be agreed upon by the local= and
   remote nodes.  These parameters are exchanged in the= Config message. 
   The HelloInterval indicates how frequently LMP Hello messages= will
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 8]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   be sent, and is measured in milliseconds (ms).  For= example, if the
   value were 150, then the transmitting node would send the Hello=
   message at least every 150ms.  The HelloDeadInterval= indicates how
   long a device should wait to receive a Hello message before=
   declaring a control channel dead, and is measured in= milliseconds
   (ms).  The HelloDeadInterval MUST be greater than the= HelloInterval,
   and SHOULD be at least 3 times the value of HelloInterval.
   
   If the fast keep-alive mechanism of LMP is not used, the
   HelloInterval and HelloDeadInterval MUST be set to zero.
   
   When a node has either sent or received a ConfigAck message, it= may
   begin sending Hello messages.  Once it has both sent and= received a
   Hello message, the control channel moves to the UP state. = (It is
   also possible to move to the UP state without sending Hellos if=
   other methods are used to indicate bi-directional= control-channel
   connectivity.)  If, however, a node receives a ConfigNack= message
   instead of a ConfigAck message, the node MUST not send Hello=
   messages and the control channel SHOULD NOT move to the UP= state. 
   See Section 8.1 for the complete control channel FSM.
   
3.2.2. Fast Keep-alive
   
   Each Hello message contains two sequence numbers: the first= sequence
   number (TxSeqNum) is the sequence number for the Hello message= being
   sent and the second sequence number (RcvSeqNum) is the sequence=
   number of the last Hello message received over this control= channel
   from the adjacent node. Each node increments its sequence= number
   when it sees its current sequence number reflected in Hellos=
   received from its peer. The sequence numbers start at 1 and= wrap
   around back to 2; 0 is used in the RcvSeqNum to indicate that a=
   Hello has not yet been seen.
   
   Under normal operation, the difference between the RcvSeqNum in= a
   Hello message that is received and the local TxSeqNum that is=
   generated will be at most 1.  This difference can be more= than one
   only when a control channel restarts or when the values wrap.=
   
   Note that the 32-bit sequence numbers MAY wrap.  The= following
   expression may be used to test if a newly received TxSeqNum= value is
   less than a previously received value:
   
   If ((int) old_id =96 (int) new_id > 0) {
      New value is less than old value;
   }
   
   Having sequence numbers in the Hello messages allows each node= to
   verify that its peer is receiving its Hello messages. By= including
   the RcvSeqNum in Hello packets, the local node will know which= Hello
   packets the remote node has received.
   

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            &= nbsp; [Page 9]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   The following example illustrates how the sequence numbers= operate. 
   Note that only the operation at one node is shown:
   
   1)  After completing the configuration stage, Node A sends= Hello
       messages to Node B with= {TxSeqNum=3D1;RcvSeqNum=3D0}.
   2)  When Node A receives a Hello from Node B with
       {TxSeqNum=3D1;RcvSeqNum=3D1}, it sends= Hellos to Node B with
       {TxSeqNum=3D2;RcvSeqNum=3D1}.
   3)  When Node A receives a Hello from Node B with
       {TxSeqNum=3D2;RcvSeqNum=3D2}, it sends= Hellos to Node B with
       {TxSeqNum=3D3;RcvSeqNum=3D2}.
   
3.2.3. Control Channel Down
   
   To allow bringing a control channel DOWN gracefully for
   administration purposes, a ControlChannelDown flag is available= in
   the Common Header of LMP packets.  When data links are= still in use
   between a pair of nodes, a control channel SHOULD only be taken= down
   administratively when there are other active control channels= that
   can be used to manage the data links.
   
   When bringing a control channel DOWN administratively, a node= MUST
   set the ControlChannelDown flag in all LMP messages sent over= the
   control channel.  The node may stop sending Hello messages= after
   HelloDeadInterval seconds have passed, or if it receives an LMP=
   message over the same control channel with the= ControlChannelDown
   flag set.
   
   When a node receives an LMP packet with the ControlChannelDown= flag
   set, it SHOULD send a Hello message with the ControlChannelDown= flag
   set and move the control channel to the Down state.

BM> On the receiving node, suggest transitioning to CONFSND state= rather
BM> than DOWN state.. otherwise, it could not automatically get into
BM> config procedure- i.e. would need a trigger/event
BM> On the sending side, the trigger is the operator command to bring= up
BM> the control channel

   
3.2.4. Degraded State
 
   A consequence of allowing the control channels to be physically=
   diverse from the associated data links is that there may not be= any
   active control channels available while the data links are= still in
   use. For many applications, it is unacceptable to tear down a= link
   that is carrying user traffic simply because the control= channel is
   no longer available; however, the traffic that is using the= data
   links may no longer be guaranteed the same level of= service.  Hence
   the TE link is in a Degraded state.
   
   When a TE link is in the Degraded state, routing and signaling=
   SHOULD be notified so that new connections are not accepted and= the
   TE link is advertised with no unreserved resources.
   
4. Link Property Correlation
   
   As part of LMP, a link property correlation exchange is defined=
   using the LinkSummary, LinkSummaryAck, and LinkSummaryNack= messages. 
   The contents of these messages are built using LMP objects,= which
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 10]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   can be either negotiable or non-negotiable (identified by the N= flag
   in the TLV 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.
   
   Link property correlation MUST be done before the link is= brought up
   and MAY be done at any time a link is UP and not in the= Verification
   process.
   
   The LinkSummary message is used to verify for consistency the= TE and
   data bearing link information on both sides.  Link Summary= messages
   are also used to aggregate multiple data links (either ports or=
   component links) into a TE link; exchange, correlate (to= determine
   inconsistencies), or change TE link parameters; and exchange,=
   correlate (to determine inconsistencies), or change Interface= Ids
   (either Port Ids or Component Interface Ids).
   
   Each TE link has an identifier (Link_Id) that is assigned at= each
   end of the link.  These identifiers MUST be the same type= (i.e,
   IPv4, IPv6, unnumbered) at both ends.  Similarly, each= interface is
   assigned an identifier (Interface_Id) at each end.  These=
   identifiers MUST be the same type at both ends.

BM> Why the restriction that both ends of a TE Link have to use the= same
BM> identification?


   
   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).  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. 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 an allocated= data
   link has a mapping mismatch, it SHOULD be flagged and verified= when
   it becomes free.  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
   MUST 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.
   
   It is possible that the LinkSummary message could grow quite= large
   due to the number of Data Link TLVs.  Since the= LinkSummary message
   is IP encoded, normal IP fragmentation should be used if the=
   resulting PDU exceeds the MTU.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 11]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
5. Verifying 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 when establishing a TE link, and
   subsequently, on a periodic basis for all unallocated (free)= data
   links of the TE link.
   
   If the link connectivity procedure is not supported for the TE= link,
   then a BeginVerifyNack message MUST be transmitted with Error= Code
   =3D1, =93Link Verification Procedure not supported for this TE= Link=94.
   
   A unique characteristic of all-optical PXCs is that the= data-bearing
   links are transparent when allocated to user traffic. = This
   characteristic of PXCs poses a challenge for validating the=
   connectivity of the data links since shining unmodulated light=
   through a link may not result in received light at the next= PXC. 
   This is because there may be terminating (or opaque) elements,= such
   as DWDM equipment, between the PXCs.  Therefore, to ensure= proper
   verification of data link connectivity, it is required that= until
   the links are allocated for user traffic, they must be= opaque.  To
   support various degrees of opaqueness (e.g., examining overhead=
   bytes, terminating the payload, etc.), and hence different
   mechanisms to transport the Test messages, a Verify Transport=
   Mechanism field is included in the BeginVerify and= BeginVerifyAck
   messages.  There is no requirement that all data links be= terminated
   simultaneously, but at a minimum, the data links MUST be able= to be
   terminated one at a time.  Furthermore, for the link= verification
   procedure it is assumed that the nodal architecture is designed= so
   that messages can be sent and received over any data= link.  Note
   that this requirement is trivial for DXCs (and OEO devices in=
   general) since each data link is terminated and processed
   electronically before being forwarded to the next OEO device,= but
   that in PXCs (and transparent devices in general) this is an=
   additional requirement.
   
   To interconnect two nodes, a TE link is defined between them,= and at
   a minimum, there MUST be at least one active control channel= between
   the nodes.  For link verification, a TE link MUST include= at least
   one data link.
   
   Once a control channel has been established between the two= nodes,
   data link connectivity can be verified by exchanging Test= messages
   over each of the data links specified in the TE link.  It= should be
   noted that all LMP messages except the Test message are= exchanged
   over the control channels and that Hello messages continue to= be
   exchanged over each control channel during the data link
   verification process.  The Test message is sent over the= data link
   that is being verified.  Data links are tested in the= transmit
   direction as they are unidirectional, and therefore, it may be=

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 12]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   possible for both nodes to (independently) exchange the Test=
   messages simultaneously.
   
   To initiate the link verification procedure, the local node= MUST
   send a BeginVerify message over a control channel.  To= limit the
   scope of Link Verification to a particular TE Link, the LINK_ID= MUST
   be non-zero.  If this field is zero, the data links can= span
   multiple TE links and/or they may comprise a TE link that is= yet to
   be configured.
   
   The BeginVerify message also contains the number of data links= that
   are to be verified; the interval (called VerifyInterval) at= which
   the Test messages will be sent; the encoding scheme and= transport
   mechanisms that are supported; the data rate for Test messages;= and,
   when the data links correspond to fibers, the wavelength= identifier
   over which the Test messages will be transmitted.
   
   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 specifying the desired transport mechanism for= the
   TEST messages.  The remote node includes a 32-bit node= unique
   VerifyId in the BeginVerifyAck message.  The VerifyId is= then used
   in all corresponding verification messages to differentiate= them
   from different LMP peers and/or parallel Test procedures. = When the
   local node receives a BeginVerifyAck message from the remote= node,
   it may begin testing the data links by transmitting periodic= Test
   messages over each data link.  The Test message includes= the
   VerifyId and the local Interface Id for the associated 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 without receiving a TestStatusSuccess or= TestStatusFailure
   message by sending an EndVerify message.
   
   Message correlation is done using message identifiers and the= Verify
   Id; this enables verification of data links, belonging to= different
   link bundles or LMP sessions, in parallel.
   
   When the Test message is received, the received Interface Id= (used
   in GMPLS as either a Port/Wavelength label or Component= Interface
   Identifier depending on the configuration) 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), along with the VerifyId received in the Test= message.  The
   receipt of a TestStatusSuccess message indicates that the Test=
   message was detected at the remote node and the physical
   connectivity of the data link has been verified.  When the=
   TestStatusSuccess message is received, the local node SHOULD= mark
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 13]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   the data link as UP and send a TestStatusAck message to the= remote
   node.  If, however, the Test message 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 channel 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
   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 SHOULD 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 1 shows an example of the link verification scenario= that is
   executed when a link between PXC A and PXC B is added. In this=
   example, the TE link consists of three free ports (each= transmitted
   along a separate fiber) and is associated with a bi-directional=
   control channel (indicated by a "c"). The= verification process is as
   follows: PXC A sends a BeginVerify message over the control= channel
   =93c=94 to PXC B indicating it will begin verifying the= ports.  PXC B
   receives the BeginVerify message, assigns a VerifyId to the= Test
   procedure, and returns the BeginVerifyAck message over the= control
   channel to PXC A.  When PXC A receives the BeginVerifyAck= message,
   it begins transmitting periodic Test messages over the first= port
   (Interface Id=3D1). When PXC B receives the Test messages, it= maps the
   received Interface Id to its own local Interface Id =3D 10 and=
   transmits a TestStatusSuccess message over the control channel= back
   to PXC A.  The TestStatusSuccess message includes both the= local and
   received Interface Ids for the port as well as the= VerifyId.  PXC A
   will send a TestStatusAck message over the control channel back= to
   PXC B indicating it received the TestStatusSuccess= message.  The
   process is repeated until all of the ports are verified. At= this
   point, PXC A will send an EndVerify message over the control= channel
   to PXC B to indicate that testing is complete; PXC B will= respond by
   sending an EndVerifyAck message over the control channel back= to PXC
   A.
   
  = +---------------------+        &nbs= p;            = +---------------------+
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
   +      PXC= A          +<-------- c= --------->+         PXC= B       +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;      1 +--------------------->+= 10            &= nbsp;     +
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 14]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;      2= +            &n= bsp;   /---->+= 11            &= nbsp;     +
  = +            &n= bsp;       = +         = /----/     = +            &n= bsp;        +
  = +            &n= bsp;        +    = /---/           = +            &n= bsp;        +
  = +            &n= bsp;      3= +----/           &nb= sp;     += 12            &= nbsp;     +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +            &n= bsp;      4 +--------------------->+= 14            &= nbsp;     +
  = +            &n= bsp;       = +            &n= bsp;        = +            &n= bsp;        +
  = +---------------------+        &nbs= p;            = +---------------------+
   
      Figure 1:  Example of link connectivity= between PXC A and PXC B.
   
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 channels 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 LSPs.
   
   An important implication of using PXCs is that traditional= methods
   that are used to monitor the health of allocated data links in= OEO
   nodes (e.g., DXCs) may no longer be appropriate, since PXCs are=
   transparent to the bit-rate, format, and wavelength. = Instead, fault
   detection is delegated to the physical layer (i.e., loss of= light or
   optical monitoring of the data) instead of layer 2 or layer 3.=
   
   Recall that a TE link connecting two nodes may consist of a= number
   of data links. If one or more data links fail between two= nodes, a
   mechanism must be used for rapid failure notification so that=
   appropriate protection/restoration mechanisms can be= initiated.  If
   the failure is subsequently cleared, then a mechanism must be= used
   to notify that the failure is clear and the channel status is= OK. 
   
6.1. Fault Detection
   
   Fault detection should be handled at the layer closest to the=
   failure; for optical networks, this is the physical (optical)= layer.
   One measure of fault detection at the physical layer is= detecting
   loss of light (LOL). Other techniques for monitoring optical= signals
   are still being developed and will not be further considered in= this
   document. However, it should be clear that the mechanism used= for
   fault notification in LMP is independent of the mechanism used= to
   detect the failure, but simply relies on the fact that a= failure is
   detected.
   
6.2. Fault Localization Procedure
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 15]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   If data links fail between two PXCs, the power monitoring= system in
   all of the downstream nodes may detect LOL and indicate a= failure. 
   To avoid multiple alarms stemming from the same failure, LMP=
   provides a failure notification through the ChannelStatus= message. 
   This message may be used to indicate that a single data channel= has
   failed, multiple data channels have failed, or an entire TE= link has
   failed.  Failure correlation is done locally at each node= upon
   receipt of the failure notification.
   
   As part of the fault localization, 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 (including ingress side)= for
   the corresponding LSP(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.  Once the failure is= correlated,
   the upstream node SHOULD send a ChannelStatus message to the=
   downstream node indicating that the channel is failed or is= ok.  If
   a ChannelStatus message is not received by the downstream node,= it
   SHOULD send a ChannelStatusRequest message for the channel in=
   question.  Once the failure has been localized, the= 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 Fig. 2, a sample network is shown where four PXCs are= connected
   in a linear array configuration.  The control channels are= bi-
   directional and are labeled with a "c".  All= LSPs are also bi-
   directional.
   
   In the first example [see Fig. 2(a)], there is a failure on one=
   direction of the bi-directional LSP.  PXC 4 will detect= the failure
   and will send a ChannelStatus message to PXC3 indicating the= failure
   (e.g., LOL) to the corresponding upstream node.  When PXC3= receives
   the ChannelStatus message from PXC4, it returns a= ChannelStatusAck
   message back to PXC4 and correlates the failure locally. = When PXC3
   correlates the failure and verifies that it is CLEAR, it has=
   localized the failure to the data link between PXC3 and PXC4.=
   

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 16]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   In the second example [see Fig. 2(b)], a single failure (e.g.,= fiber
   cut) affects both directions of the bi-directional LSP. = PXC2 (PXC3)
   will detect the failure of the upstream (downstream) direction= and
   send a ChannelStatus message to the upstream (in terms of data= flow)
   node indicating the failure (e.g., LOL).  Simultaneously= (ignoring
   propagation delays), PXC1 (PXC4) will detect the failure on the=
   upstream (downstream) direction, and will send a ChannelStatus=
   message to the corresponding upstream (in terms of data flow)= node
   indicating the failure.  PXC2 and PXC3 will have localized= the two
   directions of the failure.
   
   
      = +-------+       = +-------+       = +-------+        +-------+
       + PXC 1= +        + PXC 2= +        + PXC 3= +        + PXC 4 +
       +      = +-- c ---+       +-- c= ---+       +-- c= ---+       +
   ----+---\  = +       = +      = +       = +      = +       = +       +
   <---+---\\--+--------+-------+---\   = +      = +        +    /--+--->=
       +   = \--+--------+-------+---\\---+-------+---##---+---//--+----
       +      = +       = +       +   = \---+-------+--------+---/   +
       +      = +       = +      = +       = +       +  (a)  = +       +
   ----+-------+--------+---\  = +       = +      = +       = +       +
   <---+-------+--------+---\\--+---##---+--\   = +       = +       +
       +      = +        +   = \--+---##---+--\\   +       = +       +
       +      = +       = +       +  (b)   +  = \\--+--------+-------+--->
       +      = +       = +      = +        +   = \--+--------+-------+----
       +      = +       = +      = +       = +      = +       = +       +
      = +-------+       = +-------+       = +-------+        +-------+
   
          Figure= 2:     Two types of data link failures are shown
          (indicated by ## in= the figure):  (A) a data link
          corresponding to the= downstream direction of a bi-directional
          LSP fails, (B) two= data links corresponding to both
          directions of a= bi-directional LSP fail.  The control channel
          connecting two PXCs= is indicated with a "c".
 
6.4. Channel 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
   Channel Activation Indication.  This is particularly= useful in
   networks with transparent nodes where the status of data links= may
   need to be triggered using control channel messages.  For= example,
   if a data link is pre-provisioned and the physical link fails= after
   verification and before inserting user traffic, a mechanism is=
   needed to indicate the data link should be active or they may= not be
   able to detect the failure.
   
   The ChannelStatus message is used to indicate that a channel or=
   group of channels are now active.  The ChannelStatusAck= message MUST
   be transmitted upon receipt of a ChannelStatus message. = When a
   ChannelStatus message is received, the corresponding data= link(s)
   MUST be put into the Active state.  If upon putting them= into the
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 17]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   Active state, a failure is detected, the ChannelStatus message= MUST
   be transmitted as described in Section 6.2.
   
6.5. Channel Deactivation Indication 
   
   The ChannelStatus message may also be used to notify an LMP= neighbor
   that the data link no longer needs to be monitored.  This= is the
   counterpart to the Channel Active Indication.
   
   When a ChannelStatus message is received with Channel Deactive=
   Indication, the corresponding data link(s) MUST be taken out of= the
   Active state.
 
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.
   
   For control channel specific messages, the Message_Id field is=
   within the scope of the CCID.  For TE link specific= messages, the
   Message_Id field is within the scope of the LMP adjacency.
   
   The Message_Id field of the MESSAGE_ID object contains a= generator
   selected value.  This value MUST be greater than any other= value
   previously used.  A value is considered to be previously= used when
   it has been sent in an LMP message with the same CCID (for= control
   channel specific messages) or LMP adjacency (for TE Link= specific
   messages).  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.
   
   Note that the 32-bit Message_Id value MAY wrap.  The= following
   expression may be used to test if a newly received Message_Id= value
   is less than a previously received value:
   
   If ((int) old_id =96 (int) new_id > 0) {
      New value is less than old value;
   }
   
   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 is a Config message, and the Message_Id value is= less
   than the largest Message_Id value previously received from the=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 18]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   sender for the CCID, then the message SHOULD be treated as= being out
   of order.
   
   If the message is a LinkSummary message and the Message_Id= value is
   less than the largest Message_Id value previously received from= the
   sender for the TE Link, then the message SHOULD be treated as= being
   out of order.

BM> Isn't this logic true for link verification as well?

   
   If the message is a ChannelStatus message and the Message_Id= value
   is less than the largest Message_Id value previously received= from
   the sender for the specified TE link, then the receiver SHOULD= check
   the Message_Id value previously received for the state of each= data
   channel included in the ChannelStatus message.  If the= Message_Id
   value is greater than the most recently received Message_Id= value
   associated with at least one of the data channels included in= the
   message, the message MUST NOT be treated as out of order;= otherwise
   the message SHOULD be treated as being out of order. However,= the
   state of any data channel MUST NOT be updated if the Message_Id=
   value is less than the most recently received Message_Id value=
   associated with the data channel.
   
   All other messages MUST NOT be treated as out-of-order.
   
8. Graceful Restart
   
   This section describes the mechanism to resynchronize the LMP= state
   after a control plane restart.  A control plane restart= may occur
   when bringing up the first control channel after an LMP= adjacency
   has failed, or as a result of an LMP component restart. = The latter
   is detected by setting the =93Control Plane Restart=94 bit in= the Common

BM> Isn't the bit called LMP Restart?

   Header of the LMP messages.  When the control plane fails= due to the
   loss of the control channel (rather than an LMP component= restart),
   the LMP Link information should be retained.  It is= possible that a
   node may be capable of retaining the LMP Link information= across an
   LMP component restart.  However, in both cases the status= of the
   data channels MUST be synchronized.
   
   We assume the Local Interface Ids remain stable across a= control
   plane restart.
   
   After the control plane of a node restarts, the control= channel(s)
   must be re-established using the procedures of Section 3.1.=
   
   If the control plane failure was the result of an LMP component=
   restart, then the =93Control Plane Restart=94 flag MUST be set= in LMP
   messages until a Hello message is received with the RcvSeqNum= equal
   to the local TxSeqNum.  This indicates that the control= channel is
   UP and the LMP neighbor has detected the restart.
   
   Once a control channel is UP, the LMP neighbor 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=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 19]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   indicating that the parameters are non-negotiable.  This= provides
   the local/remote Link Id and Interace Id mappings, the= associated
   Link/Data channel parameters, and indication of which data= links are
   currently allocated to user traffic.  When a node receives= the
   LinkSummary message, it checks its local configuration. = If the node
   is capable of retaining the LMP Link information across a= restart,
   it must process the LinkSummary message 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 node= was not
   capable of retaining the LMP Link information across a restart,= the
   node MUST accept the Link/Data channel parameters of the= received
   LinkSummary message and respond with a LinkSummaryAck message.=
   
   Upon completion of the LinkSummary exchange, the node that has=
   restarted the control plane SHOULD send a ChannelStatusRequest=
   message for that TE link.  The node SHOULD also verify the=
   connectivity of all unallocated data channels.
   
9. Addressing
   
   All LMP messages are sent directly over IP (except, in some= cases,
   the Test messages are limited by the transport mechanism for= in-band
   messaging).  The destination address of the IP packet MUST= be the
   address learned in the Configuration procedure (i.e., the= Source IP
   address found in the IP header of the received Config message).=
   
   The manner in which a Config message is addressed may depend on= the
   signaling transport mechanism.  When the transport= mechanism is a
   point-to-point link, Config messages SHOULD be sent to the= Multicast
   address (224.0.0.1).  Otherwise, Config messages MUST be= sent to an
   IP address on the neighboring node.  This is configured at= both ends
   of the control channel.
   
10.
   LMP Authentication
   
   LMP authentication is optional (included in the Common Header)= and,
   if used, MUST be supported by both sides of the control= channel.  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

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 20]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   the data portion depend on the authentication type. = Currently, only
   MD5 is supported for LMP.
   
11.
   IANA Considerations
   
   LMP defines the following name spaces which require management:=
   
   - Message Type Name Space.
   - Class and class type name spaces for LMP objects. 
   
   The following sections provide guidelines for managing these= name
   spaces.
   
11.1.
     Message Type Name Space
   
   LMP divides the name space for message types into two= ranges.  The
   following are the guidelines for managing these ranges:
   
   - Message Types 0 - 49 and 60 - 255: These message types are= part of
     the LMP base protocol.  Following the policies= outlined in [IANA],
     message types in this range are allocated through= an IETF
     Consensus action.
   
   - Message Types 50 - 59: Message types in this range are= reserved
     for UNI LMP extensions and the allocation in this= range is the
     responsibility of the OIF for supporting UNI= signaling. IANA
     management of this range of the Message Type name= space is
     unnecessary.
 
11.2.
     Object Class Name Space
   
   LMP divides the name space for object classes into two= ranges.  The
   following are the guidelines for managing these ranges:
   
   - Classes 0 - 49 and 60 - 127:  Object types in this range= are part
     of the LMP base protocol.  Following the= policies outlined in
     [IANA], class types in this range are allocated= through an IETF
     Consensus action. Within each class, 256 class= types are possible.
     The allocation of class types for base LMP objects= are described
     in this draft and these are subject to IETF= consensus action.
   
   - Classes 50 - 59 are reserved for UNI LMP extensions and the=
     allocation in this range is the responsibility of= the OIF for
     supporting UNI signaling. IANA management of this= range of the
     class name space, and the underlying class types,= is unnecessary.
 






 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 21]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

12.
   LMP Finite State Machines
   
12.1.
     Control Channel FSM
   
   The control channel FSM defines the states and logics of= operation
   of an LMP control channel.  The description of FSM state= transitions
   and associated actions is given in Section 3.
   
12.1.1. Control Channel States
   
   A control channel can be in one of the states described= below. 
   Every state corresponds to a certain condition of the control=
   channel and is usually associated with a specific type of LMP=
   message that is periodically transmitted to the far end.
   
   Down:        This is the= initial control channel state.  In this
            &nbs= p;   state, no attempt is being made to bring the control
            &nbs= p;   channel up and no LMP messages are sent.  The control=
            &nbs= p;   channel parameters should be set to the initial values.
   
   ConfigSnd:   The control channel is in the parameter= negotiation
            &nbs= p;   state.  In this state the node periodically sends a
            &nbs= p;   Config message, and is expecting the other side to
            &nbs= p;   reply with either a ConfigAck or ConfigNack message. =
            &nbs= p;   The FSM does not transition into the Active state until
            &nbs= p;   the remote side positively acknowledges the parameters.
   
   ConfRcv:     The control channel is in the= parameter negotiation
            &nbs= p;   state.  In this state, the node is waiting for
            &nbs= p;   acceptable configuration parameters from the remote
            &nbs= p;   side.  Once such parameters are received and
            &nbs= p;   acknowledged, the FSM can transition to the Active
            &nbs= p;   state.
   
   Active:      In this state the node= periodically sends a Hello
            &nbs= p;   message and is waiting to receive a valid Hello
            &nbs= p;   message.  Once a valid Hello message is received, it=
            &nbs= p;   can transition to the UP state.
   
   Up:          The= CC is in an operational state.  The node receives
            &nbs= p;   valid Hello messages and sends Hello messages.
   
   GoingDown:   A CC may go into this state because of= administrative
            &nbs= p;   action.  While a CC is in this state, the node sets the=
            &nbs= p;   ControlChannelDown bit in all the messages it sends.
   
12.1.2. Control Channel Events
   
   Operation of the LMP control channel is described in terms of= FSM
   states and events.  Control channel Events are generated= by the
   underlying protocols and software modules, as well as by the= packet
   processing routines and FSMs of associated TE links. = Every event
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 22]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   has its number and a symbolic name.  Description of= possible control
   channel events is given below.
   
   1 : evBringUp:    This is an externally= triggered event indicating
            &nbs= p;        that the control channel= negotiation should begin. 
            &nbs= p;        This event, for example, may be= triggered by an
            &nbs= p;        operator command, by the= successful completion of
            &nbs= p;        a control channel bootstrap= procedure, or by
            &nbs= p;        configuration.  Depending= on the configuration,
            &nbs= p;        this will trigger either
            &nbs= p;            1a) the= sending of a Config message,
            &nbs= p;            1b) a= period of waiting to receive a Config
            &nbs= p;            &n= bsp;    message from the remote node.
   
   2 : evCCDn:       This event is= generated when there is indication
            &nbs= p;        that the control channel is no= longer available.
   
   3 : evConfDone:   This event indicates a ConfigAck= message has been
            &nbs= p;        received, acknowledging the= Config parameters.
   
   4 : evConfErr:    This event indicates a= ConfigNack message has been
            &nbs= p;        received, rejecting the Config= parameters.
   
   5 : evNewConfOK:  New Config message was received from= neighbor and
            &nbs= p;        positively Acknowledged.
   
   6 : evNewConfErr: New Config message was received from neighbor= and
            &nbs= p;        rejected with a ConfigNack= message.
   
   7 : evContenWin:  New Config message was received from= neighbor at
            &nbs= p;        the same time a Config message= was sent to the
            &nbs= p;        neighbor.  The Local node= wins the contention.  As
            &nbs= p;        a result, the received Config= message is ignored.
   
   8 : evContenLost: New Config message was received from neighbor= at
            &nbs= p;        the same time a Config message= was sent to the
            &nbs= p;        neighbor.  The Local node= loses the contention.
            &nbs= p;            8a) The= Config message is positively
            &nbs= p;            &n= bsp;    Acknowledged.
            &nbs= p;            8b) The= Config message is negatively
            &nbs= p;            &n= bsp;    Acknowledged.
   
   9 : evAdminDown:  The administrator has requested that the= control
            &nbs= p;        channel is brought down= administratively.  Hello
            &nbs= p;        messages (with= ControlChannelDown flag set) SHOULD
            &nbs= p;        be sent for HelloDeadInterval= seconds or until an
            &nbs= p;        LMP message is received over= the control channel
            &nbs= p;        with the ControlChannelDown= flag set.
   
   10: evNbrGoesDn:  A packet with ControlChannelDown flag is= received
            &nbs= p;        from the neighbor.
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 23]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   11: evHelloRcvd:  A Hello packet with expected SeqNum has= been
            &nbs= p;        received.
   
   12: evHoldTimer:  The HelloDeadInterval timer has expired= indicating
            &nbs= p;        that no Hello packet has been= received.  This
            &nbs= p;        moves the control channel back= into the
            &nbs= p;        Negotiation state, and= depending on the local
            &nbs= p;        configuration, this will= trigger either
            &nbs= p;            12a)= the sending of periodic Config messages,
            &nbs= p;            12b) a= period of waiting to receive Config
            &nbs= p;            &n= bsp;    messages from the remote node.
            &nbs= p;            =
   13: evSeqNumErr:  A Hello with unexpected SeqNum received= and
            &nbs= p;        discarded.
 
   14: evReconfig:   Control channel parameters have= been reconfigured
            &nbs= p;        and require renegotiation.
   
   15: evConfRet:    A retransmission timer has= expired and a Config
            &nbs= p;        message is resent.
   
   16: evHelloRet:   The HelloInterval timer has expired= and a Hello
            &nbs= p;        packet is sent.
   
   17: evDownTimer:  A timer has expired and no messages have= been
            &nbs= p;        received with the= ControlChannelDown flag set.
 

























 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 24]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

12.1.3. Control Channel FSM Description
   
   Figure 3 illustrates operation of the control channel FSM
   in a form of FSM state transition diagram.
   
            &nbs= p;            &n= bsp;     +--------+
           = +----------------->|       = |<--------------+
           = |       +--------->|  Down = |<----------+   |
           = |      = |+---------|        |<-------+ = |   |
           = |      = ||        = +--------+        |  |  = |
           = |      = ||          = |    ^    2,9,10| 2|  2|
           = |      = ||1b       1a|   = |          | = |   |
           = |      = ||          = v    | 2,9,10   |  |   |
           = |      = ||        = +--------+        |  |  = |
           = |       ||     = +->|        |<------+| = |   |
           = |       ||  4,7,|  |ConfSnd= |       ||  |   |
           = |       ||= 14,15+--|        |<----+ || = |   |
           = |      = ||        = +--------+     | ||  |   |
           = |      = ||       3,8a|= |          | || = |   |
           = |       || +---------+ |8b  14,12a|= ||  |   |
           = |       ||= |          = v          | || = |   |
           = |      = |+-|------>+--------+     | ||  |   |=
           = |       |  |   = +->|        |-----|-|+ = |   |
           = |       |  |6,14|  |ConfRcv= |     | |   |   |
           = |       |  |   = +--|        |<--+ | |  = |   |
           = |       | = |       +--------+   | |= |   |   |
           = |       | = |          5|= ^      | | |   |   |
           = |       |  +---------+ |= |      | | |   |   |
           = |      = |            | |= |      | | |   |   |
           = |      = |            v v= |6,12b | | |   |   |
           = |      = |10        +--------+   | |= |   |   |
           = |      = +----------|        |   | |= |   |   |
           = |       |      = +--| Active |---|-+ |   |   |
      = 10,17|       |   5,16| = |        |-------|---+   |=
        +-------+ 9 |  = 13  +->|        |  = |   |       |
        | Going= |<--|----------+--------+   |  = |       |
        | Down  |  = |           11|= ^       |  = |       |
        +-------+  = |             |= |5      |  = |       |
           = ^      = |             v= |  6,12b|   |       |
           = |9     = |10        +--------+  = |   |12a,14 |
           = |      = +----------|        |---+  = |       |
           = |            &n= bsp;     |   Up  = |-------+       |
           = +------------------|       = |---------------+
            &nbs= p;            &n= bsp;     +--------+
            &nbs= p;            &n= bsp;       |   ^
            &nbs= p;            &n= bsp;       |   |
            &nbs= p;            &n= bsp;       +---+
            &nbs= p;            &n= bsp;      11,13,16
            &nbs= p;          Figure 3: Control= Channel FSM
   


 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 25]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   Event evCCDn always forces the FSM to the Down State. = Events
   evHoldTimer evReconfig always force the FSM to the Negotiation= state
   (either ConfigSnd or ConfigRcv).
   
12.2.
     TE Link FSM
   
   The TE Link FSM defines the states and logics of operation of= an LMP
   TE Link.
   
12.2.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 and is=
   usually associated with a specific type of LMP message that is=
   periodically transmitted to the far end via the associated= control
   channel or in-band via the data links.
   
   Down:       There are no data= links allocated to the TE link.
   
   Init:       Data links have been= allocated to the TE link, but the
            &nbs= p;  configuration has not yet been synchronized with the LMP
            &nbs= p;  neighbor.

BM> I guess we are saying that once initially synchronized, subsequent= changes
BM> to TE Links that cause link summary to run could happen whilst the TE= Link
BM> is still in UP state.
BM> In the middle of the day, is the IDs and/or other properties
BM> of links are changed such that a TE Links go out of= synchronization,
BM> should we go back to "Init" state?, such that the above= definition of
BM> Init state is observed all the time?


   Up:         This is the= normal operational state of the TE link.  At
            &nbs= p;  least one primary CC is required to be operational
            &nbs= p;  between the nodes sharing the TE link.
   
   Degraded:   In this state, all primary CCs are down,= but the TE link
            &nbs= p;  still includes some allocated data links.

BM> Does the term "allocated" here refer to "allocated to= data traffic"?
BM> I don't think so.. but could we be explicit?

BM> Related question. Whilst in Init state, if the last CC goes down,
BM> Shouldn't the TE Link go into degraded?

   
12.2.2. TE Link Events
   
   Operation of the LMP TE link is described in terms of FSM= states and
   events. TE Link events are generated by the packet processing=
   routines and by the FSMs of the associated primary control
   channel(s) and the data links. Every event has its number and a=
   symbolic name. Description of possible control channel events= is
   given below.
   
   1 : evDCUp:         One= or more data channels have been enabled and
            &nbs= p;          assigned to the TE= Link.
   2 : evSumAck:       LinkSummary= message received and positively
            &nbs= p;          acknowledged.
   3 : evSumNack:      LinkSummary= message received and negatively
            &nbs= p;          acknowledged.
   4 : evRcvAck:      = LinkSummaryAck message received acknowledging
            &nbs= p;          the TE Link= Configuration.
   5 : evRcvNack:      LinkSummaryNack= message received.
   6 : evSumRet:      = Retransmission timer has expired and LinkSummary
            &nbs= p;          message is resent.=
   7 : evCCUp:        = First active control channel goes up.
   8 : evCCDown:       Last active= control channel goes down.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 26]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   9 : evDCDown:       Last data= channel of TE Link has been removed.
   
   
12.2.3. TE Link FSM Description
   
   Figure 4 illustrates operation of the LMP TE Link FSM in a form= of
   FSM state transition diagram.
            &nbs= p;        
   
            &nbs= p;            &n= bsp;           3,7,8
            &nbs= p;            &n= bsp;           +--+
            &nbs= p;            &n= bsp;           |  |=
            &nbs= p;            &n= bsp;           |  v=
            &nbs= p;            &n= bsp;        +--------+
            &nbs= p;            &n= bsp;       = |        |
            &nbs= p;       +------------>|  Down = |<---------+
            &nbs= p;      = |            = |       = |          |
            &nbs= p;      = |            = +--------+          |
            &nbs= p;      = |            &n= bsp;   | = ^             |=
            &nbs= p;      = |            &n= bsp;  1| = |9            |
            &nbs= p;      = |            &n= bsp;   v = |             |=
            &nbs= p;      = |            = +--------+          |
            &nbs= p;      = |            = |       = |<-+       |
            &nbs= p;      = |            = |  Init  |  |3,5,6  |9
            &nbs= p;      = |            = |        |--+ 7,8   |
            &nbs= p;     = 9|            = +--------+          |
            &nbs= p;      = |            &n= bsp;    = |            &n= bsp; |
            &nbs= p;      = |            &n= bsp; = 2,4|            = ;  |
            &nbs= p;      = |            &n= bsp;    = v            &n= bsp; |
            &nbs= p;    +--------+   7  = +--------+          |
            &nbs= p;    |       = |------>|        |----------+
            &nbs= p;    |  Deg  = |       |   Up   |
            &nbs= p;    |       = |<------|        |
            &nbs= p;    +--------+   8   +--------+
            &nbs= p;            &n= bsp;           |  ^=
            &nbs= p;            &n= bsp;           |  |=
            &nbs= p;            &n= bsp;           +--+
            &nbs= p;            &n= bsp;         2,3,4,5,6
   
            &nbs= p;            Figure= 4: LMP TE Link FSM
   
   In the above FSM, the sub-states that may be implemented when= the
   link verification procedure is used have been omitted.

BM> Consider a TE Link that transitions to Down state via Degraded..= it
BM> has no data links and no CCs either. If now a DC is added to the= TE
BM> Link, shouldn't it go [back] to degraded state, rather than Init.
BM> When a TE Link in the Down state gets a new data link, it fits
BM> the definition of the degraded state.

   
12.3.
     Data Link FSM
   
   The data link FSM defines the states and logics of operation of= a
   port or component link within an LMP TE link.  Operation= of a data
   link is described in terms of FSM states and events. = Data-bearing
   links can either be in the active (transmitting) mode, where= Test
   messages are transmitted from them, or the passive (receiving)= mode,
   where Test messages are received through them.  For= clarity,
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 27]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   separate FSMs are defined for the active/passive data-bearing= links;
   however, a single set of data link states and events are= defined.  
   
12.3.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
            &nbs= p;     (i.e., the link is not =91in service=92
   
   Test:          The= data link is being tested.  An LMP Test message
            &nbs= p;     is periodically sent through the link.
   
   PasvTest:      The data link is being= checked for incoming test
            &nbs= p;     messages.
   
   Up/Free:       The link has been= successfully tested and is now put
            &nbs= p;     in the pool of resources (in-service).  The= link has
            &nbs= p;     not yet been allocated to data traffic.
   
   Up/Allocated:  The link is UP and has been allocated for= data
            &nbs= p;     traffic.
   
   Degraded:      The link was in the= Up/Allocated state when the last
            &nbs= p;     CC associated with data link's TE Link has gone= down. 
            &nbs= p;     The link is put in the Degraded state, since it= is
            &nbs= p;     still being used for data LSP.
   
12.3.2. Data Link Events
   
   Data bearing link events are generated by the packet processing=
   routines and by the FSMs of the associated control channel and= the
   TE link.  Every event has its number and a symbolic name.=
   Description of possible data link events is given below:
   
   1 :evCCUp:       CC has gone up.=
   2 :evCCDown:     LMP neighbor connectivity= is lost.  This indicates
            &nbs= p;       the last LMP control channel has= failed between
            &nbs= p;       neighboring nodes.
   3 :evStartTst:   This is an external event that= triggers the sending
            &nbs= p;       of Test messages over the data= bearing link.
   
   4 :evStartPsv:   This is an external event that= triggers the
            &nbs= p;       listening for Test messages over the= data bearing
            &nbs= p;       link.
   
   5 :evTestOK:     Link verification was= successful and the link can
            &nbs= p;       be used for path establishment.
            &nbs= p;           (a) This= event indicates the Link Verification
            &nbs= p;            &n= bsp;  procedure (see Section 5) was successful
            &nbs= p;            &n= bsp;  for this data link and a TestStatusSuccess
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 28]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

            &nbs= p;            &n= bsp;  message was received over the control
            &nbs= p;            &n= bsp;  channel.
            &nbs= p;           (b) This= event indicates the link is ready for
            &nbs= p;            &n= bsp;  path establishment, but the Link
            &nbs= p;            &n= bsp;  Verification procedure was not used.  For
            &nbs= p;            &n= bsp;  in-band signaling of the control channel,
            &nbs= p;            &n= bsp;  the control channel establishment may be
            &nbs= p;            &n= bsp;  sufficient to verify the link.
   6 :evTestRcv:    Test message was received over= the data port and a
            &nbs= p;       TestStatusSuccess message is= transmitted over the
            &nbs= p;       control channel.
   7 :evTestFail:   Link verification returned negative= results.  This
            &nbs= p;       could be because (a) a= TestStatusFailure message
            &nbs= p;       was received, or (b) an EndVerifyAck= message was
            &nbs= p;       received without receiving a= TestStatusSuccess or
            &nbs= p;       TestStatusFailure message for the= data link.
   8 :evPsvTestFail:Link verification returned negative= results.  This
            &nbs= p;       indicates that a Test message was not= detected and
            &nbs= p;       either (a) the VerifyDeadInterval has= expired or
            &nbs= p;       (b) an EndVerify messages has been= received and the
            &nbs= p;       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
            &nbs= p;       message 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:evdcDown:     The data channel is no= longer available.
























 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 29]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

12.3.3. Active Data Link FSM Description
   
   Figure 5 illustrates operation of the LMP active data link FSM= in a
   form of FSM state transition diagram.
   
            &nbs= p;            &n= bsp;   +------+
            &nbs= p; +------------->|      |<-------+
            &nbs= p; |   +--------->| Down= |        |
            &nbs= p; |   |    = +----|      |<-----+ |
            &nbs= p; |   |     |   = +------+      | |
            &nbs= p; |   |     |5b   3| = ^        | |
            &nbs= p; |   |     |     = |  |2,7     | |
            &nbs= p; |   |     |     = v  |        | |
            &nbs= p; |   |     |   = +------+      | |
            &nbs= p; |   |     |   = |      |<-+   | |
            &nbs= p; |   |     |    | Test= |  |11 | |
            &nbs= p; |   |     |   = |      |--+   | |
            &nbs= p; |   |     |   = +------+      | |
            &nbs= p; |   |     |     5a|= 3^       | |
            &nbs= p; |   |    = |       | = |       | |
            &nbs= p; |   |    = |       v = |       | |
            &nbs= p; |   |2,12 |   +---------+    | |
            &nbs= p; |   |    = +-->|         |14  | |
            &nbs= p; |   |         | Up/Free= |----+ |
            &nbs= p; |   +---------|        = |      |
            &nbs= p; |            = +---------+      |
            &nbs= p;= |            &n= bsp;   9| ^         = |
            &nbs= p;= |            &n= bsp;    |= |          |
            &nbs= p;= |10            =    v |10        |
           = +-----+  2     = +---------+      |
           = |    = |<--------|        = |13    |
            | Deg= |         |Up/Alloc |------+
           = |    = |-------->|         |
           = +-----+  1      +---------+
   
            &nbs= p;       Figure 5: Active LMP Data Link FSM=
   















 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 30]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

12.3.4. Passive Data Link FSM Description
   
   Figure 6 illustrates operation of the LMP passive data link FSM= in a
   form of FSM state transition diagram.
   
            &nbs= p;            &n= bsp;   +------+
            &nbs= p; +------------->|      |<------+
            &nbs= p; |  +---------->| Down |       |=
            &nbs= p; |  |     +-----|     = |<----+ |
            &nbs= p; |  |     |    = +------+     | |
            &nbs= p; |  |     |5b    4| = ^       | |
            &nbs= p; |  |     |      = |  |2,8    | |
            &nbs= p; |  |     |      = v  |       | |
            &nbs= p; |  |     |    +----------+ = | |
            &nbs= p; |  |     |    | PasvTest | = | |
            &nbs= p; |  |     |    +----------+ = | |
            &nbs= p; |  |     |      = 6|  4^     | |
            &nbs= p; |  |    = |        |  = |     | |  
            &nbs= p; |  |    = |        v  = |     | |
            &nbs= p; |  |2,12 |    +---------+   | |
            &nbs= p; |  |     +--->| Up/Free |14 | |
            &nbs= p; |  |         = |         |---+ |
            &nbs= p; |  +----------|        = |     |
            &nbs= p; |            = +---------+     |
            &nbs= p;= |            &n= bsp;    9| ^        |
            &nbs= p;= |            &n= bsp;     | |        |=
            &nbs= p;= |10            =     v |10      |
           = +-----+        = +---------+     |
           = |     |  2     = |         |13   |
            | Deg= |<--------|Up/Alloc |-----+
           = |    = |-------->|         |
           = +-----+  1      +---------+
   
            &nbs= p;       Figure 6: Passive LMP Data Link FSM=


















 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 31]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

13.
   LMP Message Formats
   
   All LMP messages are IP encoded (except, in some cases, the= Test
   messages are limited by the transport mechanism for in-band=
   messaging) with protocol number xxx - TBA (to be assigned) by= IANA.
   
13.1.
     Common Header
   
   In addition to the standard IP header, all LMP messages= (except, in
   some cases, the Test messages which are limited by the= transport
   mechanism for in-band messaging) have the following common= header:
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          LMP= Length          = |          = Checksum           = |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Vers: 4 bits
   
        Protocol version number. = This is version 1.
   
   Flags: 8 bits.  The following values are defined. = All other values
          are reserved.
   
        0x01: ControlChannelDown
        
        0x02: LMP Restart
        
            &nbs= p;  This bit is set to indicate the LMP component has
            &nbs= p;  restarted.  This flag may be reset to 0 when a Hello
            &nbs= p;  message is received with RcvSeqNum equal to the local
            &nbs= p;  TxSeqNum.
            &nbs= p;  
        0x04: LMP-WDM Support
        
            &nbs= p;  When set, indicates that this node is willing and
            &nbs= p;  capable of receiving all the messages and objects
            &nbs= p;  described in [LMP-DWDM].
        
        0x08: Authentication
        
            &nbs= p;  When set, this bit indicates that an authentication
            &nbs= p;  block is attached at the end of the LMP message.  See
            &nbs= p;  Sections 7 and 9.3 for more details.
 
   Msg Type: 8 bits.  The following values are defined. = All other
            = values are reserved.
   
        1  =3D Config
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 32]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        
        2  =3D ConfigAck
        
        3  =3D ConfigNack
        
        4  =3D Hello
        
        5  =3D BeginVerify
        
        6  =3D BeginVerifyAck
        
        7  =3D BeginVerifyNack
        
        8  =3D EndVerify
        
        9  =3D EndVerifyAck
        
        10 =3D Test
        
        11 =3D TestStatusSuccess
        
        12 =3D TestStatusFailure
        
        13 =3D TestStatusAck
        
        14 =3D LinkSummary
        
        15 =3D LinkSummaryAck
        
        16 =3D LinkSummaryNack
        
        17 =3D ChannelStatus
        
        18 =3D ChannelStatusAck
        
        19 =3D ChannelStatusRequest
        
        20 =3D ChannelStatusResponse
        
        All of the messages are sent over= the control channel EXCEPT
        the Test message, which is sent= over the data link that is
        being tested.
   
   LMP Length: 16 bits
   
        The total length of this LMP= message in bytes, including the
        common header and any= variable-length objects that follow.
 
   Checksum: 16 bits
   
        The standard IP checksum of the= entire contents of the LMP
        message, starting with the LMP= message header. This checksum is
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 33]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        calculated as the 16-bit one's= complement of the one's
        complement sum of all the 16-bit= words in the packet. If the
        packet's length is not an= integral number of 16-bit words, the
        packet is padded with a byte of= zero before calculating the
        checksum.

BM> One thing that will be of great help for implementation is a= "message
BM> specific" field (perhaps a couple of them). An example use of= such a field
BM> could be to store the number of data link objects in a link= summary
BM> and link summary ack message.

 
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= TLV
   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            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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           &nb= sp; |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;            (TLV= Object)           &n= bsp;            //=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   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 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.
   
   Length: 16 bits
   
        The Length field indicates the= length of the Object in bytes.
   
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

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 34]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   the LMP packet, but is transmitted in the same IP packet as= shown
   below:
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;        LMP Common= Header           &nb= sp;           //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;           LMP= Payload           &n= bsp;            =   //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;       Authentication= Block           &nbs= p;         //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   The authentication block consists of an 8 byte header followed= by the
   data portion shown as follows:
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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 |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;    Cryptographic Sequence= Number           &nb= sp;     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = |            &n= bsp;          MD5 Signature= (16)            = ;          |
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Auth Type: 8 bits
   
            &nbs= p; This defines the type of authentication used for LMP
            &nbs= p; messages.  The following authentication types are
            &nbs= p; defined, all other are reserved for future use:
            &nbs= p; 
            &nbs= p; 0  No authentication
            &nbs= p; 1  Cryptographic authentication
            &nbs= p; 
   Key ID: 8 bits
   
            &nbs= p; This field is defined only for cryptographic
            &nbs= p; authentication.
            &nbs= p; 
   Auth Data Length: 8 bits
            &nbs= p; This field contains the length of the data portion of the
            &nbs= p; authentication block.
            &nbs= p; 
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 35]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   LMP authentication is performed on a per control channel= basis.  The
   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 a control channel 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
   on a control channel that is configured for authentication, it= must
   be authenticated.  The value of the Authentication field= MUST match
   the authentication type configured for the control channel (if= any).
   
   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.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 36]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   (1) Locate the receiving control channel's configured key= having Key
       ID equal to that specified in the= received LMP authentication
       block.  If the key is not found,= 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 control channel= data structure, 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 control channel's
           data structure= is set to the sequence number found in the
           packet's LMP= header.
   
13.4.
     Parameter Negotiation Messages

BM> Suggest changing to "Hello parameter negotiation= messages".

   
13.4.1. Config Message (MsgType =3D 1)
   
   The Config message is used in the control channel negotiation= phase
   of LMP.  The contents of the Config message are built= using LMP
   objects.  The format of the Config message is as follows:=
   
   <Config Message> ::=3D <Common Header>= <LOCAL_CCID> <MESSAGE_ID>
            &nbs= p;          = <LOCAL_NODE_ID> <CONFIG>
   
   The above transmission order SHOULD be followed.

BM> If order is to be followed for ALL messages, include it in one
BM> place at beginning of section 13
   
   The MESSAGE_ID is within the scope of the CCID.
   
   The Config message MUST be periodically transmitted until (1)= it
   receives a ConfigAck or ConfigNack message, (2) a timeout= expires
   and no ConfigAck or ConfigNack message has been received, or= (3) it
   receives a Config message from the remote node and has lost the=
   contention (e.g., the Node Id of the remote node is higher than= the
   Node Id of the local node).  Both the retransmission= interval and
   the timeout period are local configuration parameters.
   
13.4.2. ConfigAck Message (MsgType =3D 2)
   
   The ConfigAck message is used to acknowledge receipt of the= Config
   message and indicate agreement on all parameters.
   


 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 37]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   <ConfigAck Message> ::=3D <Common Header>= <LOCAL_CCID> <LOCAL_NODE_ID>
            &nbs= p;            &n= bsp; <REMOTE_CCID> <MESSAGE_ID_ACK>
            &nbs= p;            &n= bsp; <REMOTE_NODE_ID>
   
   The above transmission order SHOULD be followed.
   
   The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and= REMOTE_NODE_ID
   objects MUST be obtained from the Config message being= acknowledged.
   
13.4.3. ConfigNack Message (MsgType =3D 3)
   
   The ConfigNack message is used to acknowledge receipt of the= Config
   message and indicate disagreement on non-negotiable parameters= or
   propose other values for negotiable parameters. = Parameters where
   agreement was reached MUST NOT be included in the ConfigNack=
   Message.  The format of the ConfigNack message is as= follows:
   
   <ConfigNack Message> ::=3D <Common Header>= <LOCAL_CCID>
            &nbs= p;            &n= bsp;  <LOCAL_NODE_ID>  <REMOTE_CCID>
            &nbs= p;            &n= bsp;  <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
            &nbs= p;            &n= bsp;  <ERROR_CODE> [<CONFIG>]
   
   The above transmission order SHOULD be followed.
   
   The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and= REMOTE_NODE_ID
   objects MUST be obtained from the Config message being= negatively
   acknowledged.
   
   The ConfigNack uses CONFIG_ERROR_ C-Type 1.
   
   It is possible that multiple parameters may be invalid in the= Config
   message.  As such, multiple bits may be set in the= ERROR_CODE.
   
   If a negotiable CONFIG object is included in the ConfigNack= message,
   it MUST include acceptable values for the parameters.  The=
   ERROR_CODE MUST indicate =93Renegotiate CONFIG parameter.=94=
   
   If the ConfigNack message includes CONFIG objects for= non-negotiable
   parameters, they MUST be copied from the CONFIG objects= received in
   the Config message.  The ERROR_CODE MUST indicate= =93Unacceptable non-
   negotiable CONFIG parameter.=94
   
   If the ConfigNack message is received and only includes CONFIG=
   objects that are negotiable, then a new Config message SHOULD= be
   sent.  The values in the CONFIG object of the new Config= message
   SHOULD take into account the acceptable values included in the=
   ConfigNack message.
   
13.5.
     Hello Message (MsgType =3D 4)
   
   The format of the Hello message is as follows:
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 38]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   <Hello Message> ::=3D <Common Header>= <LOCAL_CCID> <Hello>

BM>           &nbs= p;            &n= bsp;            =             ^^^^^^= Should be in upper case
   
   The above transmission order SHOULD be followed.
   
   The Hello message MUST be periodically transmitted at least= once
   every HelloInterval msec.  If no Hello message is received= within
   the HelloDeadInterval, the control channel is assumed to have=
   failed.
   
13.6.
     Link Verification
   
13.6.1. BeginVerify Message (MsgType =3D 5)
   
   The BeginVerify message is sent over the control channel and is= used
   to initiate the link verification process.  The format is= as
   follows:
   
   <BeginVerify Message> ::=3D <Common Header>= <LOCAL_LINK_ID>
            &nbs= p;            &n= bsp;   <MESSAGE_ID> [<REMOTE_LINK_ID>]
            &nbs= p;            &n= bsp;   <BEGIN_VERIFY>
   
   The above transmission order SHOULD be followed.
   
   To limit the scope of Link Verification to a particular TE= Link, the
   LOCAL_LINK_ID SHOULD be non-zero.  If this field is zero,= the data
   links can span multiple TE links and/or they may comprise a TE= link
   that is yet to be configured.
   
   The REMOTE_LINK_ID may be included if the local/remote Link Id=
   mapping is known.
   
   The REMOTE_LINK_ID MUST be non-zero if included.
   
   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.6.2. BeginVerifyAck Message (MsgType =3D 6)
   
   When a BeginVerify message is received and Test messages are= ready
   to be processed, a BeginVerifyAck message MUST be transmitted.=
    
   <BeginVerifyAck Message> ::=3D <Common Header>= [<LOCAL_LINK_ID>]
            &nbs= p;            &n= bsp;      <MESSAGE_ID_ACK>= <BEGIN_VERIFY_ACK>
            &nbs= p;            &n= bsp;      <VERIFY_ID>
   
   The above transmission order SHOULD be followed.
   
 
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 39]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   The LOCAL_LINK_ID may be included if the local/remote Link Id=
   mapping is known or learned through the BeginVerify message.=
   
   The LOCAL_LINK_ID MUST be non-zero if included.
   
   
   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.6.3. BeginVerifyNack Message (MsgType =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.
   
   <BeginVerifyNack Message> ::=3D <Common Header>= <LOCAL_LINK_ID>
            &nbs= p;            &n= bsp;       <MESSAGE_ID_ACK>= <ERROR_CODE>
   
   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 =93Link Verification Procedure not supported=94.
   
   If Verification is supported, but the node unable to begin the=
   procedure, the ERROR_CODE MUST indicate =93Unwilling to= verify=94.  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 =93Unsupported verification transport=
   mechanism=94.
   
   If remote configuration of the TE Link Id is not supported and= the
   REMOTE_LINK_ID object (included in the BeginVerify message)= does not
   match any configured values, the ERROR_CODE MUST indicate =93TE= Link
   Id configuration error=94.
   
   The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2.
   
13.6.4. EndVerify Message (MsgType =3D 8)
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 40]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   The EndVerify message is sent over the control channel and is= used
   to terminate the link verification process.  The EndVerify= message
   may be sent at any time the initiating node desires to end the=
   Verify procedure.  The format is as follows:
   
   <EndVerify Message> ::=3D <Common Header>= <MESSAGE_ID> <VERIFY_ID>
   
   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.6.5. EndVerifyAck Message (MsgType =3D9)
   
   The EndVerifyAck message is sent over the control channel and= is
   used to acknowledge the termination of the link verification=
   process.  The format is as follows:
   
   <EndVerifyAck Message> ::=3D <Common Header>= <VERIFY_ID>
            &nbs= p;            &n= bsp;    <MESSAGE_ID_ACK>
   
   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.6.6. Test Message (MsgType =3D 10)
   
   The Test message is transmitted over the data link and is used= to
   verify its physical connectivity. Unless explicitly stated in= the
   Verify Transport Mechanism description for the BEGIN_VERIFY= class,
   this is transmitted as an IP packet with payload format as= follows:
   
   <Test Message> ::=3D <Common Header>= <VERIFY_ID> <LOCAL_INTERFACE_ID>
   
   The above transmission order SHOULD be followed.
   
   Note that this message is sent over a data link and NOT over= the
   control channel.  The transport mechanism for the Test= message is
   negotiated using Verify Transport Mechanism field of the= BeginVerify
   Object and the Verify Transport Response field of the= BeginVerifyAck
   Object (see Sections 14.9 and 14.10).
   
   The local (transmitting) node sends a given Test message
   periodically (at least once every VerifyInterval ms) on the=
   corresponding data link until (1) it receives a correlating=
   TestStatusSuccess or TestStatusFailure message on the control=
   channel from the remote (receiving) node or (2) all active= control
   channels between the two nodes have failed. The remote node= will
   send a given TestStatus message periodically over the control=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 41]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   channel until it receives either a correlating TestStatusAck= message
   or an EndVerify message is received over the control channel.=
        
13.6.7. TestStatusSuccess Message (MsgType =3D 11)
   
   The TestStatusSuccess message is transmitted over the control=
   channel and is used to transmit the mapping between the local=
   Interface Id and the Interface Id that was received in the Test=
   message.  
   
   <TestStatusSuccess Message> ::=3D <Common Header>= <LOCAL_LINK_ID>
            &nbs= p;            &n= bsp;         <MESSAGE_ID>= <LOCAL_INTERFACE_ID>
            &nbs= p;            &n= bsp;        = <REMOTE_INTERFACE_ID> <VERIFY_ID>
   
   The above transmission order SHOULD be followed.
   
   The contents of the REMOTE_INTERFACE_ID object MUST be obtained= from
   the corresponding Test message being positively acknowledged.=
   
13.6.8. TestStatusFailure Message (MsgType =3D 12)
   
   The TestStatusFailure message is transmitted over the control=
   channel and is used to indicate that the Test message was not=
   received.
   
   <TestStatusFailure Message> ::=3D <Common Header>= <MESSAGE_ID>
            &nbs= p;            &n= bsp;         <VERIFY_ID>
   
   The above transmission order SHOULD be followed.
   
13.6.9. TestStatusAck Message (MsgType =3D 13)
   
   The TestStatusAck message is used to acknowledge receipt of the=
   TestStatusSuccess or TestStatusFailure messages.
   
   <TestStatusAck Message> ::=3D <Common Header>= <MESSAGE_ID_ACK>
            &nbs= p;            &n= bsp;     <VERIFY_ID>
   
   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.7.
     Link Summary Messages
   
13.7.1. LinkSummary Message (MsgType =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:
   

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 42]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   <LinkSummary Message> ::=3D <Common Header>= <MESSAGE_ID> <TE_LINK>
            &nbs= p;            &n= bsp;   <DATA_LINK> [<DATA_LINK>...]
   
   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.7.2. LinkSummaryAck Message (MsgType =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.
   
   <LinkSummaryAck Message> ::=3D  <Common= Header> <MESSAGE_ID_ACK>
   
   The above transmission order SHOULD be followed.
   
13.7.3. LinkSummaryNack Message (MsgType =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.
   
   <LinkSummaryNack Message> ::=3D <Common Header>= <MESSAGE_ID_ACK>
            &nbs= p;            &n= bsp;       <ERROR_CODE>= [<DATA_LINK>...]
   
   The above transmission order SHOULD be followed.
   
   The LinkSummary TLVs MUST include acceptable values for all=
   negotiable parameters.  If the LinkSummaryNack includes= LinkSummary
   TLVs for non-negotiable parameters, they MUST be copied from= the
   LinkSummary TLVs 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.

BM> It looks like sending a linksummarynack that includes both= non-negotiable
BM> parameters as well as negotiable parameters is kind of useless..
BM> because the initiator will not resend a link summary in that case.= Yes?

   
   The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.=
   
13.8.
     Fault Management Messages
   
13.8.1. ChannelStatus Message (MsgType =3D 17)
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 43]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   The ChannelStatus message is sent over the control channel 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:
   
   <ChannelStatus Message> ::=3D <Common Header>= <LOCAL_LINK_ID>
            &nbs= p;            &n= bsp;     <MESSAGE_ID> <CHANNEL_STATUS>
   
   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.8.2. ChannelStatusAck Message (MsgType =3D 18)
   
   The ChannelStatusAck message is used to acknowledge receipt of= the
   ChannelStatus Message.  The format is as follows:
   
   <ChannelStatusAck Message> ::=3D <Common Header>= <MESSAGE_ID_ACK>
   
   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.8.3. ChannelStatusRequest Message (MsgType =3D 19)
   
   The ChannelStatusRequest message is sent over the control= channel
   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:
   
   <ChannelStatusRequest Message> ::=3D <Common= Header> <LOCAL_LINK_ID>
            &nbs= p;            &n= bsp;           = <MESSAGE_ID>
            &nbs= p;            &n= bsp;           = [<CHANNEL_STATUS_REQUEST>]
   
   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.8.4. ChannelStatusResponse Message (MsgType =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 channel(s).  The format is as follows:=
   
   <ChannelStatusResponse Message> ::=3D <Common= Header> <MESSAGE_ID_ACK> 
            &nbs= p;            &n= bsp;            = <CHANNEL_STATUS>
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 44]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   The above transmission order SHOULD be followed.
   
   The contents of the MESSAGE_ID_ACK objects MUST be obtained= from the
   ChannelStatusRequest message being acknowledged.
   
14.
   LMP Object Definitions
   
14.1.
     CCID (Control Channel ID) Classes
   
14.1.1. LOCAL_CCID Class
   
   Class =3D 1. 
   
   o    C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =   = CC_Id           &nbs= p;            &n= bsp;     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   CC_Id:  32 bits
   
        This MUST be node-wide unique and= non-zero.  The CC_Id
        identifies the control channel of= the sender associated with
        the message.
   
   This Object is non-negotiable.



BM> Suggestion: Why not reserve C-Type =3D 2 for OIF- OIF OUNI 125.7= allows
BM> CCID to be either numbered (IPv4) or unnumbered.
 
14.1.2. REMOTE_CCID Class
 
   Class =3D 2.
   
   o    C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =    = CC_Id           &nbs= p;            &n= bsp;    |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   CC_Id:  32 bits
   
        This identifies the remote node= =92s CC_Id and MUST be non-zero.  
   
   This Object is non-negotiable.
   
14.2.
     NODE_ID Classes
   
14.2.1.  LOCAL_NODE_ID Class
 
   Class =3D 3.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 45]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   o    C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           Node_Id (4= bytes)           &nb= sp;          |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   Node_Id:
        
        This identities the node that= originated the LMP packet.
   
   This Object is non-negotiable.
   
14.2.2. REMOTE _NODE_ID Class
   
   Class =3D 4.
   
   o    C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           Node_Id (4= bytes)           &nb= sp;          |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   Node_Id:
        
        This identities the remote node.=
   
   This Object is non-negotiable.
   
14.3.
     LINK _ID Classes
   
14.3.1. LOCAL_LINK_ID Class
 
   Class =3D 5
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           Link_Id (4= bytes)           &nb= sp;          |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 46]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;           Link_Id (16= bytes)           &nb= sp;         +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           Link_Id (4= bytes)           &nb= sp;          |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
   o    Reserved for OIF, C-Type =3D 4
   
   Link_Id:
        
        This identifies the sender=92s= Link associated with the message.
   
   This Object is non-negotiable.
   
14.3.2. REMOTE _LINK_ID Class
   
   Class =3D 6 
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           = Link_Id (4= bytes)           &nb= sp;         |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;           = Link_Id (16= bytes)           &nb= sp;        +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 47]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;           = Link_Id (4= bytes)           &nb= sp;         |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Reserved for OIF, C-Type =3D 4
   
   Link_Id:
        
        This identifies the remote node= =92s Link Id and MUST be non-zero.
   
   This Object is non-negotiable.
   
14.4.
     INTERFACE_ID Classes
   
14.4.1. LOCAL_INTERFACE_ID Class
 
   Class =3D 7
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;          Interface_Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface_Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;         Interface_Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 48]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   Interface_Id:
        
        This identifies the data link= (either port or component link). 
        The Interface_Id MUST be= node-wide unique and non-zero.
   
   This Object is non-negotiable.
   
14.4.2. REMOTE _INTERFACE_ID Class
   
   Class =3D 8. 
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;          Interface_Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface_Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;         Interface_Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Interface_Id:
   
        This identifies the remote node= =92s data link (either port or
        component link).  The= Interface Id MUST be non-zero.
   
   This Object is non-negotiable.
   
14.5.
     MESSAGE_ID Class
   
   Class =3D 9. 
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 49]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   o    MessageId, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            = Message_Id           = ;            &nb= sp;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   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.6.
     MESSAGE_ID_ACK Class
   
   Class =3D 10.
   
   o    MessageIdAck, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            = Message_Id           = ;            &nb= sp;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   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.7.
     CONFIG Class
   
   Class =3D 11.
   
   o    HelloConfig, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        = HelloInterval        = |     = HelloDeadInterval        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   HelloInterval:  16 bits.
   
        Indicates how frequently the= Hello packets will be sent and is
        measured in milliseconds (ms).=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 50]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   HelloDeadInterval:  16 bits.
   
        If no Hello packets are received= within the HelloDeadInterval,
        the control channel is assumed to= have failed.  The
        HelloDeadInterval is measured in= milliseconds (ms).  The
        HelloDeadInterval MUST be greater= than the HelloInterval, and
        SHOULD be at least 3 times the= value of HelloInterval.
   
   If the fast keep-alive mechanism of LMP is not used, the
   HelloInterval and HelloDeadInterval MUST be set to zero.


BM> Given that the only parameters negotiated by Hello COnfig are
BM> these two parameters, if fast keep-alive mechanism is not used,
BM> why bother with Hello Config protocol? Why then say Hello Config
BM> is mandatory?
   
14.8.
     HELLO Class
   
   Class =3D 12
   
   o    Type 1 Hello, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =  = TxSeqNum           &= nbsp;            = ;    |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =  = RcvSeqNum           =             &nbs= p;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   TxSeqNum:  32 bits
   
        This is the current sequence= number for this Hello message. 
        This sequence number will be= incremented when the sequence
        number is reflected in the= RcvSeqNum of a Hello packet that is
        received over the control= channel.
        
        TxSeqNum=3D0 is not allowed.
        
        TxSeqNum=3D1 is reserved to= indicate that the control channel has
        booted or restarted.
        
   RcvSeqNum:  32 bits
   
        This is the sequence number of= the last Hello message received
        over the control channel. = RcvSeqNum=3D0 is reserved to indicate
        that a Hello message has not yet= been received.
   
   This Object is non-negotiable.
   
14.9.
     BEGIN_VERIFY Class
   
   Class =3D 13.
   
   o    C-Type =3D 1
   
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 51]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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           &nbs= p;         = |        = VerifyInterval        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;          Number of Data= Links           &nbs= p;        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    EncType    | = (Reserved)   |  Verify Transport Mechanism   |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =   = BitRate           &n= bsp;            =     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            = Wavelength           = ;            &nb= sp;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
   Flags:  16 bits
   
        The following flags are defined:=
            &nbs= p;   
        0x01 Verify all Links
            &nbs= p;   If this bit is set, the verification process checks all
            &nbs= p;   unallocated links; else it only verifies new ports or
            &nbs= p;   component links that are to be added to this TE link.
        0x02 Data Link Type
            &nbs= p;   If set, the data links to be verified are ports,
            &nbs= p;   otherwise they are component links
        
   VerifyInterval:  16 bits
   
        This is the interval between= successive Test messages and is
        measured in milliseconds (ms).=
 
   Number of Data Links:  32 bits
   
        This is the number of data links= that will be verified.
        
   EncType:  8 bits
   
        This is the encoding type of the= data link.  The defined
        EncType values are consistent= with the Link Encoding Type
        values of [GMPLSSIG]
        
   Verify Transport Mechanism:  16 bits
   
        This defines the transport= mechanism for the Test Messages. The
        scope of this bit mask is= restricted to each link encoding
        type. The local node will set the= bits corresponding to the
        various mechanisms it can support= for transmitting LMP test
        messages. The receiver chooses= the appropriate mechanism in the
        BeginVerifyAck message.
        
        For SONET/SDH Encoding Type, the= following flags are defined:
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 52]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        0x01 J0-16: Capable of= transmitting Test messages using J0
            &nbs= p;   overhead bytes with string length of 16 bytes (with
            &nbs= p;   CRC-7).  Note that Due to the byte limitation, a
            &nbs= p;   special Test message is defined as follows:
            &nbs= p;   
            &nbs= p;   The Test message is a 15-byte message, where the last 7
            &nbs= p;   bits of each byte are usable.  Due to the byte
            &nbs= p;   limitation, the LMP Header is not included.
            &nbs= p;   
            &nbs= p;   The first usable 32 bits MUST be the VerifyId that was
            &nbs= p;   received in the VERIFY_ID Object of the BeginVerifyAck
            &nbs= p;   message.  The second usable 32 bits MUST be the
            &nbs= p;   Interface_Id.  The next usable 8 bits are used to
            &nbs= p;   determine the address type of the Interface_Id.  For=
            &nbs= p;   IPv4, this value is 1.  For unnumbered, this value is=
            &nbs= p;   3. The remaining bits are Reserved.
            &nbs= p;   
            &nbs= p;   Note that this Test Message format is only valid when
            &nbs= p;   the Interface_Id is either IPv4 or unnumbered.
            &nbs= p;   
        0x02 DCCS: Capable of= transmitting Test messages using the DCC
            &nbs= p;   Section Overhead bytes with an HDLC framing format.
        0x04 DCCL: Capable of= transmitting Test messges using the DCC
            &nbs= p;   Line Overhead bytes with an HDLC framing format.
        0x08 Payload: Capable of= transmitting Test messages in the
            &nbs= p;   payload using Packet over SONET framing using the
            &nbs= p;   encoding type specified in the EncType field.
        
        For GigE Encoding Type, the= following flags are defined: TBD
        
        For 10GigE Encoding Type, the= following flags are defined: TBD
        
   BitRate:  32 bits
   
        This is the bit rate of the data= link over which the Test
        messages will be transmitted and= is expressed in bytes per
        second.
        
   Wavelength:  32 bits
   
   When a data link is assigned to a port or component link that= is
   capable of transmitting multiple wavelengths (e.g., a fiber or=
   waveband-capable port), it is essential to know which= wavelength the
   test messages will be transmitted over.  This value= corresponds to
   the wavelength at which the Test messages will be transmitted= over
   and has local significance.  If there is no ambiguity as= to the
   wavelength over which the message will be sent, then this value=
   SHOULD be set to 0.
   
14.10.  BEGIN_VERIFY_ACK Class
   
   Class =3D 14.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 53]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   
   o    C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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       |  = Verify_Transport_Response   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   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.
        
   Verify_Transport_Response:  16 bits
        
        The recipient of the BeginVerify= message (and the future
        recipient of the TEST messages)= chooses the transport mechanism
        from the various types that are= offered by the transmitter of
        the Test messages.  One and= only one bit MUST be set in the
        verification transport response.=
   
   This Object is non-negotiable.
   
14.11.  VERIFY_ID Class
   
   Class =3D 15.
   
   o    C-Type =3D 1
 
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =  = VerifyId           &= nbsp;            = ;    |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   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.12.  TE_LINK Class
   
   Class =3D 16.
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      3
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 54]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

    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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Local_Link_Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Remote_Link_Id (4= bytes)           &nb= sp;     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;         Local_Link_Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;         Remote_Link_Id (16= bytes)           &nb= sp;    +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Local_Link_Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Remote_Link_Id (4= bytes)           &nb= sp;     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Flags: 8 bits
        The following flags are= defined.  All other values are
        reserved.
        
        0x01 Fault Management Supported.=
        
        0x02 Link Verification Supported.=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 55]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        
   Local_Link_Id:
        
        This identifies the node=92s= local Link Id and MUST be non-zero.
        
   Remote_Link_Id:
        
        This identifies the remote node= =92s Link Id and MUST be non-zero.
   
14.13.  DATA_LINK Class
   
   Class =3D 17. 
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;      Local_Interface_Id (4= bytes)           &nb= sp;    |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;      Remote_Interface_Id (4= bytes)           &nb= sp;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;          = (Subobjects)          &nb= sp;            &= nbsp; //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;      Local_Interface_Id (16= bytes)           &nb= sp;   +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;      Remote_Interface_Id (16= bytes)           &nb= sp;  +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 56]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;          = (Subobjects)          &nb= sp;            &= nbsp; //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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    = |            &n= bsp;     = (Reserved)           = ;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;      Local_Interface_Id (4= bytes)           &nb= sp;    |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;      Remote_Interface_Id (4= bytes)           &nb= sp;   |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = //            &= nbsp;          = (Subobjects)          &nb= sp;            &= nbsp; //
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
   Flags: 8 bits
   
        The following flags are= defined.  All other values are
        reserved.
        
        0x01 Interface Type: If set, the= data link is a port,
            &nbs= p;            &n= bsp;    otherwise it is a component link.
        0x02 Allocated Link: If set, the= data link is currently
            &nbs= p;            &n= bsp;    allocated for user traffic.  If a single
            &nbs= p;            &n= bsp;    Interface_Id is used for both the
            &nbs= p;            &n= bsp;    transmit and receive data links, then
            &nbs= p;            &n= bsp;    this bit only applies to the transmit
            &nbs= p;            &n= bsp;    interface.
   
   Local_Interface_Id:
        
        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 consist of a series of
        variable-length  data = items called subobjects.  The subobjects
        are defined in section 14.13.1= below.
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 57]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        
   A DATA_LINK object may contain more than one subobject. = If more
   than one subobject of the same Type appears, only the first=
   subobject of that Type is meaningful.  Subsequent= subobjects of the
   same Type MAY be ignored.
   
14.13.1.        Data Link Subobjects
   
   The contents of the DATA_LINK object include a series of= variable-
   length data items called subobjects.  Each subobject has= the form:
   
  = 0            &n= bsp;      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. 
        Currently defined values are:=
   
            &nbs= p;   1   Interface Switching Capability
   
   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.13.1.1.      Subobject 1:  Interface= Switching Capability
   
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type    = |    Length     | Switching Cap= |     EncType     |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;     Minimum Reservable= Bandwidth           =       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;     Maximum Reservable= Bandwidth           =       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   Switching Capability: 8 bits
        
        This is used to identify the= local Interface Switching
        Capability of the TE link. = See [LSP-HIER].
   
   EncType:  8 bits
   
        This is the encoding type of the= data link.  The defined
        EncType values are consistent= with the Link Encoding Type
        values of [GMPLSSIG].
   
   Minimum Reservable Bandwidth: 32 bits
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 58]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

        
        This is measured in bytes per= second and represented in IEEE
        floating point format.
        
   Maximum Reservable Bandwidth: 32 bits
        
        This is measured in bytes per= second and represented in IEEE
        floating point format.
   
   If the interface only supports a fixed rate, the minimum and= maximum
   bandwidth fields are set to the same value.
        
14.14.  CHANNEL_STATUS Class
   
   Class =3D 18
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;          Interface Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;          Interface Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 59]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;         Interface Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Interface Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |A|            =            Channel= Status           &nb= sp;            |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Active bit: 1 bit
   
   This indicates that the Channel is allocated to user traffic= and the
   data link should be actively monitored.
   
   Channel_Status: 32 bits
   
        This indicates the status= condition of a data channel.  The
        following values are= defined.  All other values are reserved.
        
        1   Signal Okay (OK):= Channel is operational
        2   Signal Degrade= (SD): A soft failure caused by a BER
            &nbs= p;       exceeding a preselected= threshold.  The specific
            &nbs= p;       BER used to define the threshold is= configured.
        3   Signal Fail (SF): A= hard signal failure including (but not
            &nbs= p;       limited to) loss of signal (LOS),= loss of frame
            &nbs= p;       (LOF), or Line AIS.
   
   This Object contains one or more Interface Ids followed by a=
   Channel_Status field.
   

 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 60]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   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.15.  CHANNEL_STATUS_REQUEST Class
   
   Class =3D 19
   
   o    IPv4, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;          Interface Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;          Interface Id (4= bytes)           &nb= sp;      |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   This Object contains one or more Interface Ids.
   
   The Length of this object is 4 + 4N in bytes, where N is the= number
   of Interface Ids.
   
   o    IPv6, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;          Interface Id (16= bytes)           &nb= sp;     +
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
  = +            &n= bsp;            =             &nbs= p;            &n= bsp;            +=
  = |            &n= bsp;            =             &nbs= p;            &n= bsp;            |=
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 61]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   This Object contains one or more Interface Ids.
   
   The Length of this object is 4 + 16N in bytes, where N is the= number
   of Interface Ids.
   
   
   o    Unnumbered, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;         Interface Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = //            &= nbsp;            = ;   = :            &n= bsp;            =       //
  = |            &n= bsp;            =     = :            &n= bsp;            =        |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  = |            &n= bsp;         Interface Id (4= bytes)           &nb= sp;       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   This Object contains one or more Interface Ids.
   
   The Length of this object is 4 + 4N in bytes, where N is the= number
   of Interface Ids.
   
   This Object is non-negotiable.
   
14.16.  ERROR_CODE Class
   
   Class =3D 20.
   
   o    CONFIG_ERROR, C-Type =3D 1
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            = ERROR= CODE            = ;            &nb= sp;  |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        The following bit-values are= defined:
        0x01 =3D Unacceptable= non-negotiable CONFIG parameter
        0x02 =3D Renegotiate CONFIG= parameter
        0x04 =3D Bad Received CCID
        
        All other values are Reserved.=
        
        Multiple bits may be set to= indicate multiple errors.
        
        This Object is non-negotiable.=



BM> How about adding a bit for "Ill-formed message" to cover=
BM> such cases as object-order-violations?
BM> THese could be under a special C-Type, say, PROTOCOL_ERROR
        
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 62]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

   o    BEGIN_VERIFY_ERROR, C-Type =3D 2
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            = ERROR= CODE            = ;            &nb= sp;  |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        The following bit-values are= defined:
        
        0x01 =3D Link Verification= Procedure not supported for this TE
            &nbs= p;  Link.
        0x02 =3D Unwilling to verify at= this time
        0x04 =3D Unsupported verification= transport mechanism 
        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.
   
   o    LINK_SUMMARY_ERROR, C-Type =3D 3
   
   = 0            &n= bsp;     = 1            &n= bsp;     = 2            &n= bsp;      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= bsp;            = ERROR= CODE            = ;            &nb= sp;  |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
        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
        All other values are Reserved.=
        
        Multiple bits may be set to= indicate multiple errors.
        
        This Object is non-negotiable.=
        
15.
   Security Considerations
   
   LMP exchanges may be authenticated using the Cryptographic
   authentication option.  MD5 is currently the only message= digest
   algorithm specified.
 
 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 63]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

16.
   References
 
   [RFC2026]   Bradner, S., "The Internet Standards= Process -- Revision
            &nbs= p;  3," BCP 9, RFC 2026, October 1996.
   [LAMBDA]    Awduche, D. O., Rekhter, Y., Drake,= J., Coltun, R.,
            &nbs= p;  "Multi-Protocol Lambda Switching: Combining MPLS Traffic
            &nbs= p;  Engineering Control with Optical Crossconnects,"
            &nbs= p;  Internet Draft, draft-awduche-mpls-te-optical-03.txt,
            &nbs= p;  (work in progress), April 2001.
   [BUNDLE]    Kompella, K., Rekhter, Y., Berger,= L., =93Link Bundling in
            &nbs= p;  MPLS Traffic Engineering,=94 Internet Draft, draft-
            &nbs= p;  kompella-mpls-bundle-05.txt, (work in progress), February
            &nbs= p;  2001.
   [RSVP-TE]   Awduche, D. O., Berger, L., Gan, D.-H.,= Li, T.,
            &nbs= p;  Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP
            &nbs= p;  Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-
            &nbs= p;  tunnel-08.txt, (work in progress), February 2001.
   [CR-LDP]    Jamoussi, B., et al,= "Constraint-Based LSP Setup using
            &nbs= p;  LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
            &nbs= p;  (work in progress), September 1999.
   [OSPF-TE]   Katz, D., Yeung, D., Kompella, K.,= "Traffic Engineering
            &nbs= p;  Extensions to OSPF," Internet Draft, draft-katz-yeung-
            &nbs= p;  ospf-traffic-04.txt, (work in progress), February 2001.
   [ISIS-TE]   Li, T., Smit, H., "IS-IS extensions= for Traffic
            &nbs= p;  Engineering," Internet Draft,draft-ietf-isis-traffic-
            &nbs= p;  02.txt, (work in progress), September 2000.
   [OSPF]      Moy, J., "OSPF= Version 2," RFC 2328, April 1998.
   [LMP-DWDM]  Fredette, A., Snyder, E., Shantigram, J., et= al, =93Link
            &nbs= p;  Management Protocol (LMP) for WDM Transmission Systems,=94
            &nbs= p;  Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in
            &nbs= p;  progress), March 2001.
   [MD5]       Rivest, R., "The= MD5 Message-Digest Algorithm," RFC
            &nbs= p;  1321, April 1992.
   [GMPLSSIG]  Ashwood-Smith, P., Banerjee, A., et al,= =93Generalized
            &nbs= p;  MPLS - Signaling Functional Description,=94 Internet Draft,
            &nbs= p;  draft-ietf-mpls-generalized-signaling-06.txt, (work in
            &nbs= p;  progress), October 2001.
   [LSP-HIER]  Kompella, K. and Rekhter, Y., =93LSP Hierarchy= with MPLS
            &nbs= p;  TE,=94 Internet Draft, draft-ietf-mpls-lsp-hierarchy-
            &nbs= p;  02.txt, (work in progress), February 2001.












 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 64]

Internet Draft      = draft-ietf-ccamp-lmp-02.txt       = November 2001

17.
   Acknowledgments
   
   The authors would like to thank Ayan Banerjee, George Swallow,= Andre
   Fredette, Adrian Farrel, and Vinay Ravuri for their insightful=
   comments and suggestions.  We would also like to thank= John Yu,
   Suresh Katukam, and Greg Bernstein for their helpful= suggestions for
   the in-band control channel applicability.
   
18.
   Author's Addresses
   
   Jonathan P.= Lang            = ;            Krishna= Mitra
   Calient= Networks           &= nbsp;           = Calient Networks
   25 Castilian= Drive           &nbs= p;          5853 Rue Ferrari=
   Goleta, CA= 93117           &nbs= p;            San= Jose, CA 95138
   Email:= jplang@calient.net         &nb= sp;     email: krishna@calient.net
   
   John= Drake           &nbs= p;            &n= bsp;     Kireeti Kompella
   Calient= Networks           &= nbsp;           = Juniper Networks, Inc.
   5853 Rue= Ferrari           &n= bsp;            385= Ravendale Drive
   San Jose, CA= 95138           &nbs= p;          Mountain View, CA= 94043
   email:= jdrake@calient.net         &nb= sp;     email: kireeti@juniper.net
   
   Yakov= Rekhter           &n= bsp;            =    Lou Berger
   Juniper Networks,= Inc.            = ;      Movaz Networks 
   385 Ravendale= Drive           &nbs= p;         email: lberger@movaz.com=
   Mountain View, CA 94043
   email:= yakov@juniper.net         &nbs= p;        
   
   Debanjan= Saha            = ;            &nb= sp;  Debashis Basak
   Tellium Optical= Systems           &n= bsp;     Accelight Networks
   2 Crescent= Place           &nbs= p;            70= Abele Road, Suite 1201
   Oceanport, NJ= 07757-0901           = ;     Bridgeville, PA 15017-3470
  = email:dsaha@tellium.com        &nbs= p;        email: dbasak@accelight.com=
   
   
   Hal= Sandick           &n= bsp;            =      Alex Zinin
   Nortel= Networks           &= nbsp;            = ; Nexsi Systems
   email:= hsandick@nortelnetworks.com      1959 Concourse= Drive
            &nbs= p;            &n= bsp;            =      San Jose, CA 95131
            &nbs= p;            &n= bsp;            =      email:  azinin@nexsi.com 
   Bala Rajagopalan
   Tellium Optical Systems
   2 Crescent Place
   Oceanport, NJ 07757-0901
   email: braja@tellium.com
   
   
   




 
Lang et= al            &= nbsp;            = ;            &nb= sp;            = [Page 65]
--=====================_22429171==_.ALT-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 10:57:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Tue, 20 Nov 2001 11:34:21 -0500 From: "George Young" To: "Jonathan Lang" Cc: Hello Jonathan, Comments/question below. Also please note, edgeFlow has changed its name to Meriton Networks Inc., and as a result the email address changes to george.young@meriton.com. Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: Jonathan Lang [mailto:jplang@calient.net] >Sent: Monday, November 19, 2001 5:21 PM >To: 'S Ramesh'; George Young >Cc: ccamp@ops.ietf.org; Jonathan Lang >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > >Ramesh, > Please see inline. > >Thanks, >Jonathan > >> -----Original Message----- >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] >> Sent: Thursday, November 15, 2001 11:15 PM >> To: George Young >> Cc: ccamp@ops.ietf.org >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) >>=20 >>=20 >> Hi Young, >>=20 >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the=20 >> Data Link FSM's in the down state also. Agreed. >I would actually propose that we remove the degraded state=20 >altogether from >the data link fsms. This is already captured at the TE link level. >Comments? If I understand your response to messrs Ramesh and moi, transition 10 should be retained from Deg to Down. If you then remove the Deg state, implying that in the Up/Alloc state you may not have a control channel, where would transition 10 go? Transition 13 'fault localization' seems to need a control channel. Without the Deg state, how would you represent the idea that sometimes transition 13 can't take place? > >>=20 >> 2. Transtition 10:evLnkDealloc can be possible know even in=20 >the degraded >> state. Yeah a control channel is needed, but this event can also be a >> external event know, from the user or a network management=20 >event. If this >> is possible then this event is required in this state. Kindly=20 >> clarify me. >agreed. > >>=20 >> 3. Also event 14.evdcDown can also possible in Test/Pasv=20 >Test state. Since >> to send a Test message or to receive a Test message we need a data >channel. >> If you see both the FSM's ( Data link ) event 3 & 4 will=20 >pose the next >> state to Test & Pasv Test state from Up/Free state. So the event >> 14.evdcDown is also possible on both the states and hence the=20 >> next state in both the case will be down. >ok. > >>=20 >> Thanks, >> Ramesh >>=20 >> George Young wrote: >>=20 >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of >> > draft-ietf-ccamp-lmp-02.txt: >> > >> > 1) It appears that in the Down state, the control channel=20 >> can be either >> > up or >> > down. That being the case, there should be transitions for events 1 >> > :evCCUp: >> > and 2 :evCCDown: from Down to Down. >> > >> > 2) Transition 10:evLnkDealloc: from Deg to Down would appear to be >> > impossible, >> > as there is no control channel available, and the control=20 >channel is >> > required to coordinate taking the channel down at both=20 >> ends. I believe >> > this >> > transition should be removed. >> > >> > With these changes, the FSMs would look like: >> > >> > 12.3.3. Active Data Link FSM Description >> > >> > Figure 5 illustrates operation of the LMP active data=20 >> link FSM in a >> > form of FSM state transition diagram. >> > >> > 1,2 >> > +------+ >> > | | >> > | +------+ >> > +-->| |<-------+ >> > +--------->| Down | | >> > | +----| |<-----+ | >> > | | +------+ | | >> > | |5b 3| ^ | | >> > | | | |2,7 | | >> > | | v | | | >> > | | +------+ | | >> > | | | |<-+ | | >> > | | | Test | |11 | | >> > | | | |--+ | | >> > | | +------+ | | >> > | | 5a| 3^ | | >> > | | | | | | >> > | | v | | | >> > |2,12 | +---------+ | | >> > | +-->| |14 | | >> > | | Up/Free |----+ | >> > +---------| | | >> > +---------+ | >> > 9| ^ | >> > | | | >> > v |10 | >> > +-----+ 2 +---------+ | >> > | |<--------| |13 | >> > | Deg | |Up/Alloc |------+ >> > | |-------->| | >> > +-----+ 1 +---------+ >> > >> > Figure 5: Active LMP Data Link FSM >> > >> > 12.3.4. Passive Data Link FSM Description >> > >> > Figure 6 illustrates operation of the LMP passive data=20 >> link FSM in a >> > form of FSM state transition diagram. >> > >> > 1,2 >> > +------+ >> > | | >> > | +------+ >> > +-->| |<------+ >> > +---------->| Down | | >> > | +-----| |<----+ | >> > | | +------+ | | >> > | |5b 4| ^ | | >> > | | | |2,8 | | >> > | | v | | | >> > | | +----------+ | | >> > | | | PasvTest | | | >> > | | +----------+ | | >> > | | 6| 4^ | | >> > | | | | | | >> > | | v | | | >> > |2,12 | +---------+ | | >> > | +--->| Up/Free |14 | | >> > | | |---+ | >> > +----------| | | >> > +---------+ | >> > 9| ^ | >> > | | | >> > v |10 | >> > +-----+ +---------+ | >> > | | 2 | |13 | >> > | Deg |<--------|Up/Alloc |-----+ >> > | |-------->| | >> > +-----+ 1 +---------+ >> > >> > Figure 6: Passive LMP Data Link FSM >> > >> > Regards, >> > George R. Young >> > edgeflow Inc. >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 >> > phone: +1 613-270-9279 Ext 287 >> > fax: +1 613-270-9268 >> > >> > >-----Original Message----- >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] >> > >Sent: Monday, November 12, 2001 9:00 PM >> > >To: ccamp@ops.ietf.org >> > >Subject: Two week Last Call on LMP >> > > >> > > >> > >Hi All, >> > > >> > >This is to announce a two week Last Call on the LMP draft: >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. >> > > >> > >Please send questions, comments and requests for clarifications >> > >to the CCAMP list. >> > > >> > >Kireeti. >> > > >> > > >>=20 >>=20 > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 08:55:31 -0800 Message-ID: From: Jonathan Lang To: 'George Young' Cc: ccamp@ops.ietf.org Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Tue, 20 Nov 2001 08:48:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, Please see inline. Thanks, Jonathan > -----Original Message----- > From: George Young [mailto:george.young@meriton.com] > Sent: Tuesday, November 20, 2001 8:34 AM > To: Jonathan Lang > Cc: ccamp@ops.ietf.org > Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > Hello Jonathan, > > Comments/question below. Also please note, edgeFlow has > changed its name > to Meriton Networks Inc., and as a result the email address changes to > george.young@meriton.com. > > Regards, > George R. Young > Meriton Networks Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > > >-----Original Message----- > >From: Jonathan Lang [mailto:jplang@calient.net] > >Sent: Monday, November 19, 2001 5:21 PM > >To: 'S Ramesh'; George Young > >Cc: ccamp@ops.ietf.org; Jonathan Lang > >Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > > > >Ramesh, > > Please see inline. > > > >Thanks, > >Jonathan > > > >> -----Original Message----- > >> From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > >> Sent: Thursday, November 15, 2001 11:15 PM > >> To: George Young > >> Cc: ccamp@ops.ietf.org > >> Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > >> > >> > >> Hi Young, > >> > >> 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the > >> Data Link FSM's in the down state also. Agreed. > >I would actually propose that we remove the degraded state > >altogether from > >the data link fsms. This is already captured at the TE link level. > >Comments? > > If I understand your response to messrs Ramesh and moi, transition 10 > should be retained from Deg to Down. > If you then remove the Deg state, implying that in the Up/Alloc state > you may not have a control channel, where would transition 10 go? > > Transition 13 'fault localization' seems to need a control channel. > Without the Deg state, how would you represent the idea that sometimes > transition 13 can't take place? What I'm proposing is that we decouple the notion of a control channel with the data link FSMs. As Ramesh said in an email, some of these events can be generated through management interface also. For active data link, the FSM would be: +------+ | |<-------+ +--------->| Down | | | +----| |<-----+ | | | +------+ | | | |5b 3| ^ | | | | | |2,7 | | | | v | | | | | +------+ | | | | | |<-+ | | | | | Test | |11 | | | | | |--+ | | | | +------+ | | | | 5a| 3^ | | | | | | | | | | v | | | |2,12 | +---------+ | | | +-->| |14 | | | | Up/Free |----+ | +---------| | | +---------+ | 9| ^ | | | | v |10 | +---------+ | | |13 | |Up/Alloc |------+ | | +---------+ > > > > >> > >> 2. Transtition 10:evLnkDealloc can be possible know even in > >the degraded > >> state. Yeah a control channel is needed, but this event > can also be a > >> external event know, from the user or a network management > >event. If this > >> is possible then this event is required in this state. Kindly > >> clarify me. > >agreed. > > > >> > >> 3. Also event 14.evdcDown can also possible in Test/Pasv > >Test state. Since > >> to send a Test message or to receive a Test message we need a data > >channel. > >> If you see both the FSM's ( Data link ) event 3 & 4 will > >pose the next > >> state to Test & Pasv Test state from Up/Free state. So the event > >> 14.evdcDown is also possible on both the states and hence the > >> next state in both the case will be down. > >ok. > > > >> > >> Thanks, > >> Ramesh > >> > >> George Young wrote: > >> > >> > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > >> > draft-ietf-ccamp-lmp-02.txt: > >> > > >> > 1) It appears that in the Down state, the control channel > >> can be either > >> > up or > >> > down. That being the case, there should be transitions > for events 1 > >> > :evCCUp: > >> > and 2 :evCCDown: from Down to Down. > >> > > >> > 2) Transition 10:evLnkDealloc: from Deg to Down would > appear to be > >> > impossible, > >> > as there is no control channel available, and the control > >channel is > >> > required to coordinate taking the channel down at both > >> ends. I believe > >> > this > >> > transition should be removed. > >> > > >> > With these changes, the FSMs would look like: > >> > > >> > 12.3.3. Active Data Link FSM Description > >> > > >> > Figure 5 illustrates operation of the LMP active data > >> link FSM in a > >> > form of FSM state transition diagram. > >> > > >> > 1,2 > >> > +------+ > >> > | | > >> > | +------+ > >> > +-->| |<-------+ > >> > +--------->| Down | | > >> > | +----| |<-----+ | > >> > | | +------+ | | > >> > | |5b 3| ^ | | > >> > | | | |2,7 | | > >> > | | v | | | > >> > | | +------+ | | > >> > | | | |<-+ | | > >> > | | | Test | |11 | | > >> > | | | |--+ | | > >> > | | +------+ | | > >> > | | 5a| 3^ | | > >> > | | | | | | > >> > | | v | | | > >> > |2,12 | +---------+ | | > >> > | +-->| |14 | | > >> > | | Up/Free |----+ | > >> > +---------| | | > >> > +---------+ | > >> > 9| ^ | > >> > | | | > >> > v |10 | > >> > +-----+ 2 +---------+ | > >> > | |<--------| |13 | > >> > | Deg | |Up/Alloc |------+ > >> > | |-------->| | > >> > +-----+ 1 +---------+ > >> > > >> > Figure 5: Active LMP Data Link FSM > >> > > >> > 12.3.4. Passive Data Link FSM Description > >> > > >> > Figure 6 illustrates operation of the LMP passive data > >> link FSM in a > >> > form of FSM state transition diagram. > >> > > >> > 1,2 > >> > +------+ > >> > | | > >> > | +------+ > >> > +-->| |<------+ > >> > +---------->| Down | | > >> > | +-----| |<----+ | > >> > | | +------+ | | > >> > | |5b 4| ^ | | > >> > | | | |2,8 | | > >> > | | v | | | > >> > | | +----------+ | | > >> > | | | PasvTest | | | > >> > | | +----------+ | | > >> > | | 6| 4^ | | > >> > | | | | | | > >> > | | v | | | > >> > |2,12 | +---------+ | | > >> > | +--->| Up/Free |14 | | > >> > | | |---+ | > >> > +----------| | | > >> > +---------+ | > >> > 9| ^ | > >> > | | | > >> > v |10 | > >> > +-----+ +---------+ | > >> > | | 2 | |13 | > >> > | Deg |<--------|Up/Alloc |-----+ > >> > | |-------->| | > >> > +-----+ 1 +---------+ > >> > > >> > Figure 6: Passive LMP Data Link FSM > >> > > >> > Regards, > >> > George R. Young > >> > edgeflow Inc. > >> > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > >> > phone: +1 613-270-9279 Ext 287 > >> > fax: +1 613-270-9268 > >> > > >> > >-----Original Message----- > >> > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> > >Sent: Monday, November 12, 2001 9:00 PM > >> > >To: ccamp@ops.ietf.org > >> > >Subject: Two week Last Call on LMP > >> > > > >> > > > >> > >Hi All, > >> > > > >> > >This is to announce a two week Last Call on the LMP draft: > >> > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB > Wed Nov 28. > >> > > > >> > >Please send questions, comments and requests for clarifications > >> > >to the CCAMP list. > >> > > > >> > >Kireeti. > >> > > > >> > > > >> > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 07:57:02 -0800 Message-ID: <3BFA7D58.1070203@lucent.com> Date: Tue, 20 Nov 2001 10:57:12 -0500 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: Jonathan Lang CC: ccamp , tsg15q9@itu.int, t1x15@t1.org Subject: Re: Localizing Fault for Protection/Restoration Content-Type: multipart/alternative; boundary="------------020704050404030901000108" --------------020704050404030901000108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan, Please see comments inline. Thanks Carmine Jonathan Lang wrote: >Carmine, > Please see inline. > >Thanks, >Jonathan > >>-----Original Message----- >>From: Carmine Daloia [mailto:daloia@lucent.com] >>Sent: Monday, November 19, 2001 11:24 AM >>To: ccamp >>Cc: tsg15q9@itu.int; t1x15@t1.org >>Subject: LMP: Localizing Fault for Protection/Restoration >> >> >>Hi all, >> >>Another issue that is addressed in Section 6 "Fault Management" is the >>determination of whether a detected defect is due to a fault within a >>Protection/Restoration subnetwork or outside the subnetwork. The >>following text is included in Section 6.2, "As part of the fault >>localization, 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).... The >>upstream node should correlate the failure to see if the failure is also >>detected locally (including ingress side) for the corresponding LSP(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.... Once the failure has been localized, the signaling protocols >>can be used to initiate span or path protection/restoration >>procedures." >> >>I think we need to specify which protection/restoration architectures >>such a ChannelStatus message would be applicable. All I currently see >>are boxes and lines, yet we don't know at what layer the >>protection/restoration is being performed nor do we know what type of >>monitoring is supported (e.g., non-intrusive monitoring, tandem >>connection monitoring, etc.). I am not saying that such a mechanism >>would not be needed, however I think it is more fundamental to agree on >>the architectures first before we attempt to agree on one particular >>message that may be needed in some of the architectures. In fact the >>ChannelStatus message (if specified) should be included in those >>protection/restoration documents that specify architectures that would >>require such a message. Note that the ChannelStatus message is actually >>a message that is communicated between the end-points of a >>protection/restoration subnetwork. The end-points of a >>protection/restoration subnetwork could be adjacent cross-connects if >>span protection/restoration is supported or the end-points could be >>non-adjacent cross-connects if path protection/restoration is supported. >>Lumping this ChannelStatus message into LMP automatically forces the >>end-points to be adjacent cross-connects. >> >LMP is a "link management protocol" that is designed to manage links between >peers (this is particularly useful when the interface over which the >control messages are sent/received may not be the same interface over which >the data flows). As such, it is not clear to me why you are proposing to >run LMP end-to-end across multiple cross-connects. > My concern is that this ChannelStatus message is not really a part of the link management application but a part of the protection/restoration application. If protection/restoration was not provided why would such a message be needed in the upstream direction? When protection/restoration architectures are defined, I believe it is possible that some of these architectures will need a type of ChannelStatus message that is described in LMP, however the message will be needed between the edges of the protection/restoration domain (which I agree could very well be a single link if span protection/restoration is performed - but not always). Note that the protection/restoration edges may not always coincide with the LMP protocol edges and therefore the protection/restoration application would need to define its own "ChannelStatus" message anyway since it cannot be sure LMP will be running between the same points as the protection/restoration application. What are your thoughts? > > >>Also, the paragraph that I quoted above indicates that once the failure >>has been localized using the procedures described in LMP, the signaling >>protocols can be used to initiate span or path protection/restoration. >>Note that for path protection/restoration, the cross-connects themselves >>are included within the protection/restoration subnetwork and therefore >>path protection/restoration needs to restore connections when >>cross-connects themselves fail. I don't see how the mechanism described >>in LMP can be used when a cross-connect fails. Assume the network >>consists of four cross-connects. >> >> A------B------C >> | | >> +------D------+ >> >>Let's assume that cross-connect B fails. According to the mechanism >>described in LMP, Cross-connect C will send a ChannelStatus back to >>Cross-connect B, however because B has failed, B will not be able to >>process the ChannelStatus message. Therefore I don't see how >>LMP would >>apply to path protection/restoration. >> >Path protection/restoration can be initiated due to link or node failures. >The ChannelStatus message is used to isolate link failures. Node failures >can be detected by the loss of the control channels (possibly in conjunction >with the loss of data channels). This should be detected at both A and C. > >>Carmine >> >> --------------020704050404030901000108 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan,

Please see comments inline.

Thanks
Carmine

Jonathan Lang wrote:
Carmine,
  Please see inline.

Thanks,
Jonathan

-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 19, 2001 11:24 AM
To: ccamp
Cc: tsg15q9@itu.int; t1x15@t1.org
Subject: LMP: Localizing Fault for Protection/Restoration


Hi all,

Another issue that is addressed in Section 6 "Fault Management" is the 
determination of whether a detected defect is due to a fault within a 
Protection/Restoration subnetwork or outside the subnetwork. The 
following text is included in Section 6.2, "As part of the fault 
localization, 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 
t
ogether the notification of all of the failed data-links).... The 
upstream node should correlate the failure to see if the failure is also 
detected locally (including ingress side) for the corresponding LSP(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.... Once the failure has been localized, the signaling protocols 
can be used to initiate span or path protection/restoration 
procedures."

I think we need to specify which protection/restoration architectures 
such a ChannelStatus message would be applicable. All I currently see 
are boxes and lines, yet we don't know at what layer the 
protection/restoration is being performed nor do we know what type of 
monitoring is supported (e.g., non-intrusive monitoring, tandem 
connection monitoring, etc.). I am not saying that such a mechanism 
would not be needed, however I think it is
 more fundamental to agree on 
the architectures first before we attempt to agree on one particular 
message that may be needed in some of the architectures. In fact the 
ChannelStatus message (if specified) should be included in those 
protection/restoration documents that specify architectures that would 
require such a message. Note that the ChannelStatus message is actually 
a message that is communicated between the end-points of a 
protection/restoration subnetwork. The end-points of a 
protection/restoration subnetwork could be adjacent cross-connects if 
span protection/restoration is supported or the end-points could be 
non-adjacent cross-connects if path protection/restoration is supported. 
Lumping this ChannelStatus message into LMP automatically forces the 
end-points to be adjacent cross-connects.
LMP is a "link management protocol" that is designed to manage links between
peers  (this is particularly useful when the interface over which the
control messages are sent/received may not be the same interface over which
the data flows).  As such, it is not clear to me why you are proposing to
run LMP end-to-end across multiple cross-connects.
My concern is that this ChannelStatus message is not really a part of the link management application but a part of the protection/restoration application. If protection/restoration was not provided why would such a message be needed in the upstream direction?

When protection/restoration architectures are defined, I believe it is possible that some of these architectures will need a type of ChannelStatus message that is described in LMP, however the message will be needed between the edges of the protection/restoration domain (which I agree could very well be a single link if span protection/restoration is performed - but not always). Note that the protection/restoration edges may not always coincide with the LMP protocol edges and therefore the protection/restoration application would need to define its own "ChannelStatus" message anyway since it cannot be sure LMP will be running between the same points as the protection/restoration application.

What are your thoughts?


Also, the paragraph that I quoted above indicates that once the failure 
has been localized using the procedures described in LMP, the signaling 
protocols can be used to initiate span or path protection/restoration. 
Note that for path protection/restoration, the cross-connects themselves 
are included within the protection/restoration subnetwork and therefore 
path protection/restoration needs to restore connections when 
cross-connects themselves fail. I don't see how the mechanism described 
in LMP can be used when a cross-connect fails. Assume the network 
consists of four cross-connects.

       A------B------C
        |                      |
       +------D------+

Let's assume that cross-connect B fails. According to the mechanism 
described in LMP, Cross-connect C will send a ChannelStatus back to 
Cross-connect B, however because B has failed, B will not be able to 
process the ChannelStatus m
essage. Therefore I don't see how 
LMP would 
apply to path protection/restoration.
Path protection/restoration can be initiated due to link or node failures.
The ChannelStatus message is used to isolate link failures.  Node failures
can be detected by the loss of the control channels (possibly in conjunction
with the loss of data channels).  This should be detected at both A and C.

Carmine



--------------020704050404030901000108-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 07:55:36 -0800 Message-ID: <87009604743AD411B1F600508BA0F95971BC24@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: 'Eric Gray' , "Saha, Sayandeb" Cc: "'ccamp@ops.ietf.org'" Subject: RE: position of ADMIN_STATUS object in RESV message Date: Tue, 20 Nov 2001 10:51:29 -0500 MIME-Version: 1.0 Content-Type: text/plain Eric, I didn't quite understand what you meant here. Would you mind explaining this a little more. -Sayan -----Original Message----- From: Eric Gray [mailto:eric.gray@sandburst.com] Sent: Monday, November 19, 2001 10:41 AM To: Saha, Sayandeb Cc: 'ccamp@ops.ietf.org' Subject: Re: position of ADMIN_STATUS object in RESV message Sayan, I may be looking at this somewhat simply, but I know of no reason why a transit node would need to disable an SE LSP because one of the reservations sharing the LSP at that node sets its admin status to down. Even in the case where the D bit is set, this should have the effect of removing the transit node from the particular reservation being torn down, rather than tearing down all reservations sharing resources at that transit node. You wrote: > Hi, > Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the > admin_status as not being a > part of the in the RESV message. > This works fine for the FF style of reservation. > But for the SE style of reservation if just one filter is taken out by > setting the D bit in admin status, > all others must go down because the admin_status applies for the entire RESV > instead of just the particular > filter in question. > Or for that matter if only one filter's state(LSP) is taken administratively > down( by setting A bit), it will now apply to all filters > Is this intended? Or is it the optical world will never do SE style > reservations? Am I missing something here? > -Sayan -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 05:21:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BFA3062.A677E674@lucent.com> Cc: "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Date: Tue, 20 Nov 2001 11:28:50 +0100 From: Huub Van Helvoort To: "Mannie, Eric" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hello Eric, > >> Simple example: > >> > >> 1) you first signal an additional VC/SPE to the destination (via a Path). > > > >[hvh] I don't see any difference with LCAS. [hvh2] first you claim there is a difference > There is an enormous difference with LCAS: GMPLS does in addition the > signaling hop-by-hop. [hvh2] then you claim they are similar > We are arguing that GMPLS-LBM covers the functions of LCAS, so by definition > you can expect to have a similar behavior. [hvh2] I still see no difference between GMPLS-LCAS and GMPLS-LBM > >> 2) the destination knows exactly which VC/SPE is added (via the label). > > > >[hvh] isn't this already done in step 1) ? > > Yes, this is just to better explain (to emphasize something). [hvh2] or create more confusion > >> 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > >> so the VC/SPE is not yet added to concatenated signal. > > > >[hvh] G.806 clause 6.2.1.1: unequiped is an indication for loss of > > connectivity. This can also be monitored at intermediate points. > > If it should be interpreted as indicated, G.806 has to be changed > > as well as the installed base. > > I think that you are confusing the contexts. [hvh2] you propose a different functionality for the use of C2 LCAS uses spare bits in the Virtual concatenation overhead and does not affect existion functionalities. > >> 4) then, you wait at the source for a confirmation from the destination > >> (i.e. Resv). > > > >[hvh] here signals in the transport plane (C2) and control plane (Resv) > > are mixed, imho this is worse than having it fully in the control > > or ttransport plane. > > It is completely mixed with GMPLS if you use LCAS. Anyway, the confirmation > (Resv) is a normal operation of the control plane (please see RSVP). [hvh2] there is a clean separation: GMPLS takes care of the path setup through the network, LCAS manages the payload provided by the individual members to construct a contiguous signal. > > >> 5) the source "equip" the VC/SPE and sends. > > > >[hvh] I am missing the exact definition of when the first bit is sent. > > I am missing the exact definition of the bit that you are talking about :-). > More seriously, if you speak about the first user data bit, it is obviously > in the container of the VC having made the transition. > > >> 6) the destination sees in the POH that the VC is "equipped" > (transition). > > > >[hvh] where is the definition of the validation for this detection? > > Like in SDH, when the Signal Label changes its value to go from state A to > state B. [hvh2] this depeands on the validation process, see also the email from Grant Cyboron. > > >> The difference between LCAS and LBM is that LCAS uses an additional > explicit > >> indication in the overhead to say "this is the payload" to use. LBM > doesn't > >> change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > :-) > > > >[hvh] the explicit indication is required in order not to loose data > > (similar to pointer justification process). > > Like with GMPLS-LBM. Do you mean that C2 is not explicit. Tell us how and > when you loose data with a C2 transition ? [hvh2] see my previous comment > >> LCAS uses a new field in the POH (CTRL) to know when the new VC > transitions > >> to a significant payload. LBM proposes to do the same simply by looking > at > >> the C2 (for HOVC) transition - regular SDH/SONET field that will change > >> anyway and that is used to indicate the type of payload. > > > >[hvh] in regular SDH/SONET C2 is fixed > > Not at all... It can change from unequipped to non unequipped, it can change > to VC-AIS, etc. You can use a test signal and then change to an ATM payload, > etc... [hvh2] the values you mention are not coming from the same source (VC-AIS is not even sent on purpose but is indirectly caused by another defect) these values are used for fault localisation > >> To be more precise about LCAS (I copy from the LCAS specification, > section > >> 6.3.1): "The first container frame to contain payload data for the new > >> member shall be the container frame immediately following the container > >> frame that contained the last bit(s) (i.e. the CRC) of the control packet > >> with NORM/EOS message for that member" (the LCAS control packet). > >> > >> So, LCAS waits for the last bit of the appropriate LCAS control packet in > >> the POH with the appropriate transition of its CTRL field. LBM waits > simply > >> for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > >> (don't change SDH/SONET). > > > >[hvh] 6.3.1 describes the insertion after validation, LBM needs also to > > describe the validation process for C2 and the exact insertion. > > Yes, this is draft zero (at the IETF it means the first version that you put > on paper). [hvh2] should remarks on a draft zero be different from remarks on a draft one? if yes, please tell me what kind of remarks you did expect for draft zero > > Thanks for your help, You're welcome. Cheers, Huub -- ------------------------------------------------------------------------ | Huub van Helvoort | Lucent Technologies | PO Box 18 | | TEL: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen | | FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands | ------------------------------------------------------------------------ Always remember that you are unique... Just like everyone else. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 03:41:44 -0800 Message-ID: <00df01c170ee$0e47d300$8a217283@meta.cpr.it> From: "Nicola Ciulli" To: Subject: relationship between adjacency and link Date: Mon, 19 Nov 2001 12:33:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I would like to have some clarification about the relationship between adjacency and link (link = either interface or link bundle or link component, I think this does not matter in this discussion). I see 3 alternatives in the Adjacency->link relationship: 1:1, N:1, 1:N. As far as I understood, OSPFv2 and OSPFv3 explicitly support 1:1 and N:1. Also, draft-ietf-mpls-lsp-hierarchy-02.txt seems to support a 1:1 relationship, since it suggests to aggregate various links into a single link bundle before building an adjacency on them: "If there are multiple LSPs that all originate on one LSR and all terminate on another LSR, then at one end of the spectrum all these LSPs could be merged (under control of the head-end LSR) into a single forwarding adjacency using the concept of Link Bundling (see [BUNDLE]), while at the other end of the spectrum each such LSP could be advertised as its own adjacency." So, is there any support for an 1:N relationship? thanks for any advice. Nicola Ciulli. ____________________________________________________________________ | | | Nicola Ciulli Consorzio Pisa Ricerche | | Centro META | | corso Italia, 116 | | Phone: +39-050-915854 56125 Pisa, Italy | | Alt. phone: +39-050-2206820 Phone: +39-050-915811 | | Fax: +39-050-915823 | | e-mail: n.ciulli@cpr.it | |____________________________________________________________________| Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 00:34:56 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , ccamp@ops.ietf.org Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format Date: Tue, 20 Nov 2001 09:26:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Manjo, indeed the STM-0 case is not covered in the current definition. This is one of the reasons for my proposed changes to the label definition I did sent out as a last call comment. SONET and SDH have similar structures and using different {SUKLM} numbering schemes results in confusion and problems like this that something is missing for one hierarchy. I haven't seen a final decision concerning the {SUKLM} scheme so I have attached my proposal again. Juergen The format of the label for SDH and/or SONET TDM-LSR link is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same signaling scheme is used in order to provide easy interworking between SDH and SONET signaling. For the S field a STS-3 group, which corresponds with the SDH AUG-1 level is introduce. The U field indicates the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. When hierarchical SDH/SONET LSPs are used, an LSP with a given bandwidth can be used to tunnel lower order LSPs. The higher order SDH/SONET LSP behaves as a virtual link with a given bandwidth (e.g. VC-3), it may also be used as a Forwarding Adjacency. A lower order SDH/SONET LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is non-significant and is set to zero. For instance, a VC-3 LSP can be advertised as a forwarding adjacency. In that case the labels allocated between the two ends of that LSP (i.e. for that "link") will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3. 1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a AUG-1/STS-3 group or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4 indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 group. 3. K is only significant for VC-4/STS-3c and must be ignored for higher order VC-3/STS-1-SPE. For SDH it indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further subdivided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. For a SONET STS-3c-SPE it is fixed to K=1 as SONET doesn't support substructured STS-3c-SPE. 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4/STS-3c-SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 5. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, STS-3c-SPE, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further subdivided and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 SPE inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE inside the corresponding TUG-2/VT Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 1st VT-1.5 8 2nd VC-11 2nd VT-1.5 9 3rd VC-11 3rd VT-1.5 10 4th VC-11 4th VT-1.5 In case of contiguous concatenation, the label that is used is the lowest label of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant. For instance, when requesting an VC-4-16c the label is S>0, U=0, K=0, L=0, M=0. Examples of labels: Example 1: S>0, U=1, K=1, L=0, M=0 Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. Example 2: S>0, U=1, K>1, L=1, M=0 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Example 3: S>0, U>1, K=0, L=1, M=0 Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 4: S>0, U>1, K=0, L>1, M=1 Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 5: S>0, U>1, K=0, L>1, M=9 Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 6: S>0, U=1, K>1, L>1, M=5 Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of the Sth AUG-1. > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Tuesday, November 20, 2001 1:49 AM > To: ccamp@ops.ietf.org > Subject: Representation of VC-3 in STM-0 in {SUKLM} format > > > Hi All, > If I have to allocate VC-3 on a STM-0 link then how to > represent it in {SUKLM}? As per gmpls-sdh-sonet draft, S is the index > of particular AUG-1 and can take values from 1 -> N. but there is no > AUG-1 in STM-0. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Nov 2001 00:17:00 -0800 Message-ID: From: Heiles Juergen To: "'manoj juneja'" , ccamp@ops.ietf.org Subject: RE: Doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt Date: Tue, 20 Nov 2001 09:08:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Manoj, see my comments below. Juergen > -----Original Message----- > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] > Sent: Monday, November 19, 2001 7:22 PM > To: ccamp@ops.ietf.org > Subject: Doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > > Hi All, > I have a doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt (page > 19, Annex 1, example # 4 and # 5). > > The 4th example mentions request for STM-16 with multiplex section > layer transparency is formed by the application of RCC with value 0, > NCC with value 0, NVC with value 0, MT with value 1, T with flag 2 to > an STM-16 elementry signal. > > Does the SDH standard support the above request ? If yes, then what > will be the label value if such a signal is requested from say STM-64 > or STM-256 link ? > The label request specifies only what kind of signal to setup, not how this signal is transported through the network. For sure the signal has to be transported transparently through the network. For this special case the interface of e.g. a router itself is the STM-16 interface and the request is to transport this STM-16 interface signal with MS layer transparency through your network. Only the RSOH can be modified. According to SDH standards this can be done by using only SDH regenerator functionality at intermediate network nodes. for example you can transport this STM-16 over a WDM system that has SDH regenerator functionality at the transponders. The transport over a STM-64 or STM-256 signal is not possible as it is not transparent for the MSOH. > The 5th example is regarding the request for STM-4c signal. > It mentions > that STM-4c signal (i.e. VC-4-4c with TOH) with multiplex > section layer > transparency is formed by the application of RCC with flag 1, NCC with > value 1, NVC with value 0, MT with value 1 and T with flag 2 > applied to > an STM-4. > This is a useless combination in my view as it is a subset of the above request. As your LSP has to be transparent for the MSOH you cannot transport it via STM-16/64/256. You can transport it over SDH regenerator equipment, but in this case it doesn't matter if the payload is VC-4-4c or 4xVC-4 or 12xVC-3. > Does the SDH standard support the above request ? If yes, then what > will be the label value if such a signal is requested from say STM-64 > or STM-256 link ? What will be the difference in {SUKLM} if > VC-4-4c had > been requested instead of STM-4c ? As you request a full STM-N interface signal in both cases I assume that you don't need a the {SUKLM}, you only need the port/interface ID. However I am not sure about this. > > Please comment. > > Regards, > manoj. > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 23:54:59 -0800 To: ccamp , "t1x1.5" , q11/15 Message-ID: <3BFA0C0F.CF38DD1E@lucent.com> Date: Tue, 20 Nov 2001 08:53:51 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: ccamp , "t1x1.5" , q11/15 Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Let me describe briefly the interactions in the transport plane that cause the traffic interruption when LCAS is not used. You get a traffic interruption if the sink doesn't know exactly at which point in the bitstream it has to start reading from the additional connection, or stop reading from the to be removed connection. A path termination/adaptation source function generates a fixed signal label. When you set up a connection via GMPLS you first reserve the matrix connections in the fabrics between source and sink path terminations in both directions (Resv A => Z). Then in the Resv return direction (Z => A), the matrix connections are committed (i.e. established). This implies that the at the Z-endpoint the path source is connected to the connection and when the last matrix connection is established, the path sink at A-endpoint receives a signal with an equipped-specific signal label. Note that the last fabric may be located in another equipment than the path endpoint. At the moment the last matrix connection is closed (in both directions), also the Z-end will receive a signal with eq-spec signal label. It then takes about 3 frames to detect the new pointer value (which is different). Once found, it then takes 0..2 frames to remove AIS insertion. Once removed, it then takes 3..10 (typically 5) frames to clear the dUNEQ defect, another 0..2 frames to remove AIS insertion, then some time to align to the multiframe and get the delay compensating buffer adjusted correctly. If there are any bits inserted by the source during this period, you are loosing bits. If the source is not transmitting bits over this connection during this period, the sink may start reading from the connection before the source is inserting bits. Again the transmission of the client signal is interrupted. If you intent to change the equipment and SDH standards (sometimes this implies a SW modification, sometimes it will be a HW modification) and force C2 in the path termination source to 0x00 until the connection is setup, you can not verify if the connection is setup while the path sink is still in signal fail condition (dUNEQ is detected). If the hardware let you read the received TTI, you may go around this verification phase issue. But when you insert at the source client bits into the additional connection at the time you change the 0x00 value in C2 to the eq-spec value, you will still have the sink at the other end detecting dUNEQ (takes 3..10 frames to clear), inserting AIS (takes 0..2 frames to stop), and have its delay compensating buffer being in a kind of free run out of service state until the AIS insertion is stopped. After that moment, the process needs to frame align, detect the phase difference, adjusts its buffer and then it is ready to support transmission. LCAS is designed under the knowledge that the connection is up and running, the buffer process is fully aligned and when it is told at which time (i.e. bit position) the bits should be read from the additional connection it will be able to do so without loosing a single bit. Hope this explains things a bit more. Regards, Maarten "Mannie, Eric" wrote: > > Hello Maarten, > > The fundamental question is still pending, why do we have a glitch with LBM > and not with LCAS, please could you explain. > > Thanks, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, November 19, 2001 3:10 PM > To: Mannie, Eric > Cc: 'Zhi-Wei Lin'; Dimitri Papadimitriou > Subject: Re: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Eric, > > "Mannie, Eric" wrote: > > > > Hello Maarten, > > > > > Turn this question around... why should we have a transport network for > > which we > > refuse to use some parts while the control plane implementation doesn't > > support > > it... > > > > (what is the "it" in the sentence ?) > > "it" refers to functionality in the transport plane not supported by control > plane based connection establishment. > > > > > Using the signal label transition cannot we expect less glitch than with > > LCAS ? > > With LCAS there is no glitch at all. Anything else will result in a glitch > of > most likely a few seconds. > > > > > I would like to add a section on GMPLS and LCAS interworking in the draft. > > Originally, this is what we intended to do with Dimitri. > > I do not like to call it interworking... GMPLS must be able to turn the > final > control over to LCAS when the user has requested hitless increase/decrease. > See > the in my reply to Dimitri on Friday at 17:29. > > > > > Anyway, it is better to give the possibility to each manufacturer to do > > GMPLS LBM alone or GMPLS LBM with LCAS. > > > > > In my understanding, the control plane is an additional means to manage > > connections in the transport network (i.e. in addition to the existing > means > > via > > network management). It should as such not introduce restrictions into the > > transport network... i.e. this alternative should add capabilities, not > take > > existing capabilities out... > > > > GMPLS LBM doesn't remove capabilities, but integrate these capabilities > :-) > > You know that I am not the type of guy that want to remove capabilities, > but > > rather I am the opposite :-) > > In this case you did remove the hitless capability that comes with LCAS... > As we > are in a new week lets forget that you did propose this... :-) > > > > > Would you (and Lucent) survive if we add a section about GMPLS and LCAS > > interworking to the draft, saying for instance that depending on the > > strategic implementation choices, one manufacturer could decide to do one > or > > the other solution, or something like that ? > > Lets not do this with this wording... the document needs a section > describing > the GMPLS scenarios with and without LCAS being present in the transport > plane, > and with and without the endpoints being within the network. > > Regards, > > Maarten > > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, November 19, 2001 11:58 AM > > To: Mannie, Eric > > Cc: 'Zhi-Wei Lin'; Dimitri Papadimitriou > > Subject: Re: [T1X1.5] Re: LCAS and > > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Eric, > > > > > Why should we have a general signaling protocol (GMPLS) for which we > > refuse > > > to use some parts. When GMPLS is used, I don't see the interest of using > > > another protocol to do a part of what GMPLS is doing. Moreover, this > > causes > > > interworking issues with GMPLS. > > > > Turn this question around... why should we have a transport network for > > which we > > refuse to use some parts while the control plane implementation doesn't > > support > > it... > > > > In my understanding, the control plane is an additional means to manage > > connections in the transport network (i.e. in addition to the existing > means > > via > > network management). It should as such not introduce restrictions into the > > transport network... i.e. this alternative should add capabilities, not > take > > existing capabilities out... > > If there would ever be an interworking issue (after introduction of a > > control > > plane) between transport plane and control plane, the control plane will > be > > adapted to remove the mistake inside of it. > > > > As indicated in one of my emails on Friday, ASON/GMPLS will have to > support > > connection bandwidth modification between virtual concatenated endpoints > > which > > do not support LCAS and which do support LCAS. ASON/GMPLS in a network > with > > virt > > conc endpoints supporting LCAS will be less constrained than in a network > > without LCAS support. > > > > Regards, > > > > Maarten > > > > "Mannie, Eric" wrote: > > > > > > Hi Zhi, > > > > > > Yes, and when LCAS is triggered it exchanges control message with the > > remote > > > end to synchronize with the addition/removal of VC(s)/SPE(s). This is > > > signaling between the two ends. > > > > > > In the same way, GMPLS can be triggered by whatever wants the GMPLS LBM > > > capability (algorithm, even a NMS, etc). In addition to the LCAS > > > functionality, GMPLS will do the provisioning at each hop, etc. > > > > > > LCAS is a protocol (it is defined like that by the ITU-T/T1X1 see the > > text). > > > This protocol is also generic (it works for both G.709 and SDH/SONET > like > > > GMPLS). But LCAS is restricted to a very specific functionality only. > This > > > very specific functionality is just a part of GMPLS. > > > > > > Why should we have a general signaling protocol (GMPLS) for which we > > refuse > > > to use some parts. When GMPLS is used, I don't see the interest of using > > > another protocol to do a part of what GMPLS is doing. Moreover, this > > causes > > > interworking issues with GMPLS. > > > > > > Kind regards, > > > > > > Eric Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 22:50:54 -0800 Message-ID: <3BF9FDC2.D1CE82F@npd.hcltech.com> Date: Tue, 20 Nov 2001 12:22:50 +0530 From: Rajaraman B Organization: Hcl Technologies Limited MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Identifying RSVP (rfc-2205) and RSVP-TE while implementing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am trying to implement RSVP-TE by extending the free source code distributed by ISI. In the same router, is it necessary to run the RSVP(for QOS purpose-rfc-2205) and RSVP-TE?. if yes, how to identify RSVP packets whether it belongs to RSVP or RSVP-TE. Both use the same meesage type. But there is a difference in object format (like session, sender template...) Please clarify. Thanks in advance, Rajaraman. B Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 17:08:32 -0800 Message-ID: <36EF020032CFD411B7B400508B55E59019EFBA@milan.turinnetworks.com> From: Steve West To: "'Mannie, Eric'" , 'Dimitri Papadimitriou' , Steve West Cc: 'Stephen Trowbridge' , 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 17:02:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Eric: Thanks for your reply. Please see my comments below. Kind regards, Steve > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Monday, November 19, 2001 2:28 AM > To: 'Dimitri Papadimitriou'; Steve West > Cc: 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; q11/15; t1x1.5 > Subject: RE: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Hello Steve, > > Just to complement the answer of Dimitri, > > > You believe that the packet loss rate and robustness of LMB is > > similar to LCAS ? > > LCAS waits for the end of control packet which is > multi-framed to decide > when the payload is significant (the "transition"). LBM > uses for instance > the C2 byte for the HOVC, since this byte appears directly > in the POH and is > not part of a control packet, that should go faster, right > ? I.e. less > glitch than with LCAS ? To avoid data corruption, the two ends of the link must agree precisely when payload data is added/deleted. This unavoidably requires hardware level synchronization. Delay does not necessarily imply data corruption. Consider for example the case where the Virtual Concatenated bandwidth capacity is being added before turning up the new services. Note also that centralized service management with parallel provisioning of all nodes on the path and end-to-end coordination through LCAS H4 may actually have lower delay than hop-by-hop coordination through RSVP-TE/GMPLS. > > But having a field in the transport plane to indicate a > transition (whatever > is the field ) is not the most important issue. Even if > you have that field, > you need some time to provision the additional VCs/SPEs in > the network. This > is not done by LCAS, and any control plane or management > plane will imply > some time for that operation, and the glitch will really > come from that > process, not from the way that you detect a transition in > the transport > plane. To support true hitless transitions in the transport plane does require bit-accurate coordination by the mapper hardware at the two ends. > > > 4. LBM is an extension to GMPLS. GMPLS is required for > LBM, whereas LCAS > > could potentially be used with GMPLS or with other > control plane or > > management plane mechanisms ? > > When a distributed control plane is used (e.g. GMPLS or > PNNI), using LCAS > implies issues on this control plane. LCAS is a > stand-alone solution that > bypass the control plane to change the resource > reservation in both end > systems. A control plane maintains states in end systems > (e.g. at the UNI) > and in intermediate systems ! So, bandwidth modifications > must be reflected > in the control plane otherwise it will become inconsistent. > > Now, the control plane is natively designed to deal with > these resource > reservations including in the source and the destination > (with the UNI). > Moreover, GMPLS is natively designed to deal with > bandwidth modification (in > the packet world this was one of the major requirements). > Originally, we > just wanted to describe how to generalize these bandwidth > modification > principles to SDH/SONET and how to interwork with LCAS. > Agreed. Some management or signaling mechanism will be required to setup cross connects at every node the path traverses. However this is independent of the need to synchronize the payload mappers. > Then, we saw that a large part of LCAS was overlapping > with GMPLS, i.e. all > the protocol part. The rest was the issue about when to > decide that a VC/SPE > contains real user data or not (the transition). > The LCAS state machines are a small subset of what is required to support the end to end connection. > Since LCAS added a control message, naturally it used a > field in that > control message to indicate that transition. But with > GMPLS we didn't need > any new control message, se we looked at what was available *in the > transport plane* to detect the fact that a VC/SPE contains > now real user > data (i.e the transition). We found natural to use the > so-called SDH/SONET > "signal label" (e.g. the C2 byte) (note for the readers: > nothing to do with > the GMPLS label :-). So we added these aspects to the > draft. This is the > part that we expected to validate with the ITU-T/T1X1 > folks, but flames came > first... > IMHO H4 is a better choice because it is already used to carry the Virtual concatenation Sequence number, and member additions / deletions require informing the mapper which sequence numbers are valid. > What we are certainly going to do, is to add in the draft > a section about > how GMPLS should work when LCAS is used at the same time. Great! > However, we think > that using GMPLS and LCAS at the same time will be more > complex than simply > using GMPLS and will not bring something additional. So the natural > observation came, "why should we use LCAS with GMPLS and > build something > more complex when there is almost no issue to solve when > simply using GMPLS > alone". Using GMPLS and LCAS at the same time to modify > the bandwidth > implies that we will have two signaling flows between the > source and the > destination running in parallel and overlapping. GMPLS > will also speak with > the source and the destination to do the same as LCAS, and with a > distributed control plane you need GMPLS anyway (or PNNI or etc). > > We also added a section to explain how several GMPLS LSPs > (i.e. circuits) > can be combined together to form a larger virtually > concatenated circuit. > This allows to deal with the non co-routing of VCs/SPEs with GMPLS. I agree that this is valuable. Also, in some applications (e.g. Internet ISP backbones), absolutely hitless operation may not be necessary, so your make-before-break proposal would work. But for traffic engineered virtual private line services with strict SLAs, absolutely hitless operation is necessary. And LCAS is well designed for this purpose. > > Kind regards, > > Eric > > -----Original Message----- > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Sunday, November 18, 2001 3:44 PM > To: Steve West > Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; > q11/15; t1x1.5 > Subject: Re: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Hi Steve, > > Thanks for your comments, see in-line... > > Steve West wrote: > > > > Dimitri: > > > > Please confirm my understanding of your proposal: > > > > 1. Your proposal supports hitless link capacity > adjustment. (Capacity > > changes that occurs during transmission of a packet will > not corrupt that > > packet.) You believe that the packet loss rate and > robustness of LMB is > > similar to LCAS ? > > It is mentioned in the proposal that the source waits for a > confirmation from the destination (i.e. Resv Message). THEN > the source "equip" the VC/SPE and sends. After the destination > sees in the POH that the VC is "equipped" (transition). > > So instead of using the transitions proposed in LCAS (based > on the H4 CTRL words) we use the ones already available. > > Since we are the beginning, we were very cautious but we expect to > reach more than reasonable robustness and reliability. > > > 2. LMB requires hardware coordination between the SONET > payload mapper > and > > the SONET POH processor (C2 octet insertion/extraction logic) ? > > At the transport plane level C2 is the field that LBM uses for the > transition in the HOVC POH. > > > 3. The hardware based synchronization performance > requirements are > similar > > to those required by LCAS. Except that LCAS coordinates > the critical > > transitions using H4 instead of C2 ? And that Virtual > Concatenation > systems > > require to coordinate their payload mappers with bits > 1-4 of the H4 byte > to > > determine the sequence number anyway ? > > See above, yes and yes (since we re-use existing VC mechanisms) > > > 4. LBM is an extension to GMPLS. GMPLS is required for > LBM, whereas LCAS > > could potentially be used with GMPLS or with other > control plane or > > management plane mechanisms ? > > The scope of this proposal is to use GMPLS-LBM without > LCAS. In fact > (from what i understand in your question) see it more from > transport > to control plane impact taking the assumption that you expect some > hardware improvement. Let's first determine if this can be > achieved > and then discuss the implementation issues that can arise > from this > proposal. In a sense, GMPLS-LBM is a self-consistent solution. > > Regards, > - dimitri. > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: Dimitri Papadimitriou > [mailto:dimitri.papadimitriou@alcatel.be] > > Sent: Friday, November 16, 2001 4:09 PM > > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > > Cc: ccamp; q11/15; t1x1.5 > > Subject: [T1X1.5] Re: LCAS and > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Hi folks, > > > > What happens... when we start the technical discussion > > all guys taking part to the previous one now are gone ? > > > > We would like to start a technical discussion.. rather > > difficult if we stay alone... or everybody agree on > > proposal made in the previous e-mail ? (this in order > > to refine the mechanism detailed in the GMPLS LBM I-D.) > > > > Any technical feedback is highly appreciated. > > > > Cheers, > > - dimitri. > > > > "Mannie, Eric" wrote: > > > > > > Hello Stephen > > > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > > > No, please see explanations below. > > > > > > > If you use LBM and change the mappings at the two > ends without some > > > coordination such as LCAS, you will have a glitch to > the traffic > > > (I think this is simple enough). > > > > > > No, please see below (C2 or V5 transition). > > > > > > >The compare/contrast discussion of LBM and LCAS is > appropriate not > > > >because LCAS is "sacred", but because you are > comparing apples to > > > >oranges. Statements in this document such as "One > drawback of LCAS is > .." > > > >are unnecessary and inappropriate in this context, > since LBM does > > > >NOT solve the problem LCAS was designed to solve. > Perhaps if you > > > >were solving the SAME problem better, this would be > OK, but this > > > >is not the case. > > > > > > No, please see below. > > > > > > Simple example: > > > > > > 1) you first signal an additional VC/SPE to the > destination (via a > Path). > > > 2) the destination knows exactly which VC/SPE is added > (via the label). > > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > > so the VC/SPE is not yet added to concatenated signal. > > > 4) then, you wait at the source for a confirmation > from the destination > > > (i.e. Resv). > > > 5) the source "equip" the VC/SPE and sends. > > > 6) the destination sees in the POH that the VC is "equipped" > (transition). > > > > > > The difference between LCAS and LBM is that LCAS uses > an additional > > explicit > > > indication in the overhead to say "this is the > payload" to use. LBM > > doesn't > > > change the SDH/SONET overhead, while LCAS changes the > SDH/SONET overhead > > :-) > > > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > > transitions > > > to a significant payload. LBM proposes to do the same > simply by looking > at > > > the C2 (for HOVC) transition - regular SDH/SONET field > that will change > > > anyway and that is used to indicate the type of payload. > > > > > > To be more precise about LCAS (I copy from the LCAS > specification, > section > > > 6.3.1): "The first container frame to contain payload > data for the new > > > member shall be the container frame immediately > following the container > > > frame that contained the last bit(s) (i.e. the CRC) of > the control > packet > > > with NORM/EOS message for that member" (the LCAS > control packet). > > > > > > So, LCAS waits for the last bit of the appropriate > LCAS control packet > in > > > the POH with the appropriate transition of its CTRL > field. LBM waits > > simply > > > for the appropriate C2 (for HOVC) or V5 (for LOVC) > transition in the POH > > > (don't change SDH/SONET). > > > > > > By the way, this is version 0 of the draft and it was > just posted. > > > > > > Suggestions, technical comments and improvements are welcome. > > > > > > I would appreciate if people could first read and > speak before shooting > > > directly :-) > > > > > > Kind regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > > Sent: Friday, November 16, 2001 7:49 PM > > > To: Mannie, Eric > > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri > Papadimitriou > > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Eric, > > > The point of my earlier email (items again below, this > time with > > > numbers) was not to prompt the comment "#3 is out of > scope, therefore > > > it is a choice between #1 and #2" (my parsing of > recent statements). > > > > > > The issue (and I think the reason for Maarten's strong > reaction) is > this: > > > GMPLS-LBM and LCAS are NOT different solutions to the > same problem. > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > (I hope this is not too subtle for non-native English > speakers). > > > > > > LCAS is a method to hitlessly change the mappings at the two > > > ends of a virtually concatenated trail to increase or > decrease the > > > bandwidth. It does not say anything about how components to be > > > added or removed from the virtually concatenated "bundle" are > > > set up or taken down. > > > > > > LBM talks about how to set up or take down those added > or removed > > > components, but not about the details of changing the > mapping (other > > > than that it is done after the new components are successfully > > > established. > > > > > > If you use LBM and change the mappings at the two ends > without some > > > coordination such as LCAS, you will have a glitch to > the traffic > > > (I think this is simple enough). > > > > > > The compare/contrast discussion of LBM and LCAS is > appropriate not > > > because LCAS is "sacred", but because you are > comparing apples to > > > oranges. Statements in this document such as "One > drawback of LCAS is > .." > > > are unnecessary and inappropriate in this context, > since LBM does > > > NOT solve the problem LCAS was designed to solve. > Perhaps if you > > > were solving the SAME problem better, this would be > OK, but this > > > is not the case. > > > > > > Time to try to be constructive: > > > - I think most of the current discussion of LCAS > should be removed from > > > this document. It is irrelevant since LCAS solves a > different problem > than > > > LBM. To say that one is "better" than the other would > only be meaningful > > > if they were solving the same problem (can you really > say that LBM > solves > > > problem A better than LCAS solves problem B?). > > > - LCAS can be a good informative reference as a way to > hitlessly modify > > > the size of a virtually concatenated trail. > > > - Clarify in the scope that the current draft > describes the use of LBM > > > without LCAS, which results in a traffic glitch when > bandwidth is > > modified. > > > Indicate that the use of LCAS to hitlessly negotiate > the changes to > > > the size of virtually concatenated pipes after LBM sets up new > > component(s) > > > or before LBM takes down old component(s) is a topic > for further study > > > and perhaps to be addressed in a future version of the draft. > > > > > > Regards, > > > Steve > > > > > > Steve Trowbridge wrote: > > > > 1. Can you use LBM without LCAS? Yes, if you don't > mind a glitch to > > > > the traffic. > > > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't > care whether the > > > > control plane knows that the different LSPs are part > of the same > > > > circuit. > > > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and > this would seem to > > > > be the preferred method for many applications. > > > > > > "Mannie, Eric" wrote: > > > > > > > > Hello Maarten, > > > > > > > > >Any sentence in which LCAS and ASON/GMPLS are > compared shows a lack > of > > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > > > Sorry, do you mean that it is forbidden to speak > about your LCAS > > document > > > > and to compare GMPLS and LCAS functionalities ? > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 17:08:23 -0800 Message-ID: <36EF020032CFD411B7B400508B55E59019EFBB@milan.turinnetworks.com> From: Steve West To: 'Dimitri Papadimitriou' Cc: "Mannie, Eric" , 'Stephen Trowbridge' , 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 17:02:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri: Thank you for your clarification. These are my observations: 1. Truelly hitless capacity adjustment requires bit-interval accurate indication to the payload mapper as to when to begin/stop inserting/extracting payload to/from a VC group member. 2. Both LBM and LCAS propose that this indication be provided by information in the member Path Overhead. 3. In HOVC virtual concatenation systems, H4 is already used by the payload mappers on the two ends of the link to coordinate sequence numbers. Coordinating and synchronizing member additions and deletions involves in part, control of these sequence numbers. Extending H4 to control member additions and deletions is therefore consistent with the sequence number function of the H4 octet. 4. On the other-hand C2 is already used to provide payload type information. Extending the application of C2 is complicated by the established (formal and de-facto) practise for its use. 5. The state machine/protocol specifications for LCAS, also supports resilient management of the virtual concatenated group. H4 functionality extensions support sequence number reassignment through member exclusions and inclusions required to respond to member path failure and recovery. LCAS requirements can and will be economically implemented as state-machine hardware additions to the Virtual Concatenation Packet Mapper. 6. LCAS may be considered an extension to virtual concatenation. It potentially supports provisioning/signaling by a number of alternative management plane / control plane architectures (potentially including GMPLS). I would suggest that GMPLS-LBM spec be revised to support and take full advantage of the benefits of LCAS. It would be a shame to spoil the GMPLS/LBM proposal by leaving such an important capability out. Kind Regards, Steve -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Sunday, November 18, 2001 6:44 AM To: Steve West Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; q11/15; t1x1.5 Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hi Steve, Thanks for your comments, see in-line... Steve West wrote: > > Dimitri: > > Please confirm my understanding of your proposal: > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > changes that occurs during transmission of a packet will not corrupt that > packet.) You believe that the packet loss rate and robustness of LMB is > similar to LCAS ? It is mentioned in the proposal that the source waits for a confirmation from the destination (i.e. Resv Message). THEN the source "equip" the VC/SPE and sends. After the destination sees in the POH that the VC is "equipped" (transition). So instead of using the transitions proposed in LCAS (based on the H4 CTRL words) we use the ones already available. Since we are the beginning, we were very cautious but we expect to reach more than reasonable robustness and reliability. > 2. LMB requires hardware coordination between the SONET payload mapper and > the SONET POH processor (C2 octet insertion/extraction logic) ? At the transport plane level C2 is the field that LBM uses for the transition in the HOVC POH. > 3. The hardware based synchronization performance requirements are similar > to those required by LCAS. Except that LCAS coordinates the critical > transitions using H4 instead of C2 ? And that Virtual Concatenation systems > require to coordinate their payload mappers with bits 1-4 of the H4 byte to > determine the sequence number anyway ? See above, yes and yes (since we re-use existing VC mechanisms) > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > could potentially be used with GMPLS or with other control plane or > management plane mechanisms ? The scope of this proposal is to use GMPLS-LBM without LCAS. In fact (from what i understand in your question) see it more from transport to control plane impact taking the assumption that you expect some hardware improvement. Let's first determine if this can be achieved and then discuss the implementation issues that can arise from this proposal. In a sense, GMPLS-LBM is a self-consistent solution. Regards, - dimitri. > Thanks, > > Steve > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Friday, November 16, 2001 4:09 PM > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > Cc: ccamp; q11/15; t1x1.5 > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Hi folks, > > What happens... when we start the technical discussion > all guys taking part to the previous one now are gone ? > > We would like to start a technical discussion.. rather > difficult if we stay alone... or everybody agree on > proposal made in the previous e-mail ? (this in order > to refine the mechanism detailed in the GMPLS LBM I-D.) > > Any technical feedback is highly appreciated. > > Cheers, > - dimitri. > > "Mannie, Eric" wrote: > > > > Hello Stephen > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > No, please see explanations below. > > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > No, please see below (C2 or V5 transition). > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > >because LCAS is "sacred", but because you are comparing apples to > > >oranges. Statements in this document such as "One drawback of LCAS is .." > > >are unnecessary and inappropriate in this context, since LBM does > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > >were solving the SAME problem better, this would be OK, but this > > >is not the case. > > > > No, please see below. > > > > Simple example: > > > > 1) you first signal an additional VC/SPE to the destination (via a Path). > > 2) the destination knows exactly which VC/SPE is added (via the label). > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > so the VC/SPE is not yet added to concatenated signal. > > 4) then, you wait at the source for a confirmation from the destination > > (i.e. Resv). > > 5) the source "equip" the VC/SPE and sends. > > 6) the destination sees in the POH that the VC is "equipped" (transition). > > > > The difference between LCAS and LBM is that LCAS uses an additional > explicit > > indication in the overhead to say "this is the payload" to use. LBM > doesn't > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > :-) > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > transitions > > to a significant payload. LBM proposes to do the same simply by looking at > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > anyway and that is used to indicate the type of payload. > > > > To be more precise about LCAS (I copy from the LCAS specification, section > > 6.3.1): "The first container frame to contain payload data for the new > > member shall be the container frame immediately following the container > > frame that contained the last bit(s) (i.e. the CRC) of the control packet > > with NORM/EOS message for that member" (the LCAS control packet). > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > > the POH with the appropriate transition of its CTRL field. LBM waits > simply > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > (don't change SDH/SONET). > > > > By the way, this is version 0 of the draft and it was just posted. > > > > Suggestions, technical comments and improvements are welcome. > > > > I would appreciate if people could first read and speak before shooting > > directly :-) > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Friday, November 16, 2001 7:49 PM > > To: Mannie, Eric > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Eric, > > The point of my earlier email (items again below, this time with > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > The issue (and I think the reason for Maarten's strong reaction) is this: > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > GMPLS-LBM and LCAS ARE solutions to different problems. > > (I hope this is not too subtle for non-native English speakers). > > > > LCAS is a method to hitlessly change the mappings at the two > > ends of a virtually concatenated trail to increase or decrease the > > bandwidth. It does not say anything about how components to be > > added or removed from the virtually concatenated "bundle" are > > set up or taken down. > > > > LBM talks about how to set up or take down those added or removed > > components, but not about the details of changing the mapping (other > > than that it is done after the new components are successfully > > established. > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > because LCAS is "sacred", but because you are comparing apples to > > oranges. Statements in this document such as "One drawback of LCAS is .." > > are unnecessary and inappropriate in this context, since LBM does > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > were solving the SAME problem better, this would be OK, but this > > is not the case. > > > > Time to try to be constructive: > > - I think most of the current discussion of LCAS should be removed from > > this document. It is irrelevant since LCAS solves a different problem than > > LBM. To say that one is "better" than the other would only be meaningful > > if they were solving the same problem (can you really say that LBM solves > > problem A better than LCAS solves problem B?). > > - LCAS can be a good informative reference as a way to hitlessly modify > > the size of a virtually concatenated trail. > > - Clarify in the scope that the current draft describes the use of LBM > > without LCAS, which results in a traffic glitch when bandwidth is > modified. > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > the size of virtually concatenated pipes after LBM sets up new > component(s) > > or before LBM takes down old component(s) is a topic for further study > > and perhaps to be addressed in a future version of the draft. > > > > Regards, > > Steve > > > > Steve Trowbridge wrote: > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > the traffic. > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > control plane knows that the different LSPs are part of the same > > > circuit. > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > be the preferred method for many applications. > > > > "Mannie, Eric" wrote: > > > > > > Hello Maarten, > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > document > > > and to compare GMPLS and LCAS functionalities ? > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 16:51:30 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Representation of VC-3 in STM-0 in {SUKLM} format Date: Mon, 19 Nov 2001 17:49:28 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, If I have to allocate VC-3 on a STM-0 link then how to represent it in {SUKLM}? As per gmpls-sdh-sonet draft, S is the index of particular AUG-1 and can take values from 1 -> N. but there is no AUG-1 in STM-0. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 14:30:58 -0800 Message-ID: From: Jonathan Lang To: 'S Ramesh' , George Young Cc: ccamp@ops.ietf.org, Jonathan Lang Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Mon, 19 Nov 2001 14:21:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesh, Please see inline. Thanks, Jonathan > -----Original Message----- > From: S Ramesh [mailto:rashanmu@npd.hcltech.com] > Sent: Thursday, November 15, 2001 11:15 PM > To: George Young > Cc: ccamp@ops.ietf.org > Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) > > > Hi Young, > > 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the > Data Link FSM's in the down state also. Agreed. I would actually propose that we remove the degraded state altogether from the data link fsms. This is already captured at the TE link level. Comments? > > 2. Transtition 10:evLnkDealloc can be possible know even in the degraded > state. Yeah a control channel is needed, but this event can also be a > external event know, from the user or a network management event. If this > is possible then this event is required in this state. Kindly > clarify me. agreed. > > 3. Also event 14.evdcDown can also possible in Test/Pasv Test state. Since > to send a Test message or to receive a Test message we need a data channel. > If you see both the FSM's ( Data link ) event 3 & 4 will pose the next > state to Test & Pasv Test state from Up/Free state. So the event > 14.evdcDown is also possible on both the states and hence the > next state in both the case will be down. ok. > > Thanks, > Ramesh > > George Young wrote: > > > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > > draft-ietf-ccamp-lmp-02.txt: > > > > 1) It appears that in the Down state, the control channel > can be either > > up or > > down. That being the case, there should be transitions for events 1 > > :evCCUp: > > and 2 :evCCDown: from Down to Down. > > > > 2) Transition 10:evLnkDealloc: from Deg to Down would appear to be > > impossible, > > as there is no control channel available, and the control channel is > > required to coordinate taking the channel down at both > ends. I believe > > this > > transition should be removed. > > > > With these changes, the FSMs would look like: > > > > 12.3.3. Active Data Link FSM Description > > > > Figure 5 illustrates operation of the LMP active data > link FSM in a > > form of FSM state transition diagram. > > > > 1,2 > > +------+ > > | | > > | +------+ > > +-->| |<-------+ > > +--------->| Down | | > > | +----| |<-----+ | > > | | +------+ | | > > | |5b 3| ^ | | > > | | | |2,7 | | > > | | v | | | > > | | +------+ | | > > | | | |<-+ | | > > | | | Test | |11 | | > > | | | |--+ | | > > | | +------+ | | > > | | 5a| 3^ | | > > | | | | | | > > | | v | | | > > |2,12 | +---------+ | | > > | +-->| |14 | | > > | | Up/Free |----+ | > > +---------| | | > > +---------+ | > > 9| ^ | > > | | | > > v |10 | > > +-----+ 2 +---------+ | > > | |<--------| |13 | > > | Deg | |Up/Alloc |------+ > > | |-------->| | > > +-----+ 1 +---------+ > > > > Figure 5: Active LMP Data Link FSM > > > > 12.3.4. Passive Data Link FSM Description > > > > Figure 6 illustrates operation of the LMP passive data > link FSM in a > > form of FSM state transition diagram. > > > > 1,2 > > +------+ > > | | > > | +------+ > > +-->| |<------+ > > +---------->| Down | | > > | +-----| |<----+ | > > | | +------+ | | > > | |5b 4| ^ | | > > | | | |2,8 | | > > | | v | | | > > | | +----------+ | | > > | | | PasvTest | | | > > | | +----------+ | | > > | | 6| 4^ | | > > | | | | | | > > | | v | | | > > |2,12 | +---------+ | | > > | +--->| Up/Free |14 | | > > | | |---+ | > > +----------| | | > > +---------+ | > > 9| ^ | > > | | | > > v |10 | > > +-----+ +---------+ | > > | | 2 | |13 | > > | Deg |<--------|Up/Alloc |-----+ > > | |-------->| | > > +-----+ 1 +---------+ > > > > Figure 6: Passive LMP Data Link FSM > > > > Regards, > > George R. Young > > edgeflow Inc. > > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > > phone: +1 613-270-9279 Ext 287 > > fax: +1 613-270-9268 > > > > >-----Original Message----- > > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > > >Sent: Monday, November 12, 2001 9:00 PM > > >To: ccamp@ops.ietf.org > > >Subject: Two week Last Call on LMP > > > > > > > > >Hi All, > > > > > >This is to announce a two week Last Call on the LMP draft: > > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > > > > > >Please send questions, comments and requests for clarifications > > >to the CCAMP list. > > > > > >Kireeti. > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 13:50:11 -0800 Message-ID: From: Jonathan Lang To: 'Carmine Daloia' , ccamp Cc: tsg15q9@itu.int, t1x15@t1.org, Jonathan Lang Subject: RE: Localizing Fault for Protection/Restoration Date: Mon, 19 Nov 2001 13:41:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Carmine, Please see inline. Thanks, Jonathan > -----Original Message----- > From: Carmine Daloia [mailto:daloia@lucent.com] > Sent: Monday, November 19, 2001 11:24 AM > To: ccamp > Cc: tsg15q9@itu.int; t1x15@t1.org > Subject: LMP: Localizing Fault for Protection/Restoration > > > Hi all, > > Another issue that is addressed in Section 6 "Fault Management" is the > determination of whether a detected defect is due to a fault within a > Protection/Restoration subnetwork or outside the subnetwork. The > following text is included in Section 6.2, "As part of the fault > localization, 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).... The > upstream node should correlate the failure to see if the failure is also > detected locally (including ingress side) for the corresponding LSP(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.... Once the failure has been localized, the signaling protocols > can be used to initiate span or path protection/restoration > procedures." > > I think we need to specify which protection/restoration architectures > such a ChannelStatus message would be applicable. All I currently see > are boxes and lines, yet we don't know at what layer the > protection/restoration is being performed nor do we know what type of > monitoring is supported (e.g., non-intrusive monitoring, tandem > connection monitoring, etc.). I am not saying that such a mechanism > would not be needed, however I think it is more fundamental to agree on > the architectures first before we attempt to agree on one particular > message that may be needed in some of the architectures. In fact the > ChannelStatus message (if specified) should be included in those > protection/restoration documents that specify architectures that would > require such a message. Note that the ChannelStatus message is actually > a message that is communicated between the end-points of a > protection/restoration subnetwork. The end-points of a > protection/restoration subnetwork could be adjacent cross-connects if > span protection/restoration is supported or the end-points could be > non-adjacent cross-connects if path protection/restoration is supported. > Lumping this ChannelStatus message into LMP automatically forces the > end-points to be adjacent cross-connects. LMP is a "link management protocol" that is designed to manage links between peers (this is particularly useful when the interface over which the control messages are sent/received may not be the same interface over which the data flows). As such, it is not clear to me why you are proposing to run LMP end-to-end across multiple cross-connects. > > Also, the paragraph that I quoted above indicates that once the failure > has been localized using the procedures described in LMP, the signaling > protocols can be used to initiate span or path protection/restoration. > Note that for path protection/restoration, the cross-connects themselves > are included within the protection/restoration subnetwork and therefore > path protection/restoration needs to restore connections when > cross-connects themselves fail. I don't see how the mechanism described > in LMP can be used when a cross-connect fails. Assume the network > consists of four cross-connects. > > A------B------C > | | > +------D------+ > > Let's assume that cross-connect B fails. According to the mechanism > described in LMP, Cross-connect C will send a ChannelStatus back to > Cross-connect B, however because B has failed, B will not be able to > process the ChannelStatus message. Therefore I don't see how > LMP would > apply to path protection/restoration. Path protection/restoration can be initiated due to link or node failures. The ChannelStatus message is used to isolate link failures. Node failures can be detected by the loss of the control channels (possibly in conjunction with the loss of data channels). This should be detected at both A and C. > > Carmine > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 12:56:18 -0800 Message-ID: <3BF9711C.95765FE8@nayna.com> Date: Mon, 19 Nov 2001 12:52:44 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: drafts CC: Sudheer Dharanikota , CCAMP WG Subject: draft-many-ccamp-srg-01.txt Content-Type: multipart/mixed; boundary="------------2A02491C512AE08036C97FA2" This is a multi-part message in MIME format. --------------2A02491C512AE08036C97FA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We would like to post the following updated draft on "Inter domain routing with Shared Risk Groups". We requested a time slot to present the draft at CCAMP WG in Salt Lake City IETF. Your comments are welcome. Regards, sudheer --------------2A02491C512AE08036C97FA2 Content-Type: text/plain; charset=iso-8859-1; name="draft-many-ccamp-srg-01.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="draft-many-ccamp-srg-01.txt" CCAMP Working Group S. Dharanikota, R. Jain (Nayna) Internet Draft D. Papadimitriou (Alcatel) Document: draft-many-ccamp-srg-00.txt R. Hartani (Caspian Networks) Category: Internet Draft G. Bernstein (Ciena) Expires: June 2002 V. Sharma (Metanoia) C.Brownmiller, Y.Xue (Worldcom) December 2001 Inter-domain routing with Shared Risk Groups draft-many-ccamp-srg-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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 Conventions used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Abstract This document discusses how inter-domain routing using Shared Risk Group (SRG) may be used for computing diverse paths, and also discusses the extensions that we propose for routing (and eventually signaling) protocols. The concepts proposed in this document are useful to provide the requested intelligent control plane for multi- layered networks. Internet Draft – CCAMP Working Group – Expires January 2002 1 draft-many-ccamp-srg-01.txt December 2001 1. Introduction For many years in the telecommunications industry, the concept of SRLG (Shared Risk Link Group) has been used for computing a path that is disjoint from a set of links sharing the same risk. For this purpose, links sharing the same risk are grouped together to have the same SRLG value. When two links (or more) share the same risk, it means that when one link fails the other(s) can fail simultaneously. Reference [IETF-DIMITRI-SRLG] provides enhancements to the concept of SRLGs thereby streamlining its meaning. Networks are planned to recover from failures due to a risk (represented by an SRLG) using different mechanisms, which we call capabilities. So if we look at SRLG on a positive note we may want to intentionally use the capabilities supported in the network due to an SRLG. For example one may provide a 1:1 shared link protection (link capability) for many connections using the link that has an SRLG value of X. A risk sharing, however, is not limited to links, which has been the case until now in a majority of the IETF proposals (e.g., [IETF- KIREETI-OSPF]). In this document, we extend the applicability of SRLGs to path (or connections) included in a domain, where we define a domain to be a group of resources (nodes and links) that provide similar capabilities and that share the same set of risk(s). For example a domain can be consecutive set of links that has 1:1 link level protection or a set of links that form a ring or a protected Forwarding Adjacency (FA) in a domain. Note that in such a scenario (for example in ring topology), a failure will affect all the other resources in the domain. This observation parallels the notion of what SRLG for a link to an SRG (Shared Risk Group) for a domain. The “shared risk concept” can also be viewed as a mechanism to hide or reduce the amount of topology information propagated in a multi- layered network. Consider a multi-layered network with fiber, optical (for instance G.709 OTN), SONET/SDH and router topology in the ascending order of encompassing the previous topology. In such a topology a link at the client layer (for example, router level) can mean many nodes and links in the server layer (for example, SONET/SDH, optical and fiber level). Hence to provide diversity at the client layer link level one should consider failures in the server layer topology. Thus, to provide diverse links or paths (sequences of links) at the client layer requires some means of abstracting the diversity at the server layer, so that this abstraction can be used by path computation at the client layer. At present the only way to provide this abstraction of the server layer topology in the client layers is to use SRLG. With the adoption of GMPLS (Generalized Multi-Protocol Label Switching) control plane in the packet and circuit based networks it is now possible to compute diverse paths in multiple layers. The notion of diversity can be abstracted and dynamically computed at many layers. In this document, we concentrate on the risk associated with a sequence of Internet Draft - CCAMP Working Group – Expires June 2002 2 draft-many-ccamp-srg-01.txt December 2001 disjoint elements (unlike in case of SRLG). The procedures of doing such a complex task is provided in this document. The following observations serve as a basis for considering the extension of the “Shared risk” concept to more than just a link: @ The number of nodes or links that are affected by a failure is dependent on the physical topology of the network (or the server layer(s) topology in a multi-layered network). - A typical node failure may also represent the failure of set of links, or multiple link failures or SRLGs. - On the other hand, a failure of a fiber (or a group of fibers) may result in the failure of multiple logical links. The abstraction of the capability of a domain can be useful in - Summarizing the information propagated in the routing protocols, - Hiding the topology of the domain for the sake of loose path specification Computing diverse paths by concatenating the capabilities of the domains. - Hiding the topology details of the server layers in a multi- layered network (if needed). @ Sharing risk is opposite to capability of a domain, which is a required parameter for service provisioning by ISPs. - Establishing a primary path disjoint from the secondary one at the same layer reduces the chances of losing traffic or dropping traffic for longer time. - Such a notion enables more factual based risk assessment and hence helps in achieving risk reduction by improving incremental topological design. 2. Requirements and Applicability As mentioned in [OIF-CARRIER-REQ] and [IPO-JOHN-IMP], the diversity compromises between two links being used for routing should be defined in terms of Shared Risk Link Groups (SRLGs), a group of links which share some resource, such as a specific sequence of fiber ducts or a specific office. A SRLG is a relationship between the resources that should be characterized by two parameters: @ Type of Compromise: Examples would be shared fiber cable, shared conduit, shared ROW, shared link on an optical ring, shared office - no power sharing, etc.) - Support for hierarchical SRLG allocation - Support for logical level and physical level diversity - Support for computing diverse path computation over multi- layered networks - Support for hiding lower-layer capability in the upper layers - Extent of Compromise: For compromised outside plant, this would be the length of the sharing. Internet Draft - CCAMP Working Group – Expires June 2002 3 draft-many-ccamp-srg-01.txt December 2001 Consequently, the mechanisms proposed in this must be applicable when: : @ To achieve constraint based path computation in a multi-layered network with integrated control plane and reduction in the amount of TE (Traffic Engineering) parameters. @ To hide the topology in a tiered network (whether control planes overlay or peer-to-peer) with a single or multiple administrators to the domain(s). @ To reduce the amount of TE information propagated by localizing the scope of information propagation and hence distribution of the path computation. @ To propose mechanisms that are applicable to packet and non- packet oriented networks (multi-service networks) in the scope of GMPLS architecture independently of the path provisioning state. Some of possible business applications that can be solved with the concepts of SRG are protected path provisioning, preferably routed circuit provisioning and preferred quality circuit provisioning. 4. Definitions and scope 4.1. Definition of risk domain Definition: A “risk domain” is a group of arbitrarily connected nodes and links that together can provide certain like-capabilities (such as a chain of dedicated/shared protected links and nodes, or a ring forming nodes and links, or a protected FA). This is advertised in the routing protocols as “risk domain link”, an abstract point-to-multipoint link. It is rather advisable not advertising this as NBMA link to avoid the complexity of the designated router. This solution does not, however, preclude handling of the risk domain concept via a representation as a NBMA link. Another way to see the risk domain link is as a Forwarding Adjacency (FA – refer to [IETF-KIREETI-FA]) if and only if source and destination are located within the same area and can have a pre- established path between them with the same capabilities in all the links through which this FA is passing through. In the current document, we assume a risk domain is part of a routing (OSPF or ISIS) area. From now on, we use the term domain interchangeably with risk domain. 4.2. Definition of SRG Definition: An SRG (a 32 bit integer) represents the risk domains’ capabilities and other parameters, which assist in computing diverse Internet Draft - CCAMP Working Group – Expires June 2002 4 draft-many-ccamp-srg-01.txt December 2001 paths through the domain and in assessing the risk associated with the risk domain. With the observations made in section 1 and the introduction of the concept of a risk domain, we define the notion of a “Shared Risk Group” (SRG) per risk domain. Note that the SRLGs of this risk domain are a subset of the SRGs. SRLGs address only risks associated with the links (physical and logical) and locations within the risk domain, whereas SRGs contains nodes and other topological information in addition to links. The key difference between an SRLG and an SRG is that an SRLG translates to only one link share risk with respect to server layer topology (even FA and virtual links) while an SRG translates a sequence of SRLGs (including nodes) over the same layer from one source to one or more than one destination located within the same area. 4.3. Scope The following are the goals of this work: - Diversity: @ To capture link, node and domain-level diversity with minimal TE information. @ Summarizable SRG notation, which decreases the complexity of computing disjoint paths. @ Propose a mechanism that works for both single and multi- layered networks, which use Generalized MPLS distributed control plane. In the first version of the document we consider only intra-AS networks with single layer topology. In the future version we will generalize the mechanism to inter- AS and multi-layered architectures. - Risk: @ Assign capabilities to the SRGs such Resource Class, TE Metric, etc. @ Assign failure probability to the SRGs, which, in turn, enable the “evaluation” of the probabilities corresponding to the risk assessment. @ Facilitate path computation against a given risk type. This case will be handled in the future versions of the document. - Other: @ SRLG is currently a flat 32 bit number in a given autonomous system. The notion of SRG will help in localization of SRLG allocation and hence helps in summarization. @ Deployment (i.e., operational aspects) of a SRLG or SRG capable network. 5. Extensions 5.1. Configuration The configuration parameters considered are the following: Internet Draft - CCAMP Working Group – Expires June 2002 5 draft-many-ccamp-srg-01.txt December 2001 Domain boundary configuration [Mandatory]: This is the configuration of domain to provide a boundary for summarization or hiding the capability information, as will be elaborated in the next few sections. This is in parallel to the concept of an area boundary in the existing IGPs. Hierarchical SRLG configuration [Optional]: The hierarchical SRLG configuration is provided by the SRLG encoding itself. In [IETF- DIMITRI-SRLG], the SRLG are encoded as a Resource Location and a Resource Identifier. The latter includes a list of type – SRLG identifier fields. This concept helps in localizing SRLG allocation, hiding the server layer link level topology and in reducing amount of server layer TE information propagation. Domain to SRG allocation [Mandatory]: Grouping of nodes and links that provide certain capability will have an SRG allocated to it. The SRG value can be a flat 32-bit number or can represent some of the domain capabilities. The SRG encoding will be discussed in the future versions of the document. The node ID from which the point- to-multipoint virtual link starts identifies the SRG allocation. This means that the root of the virtual point-to-multipoint link defines the SRG allocation. Per SRG capability allocation [Mandatory]: The capabilities of the domain such as protection and restoration can be assigned per domain. Please note that the likeness of these capabilities across the domain is a requirement for a link or a node to be part of the domain. Other link related parameters that can be extended to SRG such as TE Metric (additive metric), Resource Class (ON/OFF), etc could be also allocated per SRG. Capability to risk factor parameters [Optional]: Risk associate with a domain depends on the protection and restoration mechanisms inherent to the domain and that can be achieved through the capabilities of the domain. Since the risk domain belongs to a single operator, we can assign these parameters per mechanism per domain. This can be assigned per type of failure per SRG. Preferred path allocation parameters [Optional]: This is the weight associated to the SRG. This weight can be assigned statically configured once at the initial stage or dynamically determined since it can be defined as additive metric whose individual values are the link TE metrics. 5.2. Encoding A hierarchical encoding mechanism is the key to the summarization process of the SRLGs of a given server layer link. This encoding can be performed on the physical and logical resources as elaborated in [IETF-DIMITRI-SRLG]. SRG on the other hand represents a both the nodes and the links, which can take the same hierarchical encoding Internet Draft - CCAMP Working Group – Expires June 2002 6 draft-many-ccamp-srg-01.txt December 2001 as in SRLG, but in the current version of the document we assume it to be a 32-bit flat number with the capabilities being specified as TLVs. 5.3. Capability assignment Refer to [IETF-GMPLS-ARCH] to get the complete list of the link capabilities that can be propagated. Here we envision at least the protection related capabilities can be extended to the domain level, in addition we have few more parameters, which assist in the risk assessment, as discussed below. - Capability assignment (will be elaborated further in the later versions of the document): This is assigned to each of the SRG, which is propagated in the opaque LSA in the routing protocols and assists in the diverse path computation and risk assessment. @ Domain capability: Extensions similar to link capabilities as noted by [IETF-GMPLS-ARCH]. These include shared or dedicated protection capabilities of the links in the domain. @ Node capability: Extensions similar to link capabilities as noted by [IETF-GMPLS-ARCH]. @ Link capability: Extensions as discussed by [IETF-GMPLS-ARCH]. @ Conditional probability for risk: This provides the operator assigned risk factor for a given SRG. This can be carried per type of failure. 5.4. Routing protocol extensions 5.4.1. Propagation of a domain link A network administrator groups a set of links and nodes of similar capabilities into a domain and assigns an SRG to the domain. A physical topology can have overlapping domains if links and/or nodes participating in the domain notion support multiple capabilities. A domain is represented as an abstract point-to-multipoint link for the sake of representation, and for path computation in the routing protocols. As discussed before, this can represent any type of physical topology represented under the abstract notion of domain. The exact semantics of the domain link opaque LSA [RFC 2370] (defined as an opaque LSA of Type 10) is presented in below. The scope of this opaque LSA can be link, area or AS specific. 5.4.1.1. Opaque LSA Payload The Opaque LSA payload consists of one or more nested Type/Length/Value (TLV) structures. The format of the Opaque LSA TLV structure is defined as: 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 Internet Draft - CCAMP Working Group – Expires June 2002 7 draft-many-ccamp-srg-01.txt December 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length (in bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.4.1.2 SRG TLV The SRG TLV includes the SRG ID (32 bits identifier). 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 (TBD) | Nx4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRG ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the TLVs other than the risk factor TLV is available in the IGP extensions as available now in the IETF drafts such as [IETF-GMPLS-OSPF], [IETF-GMPLS-ISIS]. In the future versions of this document we will elaborate on the other required TLVs specific to this document. Note that even the protection related TLVs would be specified per SRG (unlike per link in the case of regular networks). 5.4.2. Path computation Path computation becomes very rich with this concept with the concept of the loose nodes and links being represented by the risk domain concept. A dynamic path computation mechanism can use the concatenation of the domains to compute the loose explicit path, leaving the expansion of the loose segments to the domain border nodes. First we start with one domain “computation” and then expand it. Here below some guidelines: - Pruning of SRG that do not belong to the same resource class - Exclude all the resources already selected for other LSP using that SRG for the same VPN ID, same source node ID, etc. - Exclude all the resources already selected for the same restoration group of LSP (case of edge-to-edge protection) - Take the explicit inclusive and exclusive requirements into consideration - In the remaining topology, prune all links with insufficient capacity to route the current LSP route demand. Internet Draft - CCAMP Working Group – Expires June 2002 8 draft-many-ccamp-srg-01.txt December 2001 Compute the shortest path in the remaining network. If no route is found, the LSP setup request fails and the LSP setup is rejected. 6. Security Considerations Security considerations related to SRLG Inference model and its applications are left for further study. 7. Conclusions In this document we presented the concept of a risk domain abstracting nodes and links with like-capabilities. This notion can be used very effectively for inter-domain routing by reducing the amount of TE information to be carried. We proposed a mechanism called SRG to capture this information and assist in diverse path computation and risk assessment in single and multi-layered networks. 8. Acknowledgments The authors acknowledge John Strand for his discussions, which lead to many of the features supported by the SRG concept. 9. References [IETF-KIREETI-TE] K. Kompella et al., “OSPF Extensions in Support of Generalized MPLS,” draft-kompella-ospf-gmpls-extensions-01.txt, IETF draft (work in progress). [IETF-DIMITRI-SRLG] D. Papadimitriou et al., “Inference of Shared Risk Link Groups,” draft-many-inference-srlg-00.txt, IETF draft (work in progress). [IETF-JOHN-IMP] J. Strand et al., “Impairments and other constraints on optical Layer routing,” draft-ietf-impairments-00.txt, IETF draft (work in progress). [IETF-SRLG-PROTO-EXT] S. Dharanikota et al., “Inter domain routing with SRGs – Protocol extensions,” draft-many-ccamp-srg-00.txt, IETF draft (work in progress). [IETF-GMPLS-ARCH] E. Mannie et al., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” draft-many-gmpls- architecture-00.txt, IETF draft (work in progress). [OIF-CARRIER-REQ] J. Strand et al., “Carrier Optical Services Framework and Associated Requirements for UNI,” OIF2000.155, OIF carrier group document. Internet Draft - CCAMP Working Group – Expires June 2002 9 draft-many-ccamp-srg-01.txt December 2001 [IETF-KIREETI-FA] K. Kompella, Y. Rekhter, “LSP Hierarchy with MPLS TE,” draft-ietf-mpls-lsp-hierarchy-02.txt, IETF Working group document. [IETF-GMPLS-OSPF] [IETF-OPT-OSPF] Kireeti Kompella et al., “OSPF Extensions in Support of Generalized MPLS,” draft-kompella-ospf- gmpls-extensions-01.txt, IETF working group draft. [IETF-GMPLS-ISIS] Kireeti Kompella et al., “IS-IS Extensions in Support of Generalized MPLS,” draft-ietf-isis-gmpls-extensions- 02.txt, IETF working group draft. [RFC 2370] R. Coltun, “The OSPF opaque LSA option,” RFC 2370. 10. Author's Addresses Sudheer Dharanikota: sudheer@nayna.com Raj Jain: raj@nayna.com Dimitri Papadimitriou: dimitri.papadimitriou@alcatel.be Riad Hartani: riad.hartani@caspiannetworks.com Greg Bernstein: gregb@ciena.com Vishal Sharma: v.sharma@ieee.org Curtis Brownmiller: curtis.brownmiller@wcom.com Yong Xue: yxue@uu.net John Strand: jls@research.att.com Internet Draft - CCAMP Working Group – Expires June 2002 10 draft-many-ccamp-srg-01.txt December 2001 Appendix A: Diversity and SRG A brief introduction is provided to the need for diversity to set the stage for the rest of the discussion. Traffic engineering in IP (Internet Protocol) networks is achieved using MPLS technology as an overlay on the IP networks. The success of the MPLS TE concept has lead to its application in the optical domain as well. The “pinned” or connection-oriented nature of LSPs reduces the capability of IP traffic to recover automatically from failures in the data path. To achieve path resiliency, therefore, diverse paths must be established between the source and destination MPLS nodes through the use of explicit routing (loose or strict). By introducing the connection-oriented (LSPs) in the IP technology, we loose the automatic hop-by-hop recovery of the data paths in case of failures. Hence, diverse paths are established between the source and destination MPLS nodes for achieving path resiliency. The diversity requirements of transport networks have some differences with those of router (Layer 3 and Layer 2 switching) networks. They are mainly: @ Transport networks provide elaborate protection and restoration mechanisms, @ Transport topologies are not always structured in mesh topologies (agreed but in fact an OCh on top of an OMS SPRing for instance appears as a point-to-point connection at the OCh level so that Ring topology does not necessarily mean ringed connection, as assumed by the router networks, and @ Transport-level protection and restoration mechanisms are not considered in the diverse path computation by the MPLS technology (at least till now) dynamic path computation constructs. Diversity in the router world is achieved as follows: - Request: Given the (physical and logical) topology, link capabilities, and constraints to calculate 1 to N diverse path between two points in the network. - Input: @ Topology: . Physical topology is always meshed and multiplexed (fiber, cables, segments etc.). . Areas and autonomous systems achieve logical topology. @ Capability: . Only link capabilities are propagated. @ Constraints: . Inclusive requirements: Such as a preferred links (color). . Exclusive requirements: Such as avoiding a node (node- level diversity, link-level diversity). . Limiting requirements: Such as bandwidth. - Output: @ Paths available or not. Internet Draft - CCAMP Working Group – Expires June 2002 11 draft-many-ccamp-srg-01.txt December 2001 @ If paths are available then provide the strict or loose paths. . Strict paths can be provided if the physical topology is known between the source and destination. . Loose paths are provided if the end-to-end physical topology is not known. Diversity in the router + transport world may be achieved as follows: @ Request: Given the (physical and logical) topology, link capabilities, domain capabilities and constraints to calculate 1 to N diverse paths between two points in the network. @ Input: @ Topology: . Physical topology is flexible (Rings, Meshes, Ring-Mesh inter connected). . Domains (or islands) are used to achieve logical topology. @ Capability: . Both link (or span) and domain capabilities need to be propagated. @ Constraints: . Inclusive requirements: Such as preferred links and preferred link, node and domain capabilities. . Exclusive requirements: Such as avoiding a link, node or domain. . Limiting requirements: Such as bandwidth. @ Output: @ Paths available or not. @ If paths are available then provide the strict or loose paths. . Strict paths can be provided if the physical topology is known between the source and destination – not necessarily I can provide an strict routed SDH L-LSP while being aware of the lambda topology but not on the fiber or duct topology. . Loose paths are provided if the end-to-end physical topology is not known or cannot be interpreted such as in ring topologies or would like to leave to the risk domain to decide (for local optimization or due to lack of information or to reduce TE information flooding) – not necessarily for instance inter-area routing can be loose even if the local source area physical topology is known. Discussion: The following observations can be made between the diverse path setup mechanisms in the router world and in the transport world: - Sharing risk is not only a property of the links, but it can be extended to nodes and domains. Thus, an SRG can be associated with the links, nodes, and even domains. Internet Draft - CCAMP Working Group – Expires June 2002 12 draft-many-ccamp-srg-01.txt December 2001 - Also, for example, domain capabilities can be associated with the domain SRG to achieve inclusive constraints. For example, a BLSR ring can have an SRG with ring capabilities associated with it. As a precursor to achieving such constraints we propose to extend the SRLG notion to represent logical topologies. By assigning SRGs in a hierarchical fashion (to a region, a zone/domain and a node), we can capture the capabilities, and risks, associated with them. An extensive discussion on this subject is provided in [IETF-DIMITRI- SRLG]. Considering the above practical knowledge of real world scenarios, it is essential (to reduce the computation time) to reduce the number of SRLGs by means of some encoding. We observe that the amount of configuration can also be reduced (for example, from 100s of SRLGs on a Trans-Atlantic link). This poses the following requirements: - Need a mechanism to encode (and hence summarizable) SRLG to group represent a link or node or domain wide individual SRGs. - Need to modify the path computation algorithms (such as CSPF) for accommodating the new encoding scheme. - Need to enhance the path computation mechanisms to work with the logical topologies (or domains). - Need to propagate the logical topologies (or domains) via the routing protocols. Internet Draft - CCAMP Working Group – Expires June 2002 13 draft-many-ccamp-srg-01.txt December 2001 Appendix B: Risk assessment and SRG Risk (the complementary of availability) assessment is defined as the evaluation of the potential risk associated with the inclusion of a given resource (this resource belongs to a given resource type located within a given logical structure such as a geographical location) in a given path. A brief discussion for the motivation of the risk assessment capabilities of SRLG is provided here. Consider the following example, where the client device makes the following requests to the optical network: - Request (either through signaling protocols or using an SLA) for a persistent connection with 99.999 % (widely known 5 9s) of availability or equally a down time less than X minutes per year. - Request a high-protection for a portion of the traffic (at the expense of paying a higher charge) compared to other low-priority traffic. Such requirements will be translated into constraints in path computation. Such constraints can be grouped into path selection constraints and path characterization constraints. - Path selection constraints: These typically dictate which physical path should be taken to achieve the client’s availability requirements. These requirements are typically the logical and physical diversity. - Path characterization constraints: Path characterization requirements typically dictate the protection mechanisms as requested by the client. This can be achieved in the form of optical rings, meshed protection mechanisms, etc. These constraints can be used in using the link, node, and domain capabilities as discussed in the previous section on diversity. The components that need formalization in this example are: - Step 1. Specification of the user requirements (such as the example above), which need to be translated into “network constraints”. - Step 2. Configuring the network in a way that helps in assessing its features, such as the availability - Step 3. Propagating the information thus configured. - Step 4. Using information thus propagated in path computation. Step 1 of specifying the requirements is not in the scope of this document. Steps 2 - 4 are discussed below. Internet Draft - CCAMP Working Group – Expires June 2002 14 draft-many-ccamp-srg-01.txt December 2001 Discussion: A convenient way to achieve risk assessment is by associating a conditional risk value with each of the SRLGs and SRGs, as discussed in [IETF-DIMITRI-SRLG]. Also, by associating a weight factor with the SRG, we can increase the choice of selecting specific SRGs. This calls for configuring: - A Risk factor per SRG - A Weight factor per SRG In addition to the SRG capabilities, discussed before, the above values can also be propagated via routing protocols. These routing requirements are discussed in the following section. With the help of the above two configuration parameters, the use of typical CSPF algorithms to compute a path can be extended to assess the risk associated with the path. For example, if a path traverses SRGs 1, 3, 5, then one may infer that the risk associated with this path is (Risk 1 x Risk 3 x Risk 5). Internet Draft - CCAMP Working Group – Expires June 2002 15 draft-many-ccamp-srg-01.txt December 2001 Full Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Internet Draft - CCAMP Working Group – Expires June 2002 16 --------------2A02491C512AE08036C97FA2 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer tel;work:408-956-8000 x357 x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc.;CTO's office version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;; fn:Sudheer Dharanikota end:vcard --------------2A02491C512AE08036C97FA2-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 12:12:48 -0800 Message-ID: From: "Mannie, Eric" To: 'Huub van Helvoort' Cc: 'Stephen Trowbridge' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 21:11:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Huub, >>3. GMPLS LBM versus LCAS >> >> LCAS causes internetworking issues with GMPLS. Having two >> signaling protocols running in parallel to control the same LSP is >> not an ideal case. > >[hvh] why do you call LCAS a signaling protocol? it is a scheme to keep > the source and sink of a virtual concatenated signal synchronised > regarding the payload offered by the individual members of the > virtual concatenated group, how the payload is transported through > the network from source to sink, i.e. the path, is up to the > control plane. We called it a signaling protocol because it is not a transport protocol (there is no payload), because it is not a management protocol (i.e. no SNMP or TMN), because it is not a routing protocol (like OSPF, ISIS, BGP etc), etc. Obviously, a protocol that exchange control packets between two entities in the purpose of modifying the bandwidth of a circuit, looks like a signaling protocol. Note there are plenty of end-to-end signaling protocols that are not hop-by-hop, like TCP, UDP, etc. >> Using LCAS in parallel with GMPLS implies that >> GMPLS traffic parameters may be modified without the GMPLS control >> plane being aware of these modifications. > >[hvh] which traffic parameters do you mean? Those defined in GMPLS extensions for SDH/SONET (see the appropriate drafts). >> However, GMPLS provides >> natively capabilities to modify traffic parameters of an >> established LSP. > >[hvh] please tell me where you read in G.7042 that LCAS does this. Sorry, this is exactly our point, LCAS doesn't does this. GMPLS is a complete solution (self-consistent) that does also what the LCAS protocol is not doing. >> Indeed, the MPLS signaling was originally >> conceived to allow traffic parameter (bandwidth) modification. >> >> LCAS is a signaling protocol restricted to the bandwidth >> modification at end systems. It doesn't allow setting up and >> releasing circuits dynamically, and doesn't allow setting up and >> releasing bandwidth in intermediate nodes. > >[hvh] Now I am confused, isn't this exactly what you claim LCAS does do > in the first paragraph? Sorry, I don't understand. >> The advantage of using >> GMPLS is that it provides a complete integrated solution, allowing >> for a wide range of traffic parameter modifications. > >[hvh] LCAS provides flexibility to existing virtual concatenated signals > and relieves the control plane of the task of synchronising source > and sink side use of available payload of a virtual concatenated > signal (similar to pointer processing). Yes, we are just saying that they are other ways of doing the same in the transport plane than LCAS (i.e. alternatives that don't require a new protocol in the POH) since we don't have to care about the control part that is done by GMPLS. >> Using multiple LSPs to support a single circuit (optional) has the >> drawback of requiring more signaling but this seems to be the most >> appropriate way to operate within the context of a global control >> plane. It provides the advantage that each independent LSP can be >> protected/restored independently. > >[hvh] the transport of a virtual concatenated signal by using multiple > signals, is a characteristic of virtual concatenation, for > each signal a path through the network has to be set up by the > control plane irrespective of LBM or LCAS. > Virtual concatenation (with/without LCAS) allows any independent > protection scheme to be applied to the individual members. Yes that matches our understanding. We were just speaking about a limitation of GMPLS that we are solving, not more. >> Note that GMPLS LBM can be first >> used to modify the bandwidth of a single unique LSP (circuit), >> without any LSP combination. > >[hvh] here is no difference with LCAS, this also allows a virtual > concatenated signal with a single member. Yes, we never said the opposite. This is just to clarify the scope of GMPLS LBM, nothing about LCAS. >> One drawback of LCAS is that it requires changing the transport >> plane since new overhead bytes are used. In consequence, new ASICs >> must be used at both termination ends. On the contrary, GMPLS LBM >> is done purely in the control plane. It does not require any new >> ASICs and is backward compatible with the existing hardware. > >[hvh] although GMPLS LBM is purely in the control plane, it still needs > hardware to distribute the contiguous bitrate over the payload > areas of the individual LSPs (and reconstruct it at the sink). > Virtual concatenation as it is defined now (without LCAS!) cannot > be changed in size without interrupting the traffic. The make-before- > break concept you propose requires also new ASICS to be developped. It depends how the C2 transition is detected. I will remove that ASIC paragraph anyway because it has nothing to do with the protocol. >> This specification defines how to perform bandwidth modification >> using the GMPLS signaling. The final result will be almost similar >> than the one achieved using LCAS, with the advantage of being an >> integrated solution that doesn't require adaptation of the >> transport plane. > >[hvh] why did you totally ignore the solution LCAS provides to survive > a failure in the network affecting one member, decreasing the > available payload (by the members contribution to the total > payload) and hitless adding th payload after the failure clears? We didn't. Adding a VC after a failure is the same as adding a VC. How many frames do you wait with LCAS before having a valid control message and CTRL field ? Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 11:48:29 -0800 Message-ID: From: "Mannie, Eric" To: 'George Newsome' Cc: 'Huub van Helvoort' , 'Stephen Trowbridge' , 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 20:45:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello George, > Why is there this tremendous effort to redesign something that already exists, and can just be used? Thanks for the tremendous, but for us a 13 pages draft and a discussion on a mailing list is not tremendous :-) > I'd have thought that you had much better things to do with your time in these difficult times. George, I don't know if you noticed but we don't work for the same company. Regards, Eric -----Original Message----- From: George Newsome [mailto:gnewsome@lucent.com] Sent: Monday, November 19, 2001 8:16 PM To: Mannie, Eric Cc: 'Huub van Helvoort'; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: Re: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, Why is there this tremendous effort to redesign something that already exists, and can just be used? I'd have thought that you had much better things to do with your time in these difficult times. Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 11:27:36 -0800 Message-ID: <3BF95C5F.80403@lucent.com> Date: Mon, 19 Nov 2001 14:24:15 -0500 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: ccamp CC: tsg15q9@itu.int, t1x15@t1.org Subject: LMP: Localizing Fault for Protection/Restoration Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Another issue that is addressed in Section 6 "Fault Management" is the determination of whether a detected defect is due to a fault within a Protection/Restoration subnetwork or outside the subnetwork. The following text is included in Section 6.2, "As part of the fault localization, 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).... The upstream node should correlate the failure to see if the failure is also detected locally (including ingress side) for the corresponding LSP(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.... Once the failure has been localized, the signaling protocols can be used to initiate span or path protection/restoration procedures." I think we need to specify which protection/restoration architectures such a ChannelStatus message would be applicable. All I currently see are boxes and lines, yet we don't know at what layer the protection/restoration is being performed nor do we know what type of monitoring is supported (e.g., non-intrusive monitoring, tandem connection monitoring, etc.). I am not saying that such a mechanism would not be needed, however I think it is more fundamental to agree on the architectures first before we attempt to agree on one particular message that may be needed in some of the architectures. In fact the ChannelStatus message (if specified) should be included in those protection/restoration documents that specify architectures that would require such a message. Note that the ChannelStatus message is actually a message that is communicated between the end-points of a protection/restoration subnetwork. The end-points of a protection/restoration subnetwork could be adjacent cross-connects if span protection/restoration is supported or the end-points could be non-adjacent cross-connects if path protection/restoration is supported. Lumping this ChannelStatus message into LMP automatically forces the end-points to be adjacent cross-connects. Also, the paragraph that I quoted above indicates that once the failure has been localized using the procedures described in LMP, the signaling protocols can be used to initiate span or path protection/restoration. Note that for path protection/restoration, the cross-connects themselves are included within the protection/restoration subnetwork and therefore path protection/restoration needs to restore connections when cross-connects themselves fail. I don't see how the mechanism described in LMP can be used when a cross-connect fails. Assume the network consists of four cross-connects. A------B------C | | +------D------+ Let's assume that cross-connect B fails. According to the mechanism described in LMP, Cross-connect C will send a ChannelStatus back to Cross-connect B, however because B has failed, B will not be able to process the ChannelStatus message. Therefore I don't see how LMP would apply to path protection/restoration. Carmine Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 11:25:25 -0800 Message-ID: <3BF95A63.4AAD76BB@lucent.com> Date: Mon, 19 Nov 2001 14:15:47 -0500 From: George Newsome Organization: Lucent Technologies, Bell Labs MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Huub van Helvoort'" , "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: Re: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Why is there this tremendous effort to redesign something that already exists, and can just be used? I'd have thought that you had much better things to do with your time in these difficult times. Regards George Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 10:58:20 -0800 Message-ID: From: Jonathan Lang To: 'George Young' , ccamp@ops.ietf.org Cc: Jonathan Lang Subject: RE: Two week Last Call on LMP (Section 6.4 & 6.5) Date: Mon, 19 Nov 2001 10:50:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, The Active/Deactive state of a data channel is a substate of the UP/Alloc state. Thanks, Jonathan > -----Original Message----- > From: George Young [mailto:george.young@edgeflow.com] > Sent: Tuesday, November 13, 2001 1:12 PM > To: ccamp@ops.ietf.org > Subject: RE: Two week Last Call on LMP (Section 6.4 & 6.5) > > > Looking at draft-ietf-ccamp-lmp-02.txt: > > Sections 6.4 and 6.5 describe the Channel Status/Active (and Deactive) > putting the corresponding channel into (or taking it out of) the 'Active' > state. At the moment, there is no 'Active' state in the TE Link FSM, > Section 12.3. > > Does going into the 'Active' state correspond to transition 9: evLnkAlloc > and leaving the 'Active' state correspond to trasition 10: evLnkDealloc? > > Regards, > George R. Young. > edgeflow Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > > >-----Original Message----- > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >Sent: Monday, November 12, 2001 9:00 PM > >To: ccamp@ops.ietf.org > >Subject: Two week Last Call on LMP > > > > > >Hi All, > > > >This is to announce a two week Last Call on the LMP draft: > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > > > >Please send questions, comments and requests for clarifications > >to the CCAMP list. > > > >Kireeti. > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 10:27:45 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <9791A828507D5A418741095C3FD0DDE33AE642@INDUS.paramanet.com> Subject: RE: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 13:02:10 -0500 Thread-Topic: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Thread-Index: AcFxHZp9We6BkEFQShuT2qncYEL6XAAASvaw From: "Grant W. Cyboron" To: "Mannie, Eric" Cc: "ccamp" , "q11/15" , "t1x1.5" Mannie, The difficulty that I see in using the C2 byte for synchronizing the switchover to the increased bandwidth lies in the fact that the source will have no knowledge of when the sink has accepted the new value of C2 as valid. G.806 section 6.2.4.2 specifies that the sink accepts the new value of C2 in m frames where 3=3D=20 +1 732 544 9120, x710 (voice) +1 732 544 9121 (fax) -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Monday, November 19, 2001 12:12 PM To: 'mvissers@lucent.com' Cc: 'Stephen Trowbridge'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hello Maarten, More about your e-mail: >Looking at your simple example, I get the impression that you do not fully >understand the use of the UNEQ value in C2/V5. The UNEQ value in C2/V5 is >generated by the HOVC/LOVC connection function (see G.783) as part of the UNEQ >VC-n signal generation process. Good, that's exactly what we want and need with GMPLS-LBM ! >The UNEQ value is not generated by the path >termination function or its associated adaptation function. An adaptation >function alsways generates an equipped-specific signal label (>=3D 2). Good, that's exactly what we want and need with GMPLS-LBM ! We never said on which specific functions acts GMPLS-LBM. At one point in the time the adaptation function has to generate an equipped signal, we just said that we need to control that event. The triggering of C2 is done in ONE frame, in LCAS you MUST wait for multiple frames. So, what do you conclude for the LBM performance? By the way, this is draft 0 and we could even think at using other C2 transitions as a trigger, like first using a test signal and then switching to the real data signal. The issue is to find the most appropriate transition or even the list of the possible transitions. >I.e. the assumptions underlying your steps 2 to 6 are incorrect and not aligned >with the SDH specifications in ITU-T. It depends what YOU understood from GMPLS, on-going GMPLS protection and restoration work, and GMPLS-LBM of course. Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 10:26:06 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt Date: Mon, 19 Nov 2001 11:22:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have a doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt (page 19, Annex 1, example # 4 and # 5). The 4th example mentions request for STM-16 with multiplex section layer transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, T with flag 2 to an STM-16 elementry signal. Does the SDH standard support the above request ? If yes, then what will be the label value if such a signal is requested from say STM-64 or STM-256 link ? The 5th example is regarding the request for STM-4c signal. It mentions that STM-4c signal (i.e. VC-4-4c with TOH) with multiplex section layer transparency is formed by the application of RCC with flag 1, NCC with value 1, NVC with value 0, MT with value 1 and T with flag 2 applied to an STM-4. Does the SDH standard support the above request ? If yes, then what will be the label value if such a signal is requested from say STM-64 or STM-256 link ? What will be the difference in {SUKLM} if VC-4-4c had been requested instead of STM-4c ? Please comment. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 09:57:56 -0800 Message-ID: From: "Mannie, Eric" To: 'Huub van Helvoort' Cc: 'Stephen Trowbridge' , 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 18:52:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Huub, >> Simple example: >> >> 1) you first signal an additional VC/SPE to the destination (via a Path). > >[hvh] I don't see any difference with LCAS. There is an enormous difference with LCAS: GMPLS does in addition the signaling hop-by-hop. We are arguing that GMPLS-LBM covers the functions of LCAS, so by definition you can expect to have a similar behavior. >> 2) the destination knows exactly which VC/SPE is added (via the label). > >[hvh] isn't this already done in step 1) ? Yes, this is just to better explain (to emphasize something). >> 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), >> so the VC/SPE is not yet added to concatenated signal. > >[hvh] G.806 clause 6.2.1.1: unequiped is an indication for loss of > connectivity. This can also be monitored at intermediate points. > If it should be interpreted as indicated, G.806 has to be changed > as well as the installed base. I think that you are confusing the contexts. We are looking for a unequipped to non-unequipped transition, as the first transition. When the VC starts to transport a payload the C2 becomes non-unequipped (e.g. takes one of the payload values defined in G.707) and then a transition back to unequipped is not in our scope. By the way you could instead use another transition, e.g. from a test signal (0.181) to a data signal. The only thing is to find the best transition. Would you prefer this one ? Intermediate systems don't change at all. End systems are a new class of devices supporting GMPLS, like LCAS requires new equipments. >> 4) then, you wait at the source for a confirmation from the destination >> (i.e. Resv). > >[hvh] here signals in the transport plane (C2) and control plane (Resv) > are mixed, imho this is worse than having it fully in the control > or ttransport plane. It is completely mixed with GMPLS if you use LCAS. Anyway, the confirmation (Resv) is a normal operation of the control plane (please see RSVP). >> 5) the source "equip" the VC/SPE and sends. > >[hvh] I am missing the exact definition of when the first bit is sent. I am missing the exact definition of the bit that you are talking about :-). More seriously, if you speak about the first user data bit, it is obviously in the container of the VC having made the transition. >> 6) the destination sees in the POH that the VC is "equipped" (transition). > >[hvh] where is the definition of the validation for this detection? Like in SDH, when the Signal Label changes its value to go from state A to state B. >> The difference between LCAS and LBM is that LCAS uses an additional explicit >> indication in the overhead to say "this is the payload" to use. LBM doesn't >> change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) > >[hvh] the explicit indication is required in order not to loose data > (similar to pointer justification process). Like with GMPLS-LBM. Do you mean that C2 is not explicit. Tell us how and when you loose data with a C2 transition ? >> LCAS uses a new field in the POH (CTRL) to know when the new VC transitions >> to a significant payload. LBM proposes to do the same simply by looking at >> the C2 (for HOVC) transition - regular SDH/SONET field that will change >> anyway and that is used to indicate the type of payload. > >[hvh] in regular SDH/SONET C2 is fixed Not at all... It can change from unequipped to non unequipped, it can change to VC-AIS, etc. You can use a test signal and then change to an ATM payload, etc... >> To be more precise about LCAS (I copy from the LCAS specification, section >> 6.3.1): "The first container frame to contain payload data for the new >> member shall be the container frame immediately following the container >> frame that contained the last bit(s) (i.e. the CRC) of the control packet >> with NORM/EOS message for that member" (the LCAS control packet). >> >> So, LCAS waits for the last bit of the appropriate LCAS control packet in >> the POH with the appropriate transition of its CTRL field. LBM waits simply >> for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH >> (don't change SDH/SONET). > >[hvh] 6.3.1 describes the insertion after validation, LBM needs also to > describe the validation process for C2 and the exact insertion. Yes, this is draft zero (at the IETF it means the first version that you put on paper). Thanks for your help, Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 09:20:06 -0800 Message-ID: From: "Mannie, Eric" To: "'mvissers@lucent.com'" Cc: 'Stephen Trowbridge' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 18:11:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, More about your e-mail: >Looking at your simple example, I get the impression that you do not fully >understand the use of the UNEQ value in C2/V5. The UNEQ value in C2/V5 is >generated by the HOVC/LOVC connection function (see G.783) as part of the UNEQ >VC-n signal generation process. Good, that's exactly what we want and need with GMPLS-LBM ! >The UNEQ value is not generated by the path >termination function or its associated adaptation function. An adaptation >function alsways generates an equipped-specific signal label (>= 2). Good, that's exactly what we want and need with GMPLS-LBM ! We never said on which specific functions acts GMPLS-LBM. At one point in the time the adaptation function has to generate an equipped signal, we just said that we need to control that event. The triggering of C2 is done in ONE frame, in LCAS you MUST wait for multiple frames. So, what do you conclude for the LBM performance? By the way, this is draft 0 and we could even think at using other C2 transitions as a trigger, like first using a test signal and then switching to the real data signal. The issue is to find the most appropriate transition or even the list of the possible transitions. >I.e. the assumptions underlying your steps 2 to 6 are incorrect and not aligned >with the SDH specifications in ITU-T. It depends what YOU understood from GMPLS, on-going GMPLS protection and restoration work, and GMPLS-LBM of course. Kind regards, Eric Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 08:56:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Mannie, Eric" To: 'Maarten Vissers' Cc: 'Stephen Trowbridge' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 17:44:51 +0100 Hello Maarten > LCAS is added to the networks to resize the pipe over which e.g. Ethernet packets flow in a hitless manner. The A and Z endpoints need therefore to be synchronised at frame level. There is no alternative in the control plane which can support this. We know that perfectly and we never said the opposite. It is not because we speak about GMPLS that there is no transport plane anymore. GMPLS-LBM discusses two issues both the control plane issues and the necessary relationship with the transport plane (i.e. how to achieve the synchronization in a similat manner as LCAS using transport plane features). To be clear, GMPLS-LBM proposed also a solution for the frame synchronization. -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Monday, November 19, 2001 12:20 PM To: Mannie, Eric Cc: 'Stephen Trowbridge'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, LCAS is added to the networks to resize the pipe over which e.g. Ethernet packets flow in a hitless manner. The A and Z endpoints need therefore to be synchronised at frame level. There is no alternative in the control plane which can support this. Looking at your simple example, I get the impression that you do not fully understand the use of the UNEQ value in C2/V5. The UNEQ value in C2/V5 is generated by the HOVC/LOVC connection function (see G.783) as part of the UNEQ VC-n signal generation process. The UNEQ value is not generated by the path termination function or its associated adaptation function. An adaptation function alsways generates an equipped-specific signal label (>= 2). So, as soon as the fabrics in the to be setup connection have setup their matrix connections, the VC-n path termination function will receive an equipped-specific signal label value, and consequently clears its UNEQ defect. I.e. the assumptions underlying your steps 2 to 6 are incorrect and not aligned with the SDH specifications in ITU-T. Regards, Maarten "Mannie, Eric" wrote: > > Hello Stephen > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > No, please see explanations below. > > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > No, please see below (C2 or V5 transition). > > >The compare/contrast discussion of LBM and LCAS is appropriate not > >because LCAS is "sacred", but because you are comparing apples to > >oranges. Statements in this document such as "One drawback of LCAS is .." > >are unnecessary and inappropriate in this context, since LBM does > >NOT solve the problem LCAS was designed to solve. Perhaps if you > >were solving the SAME problem better, this would be OK, but this > >is not the case. > > No, please see below. > > Simple example: > > 1) you first signal an additional VC/SPE to the destination (via a Path). > 2) the destination knows exactly which VC/SPE is added (via the label). > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > so the VC/SPE is not yet added to concatenated signal. > 4) then, you wait at the source for a confirmation from the destination > (i.e. Resv). > 5) the source "equip" the VC/SPE and sends. > 6) the destination sees in the POH that the VC is "equipped" (transition). > > The difference between LCAS and LBM is that LCAS uses an additional explicit > indication in the overhead to say "this is the payload" to use. LBM doesn't > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) > > LCAS uses a new field in the POH (CTRL) to know when the new VC transitions > to a significant payload. LBM proposes to do the same simply by looking at > the C2 (for HOVC) transition - regular SDH/SONET field that will change > anyway and that is used to indicate the type of payload. > > To be more precise about LCAS (I copy from the LCAS specification, section > 6.3.1): "The first container frame to contain payload data for the new > member shall be the container frame immediately following the container > frame that contained the last bit(s) (i.e. the CRC) of the control packet > with NORM/EOS message for that member" (the LCAS control packet). > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > the POH with the appropriate transition of its CTRL field. LBM waits simply > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > (don't change SDH/SONET). > > By the way, this is version 0 of the draft and it was just posted. > > Suggestions, technical comments and improvements are welcome. > > I would appreciate if people could first read and speak before shooting > directly :-) > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, November 16, 2001 7:49 PM > To: Mannie, Eric > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Eric, > The point of my earlier email (items again below, this time with > numbers) was not to prompt the comment "#3 is out of scope, therefore > it is a choice between #1 and #2" (my parsing of recent statements). > > The issue (and I think the reason for Maarten's strong reaction) is this: > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > GMPLS-LBM and LCAS ARE solutions to different problems. > (I hope this is not too subtle for non-native English speakers). > > LCAS is a method to hitlessly change the mappings at the two > ends of a virtually concatenated trail to increase or decrease the > bandwidth. It does not say anything about how components to be > added or removed from the virtually concatenated "bundle" are > set up or taken down. > > LBM talks about how to set up or take down those added or removed > components, but not about the details of changing the mapping (other > than that it is done after the new components are successfully > established. > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > The compare/contrast discussion of LBM and LCAS is appropriate not > because LCAS is "sacred", but because you are comparing apples to > oranges. Statements in this document such as "One drawback of LCAS is .." > are unnecessary and inappropriate in this context, since LBM does > NOT solve the problem LCAS was designed to solve. Perhaps if you > were solving the SAME problem better, this would be OK, but this > is not the case. > > Time to try to be constructive: > - I think most of the current discussion of LCAS should be removed from > this document. It is irrelevant since LCAS solves a different problem than > LBM. To say that one is "better" than the other would only be meaningful > if they were solving the same problem (can you really say that LBM solves > problem A better than LCAS solves problem B?). > - LCAS can be a good informative reference as a way to hitlessly modify > the size of a virtually concatenated trail. > - Clarify in the scope that the current draft describes the use of LBM > without LCAS, which results in a traffic glitch when bandwidth is modified. > Indicate that the use of LCAS to hitlessly negotiate the changes to > the size of virtually concatenated pipes after LBM sets up new component(s) > or before LBM takes down old component(s) is a topic for further study > and perhaps to be addressed in a future version of the draft. > > Regards, > Steve > > Steve Trowbridge wrote: > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > the traffic. > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > control plane knows that the different LSPs are part of the same > > circuit. > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > be the preferred method for many applications. > > "Mannie, Eric" wrote: > > > > Hello Maarten, > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > >understanding of LCAS's objective (my very strong opinion). > > > > Sorry, do you mean that it is forbidden to speak about your LCAS document > > and to compare GMPLS and LCAS functionalities ? > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 08:04:57 -0800 Message-ID: <3BF916E3.11FA00E8@lucent.com> MIME-Version: 1.0 Original-CC: "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Date: Mon, 19 Nov 2001 15:27:47 +0100 From: Huub van Helvoort To: "Mannie, Eric" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, Ia also had a look at your > Simple example: > > 1) you first signal an additional VC/SPE to the destination (via a Path). [hvh] I don't see any difference with LCAS. > 2) the destination knows exactly which VC/SPE is added (via the label). [hvh] isn't this already done in step 1) ? > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > so the VC/SPE is not yet added to concatenated signal. [hvh] G.806 clause 6.2.1.1: unequiped is an indication for loss of connectivity. This can also be monitored at intermediate points. If it should be interpreted as indicated, G.806 has to be changed as well as the installed base. > 4) then, you wait at the source for a confirmation from the destination > (i.e. Resv). [hvh] here signals in the transport plane (C2) and control plane (Resv) are mixed, imho this is worse than having it fully in the control or ttransport plane. > 5) the source "equip" the VC/SPE and sends. [hvh] I am missing the exact definition of when the first bit is sent. > 6) the destination sees in the POH that the VC is "equipped" (transition). [hvh] where is the definition of the validation for this detection? > The difference between LCAS and LBM is that LCAS uses an additional explicit > indication in the overhead to say "this is the payload" to use. LBM doesn't > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) [hvh] the explicit indication is required in order not to loose data (similar to pointer justification process). > LCAS uses a new field in the POH (CTRL) to know when the new VC transitions > to a significant payload. LBM proposes to do the same simply by looking at > the C2 (for HOVC) transition - regular SDH/SONET field that will change > anyway and that is used to indicate the type of payload. [hvh] in regular SDH/SONET C2 is fixed > To be more precise about LCAS (I copy from the LCAS specification, section > 6.3.1): "The first container frame to contain payload data for the new > member shall be the container frame immediately following the container > frame that contained the last bit(s) (i.e. the CRC) of the control packet > with NORM/EOS message for that member" (the LCAS control packet). > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > the POH with the appropriate transition of its CTRL field. LBM waits simply > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > (don't change SDH/SONET). [hvh] 6.3.1 describes the insertion after validation, LBM needs also to describe the validation process for C2 and the exact insertion. > By the way, this is version 0 of the draft and it was just posted. > > Suggestions, technical comments and improvements are welcome. > > I would appreciate if people could first read and speak before shooting > directly :-) Here in the Netherlands it is illegal to carry guns, so I cannot shoot. And shooting make more mess that it resolves anyway. Cheers, Huub. -- ------------------------------------------------------------------------ | Huub van Helvoort | Lucent Technologies | PO Box 18 | | TEL: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen | | FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands | ------------------------------------------------------------------------ Always remember that you are unique... Just like everyone else. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 08:01:29 -0800 Message-ID: <3BF90EC9.4C82E75D@lucent.com> MIME-Version: 1.0 Original-CC: "Mannie, Eric" , "'Stephen Trowbridge'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Mannie, Eric" , "'Stephen Trowbridge'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Date: Mon, 19 Nov 2001 14:53:13 +0100 From: Huub van Helvoort To: Maarten Vissers Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, After reading the draft-mannie-ccamp-gmpls-lbm-tdm-00.txt I have some questions see [hvh] between the text: >3. GMPLS LBM versus LCAS > > LCAS causes internetworking issues with GMPLS. Having two > signaling protocols running in parallel to control the same LSP is > not an ideal case. [hvh] why do you call LCAS a signaling protocol? it is a scheme to keep the source and sink of a virtual concatenated signal synchronised regarding the payload offered by the individual members of the virtual concatenated group, how the payload is transported through the network from source to sink, i.e. the path, is up to the control plane. > Using LCAS in parallel with GMPLS implies that > GMPLS traffic parameters may be modified without the GMPLS control > plane being aware of these modifications. [hvh] which traffic parameters do you mean? it cannot be the number of members in the virtual concatenated group, because the control plane tells LCAS how many there are. If a member fails, this is indicated to the control plane, but the member remains in the group even though its payload is not used any more. If the failure cannot be repaired the control plane has to replace the failed member by a remove-add sequence. > However, GMPLS provides > natively capabilities to modify traffic parameters of an > established LSP. [hvh] please tell me where you read in G.7042 that LCAS does this. > Indeed, the MPLS signaling was originally > conceived to allow traffic parameter (bandwidth) modification. > > LCAS is a signaling protocol restricted to the bandwidth > modification at end systems. It doesn't allow setting up and > releasing circuits dynamically, and doesn't allow setting up and > releasing bandwidth in intermediate nodes. [hvh] Now I am confused, isn't this exactly what you claim LCAS does do in the first paragraph? > The advantage of using > GMPLS is that it provides a complete integrated solution, allowing > for a wide range of traffic parameter modifications. [hvh] LCAS provides flexibility to existing virtual concatenated signals and relieves the control plane of the task of synchronising source and sink side use of available payload of a virtual concatenated signal (similar to pointer processing). > Using multiple LSPs to support a single circuit (optional) has the > drawback of requiring more signaling but this seems to be the most > appropriate way to operate within the context of a global control > plane. It provides the advantage that each independent LSP can be > protected/restored independently. [hvh] the transport of a virtual concatenated signal by using multiple signals, is a characteristic of virtual concatenation, for each signal a path through the network has to be set up by the control plane irrespective of LBM or LCAS. Virtual concatenation (with/without LCAS) allows any independent protection scheme to be applied to the individual members. > Note that GMPLS LBM can be first > used to modify the bandwidth of a single unique LSP (circuit), > without any LSP combination. [hvh] here is no difference with LCAS, this also allows a virtual concatenated signal with a single member. > One drawback of LCAS is that it requires changing the transport > plane since new overhead bytes are used. In consequence, new ASICs > must be used at both termination ends. On the contrary, GMPLS LBM > is done purely in the control plane. It does not require any new > ASICs and is backward compatible with the existing hardware. [hvh] although GMPLS LBM is purely in the control plane, it still needs hardware to distribute the contiguous bitrate over the payload areas of the individual LSPs (and reconstruct it at the sink). Virtual concatenation as it is defined now (without LCAS!) cannot be changed in size without interrupting the traffic. The make-before- break concept you propose requires also new ASICS to be developped. > This specification defines how to perform bandwidth modification > using the GMPLS signaling. The final result will be almost similar > than the one achieved using LCAS, with the advantage of being an > integrated solution that doesn't require adaptation of the > transport plane. [hvh] why did you totally ignore the solution LCAS provides to survive a failure in the network affecting one member, decreasing the available payload (by the members contribution to the total payload) and hitless adding th payload after the failure clears? >4. GMPLS LBM Procedures Using a Parallel Circuit > > This section describes how to modify the bandwidth of a circuit by > establishing a new completely bandwidth disjoint circuit and > moving the traffic to that new circuit by doing a switchover. This > procedure can be done manually or automatically. It uses a > simplified version of the make-before-break concept. [hvh] how do you propose to synchronise source and sink about the point in time to switch from one to the other without losing data? In the make-before-break scheme, when increasing the payload even by one member in a virtual concatenated group there have to be X+1 paths available before the switch can be performed. LCAS only requires the paths for the members to be added, so LCAS allows a link to be used for 100%. When decreasing the payload even by one member in the virtual concatenated group there have to be X-1 paths available before the switch can be performed. LCAS only releases the member without requiring any additional path first. Kind regards, vriendelijke groeten, Huub. -- ------------------------------------------------------------------------ | Huub van Helvoort | Lucent Technologies | PO Box 18 | | TEL: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen | | FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands | ------------------------------------------------------------------------ Always remember that you are unique... Just like everyone else. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 07:43:23 -0800 Message-ID: <3BF927EF.31D6B458@sandburst.com> Date: Mon, 19 Nov 2001 10:40:31 -0500 From: Eric Gray MIME-Version: 1.0 To: "Saha, Sayandeb" Cc: "'ccamp@ops.ietf.org'" Subject: Re: position of ADMIN_STATUS object in RESV message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sayan, I may be looking at this somewhat simply, but I know of no reason why a transit node would need to disable an SE LSP because one of the reservations sharing the LSP at that node sets its admin status to down. Even in the case where the D bit is set, this should have the effect of removing the transit node from the particular reservation being torn down, rather than tearing down all reservations sharing resources at that transit node. You wrote: > Hi, > Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the > admin_status as not being a > part of the in the RESV message. > This works fine for the FF style of reservation. > But for the SE style of reservation if just one filter is taken out by > setting the D bit in admin status, > all others must go down because the admin_status applies for the entire RESV > instead of just the particular > filter in question. > Or for that matter if only one filter's state(LSP) is taken administratively > down( by setting A bit), it will now apply to all filters > Is this intended? Or is it the optical world will never do SE style > reservations? Am I missing something here? > -Sayan -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 07:39:35 -0800 Message-ID: <3BF926BB.E9FFDFE3@alcatel.be> Date: Mon, 19 Nov 2001 16:35:23 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Huub van Helvoort CC: Maarten Vissers , "Mannie, Eric" , "'Stephen Trowbridge'" , ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------7389F65D86F77B4BFDDDD161" This is a multi-part message in MIME format. --------------7389F65D86F77B4BFDDDD161 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Huub, You wrote: > [hvh] although GMPLS LBM is purely in the control plane, it still needs > hardware to distribute the contiguous bitrate over the payload > areas of the individual LSPs (and reconstruct it at the sink). > Virtual concatenation as it is defined now (without LCAS!) cannot > be changed in size without interrupting the traffic. The make-before- > break concept you propose requires also new ASICS to be developped. This is really the challenge of far can we go in the performance of the proposed mechanism without changing the ASIC from the one providing VC. Today we are at an "engineering" level trying to refine the mechanism (the one lengthy described by Eric). As said on Friday (by Eric and myself) any improvement or input to help for this purpose is highly appreciated. Thanks, - dimitri. Huub van Helvoort wrote: > > Eric, > > After reading the draft-mannie-ccamp-gmpls-lbm-tdm-00.txt I have some > questions see [hvh] between the text: > > >3. GMPLS LBM versus LCAS > > > > LCAS causes internetworking issues with GMPLS. Having two > > signaling protocols running in parallel to control the same LSP is > > not an ideal case. > > [hvh] why do you call LCAS a signaling protocol? it is a scheme to keep > the source and sink of a virtual concatenated signal synchronised > regarding the payload offered by the individual members of the > virtual concatenated group, how the payload is transported through > the network from source to sink, i.e. the path, is up to the > control plane. > > > Using LCAS in parallel with GMPLS implies that > > GMPLS traffic parameters may be modified without the GMPLS control > > plane being aware of these modifications. > > [hvh] which traffic parameters do you mean? it cannot be the number of members > in the virtual concatenated group, because the control plane tells LCAS > how many there are. If a member fails, this is indicated to the control > plane, but the member remains in the group even though its payload is > not used any more. If the failure cannot be repaired the control plane > has to replace the failed member by a remove-add sequence. > > > However, GMPLS provides > > natively capabilities to modify traffic parameters of an > > established LSP. > > [hvh] please tell me where you read in G.7042 that LCAS does this. > > > Indeed, the MPLS signaling was originally > > conceived to allow traffic parameter (bandwidth) modification. > > > > LCAS is a signaling protocol restricted to the bandwidth > > modification at end systems. It doesn't allow setting up and > > releasing circuits dynamically, and doesn't allow setting up and > > releasing bandwidth in intermediate nodes. > > [hvh] Now I am confused, isn't this exactly what you claim LCAS does do > in the first paragraph? > > > The advantage of using > > GMPLS is that it provides a complete integrated solution, allowing > > for a wide range of traffic parameter modifications. > > [hvh] LCAS provides flexibility to existing virtual concatenated signals > and relieves the control plane of the task of synchronising source > and sink side use of available payload of a virtual concatenated > signal (similar to pointer processing). > > > Using multiple LSPs to support a single circuit (optional) has the > > drawback of requiring more signaling but this seems to be the most > > appropriate way to operate within the context of a global control > > plane. It provides the advantage that each independent LSP can be > > protected/restored independently. > > [hvh] the transport of a virtual concatenated signal by using multiple > signals, is a characteristic of virtual concatenation, for > each signal a path through the network has to be set up by the > control plane irrespective of LBM or LCAS. > Virtual concatenation (with/without LCAS) allows any independent > protection scheme to be applied to the individual members. > > > Note that GMPLS LBM can be first > > used to modify the bandwidth of a single unique LSP (circuit), > > without any LSP combination. > > [hvh] here is no difference with LCAS, this also allows a virtual > concatenated signal with a single member. > > > One drawback of LCAS is that it requires changing the transport > > plane since new overhead bytes are used. In consequence, new ASICs > > must be used at both termination ends. On the contrary, GMPLS LBM > > is done purely in the control plane. It does not require any new > > ASICs and is backward compatible with the existing hardware. > > [hvh] although GMPLS LBM is purely in the control plane, it still needs > hardware to distribute the contiguous bitrate over the payload > areas of the individual LSPs (and reconstruct it at the sink). > Virtual concatenation as it is defined now (without LCAS!) cannot > be changed in size without interrupting the traffic. The make-before- > break concept you propose requires also new ASICS to be developped. > > > This specification defines how to perform bandwidth modification > > using the GMPLS signaling. The final result will be almost similar > > than the one achieved using LCAS, with the advantage of being an > > integrated solution that doesn't require adaptation of the > > transport plane. > > [hvh] why did you totally ignore the solution LCAS provides to survive > a failure in the network affecting one member, decreasing the > available payload (by the members contribution to the total > payload) and hitless adding th payload after the failure clears? > > >4. GMPLS LBM Procedures Using a Parallel Circuit > > > > This section describes how to modify the bandwidth of a circuit by > > establishing a new completely bandwidth disjoint circuit and > > moving the traffic to that new circuit by doing a switchover. This > > procedure can be done manually or automatically. It uses a > > simplified version of the make-before-break concept. > > [hvh] how do you propose to synchronise source and sink about the point > in time to switch from one to the other without losing data? > > In the make-before-break scheme, when increasing the payload even by > one member in a virtual concatenated group there have to be X+1 paths > available before the switch can be performed. LCAS only requires the > paths for the members to be added, so LCAS allows a link to be used > for 100%. > When decreasing the payload even by one member in the virtual concatenated > group there have to be X-1 paths available before the switch can be > performed. LCAS only releases the member without requiring any additional > path first. > > Kind regards, vriendelijke groeten, > > Huub. > -- > ------------------------------------------------------------------------ > | Huub van Helvoort | Lucent Technologies | PO Box 18 | > | TEL: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen | > | FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands | > ------------------------------------------------------------------------ > Always remember that you are unique... Just like everyone else. --------------7389F65D86F77B4BFDDDD161 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------7389F65D86F77B4BFDDDD161-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 07:33:46 -0800 Message-Id: <4.3.2.7.2.20011119161538.0941aed8@paris.cisco.com> Date: Mon, 19 Nov 2001 16:31:46 +0100 To: Francois Le Faucheur From: Jean Philippe Vasseur Subject: Re: comments on draft-kompella-mpls-multiarea-te-02.txt Cc: ccamp@ops.ietf.org, flefauch@europe.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Francois, Thanks for your comments. See in line, At 12:21 19/11/2001 +0100, Francois Le Faucheur wrote: >Kireeti, Yakov, Jean-Philippe, > > >A few suggestions on the Multi-Area TE draft for your consideration: > >Independent per-area TE >======================= >The draft currently restricts its scope of multiple-area TE to only those >scenarios using LSPs that span multiple areas. yes the idea is to specifically address the inter-area TE case. >Some SPs have/will deploy TE in multiple areas simply by running TE >independently in each area. Although, this does not really require any >specific new mechanisms, it is a valid scenario for doing TE in multi-area >environments. So my suggestion would be to slightly broaden the scope of >the draft (ie to not deliberately restrict it to the scenarios using >inter-area LSPs) and include a section on the multiarea TE scenario where >only intra-area LSPs are used. >You could then clarify that no new mechanisms are required for this (only >require that routers at boundary may have to keep TED from two areas). >I think it would also be useful to highlight a few properties of such a >deployment scenario (scalability/achieves kind of a natural "hierarchy" in >the sense that you keep a small number of tunnels in the backbone area and >packets from many leaf-area tunnels get aggregated into core-area tunnels, >dynamic routing onto tunnels at Head-ends is somewhat simpler since >Head-end IGP "sees" tail-end in its intra-area IGP Database, does not >allow end-to-end control of smaller traffic trunks ie two traffic trunks >from two head-end areas going to same tail-end cannot be "routed" >separately in backbone area or tail-end area...). > fair comment. >Reoptimisation >============== >Since you discuss how "optimal" is the routing for each scenario of >section 4, I'd suggest a clarifying statement that handling reoptimisation >on a per-area basis does not allow "globally optimum" reoptimisation. or this may even not be locally optimum (as with rerouting with crankback). Performing rerouting/reoptimization on the ABR (so on a per area basis) may or not be more optimal than head-end rerouting/reoptimization. So moreover, as you said, this cannot be globally optimum. >I would also suggest adding a statement making it explicit that other >methods of reoptimisation are possible which may reuse the mechanisms >described earlier for initial path computation (e.g. Path Computation server). True. That's what we meant by "Periodic (time-driven) reoptimization is performed by the head-end LSR" but ok we should make it more explicit, thanks. In this case, the LSR needs to signal the already in place TE LSP for the PCS not to perform double counting. draft-vasseur-mpls-computation-rsvp-01.txt (to be published shortly) allows this. >Vocab >===== >in section 3, you clarify that you will be using OSPF terminology to >dicuss both OSPF and ISIS. You mention "backbone area" as one such term. >You may want to mention ABR as another. ok >Typos/Editos >============= > - 4.2: 2nd paragraph., last sentence. "LSR setup" should read > "LSP setup". > - 4.3: 2nd paragraph, 1st sentence . "in the tail-end area the > head-end area)" should read " in the tail-end area" > - 4.4: paragraph 5 and 7 say the same thing and should be combined. Thanks ! JP. >Hope this is useful > >Francois Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 06:48:07 -0800 Message-ID: <3BF91A9D.6000304@lucent.com> Date: Mon, 19 Nov 2001 09:43:41 -0500 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: ccamp@ops.ietf.org CC: tsg15q11@itu.int, t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the ChannelStatus message...". I agree that the suppression of downstream alarms is an important issue. If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstream. The 3R points on the OLS Line Systems would insert some type of signal downstream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. Any other views? Carmine Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 06:07:15 -0800 Message-ID: <3BF910C8.2899A871@lucent.com> Date: Mon, 19 Nov 2001 15:01:44 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp , q12/15 Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------96F1241E96F555A7FBB0CA56" This is a multi-part message in MIME format. --------------96F1241E96F555A7FBB0CA56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: CCAMP Cc: Q.12/15 Note to Q.12/15 participants: within ccamp a discussion has started to develop an extension to GMPLS supporting connection bandwidth modification. After a first round of discussion I try to step back and first discuss the applications and architecture before introducing solutions. As I believe this is a topic that is also within the scope of Q.12/15, I am copying this email to Q.12/15. Let's turn around and enter the next step ... Looking at the document from an applications level, I got the impression that the objective of this document is (as reflected in its title) to specify "connection bandwidth modification" means. I.e. 1) which connection bandwidths can we modify 2) what is the required behaviour during such connection bandwidth modification 3) what needs to be done to modify such connection bandwidth 4) what extensions are required to GMPLS (and ASON) to support this connection bandwidth modification. Obvious candidates under item 1) are virtual concatenated VC-n/STS-n/VT-n/ODUk signals which transport e.g. Ethernet, IP, MPLS packets via GFP encapsulation. Less obvious candidates under item 1) are contiguous concatenated VC-n/STS-n signals; by definition in G.707 and T1.105 these VC-n-Xc and STS-nc signals have a fixed bandwidth. But if there is a network application which requires that one connection type X is replaced in-service by another connection type Y, we can analyse the behaviour and consequential requirements that a ASON/GMPLS [or NMS] like connection establishment needs to support for this application. Note - connection types should not be restricted to contiguous concatenated VC-n/STS-n cases. Within the group of LOVC layer networks it could be VC-12 into VC-3 (and vice versa). Within the group of HOVC layer networks it could be VC-4 to VC-4-16c, VC-4-4c to VC-4-16c, VC-3 to VC-4, etc. The network behaviour in all case will be the same. In doing so, we need to tackle several networking scenarios: A) both path termination points are within the network; the service provided to the user is a client layer service B) both path termination points are outside the network; the service provided to the user is a "connection group" service C) one path termination point is within the network, while the other path termination point is outside the network; this is a hybrid or heterogeneous case. My proposal is to first focus on the applications and e.g. indicate of which connection types we want to be able to modify the bandwidth and/or the connection type. Regards, Maarten Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > Networks > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > Pages : 13 > Date : 15-Nov-01 > > This document defines how GMPLS can be used to dynamically modify > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > will cover G.709 in a next version. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> --------------96F1241E96F555A7FBB0CA56 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 --------------96F1241E96F555A7FBB0CA56-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 04:41:27 -0800 Cc: ccamp , q11/15 , "t1x1.5" Message-ID: <3BF8FD72.567B478F@lucent.com> Date: Mon, 19 Nov 2001 13:39:14 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Bernstein, Greg" Original-CC: ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------E85775DCD939E1FD3A77706C" This is a multi-part message in MIME format. --------------E85775DCD939E1FD3A77706C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg, Thanks for this summary. I like it. ASON/GMPLS like connection establishment and LCAS are in my view indeed complementary, like NMS like connection establishment and LCAS. Regards, Maarten "Bernstein, Greg" wrote: > > Hi all, from my somewhat application biased notion of LCAS and its relation > to GMPLS/G.ASON. > I thought I would get two major features from LCAS: > (1) Hitless (for packet data services) changes in bandwidth by coordinating > between the end systems the exact time (virtual frame) when the new > component comes on line. (or old component stops being used). I've kinda > viewed LCAS as a path layer service (this may not be theoretically correct) > but I've got to use some mechanism to set up need component paths, then use > LCAS to bring them into use without say loosing an Ethernet or IP packet in > the process. Similarly on reduction in bandwidth, LCAS allows me to > hitlessly take a component out of service. Then I use some other process two > actually remove the component path from the network and free up the network > resources. > > (2) Graceful degradation in the presence of failure (especially with > diversely routed components). > Here LCAS is use by the end systems (virtual concatenation capable systems) > to coordinate which components are still functional and coordinate there use > after a failure. > > Eric, Maarten? I really thought LCAS and GMPLS/G.ASON like connection > establishment were quite complementary with no real overlap, e.g., I'd still > might want bandwidth modify at the GMPLS level so I don't have to keep track > of all the components individually (application 1.) and this is somewhat > different than what you'd want to do for application (2). > > Greg B. > > *********************************** > Dr. Greg M. Bernstein > Senior Technology Director, Ciena Corporation > > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Friday, November 16, 2001 9:39 AM > To: 'Maarten Vissers' > Cc: ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Hello Maarten, > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >understanding of LCAS's objective (my very strong opinion). > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > > >LCAS plays a role after the extra connection is setup or before a > connection is released. How this > connection is setup or released is not relevant for LCAS. > > GMPLS plays a role for all the cases that you described: to setup a > connection, to maintain a connection, to modify a connection, to release a > connection, etc. > > LCAS makes a lot of sense for a static network where provisioning occurs > through a Network Management System. > > A distributed control plane (like GMPLS) with LCAS doesn't make any sense. > LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the > beginning to allow LSP (bandwidth) modification. > > Do you mean that your implementation of GMPLS will not support any > bandwidth/LSP modification ? > > Kind regards, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, November 16, 2001 5:30 PM > To: Dimitri Papadimitriou > Cc: ccamp; q11/15; t1x1.5 > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Dimitri, > > Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > understanding of LCAS's objective (my very strong opinion). LCAS plays a > role > after the extra connection is setup or before a connection is released. How > this > connection is setup or released is not relevant for LCAS. > > NMS and ASON/GMPLS are concerned with connection setup and release. And also > with modification, if such is relevant for a connection. > > Modification of connection parameters is relevant for the connection > (group(s)) > supporting the transport of a Virtual Concatenated signal (VC-n-Xv, > ODUk-Xv). > > If this modification isn't covered yet in GMPLS drafts, it is important to > extend GMPLS and add it. But never ever relate it to LCAS :-). > > When we developed virtual concatenation and LCAS we where very much aware > that > we would get much more out of these two when there would be a switched > network. > The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) > could > then monitor the fill level of the virtual concatenated pipe, and when > crossing > a threshold could request another VC-n or ODUk to be setup. In a switched > network the setup only takes a few seconds, and essentially in no time the > bandwidth of the pipe can be increased. > > If LCAS is present, this new capacity can be included in the transmission of > the > ehternet bit stream without introducing any errors in the ehternet stream. > > If LCAS is not present, the ethernet transport will be interrupted for a > shorter > or longer period and (depending on the bandwidth of the pipe) fewer or many > more > packets will be lost before the transmission is restored. I.e. as long as > the > transmitter is using X+1 trails and the receiver is using X trails (or vice > versa) transmission is interrupted. With NMS ordering the increase at A-end > and > Z-end (after the additional trail is setup) this period may be a couple of > seconds; i.e. NMS has to generate two messages to the A node and the Z node, > these messages have to travel through the DCN, the two nodes have to accept > the > messages and process those before the command can be given to the hardware > to > use X+1 instead of X trails. > When a control plane is involved instead of NMS, the control plane has to > set up > the additional trail, verify that this trail is set up correctly (check for > signal fail including trace identifier), then command one end to transmit > over > X+1 trails and quickly inform the other end that it should command the > receiving > endpoint to read from X+1 trails. This all might be in the 100ms range but > most > likely will also be in the seconds range (depending on network size and > load). > > Dimitri Papadimitriou wrote: > > > > Maarten, > > > > I think you have reach the main comparison point for this discussion > > Let's start with this: > > > > - If you want to achieve hitles adaption you need a real-time protocol > > to synchronize both ends in some way (supporting the for instance LCAS) > > this is a synchronous approach > > > > - If you just want to add more capacity and you don't focus on a > > 'glitch' > > perhaps very few millisecs when putting the capacity in use you can do > > it in > > a non-real time manner like with GMPLS - this is an asynchronous > > approach > > You always need NMS or ASON/GMPLS to be present to setup the additional > connection. If an endpoint doesn't support LCAS, its function needs to be > performed by NMS or ASON/GMPLS (with degraded performance). > > > > > The major difference between both procedures is that GMPLS gives an > > There is no difference, as the two can not be compared. > > > answer > > how to allocate capacity across the network while LCAS relies on the > > fact > > that it is already available i.e. "provisioned" (see LCAS specification) > > for use and just has to be 'lit'. > > > > Hope this will help the reader to undertstand that both methods have a > > Methods are LCAS and non-LCAS... > > > specific applicability scope, the GMPLS one is more adapted for dynamic > > environments that do not use "provisioning" of the resources ... > > In either case there is "provisioning" of the resources. The hardware in > both > endpoints must be told to use X+1 instead of X trails. > > > a real > > bandwidth on demand service. I think this is what we have addressed > > with this. And from what i understood this is what carriers are looking > > for (since the bandwdith service is non-disruptive - if it can > > accomodate > > a very few ms -, flexible and doesn't require any pre-provisioning). > > There is a large difference between "zero errors" and "a few ms (most likely > seconds) of no transmission". > > > > > The second (LCAS) is adapted for services that could be sensitive, but > > the price to pay is to provision the "resources". This is a static > > approach of the problem. I think that both have a specific scope. > > I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS > provisioning is non-time critical, whereas the non-LCAS provisioning is time > critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not > mandatory, > the investments in NMS and ASON/GMPLS to limit the traffic interruption have > to > be made. As such, your draft should focus on the means to limit the traffic > interruption when LCAS is not present. This may imply kind of third party > signalling information to be carried through the public switched transport > network; i.e. for the case the virtual concatenated endpoints are outside of > the > PSTN, the user needs to have the capability to synchronize its endpoints. > > Regards, > > Maarten > > > > > Regards, > > - dimitri. > > > > Maarten Vissers wrote: > > > > > > Eric, Dimitri, > > > > > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. > Doing so > > > I got the impression that you completely misunderstand the purpose of > LCAS. LCAS > > > is NOT a signalling protocol. It is totally unrelated as such to control > plane > > > based connection management (GMPLS, ASON) or network management based > connection > > > management. > > > > > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If > N > > > trails are set up between the A-end and Z-end, LCAS helps to hitless > change the > > > number of trails being used for the actual transport of the client > signal; i.e. > > > if X (X increase this > > > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at > the A-end > > > and Z-end to make sure the increase/reduction is performed hitless. > > > > > > The steps to perform for the case X=N are: > > > A) X ==> X+1 > > > 1) [Operator or User] request connection management [NMS or > ASON/GMPLS] > > > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated > with > > > virtual concatenated endpoint at A-end and corresponding SNPP at > Z-end > > > 2) connection management [NMS or ASON/GMPLS] commands LCAS > controllers at > > > A-end and Z-end to control the "addition" of the (X+1)th trail to > the > > > group of X trails ("Madd" command in G.7042) over which the client > > > bitstream is transported > > > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends > this > > > to the receiver at the other end > > > 3) LCAS at A-end [Z-end] waits until connection is setup; the > connection > > > in one direction is setup if the Trail Signal Fail (TSF) condition > at > > > its end has cleared; > > > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > > > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > > > 6) at the start of the next VC-n/ODUk frame the client bitstream is > > > distributed over X+1 (instead of X) VC-n/ODUk trails > > > 7) the receiver at the other end notices the change of CTRL=ADD to > > > CTRL=EOS, and expects the client signal to be present on X+1 > (instead > > > of X) VC-n/ODUk trails at the begin of the next frame. > > > > > > Example with X=3 > > > ================ > > > > > > The bits in a client bit stream with bits ...,1,2,3,4,... are > distributed over > > > trails #1..#3 as follows: > > > trail#1 trail#2 trail#3 > > > ... > > > 1-8 9-16 17-24 > > > 25-32 33-40 41-48 > > > 49-56 57-64 65-72 > > > 73-80 ... > > > > > > When trail #4 is added, no client bits will be transported over it, > until the > > > source has indicated this via the change of the control word CTRL=ADD => > > > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > > > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" > begins at > > > the moment client bit 49 is to be transmitted, then trail#4 will be used > for the > > > transport of bits 73-80 and further: > > > > > > trail#1 trail#2 trail#3 trail#4 > > > ... > > > 1-8 9-16 17-24 > > > 25-32 33-40 41-48 > > > 49-56 57-64 65-72 73-80 > > > 81-88 89-96 97-104 105-112 > > > 113-120 ... > > > > > > Regards, > > > > > > Maarten > > > > > > Internet-Drafts@ietf.org wrote: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for > TDM > > > > Networks > > > > Author(s) : E. Mannie, D. Papadimitriou > > > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Pages : 13 > > > > Date : 15-Nov-01 > > > > > > > > This document defines how GMPLS can be used to dynamically modify > > > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > > > will cover G.709 in a next version. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> --------------E85775DCD939E1FD3A77706C 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 --------------E85775DCD939E1FD3A77706C-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 03:48:46 -0800 Cc: "Karmakar, Soumen" , ccamp@ops.ietf.org Message-ID: <3BF8EF98.7192AE5E@lucent.com> Date: Mon, 19 Nov 2001 12:40:08 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Heiles Juergen Original-CC: "Karmakar, Soumen" , ccamp@ops.ietf.org Subject: Re: STM-M out of STM-N (M > Maarten, > > one comment. My interpretation of the transparency flags is as follows: > RS layer transparency means that also all higher layers are transparently transported (e.g. MS, AU). So the whole SOH should be transparently transported and it is not necessary to set the MS layer transparency flag in addition. > > Juergen > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Monday, November 19, 2001 11:04 AM > > To: Karmakar, Soumen > > Cc: ccamp@ops.ietf.org > > Subject: Re: STM-M out of STM-N (M > > > > > Soumen, > > > > "Karmakar, Soumen" wrote: > > > > > > Does this mean that the STM64 signal type (as requested in > > sonet/sdh tSpec) > > > can be carried in the STM256 link type ? > > > > No; an STM-64 can NOT be carried in a STM-256. > > > > > However this is possible by carrying the VC-4-64c with > > transport overhead > > > only , even though the user specifies just STM64 signal type ? > > > > A VC-4-64c + TOH [in SDH terms SOH] is the complete STM-64. A > > STM-64 can not be > > carried by a STM-256. A user should thus not request this > > from the SDH/SONET > > network, as its request will be rejected. > > > > As a workaround for more transparency for the short term, a > > number of vendors > > are adding the ability to transport a SUBSET of the user's > > STM-N SOH/OC-N TOH > > bytes via the STM-M/OC-M (line) interfaces. I am referring to that as > > semi-transparent STM-N (STM-Nst) transport. Some dedicated > > subnetworks will be > > supporting this workaround, but do not consider this as a > > general available > > feature in the network. > > > > The mainstream SDH/SONET networks support LOVC/VT and > > HOVC/STS signal transport. > > And via these two also PDH signal (DS1, E1, E3, DS3, E4) > > transport, and more > > recently also Ethernet transport. > > > > STM-N/OC-N transport is supported via pre-OTN/WDM line > > systems and photonic > > cross connects as "STM-N/OC-N signal" transport. Switching is > > just fine in this > > case, but monitoring the quality of service for performance > > and fault management > > is very limited in this case. For the case of pre-OTN/WDM > > networks with a > > control plane on top, some of these limitations can be > > removed by adding LMP. > > The more general resolution (switched and non-switched > > networks) for this > > monitoring issue is the addition of OTN. With the > > introduction of OTN, monitored > > STM-N/OC-N signal transport will be supported via the ODUk > > signals (i.e. similar > > to PDH over SDH/SONET). > > > > > And the list of valid labels in this case should be > > > S = 1,65, 129, 193 and UKLM = 0,0,0 ? > > > > For the case of STM-64st connection setup these are the valid labels. > > > > Note - STM-64st is essentially an AUG-64 with some of the > > SOH/TOH as specified in the Transparency field. > > > > For case of a VC-4-64c connection setup, these are also the > > valid labels. > > > > > Furthermore in the example that you showed below with the > > following fields > > > as : > > > ST = 6 (VC4) , RCC =1, NCC =64, NVC =0, MT =1, T =0. > > > > This is a request for a VC-4-64c connection. > > > > > and why not > > > ST = 11 (STM64) , RCC=0, NCC=0, NVC=0, MT= 1, T = 6 or 7 > > (110 or 111) ? > > > > T_flag_1: RS layer transparency; i.e. RSOH transparency > > T_flag_2: MS layer transparency; i.e. MSOH transparency > > T_flag_3: RSOH J0 transparency > > > > T = T_flag_msb ... T_flag_lsb = T_flag_3, T_flag_2, T_flag_1 > > > > T = 110 implies MSOH + RSOH-J0 transparency > > T = 111 implies RSOH + MSOH transparency ==> i.e. T_flag_3 is > > redundant > > > > T = 110 is a request for a STM-64 Multiplex Section > > connection which is also > > transparent for RSOH-J0. This is not the same as a fully > > transparent STM-64 > > connection. I can not be supported by an SDH/sONET network as > > Juergen described; > > it may be possible to support this signal over a series of > > SDH/SONET repeaters > > (if these can pass through J0). > > > > T = 111 (or better T = 11) is a request for a STM-64 connection (fully > > transparent) and can only be supported by pre-OTN/WDM or OTN networks. > > > > Regards, > > > > Maarten > > > > > assuming full transparency support. > > > > > > Thanks, > > > Soumen > > > > > > > -----Original Message----- > > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > > Sent: Wednesday, November 14, 2001 12:57 AM > > > > To: manoj juneja > > > > Cc: ccamp@ops.ietf.org > > > > Subject: Re: STM-M out of STM-N (M > > > > > > > > > > > Manoj, > > > > > > > > I do not know what a STM-64c is. Such signal name is not > > > > defined in SDH. > > > > Sometimes people use this to indice a (physical) STM-64 > > > > signal with a VC-4-64c > > > > inside. There is no naming yet around that I am aware of > > to indicate > > > > semi-transparent STM-N signal transport; for this email let > > > > me refer to it as > > > > STM-64st. > > > > > > > > When you need to transport a STM-64 signal in a > > > > semi-transparent manner via a > > > > STM-256, the content of the STM-64st is not-relevant; i.e. > > > > the user may change > > > > this content as (s)he likes. That's why the request is > > for a STM-64st > > > > connection. > > > > > > > > Note that this semi-transparent STM-N transport is a > > > > work around in > > > > the absence of full transparency that is offered by > > WDM and OTN > > > > networks. SDH equipment that is capable to support this must > > > > configure its AU pointer processors into adaptive mode; > > > > i.e. these > > > > AU PPs must follow the incoming AU structure. In terms > > > > of GMPLS, the > > > > STM-Nst contains a AUG-N signal. > > > > > > > > If I assume maximum transparency to be requested, the > > > > following overhead needs > > > > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > > > > B1, B2, M0, M1. > > > > > > > > 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 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ST=11 | RCC=0 | NCC=0 > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | NVC=0 | Multiplier > > (MT)=1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Transparency (T)= 1 1 1 1 1 1 1 1 > > 0 1 1 1 0 0| > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > Concerning the label, there is essentially no definition of > > > > this in GMPLS > > > > SDH/SONET documents. We transport a STM-64st signal, not HOVC > > > > or LOVC signals > > > > for which the SUKLM label is specified. Nevertheless, I > > > > assume for this moment > > > > that the intention was to reuse the SUKLM label also here > > > > (Eric can we add this > > > > explicitly to > > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > > > > case the AUG-64 within the STM-64st is transported in > > > > timeslot EDCBA=20000 in > > > > STM-256, this then results in S=65 and UKLM=0000: > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | S=65 | U=0 | K=0 | > > L=0 | M=0 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > Regards, > > > > > > > > Maarten > > > > > > > > > > > > manoj juneja wrote: > > > > > > > > > > Hi Marteen, > > > > > Thank You for u prompt response. I have > > > > another doubt relate > > > > > to this one. If I want to allocate STM64c within STM-256, > > > > then what will be > > > > > the difference between the label value if I allocate > > VC-4-64c within > > > > > STM-256. As per my understanding, the transparency should > > > > also be included > > > > > in STM64c request (generalized label request object) and > > > > label will be same. > > > > > > > > > > Please comment. > > > > > > > > > > Regards, > > > > > manoj. > > > > > > > > > > >From: Maarten Vissers > > > > > >To: manoj juneja > > > > > >CC: ccamp@ops.ietf.org > > > > > >Subject: Re: STM-M out of STM-N (M > > > > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > > > > > > > >Manoj, > > > > > > > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > > > > You can allocate > > > > > >VC-4-64c link connection within a HOVC link. The > > > > associated timeslot is an > > > > > >AU-4-64c, which is identified in EDCBA terminology with > > > > 10000, 20000, > > > > > >30000, or > > > > > >40000. If you look in my g707-gmpls-label-conversion > > > > document, you see that > > > > > > > > > > > >10000 maps on S U = 1 0 > > > > > >20000 maps on S U = 65 0 > > > > > >30000 maps on S U = 129 0 > > > > > >40000 maps on S U = 193 0 > > > > > > > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > > > > > > > >As it is a contiguous concatenated signal, there is > > just 1 label, > > > > > >identifying > > > > > >the first timeslot. Assume you want to pass the VC-4-64c > > > > via AU-4-64c > > > > > >20000, > > > > > >then the label looks like: > > > > > > > > > > > > 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 > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > | ST=6 | RCC=1 | NCC=64 > > > > | > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > | NVC=0 | Multiplier > > > > (MT)=1 | > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > | Transparency (T)=0 > > > > | > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > > > > > > > 0 1 2 > > 3 > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > > > 7 8 9 0 1 > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > | S=65 | U=0 | K=0 | > > > > L=0 | M=0 | > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > > > > >Maarten > > > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > If I want to allocate STM-M from STM-N (M < N) > > > > then what will be > > > > > >the > > > > > > > label value in GMPLS ? I mean to say if I get a request > > > > to allocate > > > > > >STM-64 > > > > > > > from STM-256 link then what will be the label value > > > > (SUKLM) and how many > > > > > > > labels will be sent back in RESV message ? > > > > > > > > > > > > > > Please comment. > > > > > > > > > > > > > > Regards, > > > > > > > manoj > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > Get your FREE download of MSN Explorer at > > > > > >http://explorer.msn.com/intl.asp > > > > > ><< mvissers.vcf >> > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > > http://explorer.msn.com/intl.asp > > > > > > --------------5FCE85EFE4225242F535D38B 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 --------------5FCE85EFE4225242F535D38B-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 03:30:34 -0800 Message-Id: <4.3.2.7.2.20011119111717.03934fd8@europe.cisco.com> Date: Mon, 19 Nov 2001 12:21:20 +0100 To: ccamp@ops.ietf.org From: Francois Le Faucheur Subject: comments on draft-kompella-mpls-multiarea-te-02.txt Cc: flefauch@europe.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Kireeti, Yakov, Jean-Philippe, A few suggestions on the Multi-Area TE draft for your consideration: Independent per-area TE ======================= The draft currently restricts its scope of multiple-area TE to only those scenarios using LSPs that span multiple areas. Some SPs have/will deploy TE in multiple areas simply by running TE independently in each area. Although, this does not really require any specific new mechanisms, it is a valid scenario for doing TE in multi-area environments. So my suggestion would be to slightly broaden the scope of the draft (ie to not deliberately restrict it to the scenarios using inter-area LSPs) and include a section on the multiarea TE scenario where only intra-area LSPs are used. You could then clarify that no new mechanisms are required for this (only require that routers at boundary may have to keep TED from two areas). I think it would also be useful to highlight a few properties of such a deployment scenario (scalability/achieves kind of a natural "hierarchy" in the sense that you keep a small number of tunnels in the backbone area and packets from many leaf-area tunnels get aggregated into core-area tunnels, dynamic routing onto tunnels at Head-ends is somewhat simpler since Head-end IGP "sees" tail-end in its intra-area IGP Database, does not allow end-to-end control of smaller traffic trunks ie two traffic trunks from two head-end areas going to same tail-end cannot be "routed" separately in backbone area or tail-end area...). Reoptimisation ============== Since you discuss how "optimal" is the routing for each scenario of section 4, I'd suggest a clarifying statement that handling reoptimisation on a per-area basis does not allow "globally optimum" reoptimisation. I would also suggest adding a statement making it explicit that other methods of reoptimisation are possible which may reuse the mechanisms described earlier for initial path computation (e.g. Path Computation server). Vocab ===== in section 3, you clarify that you will be using OSPF terminology to dicuss both OSPF and ISIS. You mention "backbone area" as one such term. You may want to mention ABR as another. Typos/Editos ============= - 4.2: 2nd paragraph., last sentence. "LSR setup" should read "LSP setup". - 4.3: 2nd paragraph, 1st sentence . "in the tail-end area the head-end area)" should read " in the tail-end area" - 4.4: paragraph 5 and 7 say the same thing and should be combined. Hope this is useful Francois Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 03:22:49 -0800 Cc: "'Stephen Trowbridge'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Message-ID: <3BF8EAE5.301579AA@lucent.com> Date: Mon, 19 Nov 2001 12:20:05 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" Original-CC: "'Stephen Trowbridge'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------4652468562E8E3BB5C021B2A" This is a multi-part message in MIME format. --------------4652468562E8E3BB5C021B2A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, LCAS is added to the networks to resize the pipe over which e.g. Ethernet packets flow in a hitless manner. The A and Z endpoints need therefore to be synchronised at frame level. There is no alternative in the control plane which can support this. Looking at your simple example, I get the impression that you do not fully understand the use of the UNEQ value in C2/V5. The UNEQ value in C2/V5 is generated by the HOVC/LOVC connection function (see G.783) as part of the UNEQ VC-n signal generation process. The UNEQ value is not generated by the path termination function or its associated adaptation function. An adaptation function alsways generates an equipped-specific signal label (>= 2). So, as soon as the fabrics in the to be setup connection have setup their matrix connections, the VC-n path termination function will receive an equipped-specific signal label value, and consequently clears its UNEQ defect. I.e. the assumptions underlying your steps 2 to 6 are incorrect and not aligned with the SDH specifications in ITU-T. Regards, Maarten "Mannie, Eric" wrote: > > Hello Stephen > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > No, please see explanations below. > > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > No, please see below (C2 or V5 transition). > > >The compare/contrast discussion of LBM and LCAS is appropriate not > >because LCAS is "sacred", but because you are comparing apples to > >oranges. Statements in this document such as "One drawback of LCAS is .." > >are unnecessary and inappropriate in this context, since LBM does > >NOT solve the problem LCAS was designed to solve. Perhaps if you > >were solving the SAME problem better, this would be OK, but this > >is not the case. > > No, please see below. > > Simple example: > > 1) you first signal an additional VC/SPE to the destination (via a Path). > 2) the destination knows exactly which VC/SPE is added (via the label). > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > so the VC/SPE is not yet added to concatenated signal. > 4) then, you wait at the source for a confirmation from the destination > (i.e. Resv). > 5) the source "equip" the VC/SPE and sends. > 6) the destination sees in the POH that the VC is "equipped" (transition). > > The difference between LCAS and LBM is that LCAS uses an additional explicit > indication in the overhead to say "this is the payload" to use. LBM doesn't > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) > > LCAS uses a new field in the POH (CTRL) to know when the new VC transitions > to a significant payload. LBM proposes to do the same simply by looking at > the C2 (for HOVC) transition - regular SDH/SONET field that will change > anyway and that is used to indicate the type of payload. > > To be more precise about LCAS (I copy from the LCAS specification, section > 6.3.1): "The first container frame to contain payload data for the new > member shall be the container frame immediately following the container > frame that contained the last bit(s) (i.e. the CRC) of the control packet > with NORM/EOS message for that member" (the LCAS control packet). > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > the POH with the appropriate transition of its CTRL field. LBM waits simply > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > (don't change SDH/SONET). > > By the way, this is version 0 of the draft and it was just posted. > > Suggestions, technical comments and improvements are welcome. > > I would appreciate if people could first read and speak before shooting > directly :-) > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, November 16, 2001 7:49 PM > To: Mannie, Eric > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Eric, > The point of my earlier email (items again below, this time with > numbers) was not to prompt the comment "#3 is out of scope, therefore > it is a choice between #1 and #2" (my parsing of recent statements). > > The issue (and I think the reason for Maarten's strong reaction) is this: > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > GMPLS-LBM and LCAS ARE solutions to different problems. > (I hope this is not too subtle for non-native English speakers). > > LCAS is a method to hitlessly change the mappings at the two > ends of a virtually concatenated trail to increase or decrease the > bandwidth. It does not say anything about how components to be > added or removed from the virtually concatenated "bundle" are > set up or taken down. > > LBM talks about how to set up or take down those added or removed > components, but not about the details of changing the mapping (other > than that it is done after the new components are successfully > established. > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > The compare/contrast discussion of LBM and LCAS is appropriate not > because LCAS is "sacred", but because you are comparing apples to > oranges. Statements in this document such as "One drawback of LCAS is .." > are unnecessary and inappropriate in this context, since LBM does > NOT solve the problem LCAS was designed to solve. Perhaps if you > were solving the SAME problem better, this would be OK, but this > is not the case. > > Time to try to be constructive: > - I think most of the current discussion of LCAS should be removed from > this document. It is irrelevant since LCAS solves a different problem than > LBM. To say that one is "better" than the other would only be meaningful > if they were solving the same problem (can you really say that LBM solves > problem A better than LCAS solves problem B?). > - LCAS can be a good informative reference as a way to hitlessly modify > the size of a virtually concatenated trail. > - Clarify in the scope that the current draft describes the use of LBM > without LCAS, which results in a traffic glitch when bandwidth is modified. > Indicate that the use of LCAS to hitlessly negotiate the changes to > the size of virtually concatenated pipes after LBM sets up new component(s) > or before LBM takes down old component(s) is a topic for further study > and perhaps to be addressed in a future version of the draft. > > Regards, > Steve > > Steve Trowbridge wrote: > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > the traffic. > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > control plane knows that the different LSPs are part of the same > > circuit. > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > be the preferred method for many applications. > > "Mannie, Eric" wrote: > > > > Hello Maarten, > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > >understanding of LCAS's objective (my very strong opinion). > > > > Sorry, do you mean that it is forbidden to speak about your LCAS document > > and to compare GMPLS and LCAS functionalities ? > > > --------------4652468562E8E3BB5C021B2A 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 --------------4652468562E8E3BB5C021B2A-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 02:30:12 -0800 Message-ID: From: "Mannie, Eric" To: 'Dimitri Papadimitriou' , Steve West Cc: 'Stephen Trowbridge' , 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Mon, 19 Nov 2001 11:27:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Steve, Just to complement the answer of Dimitri, > You believe that the packet loss rate and robustness of LMB is > similar to LCAS ? LCAS waits for the end of control packet which is multi-framed to decide when the payload is significant (the "transition"). LBM uses for instance the C2 byte for the HOVC, since this byte appears directly in the POH and is not part of a control packet, that should go faster, right ? I.e. less glitch than with LCAS ? But having a field in the transport plane to indicate a transition (whatever is the field ) is not the most important issue. Even if you have that field, you need some time to provision the additional VCs/SPEs in the network. This is not done by LCAS, and any control plane or management plane will imply some time for that operation, and the glitch will really come from that process, not from the way that you detect a transition in the transport plane. > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > could potentially be used with GMPLS or with other control plane or > management plane mechanisms ? When a distributed control plane is used (e.g. GMPLS or PNNI), using LCAS implies issues on this control plane. LCAS is a stand-alone solution that bypass the control plane to change the resource reservation in both end systems. A control plane maintains states in end systems (e.g. at the UNI) and in intermediate systems ! So, bandwidth modifications must be reflected in the control plane otherwise it will become inconsistent. Now, the control plane is natively designed to deal with these resource reservations including in the source and the destination (with the UNI). Moreover, GMPLS is natively designed to deal with bandwidth modification (in the packet world this was one of the major requirements). Originally, we just wanted to describe how to generalize these bandwidth modification principles to SDH/SONET and how to interwork with LCAS. Then, we saw that a large part of LCAS was overlapping with GMPLS, i.e. all the protocol part. The rest was the issue about when to decide that a VC/SPE contains real user data or not (the transition). Since LCAS added a control message, naturally it used a field in that control message to indicate that transition. But with GMPLS we didn't need any new control message, se we looked at what was available *in the transport plane* to detect the fact that a VC/SPE contains now real user data (i.e the transition). We found natural to use the so-called SDH/SONET "signal label" (e.g. the C2 byte) (note for the readers: nothing to do with the GMPLS label :-). So we added these aspects to the draft. This is the part that we expected to validate with the ITU-T/T1X1 folks, but flames came first... What we are certainly going to do, is to add in the draft a section about how GMPLS should work when LCAS is used at the same time. However, we think that using GMPLS and LCAS at the same time will be more complex than simply using GMPLS and will not bring something additional. So the natural observation came, "why should we use LCAS with GMPLS and build something more complex when there is almost no issue to solve when simply using GMPLS alone". Using GMPLS and LCAS at the same time to modify the bandwidth implies that we will have two signaling flows between the source and the destination running in parallel and overlapping. GMPLS will also speak with the source and the destination to do the same as LCAS, and with a distributed control plane you need GMPLS anyway (or PNNI or etc). We also added a section to explain how several GMPLS LSPs (i.e. circuits) can be combined together to form a larger virtually concatenated circuit. This allows to deal with the non co-routing of VCs/SPEs with GMPLS. Kind regards, Eric -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Sunday, November 18, 2001 3:44 PM To: Steve West Cc: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers'; ccamp; q11/15; t1x1.5 Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hi Steve, Thanks for your comments, see in-line... Steve West wrote: > > Dimitri: > > Please confirm my understanding of your proposal: > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > changes that occurs during transmission of a packet will not corrupt that > packet.) You believe that the packet loss rate and robustness of LMB is > similar to LCAS ? It is mentioned in the proposal that the source waits for a confirmation from the destination (i.e. Resv Message). THEN the source "equip" the VC/SPE and sends. After the destination sees in the POH that the VC is "equipped" (transition). So instead of using the transitions proposed in LCAS (based on the H4 CTRL words) we use the ones already available. Since we are the beginning, we were very cautious but we expect to reach more than reasonable robustness and reliability. > 2. LMB requires hardware coordination between the SONET payload mapper and > the SONET POH processor (C2 octet insertion/extraction logic) ? At the transport plane level C2 is the field that LBM uses for the transition in the HOVC POH. > 3. The hardware based synchronization performance requirements are similar > to those required by LCAS. Except that LCAS coordinates the critical > transitions using H4 instead of C2 ? And that Virtual Concatenation systems > require to coordinate their payload mappers with bits 1-4 of the H4 byte to > determine the sequence number anyway ? See above, yes and yes (since we re-use existing VC mechanisms) > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > could potentially be used with GMPLS or with other control plane or > management plane mechanisms ? The scope of this proposal is to use GMPLS-LBM without LCAS. In fact (from what i understand in your question) see it more from transport to control plane impact taking the assumption that you expect some hardware improvement. Let's first determine if this can be achieved and then discuss the implementation issues that can arise from this proposal. In a sense, GMPLS-LBM is a self-consistent solution. Regards, - dimitri. > Thanks, > > Steve > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Friday, November 16, 2001 4:09 PM > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > Cc: ccamp; q11/15; t1x1.5 > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Hi folks, > > What happens... when we start the technical discussion > all guys taking part to the previous one now are gone ? > > We would like to start a technical discussion.. rather > difficult if we stay alone... or everybody agree on > proposal made in the previous e-mail ? (this in order > to refine the mechanism detailed in the GMPLS LBM I-D.) > > Any technical feedback is highly appreciated. > > Cheers, > - dimitri. > > "Mannie, Eric" wrote: > > > > Hello Stephen > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > No, please see explanations below. > > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > No, please see below (C2 or V5 transition). > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > >because LCAS is "sacred", but because you are comparing apples to > > >oranges. Statements in this document such as "One drawback of LCAS is .." > > >are unnecessary and inappropriate in this context, since LBM does > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > >were solving the SAME problem better, this would be OK, but this > > >is not the case. > > > > No, please see below. > > > > Simple example: > > > > 1) you first signal an additional VC/SPE to the destination (via a Path). > > 2) the destination knows exactly which VC/SPE is added (via the label). > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > so the VC/SPE is not yet added to concatenated signal. > > 4) then, you wait at the source for a confirmation from the destination > > (i.e. Resv). > > 5) the source "equip" the VC/SPE and sends. > > 6) the destination sees in the POH that the VC is "equipped" (transition). > > > > The difference between LCAS and LBM is that LCAS uses an additional > explicit > > indication in the overhead to say "this is the payload" to use. LBM > doesn't > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > :-) > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > transitions > > to a significant payload. LBM proposes to do the same simply by looking at > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > anyway and that is used to indicate the type of payload. > > > > To be more precise about LCAS (I copy from the LCAS specification, section > > 6.3.1): "The first container frame to contain payload data for the new > > member shall be the container frame immediately following the container > > frame that contained the last bit(s) (i.e. the CRC) of the control packet > > with NORM/EOS message for that member" (the LCAS control packet). > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > > the POH with the appropriate transition of its CTRL field. LBM waits > simply > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > (don't change SDH/SONET). > > > > By the way, this is version 0 of the draft and it was just posted. > > > > Suggestions, technical comments and improvements are welcome. > > > > I would appreciate if people could first read and speak before shooting > > directly :-) > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Friday, November 16, 2001 7:49 PM > > To: Mannie, Eric > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Eric, > > The point of my earlier email (items again below, this time with > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > The issue (and I think the reason for Maarten's strong reaction) is this: > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > GMPLS-LBM and LCAS ARE solutions to different problems. > > (I hope this is not too subtle for non-native English speakers). > > > > LCAS is a method to hitlessly change the mappings at the two > > ends of a virtually concatenated trail to increase or decrease the > > bandwidth. It does not say anything about how components to be > > added or removed from the virtually concatenated "bundle" are > > set up or taken down. > > > > LBM talks about how to set up or take down those added or removed > > components, but not about the details of changing the mapping (other > > than that it is done after the new components are successfully > > established. > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > because LCAS is "sacred", but because you are comparing apples to > > oranges. Statements in this document such as "One drawback of LCAS is .." > > are unnecessary and inappropriate in this context, since LBM does > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > were solving the SAME problem better, this would be OK, but this > > is not the case. > > > > Time to try to be constructive: > > - I think most of the current discussion of LCAS should be removed from > > this document. It is irrelevant since LCAS solves a different problem than > > LBM. To say that one is "better" than the other would only be meaningful > > if they were solving the same problem (can you really say that LBM solves > > problem A better than LCAS solves problem B?). > > - LCAS can be a good informative reference as a way to hitlessly modify > > the size of a virtually concatenated trail. > > - Clarify in the scope that the current draft describes the use of LBM > > without LCAS, which results in a traffic glitch when bandwidth is > modified. > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > the size of virtually concatenated pipes after LBM sets up new > component(s) > > or before LBM takes down old component(s) is a topic for further study > > and perhaps to be addressed in a future version of the draft. > > > > Regards, > > Steve > > > > Steve Trowbridge wrote: > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > the traffic. > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > control plane knows that the different LSPs are part of the same > > > circuit. > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > be the preferred method for many applications. > > > > "Mannie, Eric" wrote: > > > > > > Hello Maarten, > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > document > > > and to compare GMPLS and LCAS functionalities ? > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 02:27:41 -0800 Message-ID: From: Heiles Juergen To: "'Maarten Vissers'" , "Karmakar, Soumen" Cc: ccamp@ops.ietf.org Subject: RE: STM-M out of STM-N (M -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Monday, November 19, 2001 11:04 AM > To: Karmakar, Soumen > Cc: ccamp@ops.ietf.org > Subject: Re: STM-M out of STM-N (M > > Soumen, > > "Karmakar, Soumen" wrote: > > > > Does this mean that the STM64 signal type (as requested in > sonet/sdh tSpec) > > can be carried in the STM256 link type ? > > No; an STM-64 can NOT be carried in a STM-256. > > > However this is possible by carrying the VC-4-64c with > transport overhead > > only , even though the user specifies just STM64 signal type ? > > A VC-4-64c + TOH [in SDH terms SOH] is the complete STM-64. A > STM-64 can not be > carried by a STM-256. A user should thus not request this > from the SDH/SONET > network, as its request will be rejected. > > As a workaround for more transparency for the short term, a > number of vendors > are adding the ability to transport a SUBSET of the user's > STM-N SOH/OC-N TOH > bytes via the STM-M/OC-M (line) interfaces. I am referring to that as > semi-transparent STM-N (STM-Nst) transport. Some dedicated > subnetworks will be > supporting this workaround, but do not consider this as a > general available > feature in the network. > > The mainstream SDH/SONET networks support LOVC/VT and > HOVC/STS signal transport. > And via these two also PDH signal (DS1, E1, E3, DS3, E4) > transport, and more > recently also Ethernet transport. > > STM-N/OC-N transport is supported via pre-OTN/WDM line > systems and photonic > cross connects as "STM-N/OC-N signal" transport. Switching is > just fine in this > case, but monitoring the quality of service for performance > and fault management > is very limited in this case. For the case of pre-OTN/WDM > networks with a > control plane on top, some of these limitations can be > removed by adding LMP. > The more general resolution (switched and non-switched > networks) for this > monitoring issue is the addition of OTN. With the > introduction of OTN, monitored > STM-N/OC-N signal transport will be supported via the ODUk > signals (i.e. similar > to PDH over SDH/SONET). > > > And the list of valid labels in this case should be > > S = 1,65, 129, 193 and UKLM = 0,0,0 ? > > For the case of STM-64st connection setup these are the valid labels. > > Note - STM-64st is essentially an AUG-64 with some of the > SOH/TOH as specified in the Transparency field. > > For case of a VC-4-64c connection setup, these are also the > valid labels. > > > Furthermore in the example that you showed below with the > following fields > > as : > > ST = 6 (VC4) , RCC =1, NCC =64, NVC =0, MT =1, T =0. > > This is a request for a VC-4-64c connection. > > > and why not > > ST = 11 (STM64) , RCC=0, NCC=0, NVC=0, MT= 1, T = 6 or 7 > (110 or 111) ? > > T_flag_1: RS layer transparency; i.e. RSOH transparency > T_flag_2: MS layer transparency; i.e. MSOH transparency > T_flag_3: RSOH J0 transparency > > T = T_flag_msb ... T_flag_lsb = T_flag_3, T_flag_2, T_flag_1 > > T = 110 implies MSOH + RSOH-J0 transparency > T = 111 implies RSOH + MSOH transparency ==> i.e. T_flag_3 is > redundant > > T = 110 is a request for a STM-64 Multiplex Section > connection which is also > transparent for RSOH-J0. This is not the same as a fully > transparent STM-64 > connection. I can not be supported by an SDH/sONET network as > Juergen described; > it may be possible to support this signal over a series of > SDH/SONET repeaters > (if these can pass through J0). > > T = 111 (or better T = 11) is a request for a STM-64 connection (fully > transparent) and can only be supported by pre-OTN/WDM or OTN networks. > > Regards, > > Maarten > > > assuming full transparency support. > > > > Thanks, > > Soumen > > > > > -----Original Message----- > > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > > Sent: Wednesday, November 14, 2001 12:57 AM > > > To: manoj juneja > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: STM-M out of STM-N (M > > > > > > > > Manoj, > > > > > > I do not know what a STM-64c is. Such signal name is not > > > defined in SDH. > > > Sometimes people use this to indice a (physical) STM-64 > > > signal with a VC-4-64c > > > inside. There is no naming yet around that I am aware of > to indicate > > > semi-transparent STM-N signal transport; for this email let > > > me refer to it as > > > STM-64st. > > > > > > When you need to transport a STM-64 signal in a > > > semi-transparent manner via a > > > STM-256, the content of the STM-64st is not-relevant; i.e. > > > the user may change > > > this content as (s)he likes. That's why the request is > for a STM-64st > > > connection. > > > > > > Note that this semi-transparent STM-N transport is a > > > work around in > > > the absence of full transparency that is offered by > WDM and OTN > > > networks. SDH equipment that is capable to support this must > > > configure its AU pointer processors into adaptive mode; > > > i.e. these > > > AU PPs must follow the incoming AU structure. In terms > > > of GMPLS, the > > > STM-Nst contains a AUG-N signal. > > > > > > If I assume maximum transparency to be requested, the > > > following overhead needs > > > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > > > B1, B2, M0, M1. > > > > > > 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ST=11 | RCC=0 | NCC=0 > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | NVC=0 | Multiplier > (MT)=1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Transparency (T)= 1 1 1 1 1 1 1 1 > 0 1 1 1 0 0| > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Concerning the label, there is essentially no definition of > > > this in GMPLS > > > SDH/SONET documents. We transport a STM-64st signal, not HOVC > > > or LOVC signals > > > for which the SUKLM label is specified. Nevertheless, I > > > assume for this moment > > > that the intention was to reuse the SUKLM label also here > > > (Eric can we add this > > > explicitly to > > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > > > case the AUG-64 within the STM-64st is transported in > > > timeslot EDCBA=20000 in > > > STM-256, this then results in S=65 and UKLM=0000: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | S=65 | U=0 | K=0 | > L=0 | M=0 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Regards, > > > > > > Maarten > > > > > > > > > manoj juneja wrote: > > > > > > > > Hi Marteen, > > > > Thank You for u prompt response. I have > > > another doubt relate > > > > to this one. If I want to allocate STM64c within STM-256, > > > then what will be > > > > the difference between the label value if I allocate > VC-4-64c within > > > > STM-256. As per my understanding, the transparency should > > > also be included > > > > in STM64c request (generalized label request object) and > > > label will be same. > > > > > > > > Please comment. > > > > > > > > Regards, > > > > manoj. > > > > > > > > >From: Maarten Vissers > > > > >To: manoj juneja > > > > >CC: ccamp@ops.ietf.org > > > > >Subject: Re: STM-M out of STM-N (M > > > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > > > > > >Manoj, > > > > > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > > > You can allocate > > > > >VC-4-64c link connection within a HOVC link. The > > > associated timeslot is an > > > > >AU-4-64c, which is identified in EDCBA terminology with > > > 10000, 20000, > > > > >30000, or > > > > >40000. If you look in my g707-gmpls-label-conversion > > > document, you see that > > > > > > > > > >10000 maps on S U = 1 0 > > > > >20000 maps on S U = 65 0 > > > > >30000 maps on S U = 129 0 > > > > >40000 maps on S U = 193 0 > > > > > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > > > > > >As it is a contiguous concatenated signal, there is > just 1 label, > > > > >identifying > > > > >the first timeslot. Assume you want to pass the VC-4-64c > > > via AU-4-64c > > > > >20000, > > > > >then the label looks like: > > > > > > > > > > 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 > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | ST=6 | RCC=1 | NCC=64 > > > | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | NVC=0 | Multiplier > > > (MT)=1 | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Transparency (T)=0 > > > | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > > > > 0 1 2 > 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > > 7 8 9 0 1 > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | S=65 | U=0 | K=0 | > > > L=0 | M=0 | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > > > >Regards, > > > > > > > > > >Maarten > > > > > > > > > >manoj juneja wrote: > > > > > > > > > > > > Hi All, > > > > > > If I want to allocate STM-M from STM-N (M < N) > > > then what will be > > > > >the > > > > > > label value in GMPLS ? I mean to say if I get a request > > > to allocate > > > > >STM-64 > > > > > > from STM-256 link then what will be the label value > > > (SUKLM) and how many > > > > > > labels will be sent back in RESV message ? > > > > > > > > > > > > Please comment. > > > > > > > > > > > > Regards, > > > > > > manoj > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > Get your FREE download of MSN Explorer at > > > > >http://explorer.msn.com/intl.asp > > > > ><< mvissers.vcf >> > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > > http://explorer.msn.com/intl.asp > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Nov 2001 02:11:51 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3BF8D91C.E0E6EC3E@lucent.com> Date: Mon, 19 Nov 2001 11:04:12 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "Karmakar, Soumen" Original-CC: ccamp@ops.ietf.org Subject: Re: STM-M out of STM-N (M > Does this mean that the STM64 signal type (as requested in sonet/sdh tSpec) > can be carried in the STM256 link type ? No; an STM-64 can NOT be carried in a STM-256. > However this is possible by carrying the VC-4-64c with transport overhead > only , even though the user specifies just STM64 signal type ? A VC-4-64c + TOH [in SDH terms SOH] is the complete STM-64. A STM-64 can not be carried by a STM-256. A user should thus not request this from the SDH/SONET network, as its request will be rejected. As a workaround for more transparency for the short term, a number of vendors are adding the ability to transport a SUBSET of the user's STM-N SOH/OC-N TOH bytes via the STM-M/OC-M (line) interfaces. I am referring to that as semi-transparent STM-N (STM-Nst) transport. Some dedicated subnetworks will be supporting this workaround, but do not consider this as a general available feature in the network. The mainstream SDH/SONET networks support LOVC/VT and HOVC/STS signal transport. And via these two also PDH signal (DS1, E1, E3, DS3, E4) transport, and more recently also Ethernet transport. STM-N/OC-N transport is supported via pre-OTN/WDM line systems and photonic cross connects as "STM-N/OC-N signal" transport. Switching is just fine in this case, but monitoring the quality of service for performance and fault management is very limited in this case. For the case of pre-OTN/WDM networks with a control plane on top, some of these limitations can be removed by adding LMP. The more general resolution (switched and non-switched networks) for this monitoring issue is the addition of OTN. With the introduction of OTN, monitored STM-N/OC-N signal transport will be supported via the ODUk signals (i.e. similar to PDH over SDH/SONET). > And the list of valid labels in this case should be > S = 1,65, 129, 193 and UKLM = 0,0,0 ? For the case of STM-64st connection setup these are the valid labels. Note - STM-64st is essentially an AUG-64 with some of the SOH/TOH as specified in the Transparency field. For case of a VC-4-64c connection setup, these are also the valid labels. > Furthermore in the example that you showed below with the following fields > as : > ST = 6 (VC4) , RCC =1, NCC =64, NVC =0, MT =1, T =0. This is a request for a VC-4-64c connection. > and why not > ST = 11 (STM64) , RCC=0, NCC=0, NVC=0, MT= 1, T = 6 or 7 (110 or 111) ? T_flag_1: RS layer transparency; i.e. RSOH transparency T_flag_2: MS layer transparency; i.e. MSOH transparency T_flag_3: RSOH J0 transparency T = T_flag_msb ... T_flag_lsb = T_flag_3, T_flag_2, T_flag_1 T = 110 implies MSOH + RSOH-J0 transparency T = 111 implies RSOH + MSOH transparency ==> i.e. T_flag_3 is redundant T = 110 is a request for a STM-64 Multiplex Section connection which is also transparent for RSOH-J0. This is not the same as a fully transparent STM-64 connection. I can not be supported by an SDH/sONET network as Juergen described; it may be possible to support this signal over a series of SDH/SONET repeaters (if these can pass through J0). T = 111 (or better T = 11) is a request for a STM-64 connection (fully transparent) and can only be supported by pre-OTN/WDM or OTN networks. Regards, Maarten > assuming full transparency support. > > Thanks, > Soumen > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Wednesday, November 14, 2001 12:57 AM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: STM-M out of STM-N (M > > > > > Manoj, > > > > I do not know what a STM-64c is. Such signal name is not > > defined in SDH. > > Sometimes people use this to indice a (physical) STM-64 > > signal with a VC-4-64c > > inside. There is no naming yet around that I am aware of to indicate > > semi-transparent STM-N signal transport; for this email let > > me refer to it as > > STM-64st. > > > > When you need to transport a STM-64 signal in a > > semi-transparent manner via a > > STM-256, the content of the STM-64st is not-relevant; i.e. > > the user may change > > this content as (s)he likes. That's why the request is for a STM-64st > > connection. > > > > Note that this semi-transparent STM-N transport is a > > work around in > > the absence of full transparency that is offered by WDM and OTN > > networks. SDH equipment that is capable to support this must > > configure its AU pointer processors into adaptive mode; > > i.e. these > > AU PPs must follow the incoming AU structure. In terms > > of GMPLS, the > > STM-Nst contains a AUG-N signal. > > > > If I assume maximum transparency to be requested, the > > following overhead needs > > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > > B1, B2, M0, M1. > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ST=11 | RCC=0 | NCC=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | NVC=0 | Multiplier (MT)=1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Transparency (T)= 1 1 1 1 1 1 1 1 0 1 1 1 0 0| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Concerning the label, there is essentially no definition of > > this in GMPLS > > SDH/SONET documents. We transport a STM-64st signal, not HOVC > > or LOVC signals > > for which the SUKLM label is specified. Nevertheless, I > > assume for this moment > > that the intention was to reuse the SUKLM label also here > > (Eric can we add this > > explicitly to > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > > case the AUG-64 within the STM-64st is transported in > > timeslot EDCBA=20000 in > > STM-256, this then results in S=65 and UKLM=0000: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | S=65 | U=0 | K=0 | L=0 | M=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Regards, > > > > Maarten > > > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > Thank You for u prompt response. I have > > another doubt relate > > > to this one. If I want to allocate STM64c within STM-256, > > then what will be > > > the difference between the label value if I allocate VC-4-64c within > > > STM-256. As per my understanding, the transparency should > > also be included > > > in STM64c request (generalized label request object) and > > label will be same. > > > > > > Please comment. > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: STM-M out of STM-N (M > > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > > > >Manoj, > > > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > > You can allocate > > > >VC-4-64c link connection within a HOVC link. The > > associated timeslot is an > > > >AU-4-64c, which is identified in EDCBA terminology with > > 10000, 20000, > > > >30000, or > > > >40000. If you look in my g707-gmpls-label-conversion > > document, you see that > > > > > > > >10000 maps on S U = 1 0 > > > >20000 maps on S U = 65 0 > > > >30000 maps on S U = 129 0 > > > >40000 maps on S U = 193 0 > > > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > > > >As it is a contiguous concatenated signal, there is just 1 label, > > > >identifying > > > >the first timeslot. Assume you want to pass the VC-4-64c > > via AU-4-64c > > > >20000, > > > >then the label looks like: > > > > > > > > 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 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ST=6 | RCC=1 | NCC=64 > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | NVC=0 | Multiplier > > (MT)=1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Transparency (T)=0 > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | S=65 | U=0 | K=0 | > > L=0 | M=0 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I want to allocate STM-M from STM-N (M < N) > > then what will be > > > >the > > > > > label value in GMPLS ? I mean to say if I get a request > > to allocate > > > >STM-64 > > > > > from STM-256 link then what will be the label value > > (SUKLM) and how many > > > > > labels will be sent back in RESV message ? > > > > > > > > > > Please comment. > > > > > > > > > > Regards, > > > > > manoj > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > --------------4CCA87FEC55EB7F6E124DB6F 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 --------------4CCA87FEC55EB7F6E124DB6F-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Nov 2001 06:51:34 -0800 Message-ID: <3BF7C937.54D2BDB4@alcatel.be> Date: Sun, 18 Nov 2001 15:44:07 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Steve West CC: "Mannie, Eric" , "'Stephen Trowbridge'" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------10629FE344570C24A478439C" This is a multi-part message in MIME format. --------------10629FE344570C24A478439C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Steve, Thanks for your comments, see in-line... Steve West wrote: > > Dimitri: > > Please confirm my understanding of your proposal: > > 1. Your proposal supports hitless link capacity adjustment. (Capacity > changes that occurs during transmission of a packet will not corrupt that > packet.) You believe that the packet loss rate and robustness of LMB is > similar to LCAS ? It is mentioned in the proposal that the source waits for a confirmation from the destination (i.e. Resv Message). THEN the source "equip" the VC/SPE and sends. After the destination sees in the POH that the VC is "equipped" (transition). So instead of using the transitions proposed in LCAS (based on the H4 CTRL words) we use the ones already available. Since we are the beginning, we were very cautious but we expect to reach more than reasonable robustness and reliability. > 2. LMB requires hardware coordination between the SONET payload mapper and > the SONET POH processor (C2 octet insertion/extraction logic) ? At the transport plane level C2 is the field that LBM uses for the transition in the HOVC POH. > 3. The hardware based synchronization performance requirements are similar > to those required by LCAS. Except that LCAS coordinates the critical > transitions using H4 instead of C2 ? And that Virtual Concatenation systems > require to coordinate their payload mappers with bits 1-4 of the H4 byte to > determine the sequence number anyway ? See above, yes and yes (since we re-use existing VC mechanisms) > 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS > could potentially be used with GMPLS or with other control plane or > management plane mechanisms ? The scope of this proposal is to use GMPLS-LBM without LCAS. In fact (from what i understand in your question) see it more from transport to control plane impact taking the assumption that you expect some hardware improvement. Let's first determine if this can be achieved and then discuss the implementation issues that can arise from this proposal. In a sense, GMPLS-LBM is a self-consistent solution. Regards, - dimitri. > Thanks, > > Steve > > -----Original Message----- > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Sent: Friday, November 16, 2001 4:09 PM > To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' > Cc: ccamp; q11/15; t1x1.5 > Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Hi folks, > > What happens... when we start the technical discussion > all guys taking part to the previous one now are gone ? > > We would like to start a technical discussion.. rather > difficult if we stay alone... or everybody agree on > proposal made in the previous e-mail ? (this in order > to refine the mechanism detailed in the GMPLS LBM I-D.) > > Any technical feedback is highly appreciated. > > Cheers, > - dimitri. > > "Mannie, Eric" wrote: > > > > Hello Stephen > > > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > > > No, please see explanations below. > > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > No, please see below (C2 or V5 transition). > > > > >The compare/contrast discussion of LBM and LCAS is appropriate not > > >because LCAS is "sacred", but because you are comparing apples to > > >oranges. Statements in this document such as "One drawback of LCAS is .." > > >are unnecessary and inappropriate in this context, since LBM does > > >NOT solve the problem LCAS was designed to solve. Perhaps if you > > >were solving the SAME problem better, this would be OK, but this > > >is not the case. > > > > No, please see below. > > > > Simple example: > > > > 1) you first signal an additional VC/SPE to the destination (via a Path). > > 2) the destination knows exactly which VC/SPE is added (via the label). > > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > > so the VC/SPE is not yet added to concatenated signal. > > 4) then, you wait at the source for a confirmation from the destination > > (i.e. Resv). > > 5) the source "equip" the VC/SPE and sends. > > 6) the destination sees in the POH that the VC is "equipped" (transition). > > > > The difference between LCAS and LBM is that LCAS uses an additional > explicit > > indication in the overhead to say "this is the payload" to use. LBM > doesn't > > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead > :-) > > > > LCAS uses a new field in the POH (CTRL) to know when the new VC > transitions > > to a significant payload. LBM proposes to do the same simply by looking at > > the C2 (for HOVC) transition - regular SDH/SONET field that will change > > anyway and that is used to indicate the type of payload. > > > > To be more precise about LCAS (I copy from the LCAS specification, section > > 6.3.1): "The first container frame to contain payload data for the new > > member shall be the container frame immediately following the container > > frame that contained the last bit(s) (i.e. the CRC) of the control packet > > with NORM/EOS message for that member" (the LCAS control packet). > > > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > > the POH with the appropriate transition of its CTRL field. LBM waits > simply > > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > > (don't change SDH/SONET). > > > > By the way, this is version 0 of the draft and it was just posted. > > > > Suggestions, technical comments and improvements are welcome. > > > > I would appreciate if people could first read and speak before shooting > > directly :-) > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > > Sent: Friday, November 16, 2001 7:49 PM > > To: Mannie, Eric > > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > Eric, > > The point of my earlier email (items again below, this time with > > numbers) was not to prompt the comment "#3 is out of scope, therefore > > it is a choice between #1 and #2" (my parsing of recent statements). > > > > The issue (and I think the reason for Maarten's strong reaction) is this: > > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > > GMPLS-LBM and LCAS ARE solutions to different problems. > > (I hope this is not too subtle for non-native English speakers). > > > > LCAS is a method to hitlessly change the mappings at the two > > ends of a virtually concatenated trail to increase or decrease the > > bandwidth. It does not say anything about how components to be > > added or removed from the virtually concatenated "bundle" are > > set up or taken down. > > > > LBM talks about how to set up or take down those added or removed > > components, but not about the details of changing the mapping (other > > than that it is done after the new components are successfully > > established. > > > > If you use LBM and change the mappings at the two ends without some > > coordination such as LCAS, you will have a glitch to the traffic > > (I think this is simple enough). > > > > The compare/contrast discussion of LBM and LCAS is appropriate not > > because LCAS is "sacred", but because you are comparing apples to > > oranges. Statements in this document such as "One drawback of LCAS is .." > > are unnecessary and inappropriate in this context, since LBM does > > NOT solve the problem LCAS was designed to solve. Perhaps if you > > were solving the SAME problem better, this would be OK, but this > > is not the case. > > > > Time to try to be constructive: > > - I think most of the current discussion of LCAS should be removed from > > this document. It is irrelevant since LCAS solves a different problem than > > LBM. To say that one is "better" than the other would only be meaningful > > if they were solving the same problem (can you really say that LBM solves > > problem A better than LCAS solves problem B?). > > - LCAS can be a good informative reference as a way to hitlessly modify > > the size of a virtually concatenated trail. > > - Clarify in the scope that the current draft describes the use of LBM > > without LCAS, which results in a traffic glitch when bandwidth is > modified. > > Indicate that the use of LCAS to hitlessly negotiate the changes to > > the size of virtually concatenated pipes after LBM sets up new > component(s) > > or before LBM takes down old component(s) is a topic for further study > > and perhaps to be addressed in a future version of the draft. > > > > Regards, > > Steve > > > > Steve Trowbridge wrote: > > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > > the traffic. > > > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > > control plane knows that the different LSPs are part of the same > > > circuit. > > > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > > be the preferred method for many applications. > > > > "Mannie, Eric" wrote: > > > > > > Hello Maarten, > > > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > > >understanding of LCAS's objective (my very strong opinion). > > > > > > Sorry, do you mean that it is forbidden to speak about your LCAS > document > > > and to compare GMPLS and LCAS functionalities ? > > > > > --------------10629FE344570C24A478439C Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------10629FE344570C24A478439C-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 Nov 2001 13:32:13 -0800 Message-ID: <36EF020032CFD411B7B400508B55E59019EFB4@milan.turinnetworks.com> From: Steve West To: 'Dimitri Papadimitriou' , "Mannie, Eric" , 'Stephen Trowbridge' , 'Maarten Vissers' Cc: ccamp , q11/15 , "t1x1.5" Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Sat, 17 Nov 2001 13:26:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri: Please confirm my understanding of your proposal: 1. Your proposal supports hitless link capacity adjustment. (Capacity changes that occurs during transmission of a packet will not corrupt that packet.) You believe that the packet loss rate and robustness of LMB is similar to LCAS ? 2. LMB requires hardware coordination between the SONET payload mapper and the SONET POH processor (C2 octet insertion/extraction logic) ? 3. The hardware based synchronization performance requirements are similar to those required by LCAS. Except that LCAS coordinates the critical transitions using H4 instead of C2 ? And that Virtual Concatenation systems require to coordinate their payload mappers with bits 1-4 of the H4 byte to determine the sequence number anyway ? 4. LBM is an extension to GMPLS. GMPLS is required for LBM, whereas LCAS could potentially be used with GMPLS or with other control plane or management plane mechanisms ? Thanks, Steve -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Friday, November 16, 2001 4:09 PM To: Mannie, Eric; 'Stephen Trowbridge'; 'Maarten Vissers' Cc: ccamp; q11/15; t1x1.5 Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hi folks, What happens... when we start the technical discussion all guys taking part to the previous one now are gone ? We would like to start a technical discussion.. rather difficult if we stay alone... or everybody agree on proposal made in the previous e-mail ? (this in order to refine the mechanism detailed in the GMPLS LBM I-D.) Any technical feedback is highly appreciated. Cheers, - dimitri. "Mannie, Eric" wrote: > > Hello Stephen > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > No, please see explanations below. > > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > No, please see below (C2 or V5 transition). > > >The compare/contrast discussion of LBM and LCAS is appropriate not > >because LCAS is "sacred", but because you are comparing apples to > >oranges. Statements in this document such as "One drawback of LCAS is .." > >are unnecessary and inappropriate in this context, since LBM does > >NOT solve the problem LCAS was designed to solve. Perhaps if you > >were solving the SAME problem better, this would be OK, but this > >is not the case. > > No, please see below. > > Simple example: > > 1) you first signal an additional VC/SPE to the destination (via a Path). > 2) the destination knows exactly which VC/SPE is added (via the label). > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > so the VC/SPE is not yet added to concatenated signal. > 4) then, you wait at the source for a confirmation from the destination > (i.e. Resv). > 5) the source "equip" the VC/SPE and sends. > 6) the destination sees in the POH that the VC is "equipped" (transition). > > The difference between LCAS and LBM is that LCAS uses an additional explicit > indication in the overhead to say "this is the payload" to use. LBM doesn't > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) > > LCAS uses a new field in the POH (CTRL) to know when the new VC transitions > to a significant payload. LBM proposes to do the same simply by looking at > the C2 (for HOVC) transition - regular SDH/SONET field that will change > anyway and that is used to indicate the type of payload. > > To be more precise about LCAS (I copy from the LCAS specification, section > 6.3.1): "The first container frame to contain payload data for the new > member shall be the container frame immediately following the container > frame that contained the last bit(s) (i.e. the CRC) of the control packet > with NORM/EOS message for that member" (the LCAS control packet). > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > the POH with the appropriate transition of its CTRL field. LBM waits simply > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > (don't change SDH/SONET). > > By the way, this is version 0 of the draft and it was just posted. > > Suggestions, technical comments and improvements are welcome. > > I would appreciate if people could first read and speak before shooting > directly :-) > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, November 16, 2001 7:49 PM > To: Mannie, Eric > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Eric, > The point of my earlier email (items again below, this time with > numbers) was not to prompt the comment "#3 is out of scope, therefore > it is a choice between #1 and #2" (my parsing of recent statements). > > The issue (and I think the reason for Maarten's strong reaction) is this: > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > GMPLS-LBM and LCAS ARE solutions to different problems. > (I hope this is not too subtle for non-native English speakers). > > LCAS is a method to hitlessly change the mappings at the two > ends of a virtually concatenated trail to increase or decrease the > bandwidth. It does not say anything about how components to be > added or removed from the virtually concatenated "bundle" are > set up or taken down. > > LBM talks about how to set up or take down those added or removed > components, but not about the details of changing the mapping (other > than that it is done after the new components are successfully > established. > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > The compare/contrast discussion of LBM and LCAS is appropriate not > because LCAS is "sacred", but because you are comparing apples to > oranges. Statements in this document such as "One drawback of LCAS is .." > are unnecessary and inappropriate in this context, since LBM does > NOT solve the problem LCAS was designed to solve. Perhaps if you > were solving the SAME problem better, this would be OK, but this > is not the case. > > Time to try to be constructive: > - I think most of the current discussion of LCAS should be removed from > this document. It is irrelevant since LCAS solves a different problem than > LBM. To say that one is "better" than the other would only be meaningful > if they were solving the same problem (can you really say that LBM solves > problem A better than LCAS solves problem B?). > - LCAS can be a good informative reference as a way to hitlessly modify > the size of a virtually concatenated trail. > - Clarify in the scope that the current draft describes the use of LBM > without LCAS, which results in a traffic glitch when bandwidth is modified. > Indicate that the use of LCAS to hitlessly negotiate the changes to > the size of virtually concatenated pipes after LBM sets up new component(s) > or before LBM takes down old component(s) is a topic for further study > and perhaps to be addressed in a future version of the draft. > > Regards, > Steve > > Steve Trowbridge wrote: > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > the traffic. > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > control plane knows that the different LSPs are part of the same > > circuit. > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > be the preferred method for many applications. > > "Mannie, Eric" wrote: > > > > Hello Maarten, > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > >understanding of LCAS's objective (my very strong opinion). > > > > Sorry, do you mean that it is forbidden to speak about your LCAS document > > and to compare GMPLS and LCAS functionalities ? > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 21:31:12 -0800 From: "manoj juneja" To: ssaha@netplane.com, ccamp@ops.ietf.org Bcc: Subject: Re: position of ADMIN_STATUS object in RESV message Date: Fri, 16 Nov 2001 22:28:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Did anyone answer this one ? >From: "Saha, Sayandeb" >To: "'ccamp@ops.ietf.org'" >Subject: position of ADMIN_STATUS object in RESV message >Date: Thu, 15 Nov 2001 14:46:03 -0500 > >Hi, >Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the >admin_status as not being a >part of the in the RESV message. >This works fine for the FF style of reservation. >But for the SE style of reservation if just one filter is taken out by >setting the D bit in admin status, >all others must go down because the admin_status applies for the entire >RESV >instead of just the particular >filter in question. >Or for that matter if only one filter's state(LSP) is taken >administratively >down( by setting A bit), it will now apply to all filters >Is this intended? Or is it the optical world will never do SE style >reservations? Am I missing something here? >-Sayan > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 16:56:05 -0800 Message-ID: From: "Karmakar, Soumen" To: "'Yakov Rekhter'" Cc: "'ccamp@ops.ietf.org'" Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 Date: Fri, 16 Nov 2001 16:53:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hi Yakov, Was there a decision taken on this and reflected in drafts (or to come) of the removal of COMPONENT_IF_UPSTREAM ? Or that the type is supported and may not be used. The UNI specifications mandates that both upstream and downstream component id must be specified for bidirectional connection. Will these also be reflected in the OUNI (oif2000.125.7) specification ? Thanks, Soumen > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Thursday, September 13, 2001 6:58 AM > To: Edward Harrison > Cc: 'Yakov Rekhter'; Nic Larkin; 'ccamp@ops.ietf.org' > Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 > > > Ed, > > > Can you clarify whether you are proposing removing the > COMPONENT_IF_UPSTREAM > > TLV from the INTERFACE_ID hop object (or were you just > saying that Steve > > needn't use it if he doesn't want to)? > > I am proposing to remove the COMPONENT_IF_UPSTREAM. > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 16:27:15 -0800 From: "Prashant Sharma" To: ccamp@ops.ietf.org Bcc: Subject: Question regarding LSC interface.. Date: Sat, 17 Nov 2001 00:24:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, I have one question regarding the allocation of unnumbered component interface identifiers. In lambda switch capable interfaces, is it that each wavelength is assigned a unique component identifiers or the fiber containing multiple lambda is assigned a component identifier. In case the former is true, does not it mean that label is similar to component interface id. regards Prashant. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 16:12:35 -0800 Message-ID: <3BF5AAB0.959BCBE0@alcatel.be> Date: Sat, 17 Nov 2001 01:09:20 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: "Mannie, Eric" , "'Stephen Trowbridge'" , "'Maarten Vissers'" CC: ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------B69D64FA575D21EA85B9B5C5" This is a multi-part message in MIME format. --------------B69D64FA575D21EA85B9B5C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, What happens... when we start the technical discussion all guys taking part to the previous one now are gone ? We would like to start a technical discussion.. rather difficult if we stay alone... or everybody agree on proposal made in the previous e-mail ? (this in order to refine the mechanism detailed in the GMPLS LBM I-D.) Any technical feedback is highly appreciated. Cheers, - dimitri. "Mannie, Eric" wrote: > > Hello Stephen > > > GMPLS-LBM and LCAS ARE solutions to different problems. > > No, please see explanations below. > > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > No, please see below (C2 or V5 transition). > > >The compare/contrast discussion of LBM and LCAS is appropriate not > >because LCAS is "sacred", but because you are comparing apples to > >oranges. Statements in this document such as "One drawback of LCAS is .." > >are unnecessary and inappropriate in this context, since LBM does > >NOT solve the problem LCAS was designed to solve. Perhaps if you > >were solving the SAME problem better, this would be OK, but this > >is not the case. > > No, please see below. > > Simple example: > > 1) you first signal an additional VC/SPE to the destination (via a Path). > 2) the destination knows exactly which VC/SPE is added (via the label). > 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), > so the VC/SPE is not yet added to concatenated signal. > 4) then, you wait at the source for a confirmation from the destination > (i.e. Resv). > 5) the source "equip" the VC/SPE and sends. > 6) the destination sees in the POH that the VC is "equipped" (transition). > > The difference between LCAS and LBM is that LCAS uses an additional explicit > indication in the overhead to say "this is the payload" to use. LBM doesn't > change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) > > LCAS uses a new field in the POH (CTRL) to know when the new VC transitions > to a significant payload. LBM proposes to do the same simply by looking at > the C2 (for HOVC) transition - regular SDH/SONET field that will change > anyway and that is used to indicate the type of payload. > > To be more precise about LCAS (I copy from the LCAS specification, section > 6.3.1): "The first container frame to contain payload data for the new > member shall be the container frame immediately following the container > frame that contained the last bit(s) (i.e. the CRC) of the control packet > with NORM/EOS message for that member" (the LCAS control packet). > > So, LCAS waits for the last bit of the appropriate LCAS control packet in > the POH with the appropriate transition of its CTRL field. LBM waits simply > for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH > (don't change SDH/SONET). > > By the way, this is version 0 of the draft and it was just posted. > > Suggestions, technical comments and improvements are welcome. > > I would appreciate if people could first read and speak before shooting > directly :-) > > Kind regards, > > Eric > > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, November 16, 2001 7:49 PM > To: Mannie, Eric > Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Eric, > The point of my earlier email (items again below, this time with > numbers) was not to prompt the comment "#3 is out of scope, therefore > it is a choice between #1 and #2" (my parsing of recent statements). > > The issue (and I think the reason for Maarten's strong reaction) is this: > GMPLS-LBM and LCAS are NOT different solutions to the same problem. > GMPLS-LBM and LCAS ARE solutions to different problems. > (I hope this is not too subtle for non-native English speakers). > > LCAS is a method to hitlessly change the mappings at the two > ends of a virtually concatenated trail to increase or decrease the > bandwidth. It does not say anything about how components to be > added or removed from the virtually concatenated "bundle" are > set up or taken down. > > LBM talks about how to set up or take down those added or removed > components, but not about the details of changing the mapping (other > than that it is done after the new components are successfully > established. > > If you use LBM and change the mappings at the two ends without some > coordination such as LCAS, you will have a glitch to the traffic > (I think this is simple enough). > > The compare/contrast discussion of LBM and LCAS is appropriate not > because LCAS is "sacred", but because you are comparing apples to > oranges. Statements in this document such as "One drawback of LCAS is .." > are unnecessary and inappropriate in this context, since LBM does > NOT solve the problem LCAS was designed to solve. Perhaps if you > were solving the SAME problem better, this would be OK, but this > is not the case. > > Time to try to be constructive: > - I think most of the current discussion of LCAS should be removed from > this document. It is irrelevant since LCAS solves a different problem than > LBM. To say that one is "better" than the other would only be meaningful > if they were solving the same problem (can you really say that LBM solves > problem A better than LCAS solves problem B?). > - LCAS can be a good informative reference as a way to hitlessly modify > the size of a virtually concatenated trail. > - Clarify in the scope that the current draft describes the use of LBM > without LCAS, which results in a traffic glitch when bandwidth is modified. > Indicate that the use of LCAS to hitlessly negotiate the changes to > the size of virtually concatenated pipes after LBM sets up new component(s) > or before LBM takes down old component(s) is a topic for further study > and perhaps to be addressed in a future version of the draft. > > Regards, > Steve > > Steve Trowbridge wrote: > > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > > the traffic. > > > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > > control plane knows that the different LSPs are part of the same > > circuit. > > > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > > be the preferred method for many applications. > > "Mannie, Eric" wrote: > > > > Hello Maarten, > > > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > >understanding of LCAS's objective (my very strong opinion). > > > > Sorry, do you mean that it is forbidden to speak about your LCAS document > > and to compare GMPLS and LCAS functionalities ? > > > --------------B69D64FA575D21EA85B9B5C5 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------B69D64FA575D21EA85B9B5C5-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 13:21:36 -0800 Message-ID: From: "Mannie, Eric" To: 'Krishna Pattabhiraman' , Dimitri Papadimitriou , Maarten Vissers Cc: Ramji Raghavan , ccamp , q11/15 , "t1x1.5" , Kumar Kovvali Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 22:13:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Krishna, > As Maarten correctly points out LCAS as currently defined is not a signaling protocol, but enables a hitless bandwidth change. They are end-to-end signaling protocols that have nothing to do with intermediate systems, e.g. TCP, UDP, TP0, etc. The term signaling protocol doesn't say that it is hop-by-hop, end-to-end or both :-) LCAS doesn't transport any transport plane data, it has no payload. It is used to *signal* events in the life of a circuit. By the way, you can transport GMPLS messages in the SDH/SONET overhead like many manufacturers are doing (in the DCC). We could also invent another way of transporting GMPLS messages as a bit or byte oriented protocol in multi-frames :-) in a synchronous way. But ok, this is for fun :-) Kind regards, Eric -----Original Message----- From: Krishna Pattabhiraman [mailto:Krishna@coriolisnet.com] Sent: Friday, November 16, 2001 4:56 PM To: Dimitri Papadimitriou; Maarten Vissers Cc: Ramji Raghavan; ccamp; q11/15; t1x1.5; Kumar Kovvali Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hi, We had presented couple of contributions at the previous T1X1 to address some limitations of LCAS. We had proposed a lightweight LCAS protocol that doesn't require A-end and Z-end handshake and doesn't assume a provisioning event before each bandwidth update event. As Maarten correctly points out LCAS as currently defined is not a signalling protocol, but enables a hitless bandwidth change. There are couple of documents attached - justification.doc and proposal.doc. Pls feel free to comment on the justification document and the actual proposal document. The actual proposal document is a work in progress. The justification document presents examples of scenarios where "dynamic" real-time changes of bandwidths may be required and how a lightweight LCAS may be used to solve it. regards, Krishna -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Friday, November 16, 2001 10:28 AM To: Maarten Vissers Cc: ccamp; q11/15; t1x1.5 Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Maarten, I think you have reach the main comparison point for this discussion Let's start with this: - If you want to achieve hitles adaption you need a real-time protocol to synchronize both ends in some way (supporting the for instance LCAS) this is a synchronous approach - If you just want to add more capacity and you don't focus on a 'glitch' perhaps very few millisecs when putting the capacity in use you can do it in a non-real time manner like with GMPLS - this is an asynchronous approach The major difference between both procedures is that GMPLS gives an answer how to allocate capacity across the network while LCAS relies on the fact that it is already available i.e. "provisioned" (see LCAS specification) for use and just has to be 'lit'. Hope this will help the reader to undertstand that both methods have a specific applicability scope, the GMPLS one is more adapted for dynamic environments that do not use "provisioning" of the resources ... a real bandwidth on demand service. I think this is what we have addressed with this. And from what i understood this is what carriers are looking for (since the bandwdith service is non-disruptive - if it can accomodate a very few ms -, flexible and doesn't require any pre-provisioning). The second (LCAS) is adapted for services that could be sensitive, but the price to pay is to provision the "resources". This is a static approach of the problem. I think that both have a specific scope. Regards, - dimitri. Maarten Vissers wrote: > > Eric, Dimitri, > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > is NOT a signalling protocol. It is totally unrelated as such to control plane > based connection management (GMPLS, ASON) or network management based connection > management. > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > number of trails being used for the actual transport of the client signal; i.e. > if X (X number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > and Z-end to make sure the increase/reduction is performed hitless. > > The steps to perform for the case X=N are: > A) X ==> X+1 > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > A-end and Z-end to control the "addition" of the (X+1)th trail to the > group of X trails ("Madd" command in G.7042) over which the client > bitstream is transported > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > to the receiver at the other end > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > in one direction is setup if the Trail Signal Fail (TSF) condition at > its end has cleared; > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > 6) at the start of the next VC-n/ODUk frame the client bitstream is > distributed over X+1 (instead of X) VC-n/ODUk trails > 7) the receiver at the other end notices the change of CTRL=ADD to > CTRL=EOS, and expects the client signal to be present on X+1 (instead > of X) VC-n/ODUk trails at the begin of the next frame. > > Example with X=3 > ================ > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > trails #1..#3 as follows: > trail#1 trail#2 trail#3 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 > 73-80 ... > > When trail #4 is added, no client bits will be transported over it, until the > source has indicated this via the change of the control word CTRL=ADD => > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > transport of bits 73-80 and further: > > trail#1 trail#2 trail#3 trail#4 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 73-80 > 81-88 89-96 97-104 105-112 > 113-120 ... > > Regards, > > Maarten > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > Networks > > Author(s) : E. Mannie, D. Papadimitriou > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Pages : 13 > > Date : 15-Nov-01 > > > > This document defines how GMPLS can be used to dynamically modify > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > will cover G.709 in a next version. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: Fri, 16 Nov 2001 12:54:08 -0800 Message-ID: From: "Mannie, Eric" To: "'Brungard, Deborah A, ALCTA'" , 'Stephen Trowbridge' Cc: 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 21:44:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Deborah, > LCAS requires "provisioned" capacity; it makes use of allocated capacity as needed. LCAS can not provision capacity end-to-end (intermediate nodes); it is transparent to intermediate equipment. That's exactly what we said. > It applies to the end points (path termination per ITU-T definition - not GMPLS links). And it is defined for data mappings (e.g. GFP for Ethernet/SAN support). Yes. > As Steve says - comparing LCAS and GMPLS-LBM would be like comparing a data transport mapping with EMS/NMS functionality. Please, read our draft and tell us if the C2/V5 transition (see section "SPE/VC recognition and significance") can be used to do the same as LCAS. Kind regards, Eric -----Original Message----- From: Brungard, Deborah A, ALCTA [mailto:dbrungard@att.com] Sent: Friday, November 16, 2001 9:21 PM To: 'Stephen Trowbridge'; Mannie, Eric Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Agree with Steve- LCAS requires "provisioned" capacity; it makes use of allocated capacity as needed. LCAS can not provision capacity end-to-end (intermediate nodes); it is transparent to intermediate equipment. It applies to the end points (path termination per ITU-T definition - not GMPLS links). And it is defined for data mappings (e.g. GFP for Ethernet/SAN support). As Steve says - comparing LCAS and GMPLS-LBM would be like comparing a data transport mapping with EMS/NMS functionality. GMPLS should support LCAS, similar to any other mapping. Dimitri had valid quotes..looking at T1.105, it refers to LCAS as a protocol, though does not say the type..in T1X1.5's definitions, it is a protocol similar to APS. For questions on LCAS or if clarifications are identified for the T1.105 text, send email to the T1X1.5 exploder (open for non-members). T1.105 pre-pub draft is available (LCAS is in Annex B): ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC T1X1 files are at: http://www.t1.org/t1x1/_x1-grid.htm The next T1X1 meeting is the week of Jan. 21: http://www.t1.org/t1x1/jan2002.htm We previously scheduled two "lunch-time" seminars which may be of interest here. If you can not attend the meeting - the presentations will be uploaded to the T1X1.5 files: - GFP/virtual concatenation/LCAS - ASON The presentations will provide a summary of the recent ITU-T SG15 meeting and on-going work. Deborah Brungard AT&T (T1X1.5 Chair) -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Friday, November 16, 2001 1:49 PM To: Mannie, Eric Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, The point of my earlier email (items again below, this time with numbers) was not to prompt the comment "#3 is out of scope, therefore it is a choice between #1 and #2" (my parsing of recent statements). The issue (and I think the reason for Maarten's strong reaction) is this: GMPLS-LBM and LCAS are NOT different solutions to the same problem. GMPLS-LBM and LCAS ARE solutions to different problems. (I hope this is not too subtle for non-native English speakers). LCAS is a method to hitlessly change the mappings at the two ends of a virtually concatenated trail to increase or decrease the bandwidth. It does not say anything about how components to be added or removed from the virtually concatenated "bundle" are set up or taken down. LBM talks about how to set up or take down those added or removed components, but not about the details of changing the mapping (other than that it is done after the new components are successfully established. If you use LBM and change the mappings at the two ends without some coordination such as LCAS, you will have a glitch to the traffic (I think this is simple enough). The compare/contrast discussion of LBM and LCAS is appropriate not because LCAS is "sacred", but because you are comparing apples to oranges. Statements in this document such as "One drawback of LCAS is .." are unnecessary and inappropriate in this context, since LBM does NOT solve the problem LCAS was designed to solve. Perhaps if you were solving the SAME problem better, this would be OK, but this is not the case. Time to try to be constructive: - I think most of the current discussion of LCAS should be removed from this document. It is irrelevant since LCAS solves a different problem than LBM. To say that one is "better" than the other would only be meaningful if they were solving the same problem (can you really say that LBM solves problem A better than LCAS solves problem B?). - LCAS can be a good informative reference as a way to hitlessly modify the size of a virtually concatenated trail. - Clarify in the scope that the current draft describes the use of LBM without LCAS, which results in a traffic glitch when bandwidth is modified. Indicate that the use of LCAS to hitlessly negotiate the changes to the size of virtually concatenated pipes after LBM sets up new component(s) or before LBM takes down old component(s) is a topic for further study and perhaps to be addressed in a future version of the draft. Regards, Steve Steve Trowbridge wrote: > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > the traffic. > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > control plane knows that the different LSPs are part of the same > circuit. > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > be the preferred method for many applications. "Mannie, Eric" wrote: > > Hello Maarten, > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >understanding of LCAS's objective (my very strong opinion). > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 12:53:44 -0800 Message-ID: From: "Mannie, Eric" To: 'Stephen Trowbridge' Cc: 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 21:45:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Stephen > GMPLS-LBM and LCAS ARE solutions to different problems. No, please see explanations below. > If you use LBM and change the mappings at the two ends without some coordination such as LCAS, you will have a glitch to the traffic (I think this is simple enough). No, please see below (C2 or V5 transition). >The compare/contrast discussion of LBM and LCAS is appropriate not >because LCAS is "sacred", but because you are comparing apples to >oranges. Statements in this document such as "One drawback of LCAS is .." >are unnecessary and inappropriate in this context, since LBM does >NOT solve the problem LCAS was designed to solve. Perhaps if you >were solving the SAME problem better, this would be OK, but this >is not the case. No, please see below. Simple example: 1) you first signal an additional VC/SPE to the destination (via a Path). 2) the destination knows exactly which VC/SPE is added (via the label). 3) the new VC is unequipped (indicated in POH C2 (for HOVC)), so the VC/SPE is not yet added to concatenated signal. 4) then, you wait at the source for a confirmation from the destination (i.e. Resv). 5) the source "equip" the VC/SPE and sends. 6) the destination sees in the POH that the VC is "equipped" (transition). The difference between LCAS and LBM is that LCAS uses an additional explicit indication in the overhead to say "this is the payload" to use. LBM doesn't change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-) LCAS uses a new field in the POH (CTRL) to know when the new VC transitions to a significant payload. LBM proposes to do the same simply by looking at the C2 (for HOVC) transition - regular SDH/SONET field that will change anyway and that is used to indicate the type of payload. To be more precise about LCAS (I copy from the LCAS specification, section 6.3.1): "The first container frame to contain payload data for the new member shall be the container frame immediately following the container frame that contained the last bit(s) (i.e. the CRC) of the control packet with NORM/EOS message for that member" (the LCAS control packet). So, LCAS waits for the last bit of the appropriate LCAS control packet in the POH with the appropriate transition of its CTRL field. LBM waits simply for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH (don't change SDH/SONET). By the way, this is version 0 of the draft and it was just posted. Suggestions, technical comments and improvements are welcome. I would appreciate if people could first read and speak before shooting directly :-) Kind regards, Eric -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Friday, November 16, 2001 7:49 PM To: Mannie, Eric Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, The point of my earlier email (items again below, this time with numbers) was not to prompt the comment "#3 is out of scope, therefore it is a choice between #1 and #2" (my parsing of recent statements). The issue (and I think the reason for Maarten's strong reaction) is this: GMPLS-LBM and LCAS are NOT different solutions to the same problem. GMPLS-LBM and LCAS ARE solutions to different problems. (I hope this is not too subtle for non-native English speakers). LCAS is a method to hitlessly change the mappings at the two ends of a virtually concatenated trail to increase or decrease the bandwidth. It does not say anything about how components to be added or removed from the virtually concatenated "bundle" are set up or taken down. LBM talks about how to set up or take down those added or removed components, but not about the details of changing the mapping (other than that it is done after the new components are successfully established. If you use LBM and change the mappings at the two ends without some coordination such as LCAS, you will have a glitch to the traffic (I think this is simple enough). The compare/contrast discussion of LBM and LCAS is appropriate not because LCAS is "sacred", but because you are comparing apples to oranges. Statements in this document such as "One drawback of LCAS is .." are unnecessary and inappropriate in this context, since LBM does NOT solve the problem LCAS was designed to solve. Perhaps if you were solving the SAME problem better, this would be OK, but this is not the case. Time to try to be constructive: - I think most of the current discussion of LCAS should be removed from this document. It is irrelevant since LCAS solves a different problem than LBM. To say that one is "better" than the other would only be meaningful if they were solving the same problem (can you really say that LBM solves problem A better than LCAS solves problem B?). - LCAS can be a good informative reference as a way to hitlessly modify the size of a virtually concatenated trail. - Clarify in the scope that the current draft describes the use of LBM without LCAS, which results in a traffic glitch when bandwidth is modified. Indicate that the use of LCAS to hitlessly negotiate the changes to the size of virtually concatenated pipes after LBM sets up new component(s) or before LBM takes down old component(s) is a topic for further study and perhaps to be addressed in a future version of the draft. Regards, Steve Steve Trowbridge wrote: > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > the traffic. > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > control plane knows that the different LSPs are part of the same > circuit. > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > be the preferred method for many applications. "Mannie, Eric" wrote: > > Hello Maarten, > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >understanding of LCAS's objective (my very strong opinion). > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 12:27:44 -0800 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624101B30@OCCLUST02EVS1.ugd.att.com> From: "Brungard, Deborah A, ALCTA" To: "'Stephen Trowbridge'" , "Mannie, Eric" Cc: "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 15:21:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Agree with Steve- LCAS requires "provisioned" capacity; it makes use of allocated capacity as needed. LCAS can not provision capacity end-to-end (intermediate nodes); it is transparent to intermediate equipment. It applies to the end points (path termination per ITU-T definition - not GMPLS links). And it is defined for data mappings (e.g. GFP for Ethernet/SAN support). As Steve says - comparing LCAS and GMPLS-LBM would be like comparing a data transport mapping with EMS/NMS functionality. GMPLS should support LCAS, similar to any other mapping. Dimitri had valid quotes..looking at T1.105, it refers to LCAS as a protocol, though does not say the type..in T1X1.5's definitions, it is a protocol similar to APS. For questions on LCAS or if clarifications are identified for the T1.105 text, send email to the T1X1.5 exploder (open for non-members). T1.105 pre-pub draft is available (LCAS is in Annex B): ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC T1X1 files are at: http://www.t1.org/t1x1/_x1-grid.htm The next T1X1 meeting is the week of Jan. 21: http://www.t1.org/t1x1/jan2002.htm We previously scheduled two "lunch-time" seminars which may be of interest here. If you can not attend the meeting - the presentations will be uploaded to the T1X1.5 files: - GFP/virtual concatenation/LCAS - ASON The presentations will provide a summary of the recent ITU-T SG15 meeting and on-going work. Deborah Brungard AT&T (T1X1.5 Chair) -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Friday, November 16, 2001 1:49 PM To: Mannie, Eric Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, The point of my earlier email (items again below, this time with numbers) was not to prompt the comment "#3 is out of scope, therefore it is a choice between #1 and #2" (my parsing of recent statements). The issue (and I think the reason for Maarten's strong reaction) is this: GMPLS-LBM and LCAS are NOT different solutions to the same problem. GMPLS-LBM and LCAS ARE solutions to different problems. (I hope this is not too subtle for non-native English speakers). LCAS is a method to hitlessly change the mappings at the two ends of a virtually concatenated trail to increase or decrease the bandwidth. It does not say anything about how components to be added or removed from the virtually concatenated "bundle" are set up or taken down. LBM talks about how to set up or take down those added or removed components, but not about the details of changing the mapping (other than that it is done after the new components are successfully established. If you use LBM and change the mappings at the two ends without some coordination such as LCAS, you will have a glitch to the traffic (I think this is simple enough). The compare/contrast discussion of LBM and LCAS is appropriate not because LCAS is "sacred", but because you are comparing apples to oranges. Statements in this document such as "One drawback of LCAS is .." are unnecessary and inappropriate in this context, since LBM does NOT solve the problem LCAS was designed to solve. Perhaps if you were solving the SAME problem better, this would be OK, but this is not the case. Time to try to be constructive: - I think most of the current discussion of LCAS should be removed from this document. It is irrelevant since LCAS solves a different problem than LBM. To say that one is "better" than the other would only be meaningful if they were solving the same problem (can you really say that LBM solves problem A better than LCAS solves problem B?). - LCAS can be a good informative reference as a way to hitlessly modify the size of a virtually concatenated trail. - Clarify in the scope that the current draft describes the use of LBM without LCAS, which results in a traffic glitch when bandwidth is modified. Indicate that the use of LCAS to hitlessly negotiate the changes to the size of virtually concatenated pipes after LBM sets up new component(s) or before LBM takes down old component(s) is a topic for further study and perhaps to be addressed in a future version of the draft. Regards, Steve Steve Trowbridge wrote: > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > the traffic. > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > control plane knows that the different LSPs are part of the same > circuit. > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > be the preferred method for many applications. "Mannie, Eric" wrote: > > Hello Maarten, > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >understanding of LCAS's objective (my very strong opinion). > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:59:33 -0800 Message-ID: <3BF55FA9.ADE582FA@lucent.com> Date: Fri, 16 Nov 2001 11:49:13 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, The point of my earlier email (items again below, this time with numbers) was not to prompt the comment "#3 is out of scope, therefore it is a choice between #1 and #2" (my parsing of recent statements). The issue (and I think the reason for Maarten's strong reaction) is this: GMPLS-LBM and LCAS are NOT different solutions to the same problem. GMPLS-LBM and LCAS ARE solutions to different problems. (I hope this is not too subtle for non-native English speakers). LCAS is a method to hitlessly change the mappings at the two ends of a virtually concatenated trail to increase or decrease the bandwidth. It does not say anything about how components to be added or removed from the virtually concatenated "bundle" are set up or taken down. LBM talks about how to set up or take down those added or removed components, but not about the details of changing the mapping (other than that it is done after the new components are successfully established. If you use LBM and change the mappings at the two ends without some coordination such as LCAS, you will have a glitch to the traffic (I think this is simple enough). The compare/contrast discussion of LBM and LCAS is appropriate not because LCAS is "sacred", but because you are comparing apples to oranges. Statements in this document such as "One drawback of LCAS is .." are unnecessary and inappropriate in this context, since LBM does NOT solve the problem LCAS was designed to solve. Perhaps if you were solving the SAME problem better, this would be OK, but this is not the case. Time to try to be constructive: - I think most of the current discussion of LCAS should be removed from this document. It is irrelevant since LCAS solves a different problem than LBM. To say that one is "better" than the other would only be meaningful if they were solving the same problem (can you really say that LBM solves problem A better than LCAS solves problem B?). - LCAS can be a good informative reference as a way to hitlessly modify the size of a virtually concatenated trail. - Clarify in the scope that the current draft describes the use of LBM without LCAS, which results in a traffic glitch when bandwidth is modified. Indicate that the use of LCAS to hitlessly negotiate the changes to the size of virtually concatenated pipes after LBM sets up new component(s) or before LBM takes down old component(s) is a topic for further study and perhaps to be addressed in a future version of the draft. Regards, Steve Steve Trowbridge wrote: > 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to > the traffic. > > 2. Can you use LCAS without LBM? Yes, if you don't care whether the > control plane knows that the different LSPs are part of the same > circuit. > > 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to > be the preferred method for many applications. "Mannie, Eric" wrote: > > Hello Maarten, > > >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >understanding of LCAS's objective (my very strong opinion). > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:59:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain From: Steve Gorshe To: "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: RE: [T1X1.5] LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 10:44:48 -0800 I think two small technical corrections are needed in Maarten's good example below on the actual timing of the bandwidth change-over. I marked the corrections with [ssg]. As for the larger issue, the current G.7042 uses the terms NMS and EMS for the provisioning piece because an ITU-T document can not refer to standards that are still under development. I think we have all understood that a GMPLS control plane is equivalent to NMS/EMS provisioning for the purposes of LCAS. The only thing LCAS requires is that the new member be assigned as part of the virtually concatenated group before LCAS synchronizes the adding of that member to the group. LCAS doesn't care how that assignment/provisioning took place. I think Greg Bernstein summarized rather well. Regards, Steve -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 16, 2001 6:36 AM To: ccamp; q11/15; t1x1.5 Subject: [T1X1.5] LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, Dimitri, I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so I got the impression that you completely misunderstand the purpose of LCAS. LCAS is NOT a signalling protocol. It is totally unrelated as such to control plane based connection management (GMPLS, ASON) or network management based connection management. LCAS doesn't change the number of VC-n or ODUk trails in the network. If N trails are set up between the A-end and Z-end, LCAS helps to hitless change the number of trails being used for the actual transport of the client signal; i.e. if X (X X+1 1) [Operator or User] request connection management [NMS or ASON/GMPLS] to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with virtual concatenated endpoint at A-end and corresponding SNPP at Z-end 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at A-end and Z-end to control the "addition" of the (X+1)th trail to the group of X trails ("Madd" command in G.7042) over which the client bitstream is transported 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this to the receiver at the other end 3) LCAS at A-end [Z-end] waits until connection is setup; the connection in one direction is setup if the Trail Signal Fail (TSF) condition at its end has cleared; 4) LCAS communicates the TSF clearing to the other end ("MST=OK") 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and [ssg] Of course, the member that had been using CTRL=EOS now goes to CTRL=NORM. 6) at the start of the next VC-n/ODUk frame the client bitstream is distributed over X+1 (instead of X) VC-n/ODUk trails [ssg] Strictly speaking, the bandwidth change does take place at the beginning of the "next VC-n/ODUk frame." The LCAS messaging is carried in a control packet that is sent over multiple VC-n/ODUk frames, and this control packet ends with a CRC for error protection. The bandwidth change takes effect in the first VC-n/ODUk frame after the frame carrying the end of the control packet that signalled the changed (i.e., that contained the CTRL=EOS change.) This allows checking the control packet CRC before making the change. Of course, the same is true for deleting a member. 7) the receiver at the other end notices the change of CTRL=ADD to CTRL=EOS, and expects the client signal to be present on X+1 (instead of X) VC-n/ODUk trails at the begin of the next frame. Example with X=3 ================ The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over trails #1..#3 as follows: trail#1 trail#2 trail#3 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 ... When trail #4 is added, no client bits will be transported over it, until the source has indicated this via the change of the control word CTRL=ADD => CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at the moment client bit 49 is to be transmitted, then trail#4 will be used for the transport of bits 73-80 and further: trail#1 trail#2 trail#3 trail#4 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 81-88 89-96 97-104 105-112 113-120 ... Regards, Maarten Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > Networks > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > Pages : 13 > Date : 15-Nov-01 > > This document defines how GMPLS can be used to dynamically modify > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > will cover G.709 in a next version. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: Fri, 16 Nov 2001 10:58:16 -0800 Message-ID: <3BF56AFD.38C2547B@alcatel.com> Date: Fri, 16 Nov 2001 14:37:33 -0500 From: Senthil Venkatachalam Organization: Alcatel MIME-Version: 1.0 To: Alex Zinin CC: Kireeti Kompella , Vijay Gill , Sudheer Dharnikota , Papadimitriou Dimitri , ccamp@ops.ietf.org Subject: Re: draft-venkatachalam-interarea-mpls-te-02.txt Content-Type: multipart/alternative; boundary="------------4D03E9048C977AA4A4F5F9CE" --------------4D03E9048C977AA4A4F5F9CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I resubmitted two days ago..will check and do again... Senthil Alex Zinin wrote: > Senthil, > > The IETF directory says it expired. Please resubmit or > post a link to it. > > -- > Alex Zinin > > Tuesday, November 13, 2001, 2:19:05 PM, Senthil Venkatachalam wrote: > > > Hi Kireeti, > > > We would like to request a slot to present our draft: > > draft-venkatachalam-interarea-mpls-te-02.txt > > at the Salt Lake City IETF. > > > Best Regards, > > Senthil. > > > -- > > Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com > > Off#:, MBox: (703) 679-6435 [Off] > > Alcatel USA (703) 679-6450 [Fax] > > __________________________________________________________________ -- Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com Off#:, MBox: (703) 679-6435 [Off] Alcatel USA (703) 679-6450 [Fax] __________________________________________________________________ --------------4D03E9048C977AA4A4F5F9CE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I resubmitted two days ago..will check and do again...

Senthil
 
 

Alex Zinin wrote:

Senthil,

   The IETF directory says it expired. Please resubmit or
   post a link to it.

--
Alex Zinin

Tuesday, November 13, 2001, 2:19:05 PM, Senthil Venkatachalam wrote:

> Hi Kireeti,

> We would like to request a slot to present our draft:
> draft-venkatachalam-interarea-mpls-te-02.txt
> at the Salt Lake City IETF.

> Best Regards,
> Senthil.

> --
> Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
> Off#:, MBox:                 (703) 679-6435 [Off]
> Alcatel USA                  (703) 679-6450 [Fax]
> __________________________________________________________________

-- 
Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________
  --------------4D03E9048C977AA4A4F5F9CE-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:38:12 -0800 Message-ID: From: "Bernstein, Greg" To: "'Mannie, Eric'" , "'Maarten Vissers'" Cc: ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 10:28:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, from my somewhat application biased notion of LCAS and its relation to GMPLS/G.ASON. I thought I would get two major features from LCAS: (1) Hitless (for packet data services) changes in bandwidth by coordinating between the end systems the exact time (virtual frame) when the new component comes on line. (or old component stops being used). I've kinda viewed LCAS as a path layer service (this may not be theoretically correct) but I've got to use some mechanism to set up need component paths, then use LCAS to bring them into use without say loosing an Ethernet or IP packet in the process. Similarly on reduction in bandwidth, LCAS allows me to hitlessly take a component out of service. Then I use some other process two actually remove the component path from the network and free up the network resources. (2) Graceful degradation in the presence of failure (especially with diversely routed components). Here LCAS is use by the end systems (virtual concatenation capable systems) to coordinate which components are still functional and coordinate there use after a failure. Eric, Maarten? I really thought LCAS and GMPLS/G.ASON like connection establishment were quite complementary with no real overlap, e.g., I'd still might want bandwidth modify at the GMPLS level so I don't have to keep track of all the components individually (application 1.) and this is somewhat different than what you'd want to do for application (2). Greg B. *********************************** Dr. Greg M. Bernstein Senior Technology Director, Ciena Corporation -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Friday, November 16, 2001 9:39 AM To: 'Maarten Vissers' Cc: ccamp; q11/15; t1x1.5; Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Hello Maarten, >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of >understanding of LCAS's objective (my very strong opinion). Sorry, do you mean that it is forbidden to speak about your LCAS document and to compare GMPLS and LCAS functionalities ? >LCAS plays a role after the extra connection is setup or before a connection is released. How this connection is setup or released is not relevant for LCAS. GMPLS plays a role for all the cases that you described: to setup a connection, to maintain a connection, to modify a connection, to release a connection, etc. LCAS makes a lot of sense for a static network where provisioning occurs through a Network Management System. A distributed control plane (like GMPLS) with LCAS doesn't make any sense. LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the beginning to allow LSP (bandwidth) modification. Do you mean that your implementation of GMPLS will not support any bandwidth/LSP modification ? Kind regards, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 16, 2001 5:30 PM To: Dimitri Papadimitriou Cc: ccamp; q11/15; t1x1.5 Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Dimitri, Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of understanding of LCAS's objective (my very strong opinion). LCAS plays a role after the extra connection is setup or before a connection is released. How this connection is setup or released is not relevant for LCAS. NMS and ASON/GMPLS are concerned with connection setup and release. And also with modification, if such is relevant for a connection. Modification of connection parameters is relevant for the connection (group(s)) supporting the transport of a Virtual Concatenated signal (VC-n-Xv, ODUk-Xv). If this modification isn't covered yet in GMPLS drafts, it is important to extend GMPLS and add it. But never ever relate it to LCAS :-). When we developed virtual concatenation and LCAS we where very much aware that we would get much more out of these two when there would be a switched network. The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) could then monitor the fill level of the virtual concatenated pipe, and when crossing a threshold could request another VC-n or ODUk to be setup. In a switched network the setup only takes a few seconds, and essentially in no time the bandwidth of the pipe can be increased. If LCAS is present, this new capacity can be included in the transmission of the ehternet bit stream without introducing any errors in the ehternet stream. If LCAS is not present, the ethernet transport will be interrupted for a shorter or longer period and (depending on the bandwidth of the pipe) fewer or many more packets will be lost before the transmission is restored. I.e. as long as the transmitter is using X+1 trails and the receiver is using X trails (or vice versa) transmission is interrupted. With NMS ordering the increase at A-end and Z-end (after the additional trail is setup) this period may be a couple of seconds; i.e. NMS has to generate two messages to the A node and the Z node, these messages have to travel through the DCN, the two nodes have to accept the messages and process those before the command can be given to the hardware to use X+1 instead of X trails. When a control plane is involved instead of NMS, the control plane has to set up the additional trail, verify that this trail is set up correctly (check for signal fail including trace identifier), then command one end to transmit over X+1 trails and quickly inform the other end that it should command the receiving endpoint to read from X+1 trails. This all might be in the 100ms range but most likely will also be in the seconds range (depending on network size and load). Dimitri Papadimitriou wrote: > > Maarten, > > I think you have reach the main comparison point for this discussion > Let's start with this: > > - If you want to achieve hitles adaption you need a real-time protocol > to synchronize both ends in some way (supporting the for instance LCAS) > this is a synchronous approach > > - If you just want to add more capacity and you don't focus on a > 'glitch' > perhaps very few millisecs when putting the capacity in use you can do > it in > a non-real time manner like with GMPLS - this is an asynchronous > approach You always need NMS or ASON/GMPLS to be present to setup the additional connection. If an endpoint doesn't support LCAS, its function needs to be performed by NMS or ASON/GMPLS (with degraded performance). > > The major difference between both procedures is that GMPLS gives an There is no difference, as the two can not be compared. > answer > how to allocate capacity across the network while LCAS relies on the > fact > that it is already available i.e. "provisioned" (see LCAS specification) > for use and just has to be 'lit'. > > Hope this will help the reader to undertstand that both methods have a Methods are LCAS and non-LCAS... > specific applicability scope, the GMPLS one is more adapted for dynamic > environments that do not use "provisioning" of the resources ... In either case there is "provisioning" of the resources. The hardware in both endpoints must be told to use X+1 instead of X trails. > a real > bandwidth on demand service. I think this is what we have addressed > with this. And from what i understood this is what carriers are looking > for (since the bandwdith service is non-disruptive - if it can > accomodate > a very few ms -, flexible and doesn't require any pre-provisioning). There is a large difference between "zero errors" and "a few ms (most likely seconds) of no transmission". > > The second (LCAS) is adapted for services that could be sensitive, but > the price to pay is to provision the "resources". This is a static > approach of the problem. I think that both have a specific scope. I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS provisioning is non-time critical, whereas the non-LCAS provisioning is time critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not mandatory, the investments in NMS and ASON/GMPLS to limit the traffic interruption have to be made. As such, your draft should focus on the means to limit the traffic interruption when LCAS is not present. This may imply kind of third party signalling information to be carried through the public switched transport network; i.e. for the case the virtual concatenated endpoints are outside of the PSTN, the user needs to have the capability to synchronize its endpoints. Regards, Maarten > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Eric, Dimitri, > > > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > > is NOT a signalling protocol. It is totally unrelated as such to control plane > > based connection management (GMPLS, ASON) or network management based connection > > management. > > > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > > number of trails being used for the actual transport of the client signal; i.e. > > if X (X > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > > and Z-end to make sure the increase/reduction is performed hitless. > > > > The steps to perform for the case X=N are: > > A) X ==> X+1 > > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > > A-end and Z-end to control the "addition" of the (X+1)th trail to the > > group of X trails ("Madd" command in G.7042) over which the client > > bitstream is transported > > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > > to the receiver at the other end > > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > > in one direction is setup if the Trail Signal Fail (TSF) condition at > > its end has cleared; > > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > > 6) at the start of the next VC-n/ODUk frame the client bitstream is > > distributed over X+1 (instead of X) VC-n/ODUk trails > > 7) the receiver at the other end notices the change of CTRL=ADD to > > CTRL=EOS, and expects the client signal to be present on X+1 (instead > > of X) VC-n/ODUk trails at the begin of the next frame. > > > > Example with X=3 > > ================ > > > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > > trails #1..#3 as follows: > > trail#1 trail#2 trail#3 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 > > 73-80 ... > > > > When trail #4 is added, no client bits will be transported over it, until the > > source has indicated this via the change of the control word CTRL=ADD => > > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > > transport of bits 73-80 and further: > > > > trail#1 trail#2 trail#3 trail#4 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 73-80 > > 81-88 89-96 97-104 105-112 > > 113-120 ... > > > > Regards, > > > > Maarten > > > > Internet-Drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > > Networks > > > Author(s) : E. Mannie, D. Papadimitriou > > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Pages : 13 > > > Date : 15-Nov-01 > > > > > > This document defines how GMPLS can be used to dynamically modify > > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > > will cover G.709 in a next version. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:38:03 -0800 Message-ID: <3BF55A8D.8000803@lucent.com> Date: Fri, 16 Nov 2001 13:27:25 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, I think you're a network scientist! I think we need to look at classifications of what "signalling protocol" refers to. I think from what Maarten mentioned, it seems like he equates "signaling protocol" to "control plane signaling protocol". There is probably a need for differentiating between: A protocol at the control plane A protocol at the transport plane A protocol at the management plane Clearly GMPLS is a control plane protocol. And I think it's pretty clear that LCAS is a transport plane protocol and not control plane protocol. And if you think about it, the exchange of transport layer maintenance signals (such as AIS, FDI, RDI, etc.) can also be considered a transport plane signaling protocol, albeit a simple protocol. But you're right. This is not the point. Zhi Mannie, Eric wrote: > Hello Maarten, > > >>I got the impression that you completely misunderstand the purpose of >> > LCAS. LCAS is NOT a signalling protocol. > > The LCAS specification defines the "LCAS protocol" (annex A), with time > sequence diagrams (Appendix I), control packets (section 6.2) with fields, > etc etc... if this is not a signaling protocol I am not a network scientist > anymore. Anyway, this is not the point. > > Kind regards, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, November 16, 2001 3:36 PM > To: ccamp; q11/15; t1x1.5 > Subject: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Eric, Dimitri, > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. > Doing so > I got the impression that you completely misunderstand the purpose of LCAS. > LCAS > is NOT a signalling protocol. It is totally unrelated as such to control > plane > based connection management (GMPLS, ASON) or network management based > connection > management. > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > trails are set up between the A-end and Z-end, LCAS helps to hitless change > the > number of trails being used for the actual transport of the client signal; > i.e. > if X (X this > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the > A-end > and Z-end to make sure the increase/reduction is performed hitless. > > The steps to perform for the case X=N are: > A) X ==> X+1 > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > A-end and Z-end to control the "addition" of the (X+1)th trail to the > group of X trails ("Madd" command in G.7042) over which the client > bitstream is transported > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > to the receiver at the other end > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > in one direction is setup if the Trail Signal Fail (TSF) condition at > its end has cleared; > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > 6) at the start of the next VC-n/ODUk frame the client bitstream is > distributed over X+1 (instead of X) VC-n/ODUk trails > 7) the receiver at the other end notices the change of CTRL=ADD to > CTRL=EOS, and expects the client signal to be present on X+1 (instead > of X) VC-n/ODUk trails at the begin of the next frame. > > > Example with X=3 > ================ > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed > over > trails #1..#3 as follows: > trail#1 trail#2 trail#3 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 > 73-80 ... > > When trail #4 is added, no client bits will be transported over it, until > the > source has indicated this via the change of the control word CTRL=ADD => > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins > at > the moment client bit 49 is to be transmitted, then trail#4 will be used for > the > transport of bits 73-80 and further: > > trail#1 trail#2 trail#3 trail#4 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 73-80 > 81-88 89-96 97-104 105-112 > 113-120 ... > > > > Regards, > > Maarten > > > Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. > >> Title : GMPLS LSP Bandwidth Modification (LBM) for TDM >> Networks >> Author(s) : E. Mannie, D. Papadimitriou >> Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt >> Pages : 13 >> Date : 15-Nov-01 >> >>This document defines how GMPLS can be used to dynamically modify >>the bandwidth of a TDM circuit. It focuses first on SONET/SDH and >>will cover G.709 in a next version. >> >>A URL for this Internet-Draft is: >> >> > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> >> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:22:30 -0800 Message-ID: <3BF558AA.1000007@lucent.com> Date: Fri, 16 Nov 2001 13:19:22 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: Dimitri Papadimitriou CC: "Mannie, Eric" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, OK, so maybe that's where the confusion comes in. LCAS doesn't say what I think Eric was implying. LCAS, in G.7042, only describes the protocol for doing this. Your quote from section 3.18 (by the way which document is this?) also does not imply only NMS or EMS: they are one trigger for the LCAS to start. So I guess we do have different interpretation. Do you agree with mine? Also, which document is it you refer to "within your document"? Zhi Dimitri Papadimitriou wrote: > Zhi, > > I read here the fourth sentence of the Annex: > "The scheme allows hit-less addition and removal of > bandwidth under control of a management system." > > Then in the LCAS document Section 3.18 > "The LCAS assumes that in cases of capacity initiation, > increases or decreases, the construction or destruction > of the end-to-end path is the responsibility of the > Network and Element Management Systems." > > So i think these sentences are clear within your documents > - i am not responsible for this - you are the author not > me or probably we have different interpretations of NMS > systems. > > - dimitri. > > Zhi-Wei Lin wrote: > >>Hi Eric, >> >>I would like to understand your statement: >> >>"LCAS makes a lot of sense for a static network where provisioning >>occurs through a Network Management System." >> >>Is this your view of LCAS, that it is strictly limited to a static >>network & that it is triggered only by NMS? >> >>Zhi >> >>Mannie, Eric wrote: >> >> >>>Hello Maarten, >>> >>> >>> >>>>Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of >>>>understanding of LCAS's objective (my very strong opinion). >>>> >>>> >>>Sorry, do you mean that it is forbidden to speak about your LCAS document >>>and to compare GMPLS and LCAS functionalities ? >>> >>> >>> >>>>LCAS plays a role after the extra connection is setup or before a >>>> >>>> >>>connection is released. How this >>>connection is setup or released is not relevant for LCAS. >>> >>>GMPLS plays a role for all the cases that you described: to setup a >>>connection, to maintain a connection, to modify a connection, to release a >>>connection, etc. >>> >>>LCAS makes a lot of sense for a static network where provisioning occurs >>>through a Network Management System. >>> >>>A distributed control plane (like GMPLS) with LCAS doesn't make any sense. >>>LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the >>>beginning to allow LSP (bandwidth) modification. >>> >>>Do you mean that your implementation of GMPLS will not support any >>>bandwidth/LSP modification ? >>> >>>Kind regards, >>> >>>Eric >>> >>>-----Original Message----- >>>From: Maarten Vissers [mailto:mvissers@lucent.com] >>>Sent: Friday, November 16, 2001 5:30 PM >>>To: Dimitri Papadimitriou >>>Cc: ccamp; q11/15; t1x1.5 >>>Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt >>> >>> >>>Dimitri, >>> >>>Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of >>>understanding of LCAS's objective (my very strong opinion). LCAS plays a >>>role >>>after the extra connection is setup or before a connection is released. How >>>this >>>connection is setup or released is not relevant for LCAS. >>> >>>NMS and ASON/GMPLS are concerned with connection setup and release. And also >>>with modification, if such is relevant for a connection. >>> >>>Modification of connection parameters is relevant for the connection >>>(group(s)) >>>supporting the transport of a Virtual Concatenated signal (VC-n-Xv, >>>ODUk-Xv). >>> >>>If this modification isn't covered yet in GMPLS drafts, it is important to >>>extend GMPLS and add it. But never ever relate it to LCAS :-). >>> >>>When we developed virtual concatenation and LCAS we where very much aware >>>that >>>we would get much more out of these two when there would be a switched >>>network. >>>The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) >>>could >>>then monitor the fill level of the virtual concatenated pipe, and when >>>crossing >>>a threshold could request another VC-n or ODUk to be setup. In a switched >>>network the setup only takes a few seconds, and essentially in no time the >>>bandwidth of the pipe can be increased. >>> >>>If LCAS is present, this new capacity can be included in the transmission of >>>the >>>ehternet bit stream without introducing any errors in the ehternet stream. >>> >>>If LCAS is not present, the ethernet transport will be interrupted for a >>>shorter >>>or longer period and (depending on the bandwidth of the pipe) fewer or many >>>more >>>packets will be lost before the transmission is restored. I.e. as long as >>>the >>>transmitter is using X+1 trails and the receiver is using X trails (or vice >>>versa) transmission is interrupted. With NMS ordering the increase at A-end >>>and >>>Z-end (after the additional trail is setup) this period may be a couple of >>>seconds; i.e. NMS has to generate two messages to the A node and the Z node, >>>these messages have to travel through the DCN, the two nodes have to accept >>>the >>>messages and process those before the command can be given to the hardware >>>to >>>use X+1 instead of X trails. >>>When a control plane is involved instead of NMS, the control plane has to >>>set up >>>the additional trail, verify that this trail is set up correctly (check for >>>signal fail including trace identifier), then command one end to transmit >>>over >>>X+1 trails and quickly inform the other end that it should command the >>>receiving >>>endpoint to read from X+1 trails. This all might be in the 100ms range but >>>most >>>likely will also be in the seconds range (depending on network size and >>>load). >>> >>> >>> >>>Dimitri Papadimitriou wrote: >>> >>> >>>>Maarten, >>>> >>>>I think you have reach the main comparison point for this discussion >>>>Let's start with this: >>>> >>>>- If you want to achieve hitles adaption you need a real-time protocol >>>>to synchronize both ends in some way (supporting the for instance LCAS) >>>>this is a synchronous approach >>>> >>>>- If you just want to add more capacity and you don't focus on a >>>>'glitch' >>>>perhaps very few millisecs when putting the capacity in use you can do >>>>it in >>>>a non-real time manner like with GMPLS - this is an asynchronous >>>>approach >>>> >>>> >>>You always need NMS or ASON/GMPLS to be present to setup the additional >>>connection. If an endpoint doesn't support LCAS, its function needs to be >>>performed by NMS or ASON/GMPLS (with degraded performance). >>> >>> >>> >>>>The major difference between both procedures is that GMPLS gives an >>>> >>>> >>>There is no difference, as the two can not be compared. >>> >>> >>> >>>>answer >>>>how to allocate capacity across the network while LCAS relies on the >>>>fact >>>>that it is already available i.e. "provisioned" (see LCAS specification) >>>>for use and just has to be 'lit'. >>>> >>>>Hope this will help the reader to undertstand that both methods have a >>>> >>>> >>>Methods are LCAS and non-LCAS... >>> >>> >>> >>>>specific applicability scope, the GMPLS one is more adapted for dynamic >>>>environments that do not use "provisioning" of the resources ... >>>> >>>> >>>In either case there is "provisioning" of the resources. The hardware in >>>both >>>endpoints must be told to use X+1 instead of X trails. >>> >>> >>> >>>>a real >>>>bandwidth on demand service. I think this is what we have addressed >>>>with this. And from what i understood this is what carriers are looking >>>>for (since the bandwdith service is non-disruptive - if it can >>>>accomodate >>>>a very few ms -, flexible and doesn't require any pre-provisioning). >>>> >>>> >>>There is a large difference between "zero errors" and "a few ms (most likely >>>seconds) of no transmission". >>> >>> >>> >>>>The second (LCAS) is adapted for services that could be sensitive, but >>>>the price to pay is to provision the "resources". This is a static >>>>approach of the problem. I think that both have a specific scope. >>>> >>>> >>>I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS >>>provisioning is non-time critical, whereas the non-LCAS provisioning is time >>>critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not >>>mandatory, >>>the investments in NMS and ASON/GMPLS to limit the traffic interruption have >>>to >>>be made. As such, your draft should focus on the means to limit the traffic >>>interruption when LCAS is not present. This may imply kind of third party >>>signalling information to be carried through the public switched transport >>>network; i.e. for the case the virtual concatenated endpoints are outside of >>>the >>>PSTN, the user needs to have the capability to synchronize its endpoints. >>> >>>Regards, >>> >>>Maarten >>> >>> >>> >>> >>>>Regards, >>>>- dimitri. >>>> >>>>Maarten Vissers wrote: >>>> >>>> >>>>>Eric, Dimitri, >>>>> >>>>>I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. >>>>> >>>>> >>>Doing so >>> >>> >>>>>I got the impression that you completely misunderstand the purpose of >>>>> >>>>> >>>LCAS. LCAS >>> >>> >>>>>is NOT a signalling protocol. It is totally unrelated as such to control >>>>> >>>>> >>>plane >>> >>> >>>>>based connection management (GMPLS, ASON) or network management based >>>>> >>>>> >>>connection >>> >>> >>>>>management. >>>>> >>>>>LCAS doesn't change the number of VC-n or ODUk trails in the network. If >>>>> >>>>> >>>N >>> >>> >>>>>trails are set up between the A-end and Z-end, LCAS helps to hitless >>>>> >>>>> >>>change the >>> >>> >>>>>number of trails being used for the actual transport of the client >>>>> >>>>> >>>signal; i.e. >>> >>> >>>>>if X (X>>>> >>>>> >>>increase this >>> >>> >>>>>number to X+1 or shrink it to X-1, then LCAS coordinates the steps at >>>>> >>>>> >>>the A-end >>> >>> >>>>>and Z-end to make sure the increase/reduction is performed hitless. >>>>> >>>>>The steps to perform for the case X=N are: >>>>>A) X ==> X+1 >>>>> 1) [Operator or User] request connection management [NMS or >>>>> >>>>> >>>ASON/GMPLS] >>> >>> >>>>> to setup additional VC-n/ODUk between SNP Pool (SNPP) associated >>>>> >>>>> >>>with >>> >>> >>>>> virtual concatenated endpoint at A-end and corresponding SNPP at >>>>> >>>>> >>>Z-end >>> >>> >>>>> 2) connection management [NMS or ASON/GMPLS] commands LCAS >>>>> >>>>> >>>controllers at >>> >>> >>>>> A-end and Z-end to control the "addition" of the (X+1)th trail to >>>>> >>>>> >>>the >>> >>> >>>>> group of X trails ("Madd" command in G.7042) over which the client >>>>> bitstream is transported >>>>> 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends >>>>> >>>>> >>>this >>> >>> >>>>> to the receiver at the other end >>>>> 3) LCAS at A-end [Z-end] waits until connection is setup; the >>>>> >>>>> >>>connection >>> >>> >>>>> in one direction is setup if the Trail Signal Fail (TSF) condition >>>>> >>>>> >>>at >>> >>> >>>>> its end has cleared; >>>>> 4) LCAS communicates the TSF clearing to the other end ("MST=OK") >>>>> 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and >>>>> 6) at the start of the next VC-n/ODUk frame the client bitstream is >>>>> distributed over X+1 (instead of X) VC-n/ODUk trails >>>>> 7) the receiver at the other end notices the change of CTRL=ADD to >>>>> CTRL=EOS, and expects the client signal to be present on X+1 >>>>> >>>>> >>>(instead >>> >>> >>>>> of X) VC-n/ODUk trails at the begin of the next frame. >>>>> >>>>>Example with X=3 >>>>>================ >>>>> >>>>>The bits in a client bit stream with bits ...,1,2,3,4,... are >>>>> >>>>> >>>distributed over >>> >>> >>>>>trails #1..#3 as follows: >>>>> trail#1 trail#2 trail#3 >>>>> ... >>>>> 1-8 9-16 17-24 >>>>> 25-32 33-40 41-48 >>>>> 49-56 57-64 65-72 >>>>> 73-80 ... >>>>> >>>>>When trail #4 is added, no client bits will be transported over it, >>>>> >>>>> >>>until the >>> >>> >>>>>source has indicated this via the change of the control word CTRL=ADD => >>>>>CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits >>>>>...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" >>>>> >>>>> >>>begins at >>> >>> >>>>>the moment client bit 49 is to be transmitted, then trail#4 will be used >>>>> >>>>> >>>for the >>> >>> >>>>>transport of bits 73-80 and further: >>>>> >>>>> trail#1 trail#2 trail#3 trail#4 >>>>> ... >>>>> 1-8 9-16 17-24 >>>>> 25-32 33-40 41-48 >>>>> 49-56 57-64 65-72 73-80 >>>>> 81-88 89-96 97-104 105-112 >>>>> 113-120 ... >>>>> >>>>>Regards, >>>>> >>>>>Maarten >>>>> >>>>>Internet-Drafts@ietf.org wrote: >>>>> >>>>> >>>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> >>>>>> >>>directories. >>> >>> >>>>>> Title : GMPLS LSP Bandwidth Modification (LBM) for >>>>>> >>>>>> >>>TDM >>> >>> >>>>>> Networks >>>>>> Author(s) : E. Mannie, D. Papadimitriou >>>>>> Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt >>>>>> Pages : 13 >>>>>> Date : 15-Nov-01 >>>>>> >>>>>>This document defines how GMPLS can be used to dynamically modify >>>>>>the bandwidth of a TDM circuit. It focuses first on SONET/SDH and >>>>>>will cover G.709 in a next version. >>>>>> >>>>>>A URL for this Internet-Draft is: >>>>>> >>>>>> >>>>>> >>>http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> >>>>>> >>>>>> >>>>> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 10:09:10 -0800 Message-ID: <3BF55577.19ED9C20@alcatel.be> Date: Fri, 16 Nov 2001 19:05:43 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Zhi-Wei Lin CC: "Mannie, Eric" , "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------28310B2D4D64EFCC08FFE254" This is a multi-part message in MIME format. --------------28310B2D4D64EFCC08FFE254 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi, I read here the fourth sentence of the Annex: "The scheme allows hit-less addition and removal of bandwidth under control of a management system." Then in the LCAS document Section 3.18 "The LCAS assumes that in cases of capacity initiation, increases or decreases, the construction or destruction of the end-to-end path is the responsibility of the Network and Element Management Systems." So i think these sentences are clear within your documents - i am not responsible for this - you are the author not me or probably we have different interpretations of NMS systems. - dimitri. Zhi-Wei Lin wrote: > > Hi Eric, > > I would like to understand your statement: > > "LCAS makes a lot of sense for a static network where provisioning > occurs through a Network Management System." > > Is this your view of LCAS, that it is strictly limited to a static > network & that it is triggered only by NMS? > > Zhi > > Mannie, Eric wrote: > > > Hello Maarten, > > > > > >>Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > >>understanding of LCAS's objective (my very strong opinion). > >> > > > > Sorry, do you mean that it is forbidden to speak about your LCAS document > > and to compare GMPLS and LCAS functionalities ? > > > > > >>LCAS plays a role after the extra connection is setup or before a > >> > > connection is released. How this > > connection is setup or released is not relevant for LCAS. > > > > GMPLS plays a role for all the cases that you described: to setup a > > connection, to maintain a connection, to modify a connection, to release a > > connection, etc. > > > > LCAS makes a lot of sense for a static network where provisioning occurs > > through a Network Management System. > > > > A distributed control plane (like GMPLS) with LCAS doesn't make any sense. > > LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the > > beginning to allow LSP (bandwidth) modification. > > > > Do you mean that your implementation of GMPLS will not support any > > bandwidth/LSP modification ? > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Friday, November 16, 2001 5:30 PM > > To: Dimitri Papadimitriou > > Cc: ccamp; q11/15; t1x1.5 > > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > > > > Dimitri, > > > > Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > > understanding of LCAS's objective (my very strong opinion). LCAS plays a > > role > > after the extra connection is setup or before a connection is released. How > > this > > connection is setup or released is not relevant for LCAS. > > > > NMS and ASON/GMPLS are concerned with connection setup and release. And also > > with modification, if such is relevant for a connection. > > > > Modification of connection parameters is relevant for the connection > > (group(s)) > > supporting the transport of a Virtual Concatenated signal (VC-n-Xv, > > ODUk-Xv). > > > > If this modification isn't covered yet in GMPLS drafts, it is important to > > extend GMPLS and add it. But never ever relate it to LCAS :-). > > > > When we developed virtual concatenation and LCAS we where very much aware > > that > > we would get much more out of these two when there would be a switched > > network. > > The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) > > could > > then monitor the fill level of the virtual concatenated pipe, and when > > crossing > > a threshold could request another VC-n or ODUk to be setup. In a switched > > network the setup only takes a few seconds, and essentially in no time the > > bandwidth of the pipe can be increased. > > > > If LCAS is present, this new capacity can be included in the transmission of > > the > > ehternet bit stream without introducing any errors in the ehternet stream. > > > > If LCAS is not present, the ethernet transport will be interrupted for a > > shorter > > or longer period and (depending on the bandwidth of the pipe) fewer or many > > more > > packets will be lost before the transmission is restored. I.e. as long as > > the > > transmitter is using X+1 trails and the receiver is using X trails (or vice > > versa) transmission is interrupted. With NMS ordering the increase at A-end > > and > > Z-end (after the additional trail is setup) this period may be a couple of > > seconds; i.e. NMS has to generate two messages to the A node and the Z node, > > these messages have to travel through the DCN, the two nodes have to accept > > the > > messages and process those before the command can be given to the hardware > > to > > use X+1 instead of X trails. > > When a control plane is involved instead of NMS, the control plane has to > > set up > > the additional trail, verify that this trail is set up correctly (check for > > signal fail including trace identifier), then command one end to transmit > > over > > X+1 trails and quickly inform the other end that it should command the > > receiving > > endpoint to read from X+1 trails. This all might be in the 100ms range but > > most > > likely will also be in the seconds range (depending on network size and > > load). > > > > > > > > Dimitri Papadimitriou wrote: > > > >>Maarten, > >> > >>I think you have reach the main comparison point for this discussion > >>Let's start with this: > >> > >>- If you want to achieve hitles adaption you need a real-time protocol > >>to synchronize both ends in some way (supporting the for instance LCAS) > >>this is a synchronous approach > >> > >>- If you just want to add more capacity and you don't focus on a > >>'glitch' > >>perhaps very few millisecs when putting the capacity in use you can do > >>it in > >>a non-real time manner like with GMPLS - this is an asynchronous > >>approach > >> > > > > You always need NMS or ASON/GMPLS to be present to setup the additional > > connection. If an endpoint doesn't support LCAS, its function needs to be > > performed by NMS or ASON/GMPLS (with degraded performance). > > > > > >>The major difference between both procedures is that GMPLS gives an > >> > > > > There is no difference, as the two can not be compared. > > > > > >>answer > >>how to allocate capacity across the network while LCAS relies on the > >>fact > >>that it is already available i.e. "provisioned" (see LCAS specification) > >>for use and just has to be 'lit'. > >> > >>Hope this will help the reader to undertstand that both methods have a > >> > > > > Methods are LCAS and non-LCAS... > > > > > >>specific applicability scope, the GMPLS one is more adapted for dynamic > >>environments that do not use "provisioning" of the resources ... > >> > > > > In either case there is "provisioning" of the resources. The hardware in > > both > > endpoints must be told to use X+1 instead of X trails. > > > > > >>a real > >>bandwidth on demand service. I think this is what we have addressed > >>with this. And from what i understood this is what carriers are looking > >>for (since the bandwdith service is non-disruptive - if it can > >>accomodate > >>a very few ms -, flexible and doesn't require any pre-provisioning). > >> > > > > There is a large difference between "zero errors" and "a few ms (most likely > > seconds) of no transmission". > > > > > >>The second (LCAS) is adapted for services that could be sensitive, but > >>the price to pay is to provision the "resources". This is a static > >>approach of the problem. I think that both have a specific scope. > >> > > > > I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS > > provisioning is non-time critical, whereas the non-LCAS provisioning is time > > critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not > > mandatory, > > the investments in NMS and ASON/GMPLS to limit the traffic interruption have > > to > > be made. As such, your draft should focus on the means to limit the traffic > > interruption when LCAS is not present. This may imply kind of third party > > signalling information to be carried through the public switched transport > > network; i.e. for the case the virtual concatenated endpoints are outside of > > the > > PSTN, the user needs to have the capability to synchronize its endpoints. > > > > Regards, > > > > Maarten > > > > > > > >>Regards, > >>- dimitri. > >> > >>Maarten Vissers wrote: > >> > >>>Eric, Dimitri, > >>> > >>>I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. > >>> > > Doing so > > > >>>I got the impression that you completely misunderstand the purpose of > >>> > > LCAS. LCAS > > > >>>is NOT a signalling protocol. It is totally unrelated as such to control > >>> > > plane > > > >>>based connection management (GMPLS, ASON) or network management based > >>> > > connection > > > >>>management. > >>> > >>>LCAS doesn't change the number of VC-n or ODUk trails in the network. If > >>> > > N > > > >>>trails are set up between the A-end and Z-end, LCAS helps to hitless > >>> > > change the > > > >>>number of trails being used for the actual transport of the client > >>> > > signal; i.e. > > > >>>if X (X >>> > > increase this > > > >>>number to X+1 or shrink it to X-1, then LCAS coordinates the steps at > >>> > > the A-end > > > >>>and Z-end to make sure the increase/reduction is performed hitless. > >>> > >>>The steps to perform for the case X=N are: > >>>A) X ==> X+1 > >>> 1) [Operator or User] request connection management [NMS or > >>> > > ASON/GMPLS] > > > >>> to setup additional VC-n/ODUk between SNP Pool (SNPP) associated > >>> > > with > > > >>> virtual concatenated endpoint at A-end and corresponding SNPP at > >>> > > Z-end > > > >>> 2) connection management [NMS or ASON/GMPLS] commands LCAS > >>> > > controllers at > > > >>> A-end and Z-end to control the "addition" of the (X+1)th trail to > >>> > > the > > > >>> group of X trails ("Madd" command in G.7042) over which the client > >>> bitstream is transported > >>> 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends > >>> > > this > > > >>> to the receiver at the other end > >>> 3) LCAS at A-end [Z-end] waits until connection is setup; the > >>> > > connection > > > >>> in one direction is setup if the Trail Signal Fail (TSF) condition > >>> > > at > > > >>> its end has cleared; > >>> 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > >>> 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > >>> 6) at the start of the next VC-n/ODUk frame the client bitstream is > >>> distributed over X+1 (instead of X) VC-n/ODUk trails > >>> 7) the receiver at the other end notices the change of CTRL=ADD to > >>> CTRL=EOS, and expects the client signal to be present on X+1 > >>> > > (instead > > > >>> of X) VC-n/ODUk trails at the begin of the next frame. > >>> > >>>Example with X=3 > >>>================ > >>> > >>>The bits in a client bit stream with bits ...,1,2,3,4,... are > >>> > > distributed over > > > >>>trails #1..#3 as follows: > >>> trail#1 trail#2 trail#3 > >>> ... > >>> 1-8 9-16 17-24 > >>> 25-32 33-40 41-48 > >>> 49-56 57-64 65-72 > >>> 73-80 ... > >>> > >>>When trail #4 is added, no client bits will be transported over it, > >>> > > until the > > > >>>source has indicated this via the change of the control word CTRL=ADD => > >>>CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > >>>...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" > >>> > > begins at > > > >>>the moment client bit 49 is to be transmitted, then trail#4 will be used > >>> > > for the > > > >>>transport of bits 73-80 and further: > >>> > >>> trail#1 trail#2 trail#3 trail#4 > >>> ... > >>> 1-8 9-16 17-24 > >>> 25-32 33-40 41-48 > >>> 49-56 57-64 65-72 73-80 > >>> 81-88 89-96 97-104 105-112 > >>> 113-120 ... > >>> > >>>Regards, > >>> > >>>Maarten > >>> > >>>Internet-Drafts@ietf.org wrote: > >>> > >>>>A New Internet-Draft is available from the on-line Internet-Drafts > >>>> > > directories. > > > >>>> Title : GMPLS LSP Bandwidth Modification (LBM) for > >>>> > > TDM > > > >>>> Networks > >>>> Author(s) : E. Mannie, D. Papadimitriou > >>>> Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > >>>> Pages : 13 > >>>> Date : 15-Nov-01 > >>>> > >>>>This document defines how GMPLS can be used to dynamically modify > >>>>the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > >>>>will cover G.709 in a next version. > >>>> > >>>>A URL for this Internet-Draft is: > >>>> > >>>> > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> > >>>> --------------28310B2D4D64EFCC08FFE254 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------28310B2D4D64EFCC08FFE254-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 09:59:22 -0800 Message-ID: <3BF55326.4040904@lucent.com> Date: Fri, 16 Nov 2001 12:55:50 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 MIME-Version: 1.0 To: "Mannie, Eric" CC: "'Maarten Vissers'" , ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Eric, I would like to understand your statement: "LCAS makes a lot of sense for a static network where provisioning occurs through a Network Management System." Is this your view of LCAS, that it is strictly limited to a static network & that it is triggered only by NMS? Zhi Mannie, Eric wrote: > Hello Maarten, > > >>Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of >>understanding of LCAS's objective (my very strong opinion). >> > > Sorry, do you mean that it is forbidden to speak about your LCAS document > and to compare GMPLS and LCAS functionalities ? > > >>LCAS plays a role after the extra connection is setup or before a >> > connection is released. How this > connection is setup or released is not relevant for LCAS. > > GMPLS plays a role for all the cases that you described: to setup a > connection, to maintain a connection, to modify a connection, to release a > connection, etc. > > LCAS makes a lot of sense for a static network where provisioning occurs > through a Network Management System. > > A distributed control plane (like GMPLS) with LCAS doesn't make any sense. > LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the > beginning to allow LSP (bandwidth) modification. > > Do you mean that your implementation of GMPLS will not support any > bandwidth/LSP modification ? > > Kind regards, > > Eric > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Friday, November 16, 2001 5:30 PM > To: Dimitri Papadimitriou > Cc: ccamp; q11/15; t1x1.5 > Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Dimitri, > > Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of > understanding of LCAS's objective (my very strong opinion). LCAS plays a > role > after the extra connection is setup or before a connection is released. How > this > connection is setup or released is not relevant for LCAS. > > NMS and ASON/GMPLS are concerned with connection setup and release. And also > with modification, if such is relevant for a connection. > > Modification of connection parameters is relevant for the connection > (group(s)) > supporting the transport of a Virtual Concatenated signal (VC-n-Xv, > ODUk-Xv). > > If this modification isn't covered yet in GMPLS drafts, it is important to > extend GMPLS and add it. But never ever relate it to LCAS :-). > > When we developed virtual concatenation and LCAS we where very much aware > that > we would get much more out of these two when there would be a switched > network. > The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) > could > then monitor the fill level of the virtual concatenated pipe, and when > crossing > a threshold could request another VC-n or ODUk to be setup. In a switched > network the setup only takes a few seconds, and essentially in no time the > bandwidth of the pipe can be increased. > > If LCAS is present, this new capacity can be included in the transmission of > the > ehternet bit stream without introducing any errors in the ehternet stream. > > If LCAS is not present, the ethernet transport will be interrupted for a > shorter > or longer period and (depending on the bandwidth of the pipe) fewer or many > more > packets will be lost before the transmission is restored. I.e. as long as > the > transmitter is using X+1 trails and the receiver is using X trails (or vice > versa) transmission is interrupted. With NMS ordering the increase at A-end > and > Z-end (after the additional trail is setup) this period may be a couple of > seconds; i.e. NMS has to generate two messages to the A node and the Z node, > these messages have to travel through the DCN, the two nodes have to accept > the > messages and process those before the command can be given to the hardware > to > use X+1 instead of X trails. > When a control plane is involved instead of NMS, the control plane has to > set up > the additional trail, verify that this trail is set up correctly (check for > signal fail including trace identifier), then command one end to transmit > over > X+1 trails and quickly inform the other end that it should command the > receiving > endpoint to read from X+1 trails. This all might be in the 100ms range but > most > likely will also be in the seconds range (depending on network size and > load). > > > > Dimitri Papadimitriou wrote: > >>Maarten, >> >>I think you have reach the main comparison point for this discussion >>Let's start with this: >> >>- If you want to achieve hitles adaption you need a real-time protocol >>to synchronize both ends in some way (supporting the for instance LCAS) >>this is a synchronous approach >> >>- If you just want to add more capacity and you don't focus on a >>'glitch' >>perhaps very few millisecs when putting the capacity in use you can do >>it in >>a non-real time manner like with GMPLS - this is an asynchronous >>approach >> > > You always need NMS or ASON/GMPLS to be present to setup the additional > connection. If an endpoint doesn't support LCAS, its function needs to be > performed by NMS or ASON/GMPLS (with degraded performance). > > >>The major difference between both procedures is that GMPLS gives an >> > > There is no difference, as the two can not be compared. > > >>answer >>how to allocate capacity across the network while LCAS relies on the >>fact >>that it is already available i.e. "provisioned" (see LCAS specification) >>for use and just has to be 'lit'. >> >>Hope this will help the reader to undertstand that both methods have a >> > > Methods are LCAS and non-LCAS... > > >>specific applicability scope, the GMPLS one is more adapted for dynamic >>environments that do not use "provisioning" of the resources ... >> > > In either case there is "provisioning" of the resources. The hardware in > both > endpoints must be told to use X+1 instead of X trails. > > >>a real >>bandwidth on demand service. I think this is what we have addressed >>with this. And from what i understood this is what carriers are looking >>for (since the bandwdith service is non-disruptive - if it can >>accomodate >>a very few ms -, flexible and doesn't require any pre-provisioning). >> > > There is a large difference between "zero errors" and "a few ms (most likely > seconds) of no transmission". > > >>The second (LCAS) is adapted for services that could be sensitive, but >>the price to pay is to provision the "resources". This is a static >>approach of the problem. I think that both have a specific scope. >> > > I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS > provisioning is non-time critical, whereas the non-LCAS provisioning is time > critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not > mandatory, > the investments in NMS and ASON/GMPLS to limit the traffic interruption have > to > be made. As such, your draft should focus on the means to limit the traffic > interruption when LCAS is not present. This may imply kind of third party > signalling information to be carried through the public switched transport > network; i.e. for the case the virtual concatenated endpoints are outside of > the > PSTN, the user needs to have the capability to synchronize its endpoints. > > Regards, > > Maarten > > > >>Regards, >>- dimitri. >> >>Maarten Vissers wrote: >> >>>Eric, Dimitri, >>> >>>I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. >>> > Doing so > >>>I got the impression that you completely misunderstand the purpose of >>> > LCAS. LCAS > >>>is NOT a signalling protocol. It is totally unrelated as such to control >>> > plane > >>>based connection management (GMPLS, ASON) or network management based >>> > connection > >>>management. >>> >>>LCAS doesn't change the number of VC-n or ODUk trails in the network. If >>> > N > >>>trails are set up between the A-end and Z-end, LCAS helps to hitless >>> > change the > >>>number of trails being used for the actual transport of the client >>> > signal; i.e. > >>>if X (X>> > increase this > >>>number to X+1 or shrink it to X-1, then LCAS coordinates the steps at >>> > the A-end > >>>and Z-end to make sure the increase/reduction is performed hitless. >>> >>>The steps to perform for the case X=N are: >>>A) X ==> X+1 >>> 1) [Operator or User] request connection management [NMS or >>> > ASON/GMPLS] > >>> to setup additional VC-n/ODUk between SNP Pool (SNPP) associated >>> > with > >>> virtual concatenated endpoint at A-end and corresponding SNPP at >>> > Z-end > >>> 2) connection management [NMS or ASON/GMPLS] commands LCAS >>> > controllers at > >>> A-end and Z-end to control the "addition" of the (X+1)th trail to >>> > the > >>> group of X trails ("Madd" command in G.7042) over which the client >>> bitstream is transported >>> 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends >>> > this > >>> to the receiver at the other end >>> 3) LCAS at A-end [Z-end] waits until connection is setup; the >>> > connection > >>> in one direction is setup if the Trail Signal Fail (TSF) condition >>> > at > >>> its end has cleared; >>> 4) LCAS communicates the TSF clearing to the other end ("MST=OK") >>> 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and >>> 6) at the start of the next VC-n/ODUk frame the client bitstream is >>> distributed over X+1 (instead of X) VC-n/ODUk trails >>> 7) the receiver at the other end notices the change of CTRL=ADD to >>> CTRL=EOS, and expects the client signal to be present on X+1 >>> > (instead > >>> of X) VC-n/ODUk trails at the begin of the next frame. >>> >>>Example with X=3 >>>================ >>> >>>The bits in a client bit stream with bits ...,1,2,3,4,... are >>> > distributed over > >>>trails #1..#3 as follows: >>> trail#1 trail#2 trail#3 >>> ... >>> 1-8 9-16 17-24 >>> 25-32 33-40 41-48 >>> 49-56 57-64 65-72 >>> 73-80 ... >>> >>>When trail #4 is added, no client bits will be transported over it, >>> > until the > >>>source has indicated this via the change of the control word CTRL=ADD => >>>CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits >>>...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" >>> > begins at > >>>the moment client bit 49 is to be transmitted, then trail#4 will be used >>> > for the > >>>transport of bits 73-80 and further: >>> >>> trail#1 trail#2 trail#3 trail#4 >>> ... >>> 1-8 9-16 17-24 >>> 25-32 33-40 41-48 >>> 49-56 57-64 65-72 73-80 >>> 81-88 89-96 97-104 105-112 >>> 113-120 ... >>> >>>Regards, >>> >>>Maarten >>> >>>Internet-Drafts@ietf.org wrote: >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>> > directories. > >>>> Title : GMPLS LSP Bandwidth Modification (LBM) for >>>> > TDM > >>>> Networks >>>> Author(s) : E. Mannie, D. Papadimitriou >>>> Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt >>>> Pages : 13 >>>> Date : 15-Nov-01 >>>> >>>>This document defines how GMPLS can be used to dynamically modify >>>>the bandwidth of a TDM circuit. It focuses first on SONET/SDH and >>>>will cover G.709 in a next version. >>>> >>>>A URL for this Internet-Draft is: >>>> >>>> > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> >>>> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 09:49:31 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' , ccamp , q11/15 , "t1x1.5" Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 18:47:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, > I got the impression that you completely misunderstand the purpose of LCAS. LCAS is NOT a signalling protocol. The LCAS specification defines the "LCAS protocol" (annex A), with time sequence diagrams (Appendix I), control packets (section 6.2) with fields, etc etc... if this is not a signaling protocol I am not a network scientist anymore. Anyway, this is not the point. Kind regards, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 16, 2001 3:36 PM To: ccamp; q11/15; t1x1.5 Subject: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Eric, Dimitri, I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so I got the impression that you completely misunderstand the purpose of LCAS. LCAS is NOT a signalling protocol. It is totally unrelated as such to control plane based connection management (GMPLS, ASON) or network management based connection management. LCAS doesn't change the number of VC-n or ODUk trails in the network. If N trails are set up between the A-end and Z-end, LCAS helps to hitless change the number of trails being used for the actual transport of the client signal; i.e. if X (X X+1 1) [Operator or User] request connection management [NMS or ASON/GMPLS] to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with virtual concatenated endpoint at A-end and corresponding SNPP at Z-end 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at A-end and Z-end to control the "addition" of the (X+1)th trail to the group of X trails ("Madd" command in G.7042) over which the client bitstream is transported 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this to the receiver at the other end 3) LCAS at A-end [Z-end] waits until connection is setup; the connection in one direction is setup if the Trail Signal Fail (TSF) condition at its end has cleared; 4) LCAS communicates the TSF clearing to the other end ("MST=OK") 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and 6) at the start of the next VC-n/ODUk frame the client bitstream is distributed over X+1 (instead of X) VC-n/ODUk trails 7) the receiver at the other end notices the change of CTRL=ADD to CTRL=EOS, and expects the client signal to be present on X+1 (instead of X) VC-n/ODUk trails at the begin of the next frame. Example with X=3 ================ The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over trails #1..#3 as follows: trail#1 trail#2 trail#3 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 ... When trail #4 is added, no client bits will be transported over it, until the source has indicated this via the change of the control word CTRL=ADD => CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at the moment client bit 49 is to be transmitted, then trail#4 will be used for the transport of bits 73-80 and further: trail#1 trail#2 trail#3 trail#4 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 81-88 89-96 97-104 105-112 113-120 ... Regards, Maarten Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > Networks > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > Pages : 13 > Date : 15-Nov-01 > > This document defines how GMPLS can be used to dynamically modify > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > will cover G.709 in a next version. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 09:40:21 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' Cc: ccamp , q11/15 , "t1x1.5" , Dimitri Papadimitriou Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 18:39:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Maarten, >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of >understanding of LCAS's objective (my very strong opinion). Sorry, do you mean that it is forbidden to speak about your LCAS document and to compare GMPLS and LCAS functionalities ? >LCAS plays a role after the extra connection is setup or before a connection is released. How this connection is setup or released is not relevant for LCAS. GMPLS plays a role for all the cases that you described: to setup a connection, to maintain a connection, to modify a connection, to release a connection, etc. LCAS makes a lot of sense for a static network where provisioning occurs through a Network Management System. A distributed control plane (like GMPLS) with LCAS doesn't make any sense. LCAS does a small subset of GMPLS LBM. MPLS and GMPLS were designed from the beginning to allow LSP (bandwidth) modification. Do you mean that your implementation of GMPLS will not support any bandwidth/LSP modification ? Kind regards, Eric -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Friday, November 16, 2001 5:30 PM To: Dimitri Papadimitriou Cc: ccamp; q11/15; t1x1.5 Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Dimitri, Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of understanding of LCAS's objective (my very strong opinion). LCAS plays a role after the extra connection is setup or before a connection is released. How this connection is setup or released is not relevant for LCAS. NMS and ASON/GMPLS are concerned with connection setup and release. And also with modification, if such is relevant for a connection. Modification of connection parameters is relevant for the connection (group(s)) supporting the transport of a Virtual Concatenated signal (VC-n-Xv, ODUk-Xv). If this modification isn't covered yet in GMPLS drafts, it is important to extend GMPLS and add it. But never ever relate it to LCAS :-). When we developed virtual concatenation and LCAS we where very much aware that we would get much more out of these two when there would be a switched network. The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) could then monitor the fill level of the virtual concatenated pipe, and when crossing a threshold could request another VC-n or ODUk to be setup. In a switched network the setup only takes a few seconds, and essentially in no time the bandwidth of the pipe can be increased. If LCAS is present, this new capacity can be included in the transmission of the ehternet bit stream without introducing any errors in the ehternet stream. If LCAS is not present, the ethernet transport will be interrupted for a shorter or longer period and (depending on the bandwidth of the pipe) fewer or many more packets will be lost before the transmission is restored. I.e. as long as the transmitter is using X+1 trails and the receiver is using X trails (or vice versa) transmission is interrupted. With NMS ordering the increase at A-end and Z-end (after the additional trail is setup) this period may be a couple of seconds; i.e. NMS has to generate two messages to the A node and the Z node, these messages have to travel through the DCN, the two nodes have to accept the messages and process those before the command can be given to the hardware to use X+1 instead of X trails. When a control plane is involved instead of NMS, the control plane has to set up the additional trail, verify that this trail is set up correctly (check for signal fail including trace identifier), then command one end to transmit over X+1 trails and quickly inform the other end that it should command the receiving endpoint to read from X+1 trails. This all might be in the 100ms range but most likely will also be in the seconds range (depending on network size and load). Dimitri Papadimitriou wrote: > > Maarten, > > I think you have reach the main comparison point for this discussion > Let's start with this: > > - If you want to achieve hitles adaption you need a real-time protocol > to synchronize both ends in some way (supporting the for instance LCAS) > this is a synchronous approach > > - If you just want to add more capacity and you don't focus on a > 'glitch' > perhaps very few millisecs when putting the capacity in use you can do > it in > a non-real time manner like with GMPLS - this is an asynchronous > approach You always need NMS or ASON/GMPLS to be present to setup the additional connection. If an endpoint doesn't support LCAS, its function needs to be performed by NMS or ASON/GMPLS (with degraded performance). > > The major difference between both procedures is that GMPLS gives an There is no difference, as the two can not be compared. > answer > how to allocate capacity across the network while LCAS relies on the > fact > that it is already available i.e. "provisioned" (see LCAS specification) > for use and just has to be 'lit'. > > Hope this will help the reader to undertstand that both methods have a Methods are LCAS and non-LCAS... > specific applicability scope, the GMPLS one is more adapted for dynamic > environments that do not use "provisioning" of the resources ... In either case there is "provisioning" of the resources. The hardware in both endpoints must be told to use X+1 instead of X trails. > a real > bandwidth on demand service. I think this is what we have addressed > with this. And from what i understood this is what carriers are looking > for (since the bandwdith service is non-disruptive - if it can > accomodate > a very few ms -, flexible and doesn't require any pre-provisioning). There is a large difference between "zero errors" and "a few ms (most likely seconds) of no transmission". > > The second (LCAS) is adapted for services that could be sensitive, but > the price to pay is to provision the "resources". This is a static > approach of the problem. I think that both have a specific scope. I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS provisioning is non-time critical, whereas the non-LCAS provisioning is time critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not mandatory, the investments in NMS and ASON/GMPLS to limit the traffic interruption have to be made. As such, your draft should focus on the means to limit the traffic interruption when LCAS is not present. This may imply kind of third party signalling information to be carried through the public switched transport network; i.e. for the case the virtual concatenated endpoints are outside of the PSTN, the user needs to have the capability to synchronize its endpoints. Regards, Maarten > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Eric, Dimitri, > > > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > > is NOT a signalling protocol. It is totally unrelated as such to control plane > > based connection management (GMPLS, ASON) or network management based connection > > management. > > > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > > number of trails being used for the actual transport of the client signal; i.e. > > if X (X > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > > and Z-end to make sure the increase/reduction is performed hitless. > > > > The steps to perform for the case X=N are: > > A) X ==> X+1 > > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > > A-end and Z-end to control the "addition" of the (X+1)th trail to the > > group of X trails ("Madd" command in G.7042) over which the client > > bitstream is transported > > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > > to the receiver at the other end > > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > > in one direction is setup if the Trail Signal Fail (TSF) condition at > > its end has cleared; > > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > > 6) at the start of the next VC-n/ODUk frame the client bitstream is > > distributed over X+1 (instead of X) VC-n/ODUk trails > > 7) the receiver at the other end notices the change of CTRL=ADD to > > CTRL=EOS, and expects the client signal to be present on X+1 (instead > > of X) VC-n/ODUk trails at the begin of the next frame. > > > > Example with X=3 > > ================ > > > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > > trails #1..#3 as follows: > > trail#1 trail#2 trail#3 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 > > 73-80 ... > > > > When trail #4 is added, no client bits will be transported over it, until the > > source has indicated this via the change of the control word CTRL=ADD => > > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > > transport of bits 73-80 and further: > > > > trail#1 trail#2 trail#3 trail#4 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 73-80 > > 81-88 89-96 97-104 105-112 > > 113-120 ... > > > > Regards, > > > > Maarten > > > > Internet-Drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > > Networks > > > Author(s) : E. Mannie, D. Papadimitriou > > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Pages : 13 > > > Date : 15-Nov-01 > > > > > > This document defines how GMPLS can be used to dynamically modify > > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > > will cover G.709 in a next version. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 08:49:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: Krishna Pattabhiraman To: Dimitri Papadimitriou , Maarten Vissers Cc: Ramji Raghavan , ccamp , q11/15 , "t1x1.5" , Kumar Kovvali Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 10:56:00 -0500 Hi, We had presented couple of contributions at the previous T1X1 to address some limitations of LCAS. We had proposed a lightweight LCAS protocol that doesn't require A-end and Z-end handshake and doesn't assume a provisioning event before each bandwidth update event. As Maarten correctly points out LCAS as currently defined is not a signalling protocol, but enables a hitless bandwidth change. There are couple of documents attached - justification.doc and proposal.doc. Pls feel free to comment on the justification document and the actual proposal document. The actual proposal document is a work in progress. The justification document presents examples of scenarios where "dynamic" real-time changes of bandwidths may be required and how a lightweight LCAS may be used to solve it. regards, Krishna -----Original Message----- From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] Sent: Friday, November 16, 2001 10:28 AM To: Maarten Vissers Cc: ccamp; q11/15; t1x1.5 Subject: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Maarten, I think you have reach the main comparison point for this discussion Let's start with this: - If you want to achieve hitles adaption you need a real-time protocol to synchronize both ends in some way (supporting the for instance LCAS) this is a synchronous approach - If you just want to add more capacity and you don't focus on a 'glitch' perhaps very few millisecs when putting the capacity in use you can do it in a non-real time manner like with GMPLS - this is an asynchronous approach The major difference between both procedures is that GMPLS gives an answer how to allocate capacity across the network while LCAS relies on the fact that it is already available i.e. "provisioned" (see LCAS specification) for use and just has to be 'lit'. Hope this will help the reader to undertstand that both methods have a specific applicability scope, the GMPLS one is more adapted for dynamic environments that do not use "provisioning" of the resources ... a real bandwidth on demand service. I think this is what we have addressed with this. And from what i understood this is what carriers are looking for (since the bandwdith service is non-disruptive - if it can accomodate a very few ms -, flexible and doesn't require any pre-provisioning). The second (LCAS) is adapted for services that could be sensitive, but the price to pay is to provision the "resources". This is a static approach of the problem. I think that both have a specific scope. Regards, - dimitri. Maarten Vissers wrote: > > Eric, Dimitri, > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > is NOT a signalling protocol. It is totally unrelated as such to control plane > based connection management (GMPLS, ASON) or network management based connection > management. > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > number of trails being used for the actual transport of the client signal; i.e. > if X (X number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > and Z-end to make sure the increase/reduction is performed hitless. > > The steps to perform for the case X=N are: > A) X ==> X+1 > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > A-end and Z-end to control the "addition" of the (X+1)th trail to the > group of X trails ("Madd" command in G.7042) over which the client > bitstream is transported > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > to the receiver at the other end > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > in one direction is setup if the Trail Signal Fail (TSF) condition at > its end has cleared; > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > 6) at the start of the next VC-n/ODUk frame the client bitstream is > distributed over X+1 (instead of X) VC-n/ODUk trails > 7) the receiver at the other end notices the change of CTRL=ADD to > CTRL=EOS, and expects the client signal to be present on X+1 (instead > of X) VC-n/ODUk trails at the begin of the next frame. > > Example with X=3 > ================ > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > trails #1..#3 as follows: > trail#1 trail#2 trail#3 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 > 73-80 ... > > When trail #4 is added, no client bits will be transported over it, until the > source has indicated this via the change of the control word CTRL=ADD => > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > transport of bits 73-80 and further: > > trail#1 trail#2 trail#3 trail#4 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 73-80 > 81-88 89-96 97-104 105-112 > 113-120 ... > > Regards, > > Maarten > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > Networks > > Author(s) : E. Mannie, D. Papadimitriou > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Pages : 13 > > Date : 15-Nov-01 > > > > This document defines how GMPLS can be used to dynamically modify > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > will cover G.709 in a next version. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: Fri, 16 Nov 2001 08:39:34 -0800 Cc: ccamp , q11/15 , "t1x1.5" Message-ID: <3BF53EFE.2E669F94@lucent.com> Date: Fri, 16 Nov 2001 17:29:50 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------C8F40EB64AA725B0D72D9C8F" This is a multi-part message in MIME format. --------------C8F40EB64AA725B0D72D9C8F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of understanding of LCAS's objective (my very strong opinion). LCAS plays a role after the extra connection is setup or before a connection is released. How this connection is setup or released is not relevant for LCAS. NMS and ASON/GMPLS are concerned with connection setup and release. And also with modification, if such is relevant for a connection. Modification of connection parameters is relevant for the connection (group(s)) supporting the transport of a Virtual Concatenated signal (VC-n-Xv, ODUk-Xv). If this modification isn't covered yet in GMPLS drafts, it is important to extend GMPLS and add it. But never ever relate it to LCAS :-). When we developed virtual concatenation and LCAS we where very much aware that we would get much more out of these two when there would be a switched network. The e.g. ethernet ports (mapping ehternet via GFP into VC-n-Xv/ODUk-Xv) could then monitor the fill level of the virtual concatenated pipe, and when crossing a threshold could request another VC-n or ODUk to be setup. In a switched network the setup only takes a few seconds, and essentially in no time the bandwidth of the pipe can be increased. If LCAS is present, this new capacity can be included in the transmission of the ehternet bit stream without introducing any errors in the ehternet stream. If LCAS is not present, the ethernet transport will be interrupted for a shorter or longer period and (depending on the bandwidth of the pipe) fewer or many more packets will be lost before the transmission is restored. I.e. as long as the transmitter is using X+1 trails and the receiver is using X trails (or vice versa) transmission is interrupted. With NMS ordering the increase at A-end and Z-end (after the additional trail is setup) this period may be a couple of seconds; i.e. NMS has to generate two messages to the A node and the Z node, these messages have to travel through the DCN, the two nodes have to accept the messages and process those before the command can be given to the hardware to use X+1 instead of X trails. When a control plane is involved instead of NMS, the control plane has to set up the additional trail, verify that this trail is set up correctly (check for signal fail including trace identifier), then command one end to transmit over X+1 trails and quickly inform the other end that it should command the receiving endpoint to read from X+1 trails. This all might be in the 100ms range but most likely will also be in the seconds range (depending on network size and load). Dimitri Papadimitriou wrote: > > Maarten, > > I think you have reach the main comparison point for this discussion > Let's start with this: > > - If you want to achieve hitles adaption you need a real-time protocol > to synchronize both ends in some way (supporting the for instance LCAS) > this is a synchronous approach > > - If you just want to add more capacity and you don't focus on a > 'glitch' > perhaps very few millisecs when putting the capacity in use you can do > it in > a non-real time manner like with GMPLS - this is an asynchronous > approach You always need NMS or ASON/GMPLS to be present to setup the additional connection. If an endpoint doesn't support LCAS, its function needs to be performed by NMS or ASON/GMPLS (with degraded performance). > > The major difference between both procedures is that GMPLS gives an There is no difference, as the two can not be compared. > answer > how to allocate capacity across the network while LCAS relies on the > fact > that it is already available i.e. "provisioned" (see LCAS specification) > for use and just has to be 'lit'. > > Hope this will help the reader to undertstand that both methods have a Methods are LCAS and non-LCAS... > specific applicability scope, the GMPLS one is more adapted for dynamic > environments that do not use "provisioning" of the resources ... In either case there is "provisioning" of the resources. The hardware in both endpoints must be told to use X+1 instead of X trails. > a real > bandwidth on demand service. I think this is what we have addressed > with this. And from what i understood this is what carriers are looking > for (since the bandwdith service is non-disruptive - if it can > accomodate > a very few ms -, flexible and doesn't require any pre-provisioning). There is a large difference between "zero errors" and "a few ms (most likely seconds) of no transmission". > > The second (LCAS) is adapted for services that could be sensitive, but > the price to pay is to provision the "resources". This is a static > approach of the problem. I think that both have a specific scope. I hope I showed that both LCAS/non-LCAS method requires provisioning. LCAS provisioning is non-time critical, whereas the non-LCAS provisioning is time critical. The latter complicates NMS and ASON/GMPLS. As LCAS is not mandatory, the investments in NMS and ASON/GMPLS to limit the traffic interruption have to be made. As such, your draft should focus on the means to limit the traffic interruption when LCAS is not present. This may imply kind of third party signalling information to be carried through the public switched transport network; i.e. for the case the virtual concatenated endpoints are outside of the PSTN, the user needs to have the capability to synchronize its endpoints. Regards, Maarten > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Eric, Dimitri, > > > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > > is NOT a signalling protocol. It is totally unrelated as such to control plane > > based connection management (GMPLS, ASON) or network management based connection > > management. > > > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > > number of trails being used for the actual transport of the client signal; i.e. > > if X (X > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > > and Z-end to make sure the increase/reduction is performed hitless. > > > > The steps to perform for the case X=N are: > > A) X ==> X+1 > > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > > A-end and Z-end to control the "addition" of the (X+1)th trail to the > > group of X trails ("Madd" command in G.7042) over which the client > > bitstream is transported > > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > > to the receiver at the other end > > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > > in one direction is setup if the Trail Signal Fail (TSF) condition at > > its end has cleared; > > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > > 6) at the start of the next VC-n/ODUk frame the client bitstream is > > distributed over X+1 (instead of X) VC-n/ODUk trails > > 7) the receiver at the other end notices the change of CTRL=ADD to > > CTRL=EOS, and expects the client signal to be present on X+1 (instead > > of X) VC-n/ODUk trails at the begin of the next frame. > > > > Example with X=3 > > ================ > > > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > > trails #1..#3 as follows: > > trail#1 trail#2 trail#3 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 > > 73-80 ... > > > > When trail #4 is added, no client bits will be transported over it, until the > > source has indicated this via the change of the control word CTRL=ADD => > > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > > transport of bits 73-80 and further: > > > > trail#1 trail#2 trail#3 trail#4 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 73-80 > > 81-88 89-96 97-104 105-112 > > 113-120 ... > > > > Regards, > > > > Maarten > > > > Internet-Drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > > Networks > > > Author(s) : E. Mannie, D. Papadimitriou > > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Pages : 13 > > > Date : 15-Nov-01 > > > > > > This document defines how GMPLS can be used to dynamically modify > > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > > will cover G.709 in a next version. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> --------------C8F40EB64AA725B0D72D9C8F 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 --------------C8F40EB64AA725B0D72D9C8F-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 08:03:41 -0800 Message-ID: <3BF53800.9DAA3283@lucent.com> Date: Fri, 16 Nov 2001 09:00:00 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou CC: Maarten Vissers , ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, LCAS is a different step in the process from LBM. If you want to grow the capacity of the link, you need to perform more than one step: 1. The additional capacity needs to be set up. e.g., if you have 6 VC-4s in a VC-4-6v and want to add VC-4 #7, you need to set up the 7th VC-4 between the endpoints. If this 7th VC-4 is set up using a BW modification request, the control plane will know that the LSP for this new VC-4 is part of the same circuit as the LSP(s) for the first 6 VC-4s. 2. The payload mapping at the two ends has to be changed to utilize the additional capacity. If you want to do this hitlessly, you use LCAS. LBM and LCAS serve (related, but) different purposes. They are complementary rather than being alternative choices. As a result, I do not like the title of clause 3: "GMPLS LBM versus LCAS". Can you use LBM without LCAS? Yes, if you don't mind a glitch to the traffic. Can you use LCAS without LBM? Yes, if you don't care whether the control plane knows that the different LSPs are part of the same circuit. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to be the preferred method for many applications. Regards, Steve Dimitri Papadimitriou wrote: > > Maarten, > > I think you have reach the main comparison point for this discussion > Let's start with this: > > - If you want to achieve hitles adaption you need a real-time protocol > to synchronize both ends in some way (supporting the for instance LCAS) > this is a synchronous approach > > - If you just want to add more capacity and you don't focus on a > 'glitch' > perhaps very few millisecs when putting the capacity in use you can do > it in > a non-real time manner like with GMPLS - this is an asynchronous > approach > > The major difference between both procedures is that GMPLS gives an > answer > how to allocate capacity across the network while LCAS relies on the > fact > that it is already available i.e. "provisioned" (see LCAS specification) > for use and just has to be 'lit'. > > Hope this will help the reader to undertstand that both methods have a > specific applicability scope, the GMPLS one is more adapted for dynamic > environments that do not use "provisioning" of the resources ... a real > bandwidth on demand service. I think this is what we have addressed > with this. And from what i understood this is what carriers are looking > for (since the bandwdith service is non-disruptive - if it can > accomodate > a very few ms -, flexible and doesn't require any pre-provisioning). > > The second (LCAS) is adapted for services that could be sensitive, but > the price to pay is to provision the "resources". This is a static > approach of the problem. I think that both have a specific scope. > > Regards, > - dimitri. > > Maarten Vissers wrote: > > > > Eric, Dimitri, > > > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > > is NOT a signalling protocol. It is totally unrelated as such to control plane > > based connection management (GMPLS, ASON) or network management based connection > > management. > > > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > > number of trails being used for the actual transport of the client signal; i.e. > > if X (X > number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > > and Z-end to make sure the increase/reduction is performed hitless. > > > > The steps to perform for the case X=N are: > > A) X ==> X+1 > > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > > A-end and Z-end to control the "addition" of the (X+1)th trail to the > > group of X trails ("Madd" command in G.7042) over which the client > > bitstream is transported > > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > > to the receiver at the other end > > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > > in one direction is setup if the Trail Signal Fail (TSF) condition at > > its end has cleared; > > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > > 6) at the start of the next VC-n/ODUk frame the client bitstream is > > distributed over X+1 (instead of X) VC-n/ODUk trails > > 7) the receiver at the other end notices the change of CTRL=ADD to > > CTRL=EOS, and expects the client signal to be present on X+1 (instead > > of X) VC-n/ODUk trails at the begin of the next frame. > > > > Example with X=3 > > ================ > > > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > > trails #1..#3 as follows: > > trail#1 trail#2 trail#3 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 > > 73-80 ... > > > > When trail #4 is added, no client bits will be transported over it, until the > > source has indicated this via the change of the control word CTRL=ADD => > > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > > transport of bits 73-80 and further: > > > > trail#1 trail#2 trail#3 trail#4 > > ... > > 1-8 9-16 17-24 > > 25-32 33-40 41-48 > > 49-56 57-64 65-72 73-80 > > 81-88 89-96 97-104 105-112 > > 113-120 ... > > > > Regards, > > > > Maarten > > > > Internet-Drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > > Networks > > > Author(s) : E. Mannie, D. Papadimitriou > > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > > Pages : 13 > > > Date : 15-Nov-01 > > > > > > This document defines how GMPLS can be used to dynamically modify > > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > > will cover G.709 in a next version. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 07:54:04 -0800 Message-ID: <3BF53611.FC51AA30@alcatel.be> Date: Fri, 16 Nov 2001 16:51:45 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: ccamp Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------E954D652B41F85CC919FAF95" This is a multi-part message in MIME format. --------------E954D652B41F85CC919FAF95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, I think also that it is written at the beginning of the corresponding section: "This section is for further study but the principles could be based on the following ideas:" You wrote: "I am intriged by this statement, and hope you are able to explain how this would be realised in a real SDH/SONET equipment and network." I think this is one of the main purpose of this section open the discussion. So i really appreciate your collaboration to go further with this idea, let's discuss it and try to completely specify how such process can be achieve by limiting the disruption to the one achievable using other methods. Thanks, - dimitri. Maarten Vissers wrote: > > Eric, Dimitri, > > You write in your document > > " For instance, a received SDH STM-64 frame can contain a VC-4-4c, > while a next frame can contain a VC-4-16c starting at the same > place as the VC-4-4c and thus occupying the same first VC-4 > spaces. This process is not service impacting or disruptive. " > > I am intriged by this statement, and hope you are able to explain how this would > be realised in a real SDH/SONET equipment and network. > > To me this looks very service impacting and disruptive. > E.g. according to G.783, 75% of the VC-4-16c received will not be passed through > while a series of AU3dLOP, AU4dLOP and/or AU4-4cdLOP will be detected and AIS is > inserted. > > Only if you have a modified AU pointer processor which is adaptive to the > incoming signal structure you will not get any defects detected and AIS > inserted; i.e. you can do this only if you have set up an AUG-N/STSG-N > connection. In this AUG-N case you haven't specified the specific substructure, > and don't need to do this. This is controlled by the user equipment, which will > not be able to use the connection while e.g. circuit packs in the equipment are > changed, or switches are made and pointer processors are reprovisioned. > > Regards, > > Maarten --------------E954D652B41F85CC919FAF95 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------E954D652B41F85CC919FAF95-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 07:33:21 -0800 Message-ID: <3BF5317B.D3C51410@lucent.com> Date: Fri, 16 Nov 2001 16:32:11 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------D29264E29041FFCFD4F3F19A" This is a multi-part message in MIME format. --------------D29264E29041FFCFD4F3F19A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Dimitri, You write in your document " For instance, a received SDH STM-64 frame can contain a VC-4-4c, while a next frame can contain a VC-4-16c starting at the same place as the VC-4-4c and thus occupying the same first VC-4 spaces. This process is not service impacting or disruptive. " I am intriged by this statement, and hope you are able to explain how this would be realised in a real SDH/SONET equipment and network. To me this looks very service impacting and disruptive. E.g. according to G.783, 75% of the VC-4-16c received will not be passed through while a series of AU3dLOP, AU4dLOP and/or AU4-4cdLOP will be detected and AIS is inserted. Only if you have a modified AU pointer processor which is adaptive to the incoming signal structure you will not get any defects detected and AIS inserted; i.e. you can do this only if you have set up an AUG-N/STSG-N connection. In this AUG-N case you haven't specified the specific substructure, and don't need to do this. This is controlled by the user equipment, which will not be able to use the connection while e.g. circuit packs in the equipment are changed, or switches are made and pointer processors are reprovisioned. Regards, Maarten --------------D29264E29041FFCFD4F3F19A 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 --------------D29264E29041FFCFD4F3F19A-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 07:30:09 -0800 Message-ID: <3BF53093.F97B26E8@alcatel.be> Date: Fri, 16 Nov 2001 16:28:19 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Maarten Vissers CC: ccamp , q11/15 , "t1x1.5" Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------14015CC31DDC6D333B0FC149" This is a multi-part message in MIME format. --------------14015CC31DDC6D333B0FC149 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, I think you have reach the main comparison point for this discussion Let's start with this: - If you want to achieve hitles adaption you need a real-time protocol to synchronize both ends in some way (supporting the for instance LCAS) this is a synchronous approach - If you just want to add more capacity and you don't focus on a 'glitch' perhaps very few millisecs when putting the capacity in use you can do it in a non-real time manner like with GMPLS - this is an asynchronous approach The major difference between both procedures is that GMPLS gives an answer how to allocate capacity across the network while LCAS relies on the fact that it is already available i.e. "provisioned" (see LCAS specification) for use and just has to be 'lit'. Hope this will help the reader to undertstand that both methods have a specific applicability scope, the GMPLS one is more adapted for dynamic environments that do not use "provisioning" of the resources ... a real bandwidth on demand service. I think this is what we have addressed with this. And from what i understood this is what carriers are looking for (since the bandwdith service is non-disruptive - if it can accomodate a very few ms -, flexible and doesn't require any pre-provisioning). The second (LCAS) is adapted for services that could be sensitive, but the price to pay is to provision the "resources". This is a static approach of the problem. I think that both have a specific scope. Regards, - dimitri. Maarten Vissers wrote: > > Eric, Dimitri, > > I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so > I got the impression that you completely misunderstand the purpose of LCAS. LCAS > is NOT a signalling protocol. It is totally unrelated as such to control plane > based connection management (GMPLS, ASON) or network management based connection > management. > > LCAS doesn't change the number of VC-n or ODUk trails in the network. If N > trails are set up between the A-end and Z-end, LCAS helps to hitless change the > number of trails being used for the actual transport of the client signal; i.e. > if X (X number to X+1 or shrink it to X-1, then LCAS coordinates the steps at the A-end > and Z-end to make sure the increase/reduction is performed hitless. > > The steps to perform for the case X=N are: > A) X ==> X+1 > 1) [Operator or User] request connection management [NMS or ASON/GMPLS] > to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with > virtual concatenated endpoint at A-end and corresponding SNPP at Z-end > 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at > A-end and Z-end to control the "addition" of the (X+1)th trail to the > group of X trails ("Madd" command in G.7042) over which the client > bitstream is transported > 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this > to the receiver at the other end > 3) LCAS at A-end [Z-end] waits until connection is setup; the connection > in one direction is setup if the Trail Signal Fail (TSF) condition at > its end has cleared; > 4) LCAS communicates the TSF clearing to the other end ("MST=OK") > 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and > 6) at the start of the next VC-n/ODUk frame the client bitstream is > distributed over X+1 (instead of X) VC-n/ODUk trails > 7) the receiver at the other end notices the change of CTRL=ADD to > CTRL=EOS, and expects the client signal to be present on X+1 (instead > of X) VC-n/ODUk trails at the begin of the next frame. > > Example with X=3 > ================ > > The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over > trails #1..#3 as follows: > trail#1 trail#2 trail#3 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 > 73-80 ... > > When trail #4 is added, no client bits will be transported over it, until the > source has indicated this via the change of the control word CTRL=ADD => > CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits > ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at > the moment client bit 49 is to be transmitted, then trail#4 will be used for the > transport of bits 73-80 and further: > > trail#1 trail#2 trail#3 trail#4 > ... > 1-8 9-16 17-24 > 25-32 33-40 41-48 > 49-56 57-64 65-72 73-80 > 81-88 89-96 97-104 105-112 > 113-120 ... > > Regards, > > Maarten > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > > Networks > > Author(s) : E. Mannie, D. Papadimitriou > > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > > Pages : 13 > > Date : 15-Nov-01 > > > > This document defines how GMPLS can be used to dynamically modify > > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > > will cover G.709 in a next version. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> --------------14015CC31DDC6D333B0FC149 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------14015CC31DDC6D333B0FC149-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 07:14:29 -0800 Message-ID: <3BF52D35.AF7FBFDA@lucent.com> Date: Fri, 16 Nov 2001 16:13:57 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------D460EB5DBCFCAB36A06878A6" This is a multi-part message in MIME format. --------------D460EB5DBCFCAB36A06878A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Dimitri, Forgot to mention that this feature should work in switched as well as non-switched networks. The latter are of course making up 99.99999% of the networks. Regards, Maarten Maarten Vissers wrote: > > Eric, Dimitri, > > Your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt contribution states: > > " One drawback of LCAS is that it requires changing the transport > plane since new overhead bytes are used. In consequence, new ASICs > must be used at both termination ends. On the contrary, GMPLS LBM > is done purely in the control plane. It does not require any new > ASICs and is backward compatible with the existing hardware. " > > The objective of LCAS is to support a hitless (no single bit error in the client > signal) modification of the connection bandwidth over which the client signal is > transported. > > LCAS is the 3rd element in the package "virtual concatenation, GFP and LCAS", > and doesn't require new hardware which isn't already required to support virtual > concatenation and GFP. I.e. the new ASICs that will support virtual > concatenation and GFP will also support LCAS. > > To get the hitless behaviour that is required, you need a synchronisation > protocol build into the bit level transport. LCAS will do this. GMPLS or ASON > will never be able to do this. > > Regards, > > Maarten --------------D460EB5DBCFCAB36A06878A6 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 --------------D460EB5DBCFCAB36A06878A6-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 06:57:24 -0800 Message-ID: <3BF528DF.2F5A809@lucent.com> Date: Fri, 16 Nov 2001 15:55:27 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------E6E38F0071CB3490448C0769" This is a multi-part message in MIME format. --------------E6E38F0071CB3490448C0769 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Dimitri, Your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt contribution states: " One drawback of LCAS is that it requires changing the transport plane since new overhead bytes are used. In consequence, new ASICs must be used at both termination ends. On the contrary, GMPLS LBM is done purely in the control plane. It does not require any new ASICs and is backward compatible with the existing hardware. " The objective of LCAS is to support a hitless (no single bit error in the client signal) modification of the connection bandwidth over which the client signal is transported. LCAS is the 3rd element in the package "virtual concatenation, GFP and LCAS", and doesn't require new hardware which isn't already required to support virtual concatenation and GFP. I.e. the new ASICs that will support virtual concatenation and GFP will also support LCAS. To get the hitless behaviour that is required, you need a synchronisation protocol build into the bit level transport. LCAS will do this. GMPLS or ASON will never be able to do this. Regards, Maarten --------------E6E38F0071CB3490448C0769 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 --------------E6E38F0071CB3490448C0769-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 06:56:31 -0800 To: ccamp , q11/15 , "t1x1.5" Message-ID: <3BF5245C.66E38071@lucent.com> Date: Fri, 16 Nov 2001 15:36:12 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 Original-To: ccamp , q11/15 , "t1x1.5" Subject: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Content-Type: multipart/mixed; boundary="------------AE1169EAE876D7415994FFCF" This is a multi-part message in MIME format. --------------AE1169EAE876D7415994FFCF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric, Dimitri, I quickly scanned through your draft-mannie-ccamp-gmpls-lbm-tdm-00.txt. Doing so I got the impression that you completely misunderstand the purpose of LCAS. LCAS is NOT a signalling protocol. It is totally unrelated as such to control plane based connection management (GMPLS, ASON) or network management based connection management. LCAS doesn't change the number of VC-n or ODUk trails in the network. If N trails are set up between the A-end and Z-end, LCAS helps to hitless change the number of trails being used for the actual transport of the client signal; i.e. if X (X X+1 1) [Operator or User] request connection management [NMS or ASON/GMPLS] to setup additional VC-n/ODUk between SNP Pool (SNPP) associated with virtual concatenated endpoint at A-end and corresponding SNPP at Z-end 2) connection management [NMS or ASON/GMPLS] commands LCAS controllers at A-end and Z-end to control the "addition" of the (X+1)th trail to the group of X trails ("Madd" command in G.7042) over which the client bitstream is transported 3) LCAS at each end generates the ADD command (CTRL=ADD) and sends this to the receiver at the other end 3) LCAS at A-end [Z-end] waits until connection is setup; the connection in one direction is setup if the Trail Signal Fail (TSF) condition at its end has cleared; 4) LCAS communicates the TSF clearing to the other end ("MST=OK") 5) once MST=OK is received, LCAS replaces CTRL=ADD by CTRL=EOS, and 6) at the start of the next VC-n/ODUk frame the client bitstream is distributed over X+1 (instead of X) VC-n/ODUk trails 7) the receiver at the other end notices the change of CTRL=ADD to CTRL=EOS, and expects the client signal to be present on X+1 (instead of X) VC-n/ODUk trails at the begin of the next frame. Example with X=3 ================ The bits in a client bit stream with bits ...,1,2,3,4,... are distributed over trails #1..#3 as follows: trail#1 trail#2 trail#3 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 ... When trail #4 is added, no client bits will be transported over it, until the source has indicated this via the change of the control word CTRL=ADD => CTRL=EOS, and the new VC-n/ODUk frame begins. Assume that client bits ...,1,2,..,48 are transmitted in VC-n/ODUk frame "i", and frame "i+1" begins at the moment client bit 49 is to be transmitted, then trail#4 will be used for the transport of bits 73-80 and further: trail#1 trail#2 trail#3 trail#4 ... 1-8 9-16 17-24 25-32 33-40 41-48 49-56 57-64 65-72 73-80 81-88 89-96 97-104 105-112 113-120 ... Regards, Maarten Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : GMPLS LSP Bandwidth Modification (LBM) for TDM > Networks > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt > Pages : 13 > Date : 15-Nov-01 > > This document defines how GMPLS can be used to dynamically modify > the bandwidth of a TDM circuit. It focuses first on SONET/SDH and > will cover G.709 in a next version. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> --------------AE1169EAE876D7415994FFCF 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 --------------AE1169EAE876D7415994FFCF-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Nov 2001 04:00:06 -0800 Message-Id: <200111161156.GAA26608@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-mannie-ccamp-gmpls-lbm-tdm-00.txt Date: Fri, 16 Nov 2001 06:56:13 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GMPLS LSP Bandwidth Modification (LBM) for TDM Networks Author(s) : E. Mannie, D. Papadimitriou Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt Pages : 13 Date : 15-Nov-01 This document defines how GMPLS can be used to dynamically modify the bandwidth of a TDM circuit. It focuses first on SONET/SDH and will cover G.709 in a next version. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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-mannie-ccamp-gmpls-lbm-tdm-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: <20011115154112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mannie-ccamp-gmpls-lbm-tdm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011115154112.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 23:12:45 -0800 Message-ID: <3BF4BD0B.4C8156AC@npd.hcltech.com> Date: Fri, 16 Nov 2001 12:45:23 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: George Young CC: ccamp@ops.ietf.org Subject: Re: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Young, 1. Yeah events 1.evCCup and 2.evCCDown has to be added in the Data Link FSM's in the down state also. Agreed. 2. Transtition 10:evLnkDealloc can be possible know even in the degraded state. Yeah a control channel is needed, but this event can also be a external event know, from the user or a network management event. If this is possible then this event is required in this state. Kindly clarify me. 3. Also event 14.evdcDown can also possible in Test/Pasv Test state. Since to send a Test message or to receive a Test message we need a data channel. If you see both the FSM's ( Data link ) event 3 & 4 will pose the next state to Test & Pasv Test state from Up/Free state. So the event 14.evdcDown is also possible on both the states and hence the next state in both the case will be down. Thanks, Ramesh George Young wrote: > Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of > draft-ietf-ccamp-lmp-02.txt: > > 1) It appears that in the Down state, the control channel can be either > up or > down. That being the case, there should be transitions for events 1 > :evCCUp: > and 2 :evCCDown: from Down to Down. > > 2) Transition 10:evLnkDealloc: from Deg to Down would appear to be > impossible, > as there is no control channel available, and the control channel is > required to coordinate taking the channel down at both ends. I believe > this > transition should be removed. > > With these changes, the FSMs would look like: > > 12.3.3. Active Data Link FSM Description > > Figure 5 illustrates operation of the LMP active data link FSM in a > form of FSM state transition diagram. > > 1,2 > +------+ > | | > | +------+ > +-->| |<-------+ > +--------->| Down | | > | +----| |<-----+ | > | | +------+ | | > | |5b 3| ^ | | > | | | |2,7 | | > | | v | | | > | | +------+ | | > | | | |<-+ | | > | | | Test | |11 | | > | | | |--+ | | > | | +------+ | | > | | 5a| 3^ | | > | | | | | | > | | v | | | > |2,12 | +---------+ | | > | +-->| |14 | | > | | Up/Free |----+ | > +---------| | | > +---------+ | > 9| ^ | > | | | > v |10 | > +-----+ 2 +---------+ | > | |<--------| |13 | > | Deg | |Up/Alloc |------+ > | |-------->| | > +-----+ 1 +---------+ > > Figure 5: Active LMP Data Link FSM > > 12.3.4. Passive Data Link FSM Description > > Figure 6 illustrates operation of the LMP passive data link FSM in a > form of FSM state transition diagram. > > 1,2 > +------+ > | | > | +------+ > +-->| |<------+ > +---------->| Down | | > | +-----| |<----+ | > | | +------+ | | > | |5b 4| ^ | | > | | | |2,8 | | > | | v | | | > | | +----------+ | | > | | | PasvTest | | | > | | +----------+ | | > | | 6| 4^ | | > | | | | | | > | | v | | | > |2,12 | +---------+ | | > | +--->| Up/Free |14 | | > | | |---+ | > +----------| | | > +---------+ | > 9| ^ | > | | | > v |10 | > +-----+ +---------+ | > | | 2 | |13 | > | Deg |<--------|Up/Alloc |-----+ > | |-------->| | > +-----+ 1 +---------+ > > Figure 6: Passive LMP Data Link FSM > > Regards, > George R. Young > edgeflow Inc. > 329 March Rd., Kanata, ON, Canada, K2K 2E1 > phone: +1 613-270-9279 Ext 287 > fax: +1 613-270-9268 > > >-----Original Message----- > >From: Kireeti Kompella [mailto:kireeti@juniper.net] > >Sent: Monday, November 12, 2001 9:00 PM > >To: ccamp@ops.ietf.org > >Subject: Two week Last Call on LMP > > > > > >Hi All, > > > >This is to announce a two week Last Call on the LMP draft: > >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > > > >Please send questions, comments and requests for clarifications > >to the CCAMP list. > > > >Kireeti. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 21:48:29 -0800 Date: Thu, 15 Nov 2001 21:46:40 -0800 From: Alex Zinin Reply-To: Alex Zinin Organization: Nexsi Systems Message-ID: <151207071583.20011115214640@nexsi.com> To: Senthil Venkatachalam Cc: Kireeti Kompella , Vijay Gill , Sudheer Dharnikota , Papadimitriou Dimitri , Subject: Re: draft-venkatachalam-interarea-mpls-te-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Senthil, The IETF directory says it expired. Please resubmit or post a link to it. -- Alex Zinin Tuesday, November 13, 2001, 2:19:05 PM, Senthil Venkatachalam wrote: > Hi Kireeti, > We would like to request a slot to present our draft: > draft-venkatachalam-interarea-mpls-te-02.txt > at the Salt Lake City IETF. > Best Regards, > Senthil. > -- > Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com > Off#:, MBox: (703) 679-6435 [Off] > Alcatel USA (703) 679-6450 [Fax] > __________________________________________________________________ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 11:48:35 -0800 Message-ID: <87009604743AD411B1F600508BA0F95971BC17@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: "'ccamp@ops.ietf.org'" Subject: position of ADMIN_STATUS object in RESV message Date: Thu, 15 Nov 2001 14:46:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Section 10.1 of draft-ietf-mpls-generalized-rsvp-te-05.txt describes the admin_status as not being a part of the in the RESV message. This works fine for the FF style of reservation. But for the SE style of reservation if just one filter is taken out by setting the D bit in admin status, all others must go down because the admin_status applies for the entire RESV instead of just the particular filter in question. Or for that matter if only one filter's state(LSP) is taken administratively down( by setting A bit), it will now apply to all filters Is this intended? Or is it the optical world will never do SE style reservations? Am I missing something here? -Sayan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 10:39:31 -0800 Message-ID: <00df01c16e04$2ad15150$681810ac@movaz.com> From: "Adrian Farrel" To: Cc: "Tim Hall" , "Thomas D. Nadeau" , "Edward Harrison" , "Adrian Farrel" , "Cheenu Srinivasan" Subject: MIBs for GMPLS Date: Thu, 15 Nov 2001 13:34:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01C16DDA.41BFC6F0" This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01C16DDA.41BFC6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please be aware that we have published four MIBs related to monitoring = and managing GMPLS systems. These may be found at=20 http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-tc-mib-00= .txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-label-mib= -00.txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-te-mib-00= .txt http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-lsr-mib-0= 0.txt The TC MIB provides additional Textual Conventions to supplement those = in draft-ietf-mpls-tc-mib-02.txt The Label MIB is entirely new for GMPLS. The TE and LSR MIBs are based on draft-ietf-mpls-tc-mib-02.txt and = draft-ietf-mpls-lsr-mib-06.txt respectively. Material for the TE MIB = was drawn from = http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmpls-te-mib-00.= txt which should now be seen as obsolete. We have asked for a slot in the CCAMP WG agenda at the upcoming IETF to = present these to you. Owing to the short timescales there are a few blatant typos that didn't = get ironed out (most notably the Abstract in the LSR MIB). We would welcome all comments and input. Regards, Adrian -- Adrian Farrel Movaz Networks Inc. Tel: 703-847-1867 afarrel@movaz.com ------=_NextPart_000_00DC_01C16DDA.41BFC6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please be aware that we have = published four MIBs=20 related to monitoring and managing GMPLS systems.
 
These may be found at
 
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-tc-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccam= p-gmpls-label-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-te-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-= gmpls-lsr-mib-00.txt
 
 
The TC MIB provides additional = Textual=20 Conventions to supplement those in = draft-ietf-mpls-tc-mib-02.txt
 
The Label MIB is entirely new for=20 GMPLS.
 
The TE and LSR MIBs are based=20 on draft-ietf-mpls-tc-mib-02.txt and draft-ietf-mpls-lsr-mib-06.txt = respectively.  Material for the TE MIB was drawn from http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp= ls-te-mib-00.txt which should now be seen as = obsolete.
 
We have asked for a slot in the CCAMP = WG agenda=20 at the upcoming IETF to present these to you.
 
Owing to the short timescales there = are a few=20 blatant typos that didn't get ironed out (most notably the Abstract in = the LSR=20 MIB).
 
We would welcome all comments and=20 input.
 
Regards,
Adrian
--
Adrian Farrel
Movaz Networks = Inc.
Tel: 703-847-1867
afarrel@movaz.com
------=_NextPart_000_00DC_01C16DDA.41BFC6F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 05:09:14 -0800 Message-ID: <3BF3BEE5.15732E8D@npd.hcltech.com> Date: Thu, 15 Nov 2001 18:41:01 +0530 From: S Ramesh Organization: HCL Technologies Limited MIME-Version: 1.0 To: manoj juneja CC: ccamp@ops.ietf.org, greg@ciena.com, jplang@calient.net, braja@tellium.com, yakov@juniper.net, vsharma@ieee.org Subject: Re: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Manoj, In LMP ( section 14.9 ) the BEGIN_VERIFY class contains a wavelength field ( 32 bits ). This field is filled with a wavelength label for the TEST messages sent over the datalink. So this wavelength remains the label when a data link is assigned to a port or component link when it supports more than a wavelength. Kindly correct me if i am wrong. THanks Ramesh manoj juneja wrote: > Hi All, > In section 3.2.1.1 of draft-ietf-mpls-generalized-signaling > -06.txt, it is written that wavelength label indiacates the lambda from > the sender's perspective. Furthermore, These values may be configured or > dynamically determined using protocol such as LMP. > There is no procedure in LMP draft for wavelength exchange. It > exchanges just the interface Ids. Does this mean the wavelength label > carried in generalized label object will be interfaceId corresponding > to the wavelength and not the actual wavelength itself ? > > Please help. > > Regrads, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Nov 2001 00:19:46 -0800 Message-ID: From: Heiles Juergen To: "'Karmakar, Soumen'" , "'Maarten Vissers'" , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: STM-M out of STM-N (M -----Original Message----- > From: Karmakar, Soumen [mailto:soumen@trillium.com] > Sent: Wednesday, November 14, 2001 7:14 PM > To: 'Maarten Vissers'; manoj juneja > Cc: ccamp@ops.ietf.org > Subject: RE: STM-M out of STM-N (M > > Does this mean that the STM64 signal type (as requested in > sonet/sdh tSpec) > can be carried in the STM256 link type ? However this is possible by > carrying th VC-4-64c with transport overhead only , even > though the user > specifies just STM64 signal type ? > And the list of valid labels in this case should be > S = 1,65, 129, 193 and UKLM = 0,0,0 ? > Furthermore in the example that you showed below with the > following fields > as : > ST = 6 (VC4) , RCC =1, NCC =64, NVC =0, MT =1, T =0. > and why not > ST = 11 (STM64) , RCC=0, NCC=0, NVC=0, MT= 1, T = 6 or 7 (110 > or 111) ? > assuming full transparency support. > > Thanks, > Soumen > > > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: Wednesday, November 14, 2001 12:57 AM > > To: manoj juneja > > Cc: ccamp@ops.ietf.org > > Subject: Re: STM-M out of STM-N (M > > > > > Manoj, > > > > I do not know what a STM-64c is. Such signal name is not > > defined in SDH. > > Sometimes people use this to indice a (physical) STM-64 > > signal with a VC-4-64c > > inside. There is no naming yet around that I am aware of to indicate > > semi-transparent STM-N signal transport; for this email let > > me refer to it as > > STM-64st. > > > > When you need to transport a STM-64 signal in a > > semi-transparent manner via a > > STM-256, the content of the STM-64st is not-relevant; i.e. > > the user may change > > this content as (s)he likes. That's why the request is for > a STM-64st > > connection. > > > > Note that this semi-transparent STM-N transport is a > > work around in > > the absence of full transparency that is offered by WDM and OTN > > networks. SDH equipment that is capable to support this must > > configure its AU pointer processors into adaptive mode; > > i.e. these > > AU PPs must follow the incoming AU structure. In terms > > of GMPLS, the > > STM-Nst contains a AUG-N signal. > > > > If I assume maximum transparency to be requested, the > > following overhead needs > > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > > B1, B2, M0, M1. > > > > 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 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ST=11 | RCC=0 | NCC=0 > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | NVC=0 | Multiplier > (MT)=1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Transparency (T)= 1 1 1 1 1 1 1 1 0 > 1 1 1 0 0| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Concerning the label, there is essentially no definition of > > this in GMPLS > > SDH/SONET documents. We transport a STM-64st signal, not HOVC > > or LOVC signals > > for which the SUKLM label is specified. Nevertheless, I > > assume for this moment > > that the intention was to reuse the SUKLM label also here > > (Eric can we add this > > explicitly to > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > > case the AUG-64 within the STM-64st is transported in > > timeslot EDCBA=20000 in > > STM-256, this then results in S=65 and UKLM=0000: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | S=65 | U=0 | K=0 | > L=0 | M=0 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Regards, > > > > Maarten > > > > > > manoj juneja wrote: > > > > > > Hi Marteen, > > > Thank You for u prompt response. I have > > another doubt relate > > > to this one. If I want to allocate STM64c within STM-256, > > then what will be > > > the difference between the label value if I allocate > VC-4-64c within > > > STM-256. As per my understanding, the transparency should > > also be included > > > in STM64c request (generalized label request object) and > > label will be same. > > > > > > Please comment. > > > > > > Regards, > > > manoj. > > > > > > >From: Maarten Vissers > > > >To: manoj juneja > > > >CC: ccamp@ops.ietf.org > > > >Subject: Re: STM-M out of STM-N (M > > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > > > >Manoj, > > > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > > You can allocate > > > >VC-4-64c link connection within a HOVC link. The > > associated timeslot is an > > > >AU-4-64c, which is identified in EDCBA terminology with > > 10000, 20000, > > > >30000, or > > > >40000. If you look in my g707-gmpls-label-conversion > > document, you see that > > > > > > > >10000 maps on S U = 1 0 > > > >20000 maps on S U = 65 0 > > > >30000 maps on S U = 129 0 > > > >40000 maps on S U = 193 0 > > > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > > > >As it is a contiguous concatenated signal, there is just 1 label, > > > >identifying > > > >the first timeslot. Assume you want to pass the VC-4-64c > > via AU-4-64c > > > >20000, > > > >then the label looks like: > > > > > > > > 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 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | ST=6 | RCC=1 | NCC=64 > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | NVC=0 | Multiplier > > (MT)=1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Transparency (T)=0 > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > 0 1 2 > 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | S=65 | U=0 | K=0 | > > L=0 | M=0 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > >Regards, > > > > > > > >Maarten > > > > > > > >manoj juneja wrote: > > > > > > > > > > Hi All, > > > > > If I want to allocate STM-M from STM-N (M < N) > > then what will be > > > >the > > > > > label value in GMPLS ? I mean to say if I get a request > > to allocate > > > >STM-64 > > > > > from STM-256 link then what will be the label value > > (SUKLM) and how many > > > > > labels will be sent back in RESV message ? > > > > > > > > > > Please comment. > > > > > > > > > > Regards, > > > > > manoj > > > > > > > > > > > > _________________________________________________________________ > > > > > Get your FREE download of MSN Explorer at > > > >http://explorer.msn.com/intl.asp > > > ><< mvissers.vcf >> > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 18:01:52 -0800 Message-Id: <200111151835.KAA00942@mx1.ustc.edu.cn> Date: Thu, 15 Nov 2001 9:48:3 +0800 From: Wang Hui To: "ccamp@ops.ietf.org" Subject: Simulations & experimentations?? Organization: Infonet Lab, USTC Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Hello to all, I am new to this field. I found that there is a lot of standards created here. But is there any simulations or experimentations to verify the design? I searched the Internet but find little experimental verification of the fundamental concepts. I wonder if there is a prototype that is developed, highlighting the key design and implementation choices and experimentally investigating network performance. Best Wang Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 17:01:28 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: lberger@movaz.com, Eric.Mannie@ebone.com Bcc: Date: Wed, 14 Nov 2001 17:57:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, As per the GMPLS drafts, the IF_ID_RSVP_HOP object will determine on which incoming interface the label should be allocated. One LSC interface can support only 1 wavelength. It means that each LSC interface is assigned an interface Id (un-numbered case) and that interface Id will be carried in IF_ID_RSVP_HOP object. One FSC interface can carry multiple wavelengths at the same time but GMPLS signalling will be transparent to that. A fiberId will be allocated to each FSC interface and that fiberId will be passed as a label. The signalling entity in the system has nothing to worry about the individual wavelengths within the fiber. Is my understanding correct ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 12:46:21 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: greg@ciena.com, jplang@calient.net, braja@tellium.com, yakov@juniper.net, vsharma@ieee.org Bcc: Date: Wed, 14 Nov 2001 13:44:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In section 3.2.1.1 of draft-ietf-mpls-generalized-signaling -06.txt, it is written that wavelength label indiacates the lambda from the sender's perspective. Furthermore, These values may be configured or dynamically determined using protocol such as LMP. There is no procedure in LMP draft for wavelength exchange. It exchanges just the interface Ids. Does this mean the wavelength label carried in generalized label object will be interfaceId corresponding to the wavelength and not the actual wavelength itself ? Please help. Regrads, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 11:36:48 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4) Date: Wed, 14 Nov 2001 14:26:50 -0500 Message-ID: Thread-Topic: Two week Last Call on LMP Thread-Index: AcFr6gDJ6ko37281SiiCFzM617qWbABV9DTw From: "George Young" To: Looking at the Data Link FSMs in Sections 12.3.3 and 12.3.4 of draft-ietf-ccamp-lmp-02.txt: 1) It appears that in the Down state, the control channel can be either up or down. That being the case, there should be transitions for events 1 :evCCUp: and 2 :evCCDown: from Down to Down. 2) Transition 10:evLnkDealloc: from Deg to Down would appear to be impossible, as there is no control channel available, and the control channel is required to coordinate taking the channel down at both ends. I believe this transition should be removed. With these changes, the FSMs would look like: 12.3.3. Active Data Link FSM Description=20 =20 Figure 5 illustrates operation of the LMP active data link FSM in a=20 form of FSM state transition diagram.=20 1,2 +------+ | | | +------+=20 +-->| |<-------+=20 +--------->| Down | |=20 | +----| |<-----+ |=20 | | +------+ | |=20 | |5b 3| ^ | |=20 | | | |2,7 | |=20 | | v | | |=20 | | +------+ | |=20 | | | |<-+ | |=20 | | | Test | |11 | |=20 | | | |--+ | |=20 | | +------+ | |=20 | | 5a| 3^ | |=20 | | | | | |=20 | | v | | |=20 |2,12 | +---------+ | |=20 | +-->| |14 | |=20 | | Up/Free |----+ |=20 +---------| | |=20 +---------+ |=20 9| ^ |=20 | | |=20 v |10 |=20 +-----+ 2 +---------+ |=20 | |<--------| |13 |=20 | Deg | |Up/Alloc |------+=20 | |-------->| |=20 +-----+ 1 +---------+=20 =20 Figure 5: Active LMP Data Link FSM=20 12.3.4. Passive Data Link FSM Description=20 =20 Figure 6 illustrates operation of the LMP passive data link FSM in a=20 form of FSM state transition diagram.=20 =20 1,2 +------+ | | | +------+=20 +-->| |<------+=20 +---------->| Down | |=20 | +-----| |<----+ |=20 | | +------+ | |=20 | |5b 4| ^ | |=20 | | | |2,8 | |=20 | | v | | |=20 | | +----------+ | |=20 | | | PasvTest | | |=20 | | +----------+ | |=20 | | 6| 4^ | |=20 | | | | | | =20 | | v | | |=20 |2,12 | +---------+ | |=20 | +--->| Up/Free |14 | |=20 | | |---+ |=20 +----------| | |=20 +---------+ |=20 9| ^ |=20 | | |=20 v |10 |=20 +-----+ +---------+ |=20 | | 2 | |13 |=20 | Deg |<--------|Up/Alloc |-----+=20 | |-------->| |=20 +-----+ 1 +---------+=20 =20 Figure 6: Passive LMP Data Link FSM=20 Regards, George R. Young edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Monday, November 12, 2001 9:00 PM >To: ccamp@ops.ietf.org >Subject: Two week Last Call on LMP > > >Hi All, > >This is to announce a two week Last Call on the LMP draft: >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > >Please send questions, comments and requests for clarifications >to the CCAMP list. > >Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 11:05:53 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Fw: Fiber and wavelength labels Date: Wed, 14 Nov 2001 12:03:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In order to request a bi-directional SONET/SDH LSP, one need to include upstream label in the path message. Can I establish a uni -directional lambda or fiber LSP (i.e. with label as wavelength or label as fiber) i.e. sending out path message without including upstream label ? If a bi-directional lambda or fiber LSP be established, can it have different wavelengthId or FiberId in opposite directions as the label value ? Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 10:16:48 -0800 Message-ID: From: "Karmakar, Soumen" To: "'Maarten Vissers'" , manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: STM-M out of STM-N (M -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, November 14, 2001 12:57 AM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: STM-M out of STM-N (M > > Manoj, > > I do not know what a STM-64c is. Such signal name is not > defined in SDH. > Sometimes people use this to indice a (physical) STM-64 > signal with a VC-4-64c > inside. There is no naming yet around that I am aware of to indicate > semi-transparent STM-N signal transport; for this email let > me refer to it as > STM-64st. > > When you need to transport a STM-64 signal in a > semi-transparent manner via a > STM-256, the content of the STM-64st is not-relevant; i.e. > the user may change > this content as (s)he likes. That's why the request is for a STM-64st > connection. > > Note that this semi-transparent STM-N transport is a > work around in > the absence of full transparency that is offered by WDM and OTN > networks. SDH equipment that is capable to support this must > configure its AU pointer processors into adaptive mode; > i.e. these > AU PPs must follow the incoming AU structure. In terms > of GMPLS, the > STM-Nst contains a AUG-N signal. > > If I assume maximum transparency to be requested, the > following overhead needs > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > B1, B2, M0, M1. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ST=11 | RCC=0 | NCC=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NVC=0 | Multiplier (MT)=1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transparency (T)= 1 1 1 1 1 1 1 1 0 1 1 1 0 0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Concerning the label, there is essentially no definition of > this in GMPLS > SDH/SONET documents. We transport a STM-64st signal, not HOVC > or LOVC signals > for which the SUKLM label is specified. Nevertheless, I > assume for this moment > that the intention was to reuse the SUKLM label also here > (Eric can we add this > explicitly to > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > case the AUG-64 within the STM-64st is transported in > timeslot EDCBA=20000 in > STM-256, this then results in S=65 and UKLM=0000: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S=65 | U=0 | K=0 | L=0 | M=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Regards, > > Maarten > > > manoj juneja wrote: > > > > Hi Marteen, > > Thank You for u prompt response. I have > another doubt relate > > to this one. If I want to allocate STM64c within STM-256, > then what will be > > the difference between the label value if I allocate VC-4-64c within > > STM-256. As per my understanding, the transparency should > also be included > > in STM64c request (generalized label request object) and > label will be same. > > > > Please comment. > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: STM-M out of STM-N (M > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > >Manoj, > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > You can allocate > > >VC-4-64c link connection within a HOVC link. The > associated timeslot is an > > >AU-4-64c, which is identified in EDCBA terminology with > 10000, 20000, > > >30000, or > > >40000. If you look in my g707-gmpls-label-conversion > document, you see that > > > > > >10000 maps on S U = 1 0 > > >20000 maps on S U = 65 0 > > >30000 maps on S U = 129 0 > > >40000 maps on S U = 193 0 > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > >As it is a contiguous concatenated signal, there is just 1 label, > > >identifying > > >the first timeslot. Assume you want to pass the VC-4-64c > via AU-4-64c > > >20000, > > >then the label looks like: > > > > > > 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ST=6 | RCC=1 | NCC=64 > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | NVC=0 | Multiplier > (MT)=1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Transparency (T)=0 > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | S=65 | U=0 | K=0 | > L=0 | M=0 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > >Regards, > > > > > >Maarten > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I want to allocate STM-M from STM-N (M < N) > then what will be > > >the > > > > label value in GMPLS ? I mean to say if I get a request > to allocate > > >STM-64 > > > > from STM-256 link then what will be the label value > (SUKLM) and how many > > > > labels will be sent back in RESV message ? > > > > > > > > Please comment. > > > > > > > > Regards, > > > > manoj > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 01:28:51 -0800 Message-ID: From: Heiles Juergen To: manoj juneja Cc: ccamp@ops.ietf.org Subject: RE: STM-M out of STM-N (M -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, November 14, 2001 9:57 AM > To: manoj juneja > Cc: ccamp@ops.ietf.org > Subject: Re: STM-M out of STM-N (M > > Manoj, > > I do not know what a STM-64c is. Such signal name is not > defined in SDH. > Sometimes people use this to indice a (physical) STM-64 > signal with a VC-4-64c > inside. There is no naming yet around that I am aware of to indicate > semi-transparent STM-N signal transport; for this email let > me refer to it as > STM-64st. > > When you need to transport a STM-64 signal in a > semi-transparent manner via a > STM-256, the content of the STM-64st is not-relevant; i.e. > the user may change > this content as (s)he likes. That's why the request is for a STM-64st > connection. > > Note that this semi-transparent STM-N transport is a > work around in > the absence of full transparency that is offered by WDM and OTN > networks. SDH equipment that is capable to support this must > configure its AU pointer processors into adaptive mode; > i.e. these > AU PPs must follow the incoming AU structure. In terms > of GMPLS, the > STM-Nst contains a AUG-N signal. > > If I assume maximum transparency to be requested, the > following overhead needs > to be passed through: J0, RS DCC, MS DCC, K1/K2, E1, F1, E2, > B1, B2, M0, M1. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ST=11 | RCC=0 | NCC=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NVC=0 | Multiplier (MT)=1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transparency (T)= 1 1 1 1 1 1 1 1 0 1 1 1 0 0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Concerning the label, there is essentially no definition of > this in GMPLS > SDH/SONET documents. We transport a STM-64st signal, not HOVC > or LOVC signals > for which the SUKLM label is specified. Nevertheless, I > assume for this moment > that the intention was to reuse the SUKLM label also here > (Eric can we add this > explicitly to > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt?). So for the > case the AUG-64 within the STM-64st is transported in > timeslot EDCBA=20000 in > STM-256, this then results in S=65 and UKLM=0000: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S=65 | U=0 | K=0 | L=0 | M=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Regards, > > Maarten > > > manoj juneja wrote: > > > > Hi Marteen, > > Thank You for u prompt response. I have > another doubt relate > > to this one. If I want to allocate STM64c within STM-256, > then what will be > > the difference between the label value if I allocate VC-4-64c within > > STM-256. As per my understanding, the transparency should > also be included > > in STM64c request (generalized label request object) and > label will be same. > > > > Please comment. > > > > Regards, > > manoj. > > > > >From: Maarten Vissers > > >To: manoj juneja > > >CC: ccamp@ops.ietf.org > > >Subject: Re: STM-M out of STM-N (M > >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > > > >Manoj, > > > > > >In pure SDH, you can not allocate STM-64 within STM-256. > You can allocate > > >VC-4-64c link connection within a HOVC link. The > associated timeslot is an > > >AU-4-64c, which is identified in EDCBA terminology with > 10000, 20000, > > >30000, or > > >40000. If you look in my g707-gmpls-label-conversion > document, you see that > > > > > >10000 maps on S U = 1 0 > > >20000 maps on S U = 65 0 > > >30000 maps on S U = 129 0 > > >40000 maps on S U = 193 0 > > > > > >KLM in all cases is 000 (i.e. non relevant). > > > > > >As it is a contiguous concatenated signal, there is just 1 label, > > >identifying > > >the first timeslot. Assume you want to pass the VC-4-64c > via AU-4-64c > > >20000, > > >then the label looks like: > > > > > > 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | ST=6 | RCC=1 | NCC=64 > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | NVC=0 | Multiplier > (MT)=1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Transparency (T)=0 > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | S=65 | U=0 | K=0 | > L=0 | M=0 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > >Regards, > > > > > >Maarten > > > > > >manoj juneja wrote: > > > > > > > > Hi All, > > > > If I want to allocate STM-M from STM-N (M < N) > then what will be > > >the > > > > label value in GMPLS ? I mean to say if I get a request > to allocate > > >STM-64 > > > > from STM-256 link then what will be the label value > (SUKLM) and how many > > > > labels will be sent back in RESV message ? > > > > > > > > Please comment. > > > > > > > > Regards, > > > > manoj > > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > ><< mvissers.vcf >> > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Nov 2001 01:00:26 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3BF231EA.8846EB47@lucent.com> Date: Wed, 14 Nov 2001 09:57:14 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: STM-M out of STM-N (M > Hi Marteen, > Thank You for u prompt response. I have another doubt relate > to this one. If I want to allocate STM64c within STM-256, then what will be > the difference between the label value if I allocate VC-4-64c within > STM-256. As per my understanding, the transparency should also be included > in STM64c request (generalized label request object) and label will be same. > > Please comment. > > Regards, > manoj. > > >From: Maarten Vissers > >To: manoj juneja > >CC: ccamp@ops.ietf.org > >Subject: Re: STM-M out of STM-N (M >Date: Tue, 13 Nov 2001 09:55:03 +0100 > > > >Manoj, > > > >In pure SDH, you can not allocate STM-64 within STM-256. You can allocate > >VC-4-64c link connection within a HOVC link. The associated timeslot is an > >AU-4-64c, which is identified in EDCBA terminology with 10000, 20000, > >30000, or > >40000. If you look in my g707-gmpls-label-conversion document, you see that > > > >10000 maps on S U = 1 0 > >20000 maps on S U = 65 0 > >30000 maps on S U = 129 0 > >40000 maps on S U = 193 0 > > > >KLM in all cases is 000 (i.e. non relevant). > > > >As it is a contiguous concatenated signal, there is just 1 label, > >identifying > >the first timeslot. Assume you want to pass the VC-4-64c via AU-4-64c > >20000, > >then the label looks like: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ST=6 | RCC=1 | NCC=64 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | NVC=0 | Multiplier (MT)=1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Transparency (T)=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | S=65 | U=0 | K=0 | L=0 | M=0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Regards, > > > >Maarten > > > >manoj juneja wrote: > > > > > > Hi All, > > > If I want to allocate STM-M from STM-N (M < N) then what will be > >the > > > label value in GMPLS ? I mean to say if I get a request to allocate > >STM-64 > > > from STM-256 link then what will be the label value (SUKLM) and how many > > > labels will be sent back in RESV message ? > > > > > > Please comment. > > > > > > Regards, > > > manoj > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > ><< mvissers.vcf >> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------2324BD3F90388B4C7C498D7B 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 --------------2324BD3F90388B4C7C498D7B-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 22:02:16 -0800 Date: Tue, 13 Nov 2001 21:57:05 -0800 (PST) From: Kireeti Kompella Message-Id: <200111140557.VAA05873@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Two week Last Call on LMP Just so that everyone is on the same page, the LMP document is on the Proposed Standards track. Thanks to our vigilant ADs for keeping the record straight. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 13:39:13 -0800 Message-ID: <3BF19C59.134C6A93@alcatel.com> Date: Tue, 13 Nov 2001 17:19:05 -0500 From: Senthil Venkatachalam Organization: Alcatel MIME-Version: 1.0 To: Kireeti Kompella , Vijay Gill CC: Sudheer Dharnikota , Papadimitriou Dimitri , ccamp@ops.ietf.org Subject: draft-venkatachalam-interarea-mpls-te-02.txt Content-Type: multipart/alternative; boundary="------------3BCA18120FF83EFDDD37E9F0" --------------3BCA18120FF83EFDDD37E9F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kireeti, We would like to request a slot to present our draft: draft-venkatachalam-interarea-mpls-te-02.txt at the Salt Lake City IETF. Best Regards, Senthil. -- Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com Off#:, MBox: (703) 679-6435 [Off] Alcatel USA (703) 679-6450 [Fax] __________________________________________________________________ --------------3BCA18120FF83EFDDD37E9F0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kireeti,

We would like to request a slot to present our draft:
draft-venkatachalam-interarea-mpls-te-02.txt
at the Salt Lake City IETF.

Best Regards,
Senthil. 

-- 
Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________
  --------------3BCA18120FF83EFDDD37E9F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 13:18:36 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Two week Last Call on LMP (Section 6.4 & 6.5) Date: Tue, 13 Nov 2001 16:11:41 -0500 Message-ID: Thread-Topic: Two week Last Call on LMP Thread-Index: AcFr6gDJ6ko37281SiiCFzM617qWbAAnFhjw From: "George Young" To: Looking at draft-ietf-ccamp-lmp-02.txt: Sections 6.4 and 6.5 describe the Channel Status/Active (and Deactive) putting the corresponding channel into (or taking it out of) the 'Active' state. At the moment, there is no 'Active' state in the TE Link FSM, Section 12.3. Does going into the 'Active' state correspond to transition 9: evLnkAlloc and leaving the 'Active' state correspond to trasition 10: evLnkDealloc? Regards, George R. Young. edgeflow Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Monday, November 12, 2001 9:00 PM >To: ccamp@ops.ietf.org >Subject: Two week Last Call on LMP > > >Hi All, > >This is to announce a two week Last Call on the LMP draft: >draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. > >Please send questions, comments and requests for clarifications >to the CCAMP list. > >Kireeti. > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 12:02:13 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: Fiber and wavelength labels Date: Tue, 13 Nov 2001 12:52:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, In order to request a bi-directional SONET/SDH LSP, one need to include upstream label in the path message. Can I establish a uni -directional lambda or fiber LSP (i.e. with label as wavelength or label as fiber) i.e. sending out path message without including upstream label ? If a bi-directional lambda or fiber LSP be established, can it have different wavelengthId or FiberId in opposite directions as the label value ? 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, 13 Nov 2001 11:52:43 -0800 From: "manoj juneja" To: mvissers@lucent.com Cc: ccamp@ops.ietf.org Bcc: Subject: Re: STM-M out of STM-N (M Hi Marteen, Thank You for u prompt response. I have another doubt relate to this one. If I want to allocate STM64c within STM-256, then what will be the difference between the label value if I allocate VC-4-64c within STM-256. As per my understanding, the transparency should also be included in STM64c request (generalized label request object) and label will be same. Please comment. Regards, manoj. >From: Maarten Vissers >To: manoj juneja >CC: ccamp@ops.ietf.org >Subject: Re: STM-M out of STM-N (MDate: Tue, 13 Nov 2001 09:55:03 +0100 > >Manoj, > >In pure SDH, you can not allocate STM-64 within STM-256. You can allocate >VC-4-64c link connection within a HOVC link. The associated timeslot is an >AU-4-64c, which is identified in EDCBA terminology with 10000, 20000, >30000, or >40000. If you look in my g707-gmpls-label-conversion document, you see that > >10000 maps on S U = 1 0 >20000 maps on S U = 65 0 >30000 maps on S U = 129 0 >40000 maps on S U = 193 0 > >KLM in all cases is 000 (i.e. non relevant). > >As it is a contiguous concatenated signal, there is just 1 label, >identifying >the first timeslot. Assume you want to pass the VC-4-64c via AU-4-64c >20000, >then the label looks like: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ST=6 | RCC=1 | NCC=64 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | NVC=0 | Multiplier (MT)=1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transparency (T)=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | S=65 | U=0 | K=0 | L=0 | M=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Regards, > >Maarten > >manoj juneja wrote: > > > > Hi All, > > If I want to allocate STM-M from STM-N (M < N) then what will be >the > > label value in GMPLS ? I mean to say if I get a request to allocate >STM-64 > > from STM-256 link then what will be the label value (SUKLM) and how many > > labels will be sent back in RESV message ? > > > > Please comment. > > > > Regards, > > manoj > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp ><< mvissers.vcf >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 01:52:17 -0800 Date: Tue, 13 Nov 2001 01:49:29 -0800 (PST) From: Kireeti Kompella Message-Id: <200111130949.BAA00653@kummer.juniper.net> To: ccamp@ops.ietf.org, mvissers@lucent.com Subject: Re: OLI/LMP-WDM/NTIP => next step in ITU-T SG15 Hi Maarten, Thanks for the update. > I will try to reach a conclusion on this VBI topic in ITU-T SG15 by the > end of this month, to support further decision making on the related > OLI/LMP-WDM topic in IETF/CCAMP in the IETF52 meeting in December. That would be very much appreciated! Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 01:34:05 -0800 Cc: q19/15 Message-ID: <3BF0E8B3.AACD78A6@lucent.com> Date: Tue, 13 Nov 2001 10:32:35 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp , "t1x1.5" Original-CC: q19/15 Subject: Re: OLI/LMP-WDM/NTIP => next step in ITU-T SG15 Content-Type: multipart/mixed; boundary="------------E8221C9D9F8D713C85D940AF" This is a multi-part message in MIME format. --------------E8221C9D9F8D713C85D940AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit TO: CCAMP, T1X1.5 CC: Q.19/15 Here is a first feedback related to the introduction of the Virtual Backplane Interface (VBI) issue in ITU-T SG15. I have introduced the series of 4 VBI contributions during the SG15 meeting in October. As a result of the introduction and associated off-line discussions, I created a proposed work programme which you find in the forwarded VBI email below. It was agreed to continue the discussion on the work programme for the VBI topic on the Q.19/15 mailing list. I initiated this discussion on Oct. 25 via the email you find below. So far, none of the organisations in ITU-T SG15 has responded on the email. This may imply that there is no need/support for standardisation of such VBI; the VBI might be viewed as an internal equipment interface (of which standardisation is outside the scope of ITU-T). I will try to reach a conclusion on this VBI topic in ITU-T SG15 by the end of this month, to support further decision making on the related OLI/LMP-WDM topic in IETF/CCAMP in the IETF52 meeting in December. Regards, Maarten =============== begin of forwarded VBI email ====================== -------- Original Message -------- Subject: work programme for VBI (virtual backplane interface) Date: Thu, 25 Oct 2001 00:41:02 +0200 From: Maarten Vissers Reply-To: Maarten Vissers Organization: Lucent Technologies To: q19/15 To: Q.9/15, Q.11/15, Q.13/15, Q.14/15, Q.16/15, Q.17/15 and Q.19/15 ---------------------------------------------------------------- |Please reply to this email via Q.19/15 email mailing list only| ---------------------------------------------------------------- Introduction ============ Last week I introduced contributions D.301, D.302, D.303 and D.304 to Q.9/15, Q.11/15, Q.12/15 and Q.14/15. http://www.itu.int/itudocr/itu-t/com15/dcontr/01-04/dc-oct01/301_ww2.doc http://www.itu.int/itudocr/itu-t/com15/dcontr/01-04/dc-oct01/302_ww2.doc http://www.itu.int/itudocr/itu-t/com15/dcontr/01-04/dc-oct01/303_ww2.doc http://www.itu.int/itudocr/itu-t/com15/dcontr/01-04/dc-oct01/304_ww2.doc These contributions introduce a new interface, referred to as "Virtual Backplane Interface". They are the result of a new equipment paradigm as described in D.302. This VBI is the interface between the tributary port of an OLS (optical line system) and the port on an optical fabric equipment (photonic cross connect). This interface consists of a number of optical interfaces carrying traffic signals (e.g. wavelengths) and a supervisory interface (called: VBI funiculus). These contributions describe the architectural aspects, the applications, the physical aspects and performance aspects associated with this VBI. They propose to start a new work item in SG15 to define this VBI. Associated work =============== Having had a further look into the work to be done, it seems that the following questions will be involved in a development of a VBI specification: Q.9/15, Q.11/15, Q.13/15, Q.14/15, Q.16/15, Q.17/15 and Q.19/15. And we should not forget the network management aspects, which implies that one or more questions in SG4 will most likely be involved (to be identified). A first break down of work is presented below: Q.9/15 equipment model/specification (specify atomic functions), definition of SDH/OTN ports, port management parameter lists Q.11/15 interface specification, including definition of primitives to pass over VBI funiculus to support the identified applications (input from Q.9/15) Q.13/15 jitter/wander aspects for VBI data interfaces Q.14/15 VBI funiculus protocol aspects, including the coding of primitives into actual protocol messages; also associated equipment management functionality Q.16/15 specification of "connection characteristics" of the combination of "fiber - optical fabric - fiber connection" to support all optical signals to be cross connected/switched Note: the specification for the case of 3R points being present in the OLS tributary ports is already present in G.693 Q.17/15 characterisation of optical switch components to support Q.16/15 work; e.g. cross talk in optical switch Q.19/15 create, coordinate and track VBI work programme, coordination with IETF and OIF groups working in same area in addition SG4 will have to have a closer look into the network management aspects of these multi-vendor subnetworks and multi-vendor optical cross connects. Timeline ======== While OLS equipment is already in the networks and PXC equipment is being added, there is an urgency to start and progress this new VBI development. I foresee a series of VBI recommendations (G.vbi.1, G.vbi.2, ...) to be created to support this work. The work should initially be done via correspondence aiming at major decisions to be made in the April/May 2002 SG15 meeting such that vendors can start implementing this VBI on their products. Approval of the VBI recommendations should be targeted for the Jan/Feb. 2003 SG15 meeting. Supporters ========== It hasn't become clear how many (operator, vendor) organisations are supporting this new equipment paradigm. So far I have heard the following: A) support new equipment paradigm: will obtain WDM line ports (i.e. OLS) and optical fabric equipment (PXC) from multiple vendors and integrate those line ports and fabric myself. B) do not support new equipment paradigm: will obtain WDM line ports and optical fabric from one vendor (vendor may OEM WDM line ports and/or optical fabric from third parties and integrate those). C) if VBI comes alive, we may extend it to SDH in order to resolve the MS SPring interworking issue when the ring contains DXCs and ADMs of multiple vendors. D) have to work the VBI issue under all conditions; either as proprietary backplane interface, or as standardised virtual backplane interface. E) we haven't been able to manage equipment of different vendors within one subnetwork so far, now we should be able to manage line ports and fabrics from different vendors... To get an understanding of the level of support, I would like to invite you to indicate if your organisation intents to support the new equipment paradigm and supports the proposed new VBI work. In case of sufficient support, the work programme details can then be discussed. Regards, Maarten PS. In order to prevent this VBI work programme discussion to flood our email boxes, it is proposed to only use the Q.19/15 mailing list. For that reason I have used "Bcc:" to send this email to Q.9, Q.11, Q.13, Q.14, Q.16 and Q.17 mailing lists, expecting that a reply all will only go to Q.19/15. If you are not yet subscribed and would like to participate in the discussion of this work programme please subscribe via the EDH mailing list page: http://www.itu.int/ITU-T/studygroups/com15/edh/subscribe.html The email list archive for Q.19/15 can be found at: http://ties.itu.int/listarchives/tsg15q19/ ==================== end of forwarded VBI email ====================== Maarten Vissers wrote: > > All, > > I am pleased to announce the availability of 4 contributions for the upcoming > SG15 meeting addressing the rationale/architecture, applications, physical and > performance aspects of the interface between an OLS and an PXC. > > These contributions resulted from interaction with key players(*) in the IETF > ccamp WG concerning the OLI, LMP-WDM and NTIP activities. > > (*) Osama Aboul-Magd, Curtis Brownmiller, John Drake, Andre Fredette > and Jonathan Lang > > You will find the contributions (in word97 and pdf formats) in > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q11/0110 > > This interface is referred to by many names so far: LMP-WDM, OLI, NTIP, OTM-LF. > In the contributions, it is referred to as Virtual Backplane Interface (VBI), > but a better name is urgently needed... > > This interface is a true transport plane interface and once standardized by > ITU-T SG15 it should be usable for the purposes needed by ITU-T/T1, IETF ccamp > WG and OIF. > > Please review the contributions and provide comment either during the upcoming > SG15 meeting in Geneva (Oct. 15-26) or via correspondence. These contributions > are intended to provide a framework for the new interface specification. The > specification work itself is obviously the next step and a united ITU-T/T1/IETF > CCAMP/OIF effort to progress this specification would be an excellent way > forward. > > Regards, > > Maarten --------------E8221C9D9F8D713C85D940AF 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 --------------E8221C9D9F8D713C85D940AF-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Nov 2001 00:59:31 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3BF0DFE7.9F102300@lucent.com> Date: Tue, 13 Nov 2001 09:55:03 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: STM-M out of STM-N (M > Hi All, > If I want to allocate STM-M from STM-N (M < N) then what will be the > label value in GMPLS ? I mean to say if I get a request to allocate STM-64 > from STM-256 link then what will be the label value (SUKLM) and how many > labels will be sent back in RESV message ? > > Please comment. > > Regards, > manoj > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------1DE3BCF70DFC2144AF4C28CC 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 --------------1DE3BCF70DFC2144AF4C28CC-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Nov 2001 18:05:07 -0800 Date: Mon, 12 Nov 2001 17:59:33 -0800 (PST) From: Kireeti Kompella Message-Id: <200111130159.RAA29160@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: Two week Last Call on LMP Hi All, This is to announce a two week Last Call on the LMP draft: draft-ietf-ccamp-lmp-02.txt. This Last Call ends COB Wed Nov 28. Please send questions, comments and requests for clarifications to the CCAMP list. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Nov 2001 15:19:19 -0800 Date: Fri, 9 Nov 2001 15:13:45 -0800 (PST) From: Kireeti Kompella Message-Id: <200111092313.PAA17464@kummer.juniper.net> To: ccamp@ops.ietf.org Subject: ITU-T Study Group 15 - Access to files from Communication Statements Cc: sjtrowbridge@lucent.com, sob@harvard.edu Hi All, IETF'ers now have access to the ITU-T Study Group 15's communication statements to the IETF; the following email has the details. Please note that these documents are copyrighted by the ITU; please respect their copyrights, and use appropriate care in duplicating and distributing these materials. ITU Copyright Information: "Access to databases of the International Telecommunication Union (ITU) for consultation of documents and/or information retrieval is permitted by the ITU subject to the user's acceptance of ITU's provisions and conditions of copyright contained within each document which obliges the user not to duplicate the document or parts thereof for distribution or sale external to the user's organization. Such information may be utilised in the receiving organization, as required, to further the work of the ITU or any standards body developing related standards, to provide guidance for product or service development and implementation and to serve as support documentation associated with a product or service." Many thanks to Steven Trowbridge and others who made access possible. Also please note http://www.ietf.org/IESG/liaison.html which has the IETF liaison statements with other standards bodies, among them the ITU-T. Kireeti. -------------- Forwarded Mail ---------------- Scott, Kireeti, and Lyndon, I am pleased to inform you that we finally have some concensus within ITU-T that gives us a way to share the files related to the Study Group 15 communications statements with IETF participants. This mechanism will likely evolve in the future (more about this below), but at least for now we have a way to share these files with IETF participants. The relevant communications include two to ccamp: - SDH Signal and Group Structures - New Recommendations for Automatically Switched Optical Netorks and one to sigtran: - Draft Recommendation G.799.1 on interconnecting GSTN and IP Networks The information may be accessed via a web browser using the following URL (from an ITU-T ftp server): ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html In the future, the Telecommunications Standardization Bureau will likely provide a way for IETF participants who wish to collaborate with ITU-T to request their own logins and passwords to access this site, but for now, all can access the information using the common ID and password that you see embedded in the URL. The structure of the information is as follows: Main Page | |-->ccamp-->copyright---->Communication on SDH Signal Structures | | | -->Communication on ASON Recs | | | |-->G.8080_Y.1304.pdf | |-->G.7713_Y.1704.pdf | |-->G.7714_Y.1705.pdf | --->G.7712_Y.1703.pdf | --->sigtran-->copyright-->Communication on G.799.1 (GSTN and IP) | --->G.799-1-DRAFT-V6.pdf Please request that your members enter at the main page - this will help insure that those who access the documents will be aware of the ITU-T copyright restrictions. (rest clipped) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Nov 2001 11:36:29 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com Bcc: Subject: STM-M out of STM-N (M Hi All, If I want to allocate STM-M from STM-N (M < N) then what will be the label value in GMPLS ? I mean to say if I get a request to allocate STM-64 from STM-256 link then what will be the label value (SUKLM) and how many labels will be sent back in RESV message ? Please comment. 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, 09 Nov 2001 04:25:08 -0800 Cc: jscott@calient.net, ccamp@ops.ietf.org, Eric.Mannie@ebone.com Message-ID: <3BEBCAD3.1812C8DC@lucent.com> Date: Fri, 09 Nov 2001 13:23:47 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: jscott@calient.net, ccamp@ops.ietf.org, Eric.Mannie@ebone.com Subject: Re: SDH/SONET in GMPLS Content-Type: multipart/mixed; boundary="------------A55985D68860D96885B475A6" This is a multi-part message in MIME format. --------------A55985D68860D96885B475A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, manoj juneja wrote: > > Hi James, > > My question was little bit different. Let me re-pharse the question. > In SONET, each VTG of STS-1 can have VTs of different size (i.e 1 VTG > can contain 1 VT-6, other VTG within the same STS-1 can contain 2 VT-3 > etc). As VTG in SONET is equivalent to TUG-2 in SDH. Does this mean > that each TUG-2 within STM-1 can contain different type of VC-X (X=2, > 12, 11) i.e. one TUG-2 can contain 3 VC-12 and other TUG-2 within same > STM-1 can contain 1 VC-2 ? First of all a TUG-2 is defined within the payload of a VC-4 or VC-3; not within a STM-1. Each TUG-2 is treated independent of any other TUG-2. Please read G.707. > > Furthermore, As per draft-mannie-mpls-sdh-ospf-isis-01.txt, It is > assumed that every STM-1/STS-1 of STM-N/STS-M, M, N > 1 will have the > same multiplexing capability. This type of restriction is not as per > SDH/SONEYT. Does this mean this restriction has been kept for making > the routing protocol simple ? Also here please use correct language... STM-N doesn't consist of N STM-1 signals. STM-N consists of STM-N SOH (RSOH + MSOH) and AUG-N. AUG-N contains either an AU-4-Nc or 4 AUG-N/4, etc. An AU tributary/time slot carries a HOVC signal (HOVC: VC-3, VC-4, VC-4-Xc (X=4,16,64,256)). Every signal is independent of the other signals. GMPLS doesn't add a restriction to this... it allows even more variation if you look in the extension document. Regards, Maarten > > Regards, > manoj. > > >From: James Scott > >To: "'ccamp@ops.ietf.org'" > >Subject: RE: SDH/SONET in GMPLS > >Date: Thu, 8 Nov 2001 17:30:11 -0800 > > > >hi manoj, > > > >mj> As per SONET standard, each STS-1 SPE > >mj> is divided into 7 VT-groups. Each VT > >mj> group may contain 4 VT1.5, 3 VT-2s, > >mj> 2 VT-3s or 1 VT-6. Furthermore, each > >mj> VT-group shall contain one size of VT. > >mj> however, each VT-group within STS-1 may > >mj> be of different VT-size. Does this type > >mj> of statement holds true for SDH also ? > > > >yes. i don't recall that SDH spells out the > >rules on trib mixing explicitly as SONET does. > >however, the intent of the rules should be > >applicable to either protocol. that being, > >to eliminate the possibility of inefficient > >usage of the columns within the trib group > >due to mismatched trib types being applied. > > > >mj> Is GMPLS supports this or it has some > >mj> restrictions for these configurations? > > > >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > >defines labels with VT/TU granularity as > >well as mappings/encodings for both > >contiguous and arbitrary concatenation. > >this should supply vendors with an adequate > >supply of rope. > > > >hope this helps. > > > >cheers, > > > >james > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------A55985D68860D96885B475A6 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 --------------A55985D68860D96885B475A6-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Nov 2001 04:16:03 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3BEBC879.70AE5FA4@lucent.com> Date: Fri, 09 Nov 2001 13:13:45 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: manoj juneja Original-CC: ccamp@ops.ietf.org Subject: Re: SDH/SONET in GMPLS Content-Type: multipart/mixed; boundary="------------8FA680A797ED4D228CE572C8" This is a multi-part message in MIME format. --------------8FA680A797ED4D228CE572C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manoj, It seems time for you to get a copy of G.707 :-). You find all details in there. You can download 3 recommendations for free from the ITU-T website. See http://www.itu.int/publications/bookshop/how-to-buy.html#free Regards, Maarten manoj juneja wrote: > > Hi All, > As per SONET standard, each STS-1 SPE is divided into 7 VT > -groups. Each VT group may contain 4 VT1.5, 3 VT-2s, 2 VT-3s or 1 VT-6. > Furthermore, each VT-group shall contain one size of VT. however, each > VT-group within STS-1 may be of different VT-size. Does this type of > statement holds true for SDH also ? I mean to say that STM-1 may > contain 21 TUG-2s. Is it true that each TUG-2 within STM-1 can be configured > differently to conatin VC-2/VC-12/VC-11 within it but each TUG-2 contains > same type of VC-X (X=2, 12, 11). > > Is GMPLS supports this or it has some restrictions for these configurations > ? > > Please help. > > Regards, > manoj. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------8FA680A797ED4D228CE572C8 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 --------------8FA680A797ED4D228CE572C8-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Nov 2001 03:08:52 -0800 Message-ID: <3BEBB78E.69144AA8@lucent.com> Date: Fri, 09 Nov 2001 12:01:34 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: "'ccamp@ops.ietf.org'" Subject: Re: SDH/SONET label Content-Type: multipart/mixed; boundary="------------CC45DDEC99D181183FBF6CEF" This is a multi-part message in MIME format. --------------CC45DDEC99D181183FBF6CEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI. Attached an update of the G.707 EDCBA - GMPLS SU label mapping description, now extended with G.707 KLM - GMPLS KLM label mapping and some examples of VC-4/STS-3c and VC-4-4c/STS-12c timeslot allocation versus SU number. Regards, Maarten --------------CC45DDEC99D181183FBF6CEF Content-Type: text/plain; charset=us-ascii; name="g707-gmpls-label-conversion.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="g707-gmpls-label-conversion.txt" Sample conversion table The following table provides the explicit mapping between the SU and the EDCBA numbering scheme: Conversion table (E,D,C,B,A) (ITU-T G.707) to SU (GMPLS): G.707 EDCBA S U Tributary Slot Type ========================================= 00000 1 0 AU-4-256c/STS-768c in STM-256/OC-768 10000 1 0 AU-4-64c/STS-192c in STM-256/OC-768 20000 65 0 AU-4-64c/STS-192c in STM-256/OC-768 30000 129 0 AU-4-64c/STS-192c in STM-256/OC-768 40000 193 0 AU-4-64c/STS-192c in STM-256/OC-768 11000 1 0 AU-4-16c/STS-48c in STM-256/OC-768 12000 17 0 AU-4-16c/STS-48c in STM-256/OC-768 13000 33 0 AU-4-16c/STS-48c in STM-256/OC-768 14000 49 0 AU-4-16c/STS-48c in STM-256/OC-768 21000 65 0 AU-4-16c/STS-48c in STM-256/OC-768 22000 81 0 AU-4-16c/STS-48c in STM-256/OC-768 23000 97 0 AU-4-16c/STS-48c in STM-256/OC-768 24000 113 0 AU-4-16c/STS-48c in STM-256/OC-768 31000 129 0 AU-4-16c/STS-48c in STM-256/OC-768 32000 145 0 AU-4-16c/STS-48c in STM-256/OC-768 33000 161 0 AU-4-16c/STS-48c in STM-256/OC-768 34000 177 0 AU-4-16c/STS-48c in STM-256/OC-768 41000 193 0 AU-4-16c/STS-48c in STM-256/OC-768 42000 209 0 AU-4-16c/STS-48c in STM-256/OC-768 43000 225 0 AU-4-16c/STS-48c in STM-256/OC-768 44000 241 0 AU-4-16c/STS-48c in STM-256/OC-768 11100 1 0 AU-4-4c/STS-12c in STM-256/OC-768 11200 5 0 AU-4-4c/STS-12c in STM-256/OC-768 11300 9 0 AU-4-4c/STS-12c in STM-256/OC-768 11400 13 0 AU-4-4c/STS-12c in STM-256/OC-768 12100 17 0 AU-4-4c/STS-12c in STM-256/OC-768 12200 21 0 AU-4-4c/STS-12c in STM-256/OC-768 12300 25 0 AU-4-4c/STS-12c in STM-256/OC-768 12400 29 0 AU-4-4c/STS-12c in STM-256/OC-768 13100 33 0 AU-4-4c/STS-12c in STM-256/OC-768 13200 37 0 AU-4-4c/STS-12c in STM-256/OC-768 13300 41 0 AU-4-4c/STS-12c in STM-256/OC-768 13400 45 0 AU-4-4c/STS-12c in STM-256/OC-768 14100 49 0 AU-4-4c/STS-12c in STM-256/OC-768 14200 53 0 AU-4-4c/STS-12c in STM-256/OC-768 14300 57 0 AU-4-4c/STS-12c in STM-256/OC-768 14400 61 0 AU-4-4c/STS-12c in STM-256/OC-768 21100 65 0 AU-4-4c/STS-12c in STM-256/OC-768 21200 69 0 AU-4-4c/STS-12c in STM-256/OC-768 21300 73 0 AU-4-4c/STS-12c in STM-256/OC-768 21400 77 0 AU-4-4c/STS-12c in STM-256/OC-768 22100 81 0 AU-4-4c/STS-12c in STM-256/OC-768 22200 85 0 AU-4-4c/STS-12c in STM-256/OC-768 22300 89 0 AU-4-4c/STS-12c in STM-256/OC-768 22400 93 0 AU-4-4c/STS-12c in STM-256/OC-768 23100 97 0 AU-4-4c/STS-12c in STM-256/OC-768 23200 101 0 AU-4-4c/STS-12c in STM-256/OC-768 23300 105 0 AU-4-4c/STS-12c in STM-256/OC-768 23400 109 0 AU-4-4c/STS-12c in STM-256/OC-768 24100 113 0 AU-4-4c/STS-12c in STM-256/OC-768 24200 117 0 AU-4-4c/STS-12c in STM-256/OC-768 24300 121 0 AU-4-4c/STS-12c in STM-256/OC-768 24400 125 0 AU-4-4c/STS-12c in STM-256/OC-768 31100 129 0 AU-4-4c/STS-12c in STM-256/OC-768 31200 133 0 AU-4-4c/STS-12c in STM-256/OC-768 31300 137 0 AU-4-4c/STS-12c in STM-256/OC-768 31400 141 0 AU-4-4c/STS-12c in STM-256/OC-768 32100 145 0 AU-4-4c/STS-12c in STM-256/OC-768 32200 149 0 AU-4-4c/STS-12c in STM-256/OC-768 32300 153 0 AU-4-4c/STS-12c in STM-256/OC-768 32400 157 0 AU-4-4c/STS-12c in STM-256/OC-768 33100 161 0 AU-4-4c/STS-12c in STM-256/OC-768 33200 165 0 AU-4-4c/STS-12c in STM-256/OC-768 33300 169 0 AU-4-4c/STS-12c in STM-256/OC-768 33400 173 0 AU-4-4c/STS-12c in STM-256/OC-768 34100 177 0 AU-4-4c/STS-12c in STM-256/OC-768 34200 181 0 AU-4-4c/STS-12c in STM-256/OC-768 34300 185 0 AU-4-4c/STS-12c in STM-256/OC-768 34400 189 0 AU-4-4c/STS-12c in STM-256/OC-768 41100 193 0 AU-4-4c/STS-12c in STM-256/OC-768 41200 197 0 AU-4-4c/STS-12c in STM-256/OC-768 41300 201 0 AU-4-4c/STS-12c in STM-256/OC-768 41400 205 0 AU-4-4c/STS-12c in STM-256/OC-768 42100 209 0 AU-4-4c/STS-12c in STM-256/OC-768 42200 213 0 AU-4-4c/STS-12c in STM-256/OC-768 42300 217 0 AU-4-4c/STS-12c in STM-256/OC-768 42400 221 0 AU-4-4c/STS-12c in STM-256/OC-768 43100 225 0 AU-4-4c/STS-12c in STM-256/OC-768 43200 229 0 AU-4-4c/STS-12c in STM-256/OC-768 43300 233 0 AU-4-4c/STS-12c in STM-256/OC-768 43400 237 0 AU-4-4c/STS-12c in STM-256/OC-768 44100 241 0 AU-4-4c/STS-12c in STM-256/OC-768 44200 245 0 AU-4-4c/STS-12c in STM-256/OC-768 44300 249 0 AU-4-4c/STS-12c in STM-256/OC-768 44400 253 0 AU-4-4c/STS-12c in STM-256/OC-768 11110 1 1 AU-4/STS-3c in STM-256/OC-768 11120 2 1 AU-4/STS-3c in STM-256/OC-768 11130 3 1 AU-4/STS-3c in STM-256/OC-768 11140 4 1 AU-4/STS-3c in STM-256/OC-768 11210 5 1 AU-4/STS-3c in STM-256/OC-768 11220 6 1 AU-4/STS-3c in STM-256/OC-768 11220 7 1 AU-4/STS-3c in STM-256/OC-768 11220 8 1 AU-4/STS-3c in STM-256/OC-768 11310 9 1 AU-4/STS-3c in STM-256/OC-768 : 11410 13 1 AU-4/STS-3c in STM-256/OC-768 : 12110 17 1 AU-4/STS-3c in STM-256/OC-768 : 12210 21 1 AU-4/STS-3c in STM-256/OC-768 : 12310 25 1 AU-4/STS-3c in STM-256/OC-768 : 12410 29 1 AU-4/STS-3c in STM-256/OC-768 : 13110 33 1 AU-4/STS-3c in STM-256/OC-768 : 13210 37 1 AU-4/STS-3c in STM-256/OC-768 : 13310 41 1 AU-4/STS-3c in STM-256/OC-768 : 13410 45 1 AU-4/STS-3c in STM-256/OC-768 : 14110 49 1 AU-4/STS-3c in STM-256/OC-768 : 14210 53 1 AU-4/STS-3c in STM-256/OC-768 : 14310 57 1 AU-4/STS-3c in STM-256/OC-768 : 14410 61 1 AU-4/STS-3c in STM-256/OC-768 : 21110 65 1 AU-4/STS-3c in STM-256/OC-768 : 21210 69 1 AU-4/STS-3c in STM-256/OC-768 : 21310 73 1 AU-4/STS-3c in STM-256/OC-768 : 21410 77 1 AU-4/STS-3c in STM-256/OC-768 : 22110 81 1 AU-4/STS-3c in STM-256/OC-768 : 22210 85 1 AU-4/STS-3c in STM-256/OC-768 : 22310 89 1 AU-4/STS-3c in STM-256/OC-768 : 22410 93 1 AU-4/STS-3c in STM-256/OC-768 : 23110 97 1 AU-4/STS-3c in STM-256/OC-768 : 23210 101 1 AU-4/STS-3c in STM-256/OC-768 : 23310 105 1 AU-4/STS-3c in STM-256/OC-768 : 23410 109 1 AU-4/STS-3c in STM-256/OC-768 : 24110 113 1 AU-4/STS-3c in STM-256/OC-768 : 24210 117 1 AU-4/STS-3c in STM-256/OC-768 : 24310 121 1 AU-4/STS-3c in STM-256/OC-768 : 24410 125 1 AU-4/STS-3c in STM-256/OC-768 : 31110 129 1 AU-4/STS-3c in STM-256/OC-768 : 31210 133 1 AU-4/STS-3c in STM-256/OC-768 : 31310 137 1 AU-4/STS-3c in STM-256/OC-768 : 31410 141 1 AU-4/STS-3c in STM-256/OC-768 : 32110 145 1 AU-4/STS-3c in STM-256/OC-768 : 32210 149 1 AU-4/STS-3c in STM-256/OC-768 : 32310 153 1 AU-4/STS-3c in STM-256/OC-768 : 32410 157 1 AU-4/STS-3c in STM-256/OC-768 : 33110 161 1 AU-4/STS-3c in STM-256/OC-768 : 33210 165 1 AU-4/STS-3c in STM-256/OC-768 : 33310 169 1 AU-4/STS-3c in STM-256/OC-768 : 33410 173 1 AU-4/STS-3c in STM-256/OC-768 : 34110 177 1 AU-4/STS-3c in STM-256/OC-768 : 34210 181 1 AU-4/STS-3c in STM-256/OC-768 : 34310 185 1 AU-4/STS-3c in STM-256/OC-768 : 34410 189 1 AU-4/STS-3c in STM-256/OC-768 : 41110 193 1 AU-4/STS-3c in STM-256/OC-768 : 41210 197 1 AU-4/STS-3c in STM-256/OC-768 : 41310 201 1 AU-4/STS-3c in STM-256/OC-768 : 41410 205 1 AU-4/STS-3c in STM-256/OC-768 : 42110 209 1 AU-4/STS-3c in STM-256/OC-768 : 42210 213 1 AU-4/STS-3c in STM-256/OC-768 : 42310 217 1 AU-4/STS-3c in STM-256/OC-768 : 42410 221 1 AU-4/STS-3c in STM-256/OC-768 : 43110 225 1 AU-4/STS-3c in STM-256/OC-768 : 43210 229 1 AU-4/STS-3c in STM-256/OC-768 : 43310 233 1 AU-4/STS-3c in STM-256/OC-768 : 43410 237 1 AU-4/STS-3c in STM-256/OC-768 : 44110 241 1 AU-4/STS-3c in STM-256/OC-768 : 44210 245 1 AU-4/STS-3c in STM-256/OC-768 : 44310 249 1 AU-4/STS-3c in STM-256/OC-768 : 44410 253 1 AU-4/STS-3c in STM-256/OC-768 44420 254 1 AU-4/STS-3c in STM-256/OC-768 44430 255 1 AU-4/STS-3c in STM-256/OC-768 44440 256 1 AU-4/STS-3c in STM-256/OC-768 11111 1 2 AU-3/STS-1 in STM-256/OC-768 11112 1 3 AU-3/STS-1 in STM-256/OC-768 11113 1 4 AU-3/STS-1 in STM-256/OC-768 11121 2 2 AU-3/STS-1 in STM-256/OC-768 11122 2 3 AU-3/STS-1 in STM-256/OC-768 11123 2 4 AU-3/STS-1 in STM-256/OC-768 : 11131 3 2 AU-3/STS-1 in STM-256/OC-768 : 11141 4 2 AU-3/STS-1 in STM-256/OC-768 : 11211 5 2 AU-3/STS-1 in STM-256/OC-768 : 11311 9 2 AU-3/STS-1 in STM-256/OC-768 : 11411 13 2 AU-3/STS-1 in STM-256/OC-768 : 12111 17 2 AU-3/STS-1 in STM-256/OC-768 : 12211 21 2 AU-3/STS-1 in STM-256/OC-768 : 12311 25 2 AU-3/STS-1 in STM-256/OC-768 : 12411 29 2 AU-3/STS-1 in STM-256/OC-768 : 13111 33 2 AU-3/STS-1 in STM-256/OC-768 : 13211 37 2 AU-3/STS-1 in STM-256/OC-768 : 13311 41 2 AU-3/STS-1 in STM-256/OC-768 : 13411 45 2 AU-3/STS-1 in STM-256/OC-768 : 14111 49 2 AU-3/STS-1 in STM-256/OC-768 : 14211 53 2 AU-3/STS-1 in STM-256/OC-768 : 14311 57 2 AU-3/STS-1 in STM-256/OC-768 : 14411 61 2 AU-3/STS-1 in STM-256/OC-768 : 21111 65 2 AU-3/STS-1 in STM-256/OC-768 : 21211 69 2 AU-3/STS-1 in STM-256/OC-768 : 21311 73 2 AU-3/STS-1 in STM-256/OC-768 : 21411 77 2 AU-3/STS-1 in STM-256/OC-768 : 22111 81 2 AU-3/STS-1 in STM-256/OC-768 : 22211 85 2 AU-3/STS-1 in STM-256/OC-768 : 22311 89 2 AU-3/STS-1 in STM-256/OC-768 : 22411 93 2 AU-3/STS-1 in STM-256/OC-768 : 23111 97 2 AU-3/STS-1 in STM-256/OC-768 : 23211 101 2 AU-3/STS-1 in STM-256/OC-768 : 23311 105 2 AU-3/STS-1 in STM-256/OC-768 : 23411 109 2 AU-3/STS-1 in STM-256/OC-768 : 24111 113 2 AU-3/STS-1 in STM-256/OC-768 : 24211 117 2 AU-3/STS-1 in STM-256/OC-768 : 24311 121 2 AU-3/STS-1 in STM-256/OC-768 : 24411 125 2 AU-3/STS-1 in STM-256/OC-768 : 31111 129 2 AU-3/STS-1 in STM-256/OC-768 : 31211 133 2 AU-3/STS-1 in STM-256/OC-768 : 31311 137 2 AU-3/STS-1 in STM-256/OC-768 : 31411 141 2 AU-3/STS-1 in STM-256/OC-768 : 32111 145 2 AU-3/STS-1 in STM-256/OC-768 : 32211 149 2 AU-3/STS-1 in STM-256/OC-768 : 32311 153 2 AU-3/STS-1 in STM-256/OC-768 : 32411 157 2 AU-3/STS-1 in STM-256/OC-768 : 33111 161 2 AU-3/STS-1 in STM-256/OC-768 : 33211 165 2 AU-3/STS-1 in STM-256/OC-768 : 33311 169 2 AU-3/STS-1 in STM-256/OC-768 : 33411 173 2 AU-3/STS-1 in STM-256/OC-768 : 34111 177 2 AU-3/STS-1 in STM-256/OC-768 : 34211 181 2 AU-3/STS-1 in STM-256/OC-768 : 34311 185 2 AU-3/STS-1 in STM-256/OC-768 : 34411 189 2 AU-3/STS-1 in STM-256/OC-768 : 41111 193 2 AU-3/STS-1 in STM-256/OC-768 : 41211 197 2 AU-3/STS-1 in STM-256/OC-768 : 41311 211 2 AU-3/STS-1 in STM-256/OC-768 : 41411 215 2 AU-3/STS-1 in STM-256/OC-768 : 42111 219 2 AU-3/STS-1 in STM-256/OC-768 : 42211 213 2 AU-3/STS-1 in STM-256/OC-768 : 42311 217 2 AU-3/STS-1 in STM-256/OC-768 : 42411 221 2 AU-3/STS-1 in STM-256/OC-768 : 43111 225 2 AU-3/STS-1 in STM-256/OC-768 : 43211 229 2 AU-3/STS-1 in STM-256/OC-768 : 43311 233 2 AU-3/STS-1 in STM-256/OC-768 : 43411 237 2 AU-3/STS-1 in STM-256/OC-768 : 44111 241 2 AU-3/STS-1 in STM-256/OC-768 : 44211 245 2 AU-3/STS-1 in STM-256/OC-768 : 44311 249 2 AU-3/STS-1 in STM-256/OC-768 : 44411 253 2 AU-3/STS-1 in STM-256/OC-768 : 44421 254 2 AU-3/STS-1 in STM-256/OC-768 : 44431 255 2 AU-3/STS-1 in STM-256/OC-768 : 44441 256 2 AU-3/STS-1 in STM-256/OC-768 44442 256 3 AU-3/STS-1 in STM-256/OC-768 44443 256 4 AU-3/STS-1 in STM-256/OC-768 G.707 DCBA S U Tributary Slot Type ========================================= 0000 1 0 AU-4-64c/STS-192c in STM-64/OC-192 1000 1 0 AU-4-16c/STS-48c in STM-64/OC-192 2000 17 0 AU-4-16c/STS-48c in STM-64/OC-192 3000 33 0 AU-4-16c/STS-48c in STM-64/OC-192 4000 49 0 AU-4-16c/STS-48c in STM-64/OC-192 1100 1 0 AU-4-4c/STS-12c in STM-64/OC-192 1200 5 0 AU-4-4c/STS-12c in STM-64/OC-192 1300 9 0 AU-4-4c/STS-12c in STM-64/OC-192 1400 13 0 AU-4-4c/STS-12c in STM-64/OC-192 2100 17 0 AU-4-4c/STS-12c in STM-64/OC-192 2200 21 0 AU-4-4c/STS-12c in STM-64/OC-192 2300 25 0 AU-4-4c/STS-12c in STM-64/OC-192 2400 29 0 AU-4-4c/STS-12c in STM-64/OC-192 3100 33 0 AU-4-4c/STS-12c in STM-64/OC-192 3200 37 0 AU-4-4c/STS-12c in STM-64/OC-192 3300 41 0 AU-4-4c/STS-12c in STM-64/OC-192 3400 45 0 AU-4-4c/STS-12c in STM-64/OC-192 4100 49 0 AU-4-4c/STS-12c in STM-64/OC-192 4200 53 0 AU-4-4c/STS-12c in STM-64/OC-192 4300 57 0 AU-4-4c/STS-12c in STM-64/OC-192 4400 61 0 AU-4-4c/STS-12c in STM-64/OC-192 1110 1 1 AU-4/STS-3c in STM-64/OC-192 1120 2 1 AU-4/STS-3c in STM-64/OC-192 1130 3 1 AU-4/STS-3c in STM-64/OC-192 1140 4 1 AU-4/STS-3c in STM-64/OC-192 1210 5 1 AU-4/STS-3c in STM-64/OC-192 1220 6 1 AU-4/STS-3c in STM-64/OC-192 1220 7 1 AU-4/STS-3c in STM-64/OC-192 1220 8 1 AU-4/STS-3c in STM-64/OC-192 1310 9 1 AU-4/STS-3c in STM-64/OC-192 : 1410 13 1 AU-4/STS-3c in STM-64/OC-192 : 2110 17 1 AU-4/STS-3c in STM-64/OC-192 : 2210 21 1 AU-4/STS-3c in STM-64/OC-192 : 2310 25 1 AU-4/STS-3c in STM-64/OC-192 : 2410 29 1 AU-4/STS-3c in STM-64/OC-192 : 3110 33 1 AU-4/STS-3c in STM-64/OC-192 : 3210 37 1 AU-4/STS-3c in STM-64/OC-192 : 3310 41 1 AU-4/STS-3c in STM-64/OC-192 : 3410 45 1 AU-4/STS-3c in STM-64/OC-192 : 4110 49 1 AU-4/STS-3c in STM-64/OC-192 : 4210 53 1 AU-4/STS-3c in STM-64/OC-192 : 4310 57 1 AU-4/STS-3c in STM-64/OC-192 : 4410 61 1 AU-4/STS-3c in STM-64/OC-192 4420 62 1 AU-4/STS-3c in STM-64/OC-192 4430 63 1 AU-4/STS-3c in STM-64/OC-192 4440 64 1 AU-4/STS-3c in STM-64/OC-192 1111 1 2 AU-3/STS-1 in STM-64/OC-192 1112 1 3 AU-3/STS-1 in STM-64/OC-192 1113 1 4 AU-3/STS-1 in STM-64/OC-192 1121 2 2 AU-3/STS-1 in STM-64/OC-192 1122 2 3 AU-3/STS-1 in STM-64/OC-192 1123 2 4 AU-3/STS-1 in STM-64/OC-192 : 1131 3 2 AU-3/STS-1 in STM-64/OC-192 : 1141 4 2 AU-3/STS-1 in STM-64/OC-192 : 1211 5 2 AU-3/STS-1 in STM-64/OC-192 : 1311 9 2 AU-3/STS-1 in STM-64/OC-192 : 1411 13 2 AU-3/STS-1 in STM-64/OC-192 : 2111 17 2 AU-3/STS-1 in STM-64/OC-192 : 2211 21 2 AU-3/STS-1 in STM-64/OC-192 : 2311 25 2 AU-3/STS-1 in STM-64/OC-192 : 2411 29 2 AU-3/STS-1 in STM-64/OC-192 : 3111 33 2 AU-3/STS-1 in STM-64/OC-192 : 3211 37 2 AU-3/STS-1 in STM-64/OC-192 : 3311 41 2 AU-3/STS-1 in STM-64/OC-192 : 3411 45 2 AU-3/STS-1 in STM-64/OC-192 : 4111 49 2 AU-3/STS-1 in STM-64/OC-192 : 4211 53 2 AU-3/STS-1 in STM-64/OC-192 : 4311 57 2 AU-3/STS-1 in STM-64/OC-192 : 4411 61 2 AU-3/STS-1 in STM-64/OC-192 : 4441 63 2 AU-3/STS-1 in STM-64/OC-192 4442 64 3 AU-3/STS-1 in STM-64/OC-192 4443 65 4 AU-3/STS-1 in STM-64/OC-192 G.707 CBA S U Tributary Slot Type ========================================= 000 1 0 AU-4-16c/STS-48c in STM-16/OC-48 100 1 0 AU-4-4c/STS-12c in STM-16/OC-48 200 5 0 AU-4-4c/STS-12c in STM-16/OC-48 300 9 0 AU-4-4c/STS-12c in STM-16/OC-48 400 13 0 AU-4-4c/STS-12c in STM-16/OC-48 110 1 1 AU-4/STS-3c in STM-16/OC-48 120 2 1 AU-4/STS-3c in STM-16/OC-48 130 3 1 AU-4/STS-3c in STM-16/OC-48 140 4 1 AU-4/STS-3c in STM-16/OC-48 210 5 1 AU-4/STS-3c in STM-16/OC-48 220 6 1 AU-4/STS-3c in STM-16/OC-48 220 7 1 AU-4/STS-3c in STM-16/OC-48 220 8 1 AU-4/STS-3c in STM-16/OC-48 310 9 1 AU-4/STS-3c in STM-16/OC-48 320 10 1 AU-4/STS-3c in STM-16/OC-48 330 11 1 AU-4/STS-3c in STM-16/OC-48 340 12 1 AU-4/STS-3c in STM-16/OC-48 410 13 1 AU-4/STS-3c in STM-16/OC-48 420 14 1 AU-4/STS-3c in STM-16/OC-48 430 15 1 AU-4/STS-3c in STM-16/OC-48 440 16 1 AU-4/STS-3c in STM-16/OC-48 111 1 2 AU-3/STS-1 in STM-16/OC-48 112 1 3 AU-3/STS-1 in STM-16/OC-48 113 1 4 AU-3/STS-1 in STM-16/OC-48 121 2 2 AU-3/STS-1 in STM-16/OC-48 122 2 3 AU-3/STS-1 in STM-16/OC-48 123 2 4 AU-3/STS-1 in STM-16/OC-48 131 3 2 AU-3/STS-1 in STM-16/OC-48 132 3 3 AU-3/STS-1 in STM-16/OC-48 133 3 4 AU-3/STS-1 in STM-16/OC-48 141 4 2 AU-3/STS-1 in STM-16/OC-48 : 211 5 2 AU-3/STS-1 in STM-16/OC-48 : 311 9 2 AU-3/STS-1 in STM-16/OC-48 : 411 13 2 AU-3/STS-1 in STM-16/OC-48 : 441 16 2 AU-3/STS-1 in STM-16/OC-48 442 16 3 AU-3/STS-1 in STM-16/OC-48 443 16 4 AU-3/STS-1 in STM-16/OC-48 G.707 BA S U Tributary Slot Type ========================================= 00 1 0 AU-4-4c/STS-12c in STM-4/OC-12 10 1 1 AU-4/STS-3c in STM-4/OC-12 20 2 1 AU-4/STS-3c in STM-4/OC-12 30 3 1 AU-4/STS-3c in STM-4/OC-12 40 4 1 AU-4/STS-3c in STM-4/OC-12 11 1 2 AU-3/STS-1 in STM-4/OC-12 12 1 3 AU-3/STS-1 in STM-4/OC-12 13 1 4 AU-3/STS-1 in STM-4/OC-12 21 2 2 AU-3/STS-1 in STM-4/OC-12 22 2 3 AU-3/STS-1 in STM-4/OC-12 23 2 4 AU-3/STS-1 in STM-4/OC-12 31 3 2 AU-3/STS-1 in STM-4/OC-12 32 3 3 AU-3/STS-1 in STM-4/OC-12 33 3 4 AU-3/STS-1 in STM-4/OC-12 41 4 2 AU-3/STS-1 in STM-4/OC-12 42 4 3 AU-3/STS-1 in STM-4/OC-12 43 4 4 AU-3/STS-1 in STM-4/OC-12 G.707 A S U Tributary Slot Type ========================================= 0 1 1 AU-4/STS-3c in STM-1/OC-3 1 1 2 AU-3/STS-1 in STM-1/OC-3 2 1 3 AU-3/STS-1 in STM-1/OC-3 3 1 4 AU-3/STS-1 in STM-1/OC-3 The following table provides the explicit mapping between the G.707 KLM and the GMPLS KLM numbering scheme: G.707 GMPLS KLM K L M Tributary Slot Type ========================================= 100 2 1 0 TU-3 in VC-4 200 3 1 0 TU-3 in VC-4 300 4 1 0 TU-3 in VC-4 110 2 2 1 TU-2 in VC-4 120 2 3 1 TU-2 in VC-4 130 2 4 1 TU-2 in VC-4 140 2 5 1 TU-2 in VC-4 150 2 6 1 TU-2 in VC-4 160 2 7 1 TU-2 in VC-4 170 2 8 1 TU-2 in VC-4 210 3 2 1 TU-2 in VC-4 220 3 3 1 TU-2 in VC-4 230 3 4 1 TU-2 in VC-4 240 3 5 1 TU-2 in VC-4 250 3 6 1 TU-2 in VC-4 260 3 7 1 TU-2 in VC-4 270 4 8 1 TU-2 in VC-4 310 4 2 1 TU-2 in VC-4 320 4 3 1 TU-2 in VC-4 330 4 4 1 TU-2 in VC-4 340 4 5 1 TU-2 in VC-4 350 4 6 1 TU-2 in VC-4 360 4 7 1 TU-2 in VC-4 370 4 8 1 TU-2 in VC-4 111 2 2 4 TU-12 in VC-4 112 2 2 5 TU-12 in VC-4 113 2 2 6 TU-12 in VC-4 121 2 3 4 TU-12 in VC-4 122 2 3 5 TU-12 in VC-4 123 2 3 6 TU-12 in VC-4 131 2 4 4 TU-12 in VC-4 : 141 2 5 4 TU-12 in VC-4 : 151 2 6 4 TU-12 in VC-4 : 161 2 7 4 TU-12 in VC-4 : 171 2 8 4 TU-12 in VC-4 : 211 3 2 4 TU-12 in VC-4 : 311 4 2 4 TU-12 in VC-4 : 371 4 8 4 TU-12 in VC-4 372 4 8 5 TU-12 in VC-4 373 4 8 6 TU-12 in VC-4 111 2 2 7 TU-11 in VC-4 112 2 2 8 TU-11 in VC-4 113 2 2 9 TU-11 in VC-4 114 2 2 10 TU-11 in VC-4 121 2 3 7 TU-11 in VC-4 122 2 3 8 TU-11 in VC-4 123 2 3 9 TU-11 in VC-4 124 2 3 10 TU-11 in VC-4 131 2 4 7 TU-11 in VC-4 : 141 2 5 7 TU-11 in VC-4 : 151 2 6 7 TU-11 in VC-4 : 161 2 7 7 TU-11 in VC-4 : 171 2 8 7 TU-11 in VC-4 : 211 3 2 7 TU-11 in VC-4 : 311 4 2 7 TU-11 in VC-4 : 371 4 8 7 TU-11 in VC-4 372 4 8 8 TU-11 in VC-4 373 4 8 9 TU-11 in VC-4 374 4 8 10 TU-11 in VC-4 G.707 GMPLS LM K L M Tributary Slot Type ========================================= 10 0 2 1 TU-2/VT-6 in VC-3/STS-1 SPE 20 0 3 1 TU-2/VT-6 in VC-3/STS-1 SPE 30 0 4 1 TU-2/VT-6 in VC-3/STS-1 SPE 40 0 5 1 TU-2/VT-6 in VC-3/STS-1 SPE 50 0 6 1 TU-2/VT-6 in VC-3/STS-1 SPE 60 0 7 1 TU-2/VT-6 in VC-3/STS-1 SPE 70 0 8 1 TU-2/VT-6 in VC-3/STS-1 SPE 11 0 2 2 VT-3 in STS-1 SPE 12 0 2 3 VT-3 in STS-1 SPE 21 0 3 2 VT-3 in STS-1 SPE 22 0 3 3 VT-3 in STS-1 SPE 31 0 4 2 VT-3 in STS-1 SPE 32 0 4 3 VT-3 in STS-1 SPE 41 0 5 2 VT-3 in STS-1 SPE 42 0 5 3 VT-3 in STS-1 SPE 51 0 6 2 VT-3 in STS-1 SPE 52 0 6 3 VT-3 in STS-1 SPE 61 0 7 2 VT-3 in STS-1 SPE 62 0 7 3 VT-3 in STS-1 SPE 71 0 8 2 VT-3 in STS-1 SPE 72 0 8 3 VT-3 in STS-1 SPE 11 0 2 4 TU-12/VT-2 in VC-3/STS-1 SPE 12 0 2 5 TU-12/VT-2 in VC-3/STS-1 SPE 13 0 2 6 TU-12/VT-2 in VC-3/STS-1 SPE 21 0 3 4 TU-12/VT-2 in VC-3/STS-1 SPE 22 0 3 5 TU-12/VT-2 in VC-3/STS-1 SPE 23 0 3 6 TU-12/VT-2 in VC-3/STS-1 SPE 31 0 4 4 TU-12/VT-2 in VC-3/STS-1 SPE : 41 0 5 4 TU-12/VT-2 in VC-3/STS-1 SPE : 51 0 6 4 TU-12/VT-2 in VC-3/STS-1 SPE : 61 0 7 4 TU-12/VT-2 in VC-3/STS-1 SPE : 71 0 8 4 TU-12/VT-2 in VC-3/STS-1 SPE 72 0 8 5 TU-12/VT-2 in VC-3/STS-1 SPE 73 0 8 6 TU-12/VT-2 in VC-3/STS-1 SPE 11 0 2 7 TU-11/VT-1.5 in VC-3/STS-1 SPE 12 0 2 8 TU-11/VT-1.5 in VC-3/STS-1 SPE 13 0 2 9 TU-11/VT-1.5 in VC-3/STS-1 SPE 14 0 2 10 TU-11/VT-1.5 in VC-3/STS-1 SPE 21 0 3 7 TU-11/VT-1.5 in VC-3/STS-1 SPE 22 0 3 8 TU-11/VT-1.5 in VC-3/STS-1 SPE 23 0 3 9 TU-11/VT-1.5 in VC-3/STS-1 SPE 24 0 3 10 TU-11/VT-1.5 in VC-3/STS-1 SPE 31 0 4 7 TU-11/VT-1.5 in VC-3/STS-1 SPE : 41 0 5 7 TU-11/VT-1.5 in VC-3/STS-1 SPE : 51 0 6 7 TU-11/VT-1.5 in VC-3/STS-1 SPE : 61 0 7 7 TU-11/VT-1.5 in VC-3/STS-1 SPE : 71 0 8 7 TU-11/VT-1.5 in VC-3/STS-1 SPE 72 0 8 8 TU-11/VT-1.5 in VC-3/STS-1 SPE 73 0 8 9 TU-11/VT-1.5 in VC-3/STS-1 SPE 74 0 8 10 TU-11/VT-1.5 in VC-3/STS-1 SPE "AU-3/STS-1" Time/Tributary Slots occupied by AU-4/STS-3c in a STM-4/OC-12: Time/Trib 111 111 S U Slot 123456789012123456789012... 1 1 X X X X X X 2 1 X X X X X X 3 1 X X X X X X 4 1 X X X X X X "AU-3/STS-1" Time/Tributary Slots occupied by AU-4/STS-3c in a STM-16/OC-48: Time/Trib 111111111122222222223333333333444444444 11111111 S U Slot 12345678901234567890123456789012345678901234567812345678901234567.. 1 1 X X X X X 2 1 X X X X 3 1 X X X X 4 1 X X X X 5 1 X X X X 6 1 X X X X 7 1 X X X X 8 1 X X X X 9 1 X X X X 10 1 X X X X 11 1 X X X X 12 1 X X X X 13 1 X X X X 14 1 X X X X 15 1 X X X X 16 1 X X X X "AU-3/STS-1" Time/Tributary Slots occupied by AU-4-4c/STS-12c in a STM-16/OC-48: Time/Trib 111111111122222222223333333333444444444 111111111122 S U Slot 123456789012345678901234567890123456789012345678123456789012345678901.. 1 0 XXXX XXXX XXXX XXXX XXXX 5 0 XXXX XXXX XXXX XXXX 9 0 XXXX XXXX XXXX XXXX 13 0 XXXX XXXX XXXX XXXX "TU-12" Time/Tributary Slots occupied by TU-2 in a VC-4: Time/Trib 111111111122222222223333333333444444444455555555556666 K L M Slot 12345678901234567890123456789012345678901234567890123456789012312345... 2 2 1 X X X X 3 2 1 X X X X 4 2 1 X X X X 2 3 1 X X X X 3 3 1 X X X X 4 3 1 X X X 2 4 1 X X X 3 4 1 X X X 4 4 1 X X X 2 5 1 X X X 3 5 1 X X X 4 5 1 X X X 2 6 1 X X X 3 6 1 X X X 4 6 1 X X X 2 7 1 X X X 3 7 1 X X X 4 7 1 X X X 2 8 1 X X X 3 8 1 X X X 4 8 1 X X X "TU-11" Time/Tributary Slots occupied by TU-2 in a VC-4: Time/Trib 111111111122222222223333333333444444444455555555556666666666777777777788888 K L M Slot 123456789012345678901234567890123456789012345678901234567890123456789012345678901234123... 2 2 1 X X X X X 3 2 1 X X X X X 4 2 1 X X X X X 2 3 1 X X X X 3 3 1 X X X X 4 3 1 X X X X 2 4 1 X X X X 3 4 1 X X X X 4 4 1 X X X X 2 5 1 X X X X 3 5 1 X X X X 4 5 1 X X X X 2 6 1 X X X X 3 6 1 X X X X 4 6 1 X X X X 2 7 1 X X X X 3 7 1 X X X X 4 7 1 X X X X 2 8 1 X X X X 3 8 1 X X X X 4 8 1 X X X X "TU-12/VT-2" Time/Tributary Slots occupied by TU-2/VT-6 in a VC-3/STS-1 SPE: Time/Trib 111111111122 11 K L M Slot 12345678901234567890112345678901... 0 2 1 X X X X X 0 3 1 X X X X X 0 4 1 X X X X X 0 5 1 X X X X 0 6 1 X X X X 0 7 1 X X X X 0 8 1 X X X X "TU-11/VT1.5" Time/Tributary Slots occupied by TU-2/VT-6 in a VC-3/STS-1 SPE: Time/Trib 1111111111222222222 K L M Slot 1234567890123456789012345678123... 0 2 1 X X X X X 0 3 1 X X X X X 0 4 1 X X X X X 0 5 1 X X X X 0 6 1 X X X X 0 7 1 X X X X 0 8 1 X X X X Annex A: Conversion formula for EDCBA <-> SU (source: draft-lin-ccamp-ipo-common-label-request-01.txt) For the EDCBA to SU conversion, the following formula can be used: S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] + max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1 B U = ceiling[ --- , 0 ] + A B+1 For the SU to EDCBA conversion, the following formula can be used: S E = max[ ceiling[ --- ], 0 ] 64 or 0 {for AU-4-256c & STM-64 or lower} S D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 16 or 0 {for AU-4-64c or above & STM-16 or lower} S C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1 4 or 0 {for AU-4-16c or above & STM-4 or lower} B = [ ( S-1 ) modulo 4 ] + 1 or 0 {for AU-4-4c or above & STM-1 or lower} A = U - 1 or 0 (for AU-4 or above) --------------CC45DDEC99D181183FBF6CEF 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 --------------CC45DDEC99D181183FBF6CEF-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Nov 2001 01:15:05 -0800 Message-ID: <3BEB9D7D.ED71C159@lucent.com> Date: Fri, 09 Nov 2001 10:10:21 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt Content-Type: multipart/mixed; boundary="------------1FB0E5CE8BC51ED1013BE096" This is a multi-part message in MIME format. --------------1FB0E5CE8BC51ED1013BE096 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Eric, Going through some of the GMPLS SDH/SONET email, I came accross an unfini= shed discussion on arbitrary contiguous concatenation. This issue is relevant = for the draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt document. Let's me try to address this issue once more via a specific example: Assume a OC-12 signal, which should carry a STS-3a and of which the lowes= t signal is in the first timeslot. The question is now the timeslots carryi= ng the 2nd and 3rd signal within the STS-3a. Is it (A) or (B) as shown below? Time 111 111 Slot 123456789012123456789012... (A) XXX XXX (B) X X X X X X And for the case of an OC-48 signal, are the STS-3a timeslots according (= C) or (D) below? Time 111111111122222222223333333333444444444 11111111= Slot 12345678901234567890123456789012345678901234567812345678901234567= =2E. (C) XXX XXX (D) X X X X X= Regards, Maarten Maarten Vissers wrote: > = > Eric, > = > Let's discuss this issue during the IETF meeting in London. Being face = to face > its easier to illustrate that a STS-3c isn't using 3 physically contigu= ous > timeslots. > = > For the standard contiguous concatenation (including STS-3c) there are = T1.105 > and G.707 defining the timeslots used. But there are no transport plane= > documents that define the timeslot allocation for arbitrary concatenati= on. I.e. > is a STS-3a using physically contiguous timeslots or is it using the sa= me > timeslots a STS-3c would use? > As the gmpls-sonet-sdh document is the first and only standard describi= ng > arbitrary concatenation, interworking is only guaranteed when it is una= mbiguous > which timeslots are being used. > = > Regards, > = > Maarten > = > "Mannie, Eric" wrote: > > > > Hello Juergen and Maarten, > > > > I don't understand the relationship between > > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that you are = talking > > about. > > > > In addition, the IETF is not specifying any SDH/SONET interoperabilit= y (Not > > at all in the GMPLS scope). > > > > Also, I am not sure to understand why the abstract (B, A) notation of= G.707 > > (used to have a clearer specification, and not used (transported) in = any > > protocol as far as I know) could imply that contiguous time-slots are= not > > contiguous anymore ? > > > > The "Arbitrary" concatenation that you are speaking about is a contig= uous > > concatenation, time-slots are physically contiguous. I don't understa= nd the > > relevance of the SDH (B, A) notation in relationship with SONET in th= e > > context of the IETF. Anyway, contiguous time-slots will stay physical= ly > > contiguous even if you see an issue with the SDH G.707 (B, A) notatio= n > > applied to SONET. > > > > Also, "flexible arbitrary concatenation" (whatever it is - everybody = seems > > to have a different understanding) is not part of > > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt. > > > > I guess also that this discussion is relevant for the ITU-T and/or T1= X1, not > > for the ccamp mailing list (of the IETF). > > > > Kind regards, > > > > Eric > > > > -----Original Message----- > > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > > Sent: Tuesday, July 24, 2001 4:28 PM > > To: 'Maarten Vissers'; ccamp > > Cc: t1x1.5; q11/15 > > Subject: AW: [T1X1.5] arbitrary contiguous concatenation question > > > > Maarten, > > > > good point. Lets hear what the supporters of arbitrary concatenation = have to > > say. > > > > Juergen > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Maarten Vissers [mailto:mvissers@lucent.com] > > > Gesendet: Dienstag, 10. Juli 2001 11:14 > > > An: ccamp > > > Cc: t1x1.5; q11/15 > > > Betreff: [T1X1.5] arbitrary contiguous concatenation question > > > > > > > > > All, > > > > > > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling > > > support for arbitrary > > > contiguous concatenation in appendix 3. Looking a bit more > > > into this arbitrary > > > concatenation from the transport plane, I came across a > > > question with respect to > > > the definition of "contiguous STS-1/AU-3 timeslots". Let me > > > introduce this > > > question: > > > > > > Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within > > > an STM-4) as > > > follows > > > > > > Time 111 > > > Slot 123456789012123456789 > > > > > > B 123412341234123412341... > > > A 111122223333111122223... > > > > > > AU-3 timeslots have a TimeSlot number and a (B,A) number, > > > with TS1 associated > > > with (1,1) and TS12 associated with (4,3). > > > > > > Note - the figure in the pre-published version of G.707 > > > doesn't show the timeslot numbering in a correct manner. > > > > > > and the AU-4 numbering is as follows (figure 7-24/G.707) > > > > > > Time > > > Slot 123412341234123412341 > > > > > > B 123412341234123412341... > > > A 000000000000000000000... > > > > > > An AU-4 [STS-3c] is as such essentially a "non-contiguous" > > > concatenation of > > > AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4 > > > (2,0) uses AU-3 > > > timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)]. > > > > > > > > > If we define STS-1 contiguous concatenation, which timeslots > > > are then used for > > > e.g. a STS-1-3c: > > > i) timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or > > > ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9] > > > > > > Similarly, for the case of a STS-1-6c do we use: > > > i) (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2) > > > [TS1,TS2,TS3,TS4,TS5,TS6] or > > > ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3) > > > [TS1,TS2,TS5,TS6,TS9,TS10] > > > > > > > > > And which timeslots do we use for e.g. a STS-1-5c? > > > > > > > > > If this detail is not specified, interworking is not possible > > > unless we include > > > the list of timeslots as we do with virtual concatenation > > > (and as discussed for > > > flexible arbitrary concatenation). > > > > > > > > > Regards, > > > > > > Maarten > > > --------------1FB0E5CE8BC51ED1013BE096 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 --------------1FB0E5CE8BC51ED1013BE096-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 18:50:45 -0800 Message-ID: From: James Scott To: 'manoj juneja' , ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com Subject: RE: SDH/SONET in GMPLS Date: Thu, 8 Nov 2001 18:42:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi manoj, mj> In SONET, each VTG of STS-1 can have VTs of mj> different size (i.e 1 VTG can contain 1 VT-6, mj> other VTG within the same STS-1 can contain 2 mj> VT-3 etc). As VTG in SONET is equivalent to mj> TUG-2 in SDH. Does this mean that each TUG-2 mj> within STM-1 can contain different type of mj> VC-X (X=2, 12, 11) i.e. one TUG-2 can contain mj> 3 VC-12 and other TUG-2 within same STM-1 can mj> contain 1 VC-2 ? yes. a TUG-2 in SDH is equivalent to a VT group in SONET. mj> Furthermore, As per draft-mannie-mpls-sdh-ospf- mj> isis-01.txt, It is assumed that every STM-1/STS-1 mj> of STM-N/STS-M, M, N > 1 will have the same mj> multiplexing capability. This type of restriction mj> is not as per SDH/SONEYT. Does this mean this mj> restriction has been kept for making the routing mj> protocol simple ? you need identical multiplexing capabilities at each end of the LSP, in order to be able to demultiplex at the LSP termination point. the reason for advertising this in the link state protocol is to ensure consistency at each endpoint. in other words, by making this a CSPF constraint, we can easily prune disjoint multiplex types from the set of acceptable paths. if this is unclear, perhaps i'll defer to the authors for further clarification. i hope that my comments have been of use. cheers, james Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 18:23:55 -0800 From: "manoj juneja" To: jscott@calient.net, ccamp@ops.ietf.org Cc: Eric.Mannie@ebone.com Bcc: Subject: RE: SDH/SONET in GMPLS Date: Thu, 08 Nov 2001 19:18:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi James, My question was little bit different. Let me re-pharse the question. In SONET, each VTG of STS-1 can have VTs of different size (i.e 1 VTG can contain 1 VT-6, other VTG within the same STS-1 can contain 2 VT-3 etc). As VTG in SONET is equivalent to TUG-2 in SDH. Does this mean that each TUG-2 within STM-1 can contain different type of VC-X (X=2, 12, 11) i.e. one TUG-2 can contain 3 VC-12 and other TUG-2 within same STM-1 can contain 1 VC-2 ? Furthermore, As per draft-mannie-mpls-sdh-ospf-isis-01.txt, It is assumed that every STM-1/STS-1 of STM-N/STS-M, M, N > 1 will have the same multiplexing capability. This type of restriction is not as per SDH/SONEYT. Does this mean this restriction has been kept for making the routing protocol simple ? Regards, manoj. >From: James Scott >To: "'ccamp@ops.ietf.org'" >Subject: RE: SDH/SONET in GMPLS >Date: Thu, 8 Nov 2001 17:30:11 -0800 > >hi manoj, > >mj> As per SONET standard, each STS-1 SPE >mj> is divided into 7 VT-groups. Each VT >mj> group may contain 4 VT1.5, 3 VT-2s, >mj> 2 VT-3s or 1 VT-6. Furthermore, each >mj> VT-group shall contain one size of VT. >mj> however, each VT-group within STS-1 may >mj> be of different VT-size. Does this type >mj> of statement holds true for SDH also ? > >yes. i don't recall that SDH spells out the >rules on trib mixing explicitly as SONET does. >however, the intent of the rules should be >applicable to either protocol. that being, >to eliminate the possibility of inefficient >usage of the columns within the trib group >due to mismatched trib types being applied. > >mj> Is GMPLS supports this or it has some >mj> restrictions for these configurations? > >draft-ietf-ccamp-gmpls-sonet-sdh-02.txt >defines labels with VT/TU granularity as >well as mappings/encodings for both >contiguous and arbitrary concatenation. >this should supply vendors with an adequate >supply of rope. > >hope this helps. > >cheers, > >james > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 17:37:05 -0800 Message-ID: From: James Scott To: "'ccamp@ops.ietf.org'" Subject: RE: SDH/SONET in GMPLS Date: Thu, 8 Nov 2001 17:30:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi manoj, mj> As per SONET standard, each STS-1 SPE mj> is divided into 7 VT-groups. Each VT mj> group may contain 4 VT1.5, 3 VT-2s, mj> 2 VT-3s or 1 VT-6. Furthermore, each mj> VT-group shall contain one size of VT. mj> however, each VT-group within STS-1 may mj> be of different VT-size. Does this type mj> of statement holds true for SDH also ? yes. i don't recall that SDH spells out the rules on trib mixing explicitly as SONET does. however, the intent of the rules should be applicable to either protocol. that being, to eliminate the possibility of inefficient usage of the columns within the trib group due to mismatched trib types being applied. mj> Is GMPLS supports this or it has some mj> restrictions for these configurations? draft-ietf-ccamp-gmpls-sonet-sdh-02.txt defines labels with VT/TU granularity as well as mappings/encodings for both contiguous and arbitrary concatenation. this should supply vendors with an adequate supply of rope. hope this helps. cheers, james Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 15:35:11 -0800 From: "manoj juneja" To: ccamp@ops.ietf.org Bcc: Subject: SDH/SONET in GMPLS Date: Thu, 08 Nov 2001 16:28:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: Hi All, As per SONET standard, each STS-1 SPE is divided into 7 VT -groups. Each VT group may contain 4 VT1.5, 3 VT-2s, 2 VT-3s or 1 VT-6. Furthermore, each VT-group shall contain one size of VT. however, each VT-group within STS-1 may be of different VT-size. Does this type of statement holds true for SDH also ? I mean to say that STM-1 may contain 21 TUG-2s. Is it true that each TUG-2 within STM-1 can be configured differently to conatin VC-2/VC-12/VC-11 within it but each TUG-2 contains same type of VC-X (X=2, 12, 11). Is GMPLS supports this or it has some restrictions for these configurations ? Please help. Regards, manoj. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 14:01:48 -0800 From: "Robin Qiu" To: fwang@axiowave.com Cc: ccamp@ops.ietf.org Bcc: Subject: RE: A question regarding draft-itef-ccamp-lmp-01.txt Date: Thu, 08 Nov 2001 16:56:59 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: My interpretations (plus more questions) below. Please feedback if you don't agree. Robin Qiu -----Original Message----- From: Fugui Wang [mailto:fwang@axiowave.com] Sent: Thursday, November 08, 2001 3:09 PM To: 'ccamp@ops.ietf.org' Subject: FW: A question regarding draft-itef-ccamp-lmp-01.txt Hi, I posted this message about a week ago. Could somebody please give me a clarification about it? Thanks a lot, Fugui -----Original Message----- From: Fugui Wang Sent: Wednesday, October 31, 2001 1:09 PM To: 'ccamp@ops.ietf.org' Subject: A question regarding draft-itef-ccamp-lmp-01.txt A question regarding draft-itef-ccamp-lmp-01.txt In section 13.16 CONFIG_ERROR [page 60]: o CONFIG_ERROR, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID Question: (1) In which situation should you have error code 0x04 = Bad Received CCID? Since the Config message only bring LOCAL_CCID, the only case I can imagine is that when the LOCAL_ID in Config doesn't match the lmpRemoteCcId field of the receiving node. But in this case, shouldn't we just update the lmpRemoteCcId field (learning remote CCId) instead of sending a ConfigNack with error code = 0x04? [Robin] I regard zero CCID as an error. The spec also requires that CCID is unique within the NODEID scope. Should the receiver of the Config message check this? For in-fiber signaling, the CCID must be the same as the interface ID. Should this be validated as well? (2) For error code 0x01 and 0x02, the N bit in the Config object of ConfigNack already tells about which error it is (The previous draft use the N bit in HelloConfig TLV to handle this). Is it necessary to have an additional ERROR_CODE object in the ConfigNack? I think the ERROR_CODE is redundant to the N bit in Config object. [Robin] The Config object is not always in the ConfigNack message. Even if it is, it might just be a copy of the original one contained in the received Config message (see 12.4.3), in which case the N bit indicates the Config sender's information. Thanks, Fugui _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 12:42:28 -0800 Message-ID: From: Jonathan Lang To: 'Fugui Wang ' , "''ccamp@ops.ietf.org' '" Cc: Jonathan Lang Subject: RE: A question regarding draft-itef-ccamp-lmp-01.txt Date: Thu, 8 Nov 2001 12:36:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Fugui, Sorry for the delayed response. Upon review/discussion amongst the authors, I believe you are correct. My suggestion would be to remove the CONFIG_ERROR code. Thanks, Jonathan -----Original Message----- From: Fugui Wang To: 'ccamp@ops.ietf.org' Sent: 11/8/2001 12:09 PM Subject: FW: A question regarding draft-itef-ccamp-lmp-01.txt Hi, I posted this message about a week ago. Could somebody please give me a clarification about it? Thanks a lot, Fugui -----Original Message----- From: Fugui Wang Sent: Wednesday, October 31, 2001 1:09 PM To: 'ccamp@ops.ietf.org' Subject: A question regarding draft-itef-ccamp-lmp-01.txt A question regarding draft-itef-ccamp-lmp-01.txt In section 13.16 CONFIG_ERROR [page 60]: o CONFIG_ERROR, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID Question: (1) In which situation should you have error code 0x04 = Bad Received CCID? Since the Config message only bring LOCAL_CCID, the only case I can imagine is that when the LOCAL_ID in Config doesn't match the lmpRemoteCcId field of the receiving node. But in this case, shouldn't we just update the lmpRemoteCcId field (learning remote CCId) instead of sending a ConfigNack with error code = 0x04? (2) For error code 0x01 and 0x02, the N bit in the Config object of ConfigNack already tells about which error it is (The previous draft use the N bit in HelloConfig TLV to handle this). Is it necessary to have an additional ERROR_CODE object in the ConfigNack? I think the ERROR_CODE is redundant to the N bit in Config object. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 12:13:08 -0800 Message-ID: From: Fugui Wang To: "'ccamp@ops.ietf.org'" Subject: FW: A question regarding draft-itef-ccamp-lmp-01.txt Date: Thu, 8 Nov 2001 15:09:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I posted this message about a week ago. Could somebody please give me a clarification about it? Thanks a lot, Fugui -----Original Message----- From: Fugui Wang Sent: Wednesday, October 31, 2001 1:09 PM To: 'ccamp@ops.ietf.org' Subject: A question regarding draft-itef-ccamp-lmp-01.txt A question regarding draft-itef-ccamp-lmp-01.txt In section 13.16 CONFIG_ERROR [page 60]: o CONFIG_ERROR, C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable CONFIG parameter 0x02 = Renegotiate CONFIG parameter 0x04 = Bad Received CCID Question: (1) In which situation should you have error code 0x04 = Bad Received CCID? Since the Config message only bring LOCAL_CCID, the only case I can imagine is that when the LOCAL_ID in Config doesn't match the lmpRemoteCcId field of the receiving node. But in this case, shouldn't we just update the lmpRemoteCcId field (learning remote CCId) instead of sending a ConfigNack with error code = 0x04? (2) For error code 0x01 and 0x02, the N bit in the Config object of ConfigNack already tells about which error it is (The previous draft use the N bit in HelloConfig TLV to handle this). Is it necessary to have an additional ERROR_CODE object in the ConfigNack? I think the ERROR_CODE is redundant to the N bit in Config object. Thanks, Fugui Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Nov 2001 09:09:57 -0800 From: "Juergen Heiles" To: Subject: WG: Moving right along ... Switching Type Date: Thu, 8 Nov 2001 18:05:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dimitri, thanks for the clarification. >From this information it seems first to me that the values for the switching type are miss-leading, instead of "TDM" or "WDM" we should use "time slots" and "wavelengths". But furthermore what additional information does the switching type provide in addition to the signal type. It seems that the switching type is always defined by the signal type. A ODU1 signal type has a switching type of TDM/time slot and a OCh a switching type of WDM/Wavelength. Can you or someone else give an example where the switching type is not related to the signal type (e.g. signal type ODU1 and switching type WDM/wavelength)? For the first example you say that the upper ODU1 (OTM1.4) are identified by individual OCh IDs. I assume that the lower ODU1 are identified by the ODU2 OCh ID and the timeslot within the ODU2. It looks strange to me, that I have to use different methods for the label generation depending on the server layers. This results in the problems with example 2. Combining several signals using TDM or WDM is no difference from the basic signal flow. It is a technology choice that may change over time. GMPLS is in my view for this case too much focused on technologies. I would prefer a label that is independent of the server layer technology. This would allow to change the server layer at intermediate points without problems. Regards Juergen > -----Ursprüngliche Nachricht----- > Von: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be] > Gesendet: Dienstag, 6. November 2001 07:31 > An: Heiles Juergen > Cc: ccamp@ops.ietf.org > Betreff: Re: Moving right along ... Switching Type > > > Juergen, see inline... > > Heiles Juergen wrote: > > > > Following the discussion on the Switching Type and looking > on the proposed G.709 extensions for GMPLS I would like to > get some feedback on the examples shown below. > > How to handle the examples concerning label request and > returned label is important for my understanding of GMPLS. > > The examples are based on G.709 ODUs. A ODU can be > transported via WDM systems or using TDM in a higher bit rate > ODU. So we can have a mixture of both methods. > > > > Juergen > > > > Example 1: > > > > Two network elements A and B with ODU1 cross-connect are > interconnected by two types of signals. > > - a four channel WDM OTM-4.1 interface with 4 optical > channels each carrying an OTU1/ODU1 > > - a single channel OTM-1.2 with one optical channel > carrying a OTU2/ODU2 and 4 ODU1 multiplexed into the ODU2. > > > > ----------------- ---------------- > > NE A + + NE B > > + + > > ODU1 ----- + + ----- ODU1 > > 1 o---+ + + OTM-4.1 + + +---o 1 > > 2 o---+ w + + 4xOCh with OTU1/ODU1 + + W +---o 2 > > + D +--------------------------------+ D + > > 3 o---+ M + + + + M +---o 3 > > 4 o---+ + + + + +---o 4 > > ----- + + ----- > > + + > > ODU1 ----- + + ----- ODU1 > > 5 o---+ + + OTM-0.2 + + +---o 5 > > 6 o---+ T + + 1xOCh with OTU2/ODU2 + + T +---o 6 > > + D +--------------------------------+ D + > > 7 o---+ M + + with 4 ODU1 + + M +---o 7 > > 8 o---+ + + + + +---o 8 > > ----- + + ----- > > + + > > ----------------- ----------------- > > > > Now setting up a ODU1 connection between A and B. 8 ODU1 > connections are available, 4 using WDM technology and 4 using > TDM technology. > > For the connection itself I don't care which of the 8 is > used and I don't care about the specific technology. > > How does the label request from NE a to NE B look like? > > - the LSP encoding type is "G.709 digital path layer" > > - the signal type is ODU1 > > - but what is the switching type "TDM" or "Lambda"? Both > are available. > > Both entities aren't ODU1 switches ? i think you have indicate in the > picture here "the interface multiplexing" capabilities not > the switching > ones. > > So I guess that these devices are both ODU1 switches. Therefore, if > the switching type is used (notice that it is not necessary here since > there is only one switching capability assigned to the "end of the > link") the switching will be TDM > > The differences comes from the Encoding type in the first case > (upper link) it will be G.709 OCh (WDM interface) in the second > case G.709 ODUk (TDM interface) > > > Furthermore what kind of label is returned by NE B to NE A? > > - for ODU 5 to 8 a "G.709 digital path layer label" with > signal type ODU1 and a indication of the time slot within the ODU2 > > - but how about ODU1 to 4, a G.709 OCh signal type with the > indication of the wavelength is not correct. > > or is each ODU 1 to 4 seen as individual link? > > In such a case (for the OTM4.1) each of the OCh will have a > dedicate ID > that will be included within the request: setup of an ODU1 LSP > - LSP encoding type: G.709 digital path layer > - signal type: ODU1 > - switching type: "TDM" (not necessary) > - If_Index: 1 (for instance to indicate the first optical channel) > > > Example 2: > > > > NE A and NE C that provide ODU1 cross-connections are > interconnected via NE B that is not GMPLS aware and that > performs a conversion between WDM and TDM multiplexing. > > - between NE A and NE B a four channel WDM OTM-4.1 signal > is used with 4 optical channels, each carrying a OTU1/ODU1. > > - between NE B and NE C a single channel OTM-0.2 signal is > used with one optical channel carrying a OTU2/ODU2 with 4 > ODU1 multiplexed into the ODU2. > > > > ------------- ---------------- ------------- > > NE A + + NE B + + NE C > > + + ODU1 + + > > ODU1 ----- + + ----- ----- + + ----- ODU1 > > 1 o--+ + + OTM-4.1 + + +--+ + + OTM-0.2 + + +--o 1 > > 2 o--+ w + + 4xOCh with + + W +--+ T + + 1xOCh with + + T +--o 2 > > + D +----------------+ D + + D +-----------------+ D + > > 3 o--+ M + + OTU1/ODU1 + + M +--+ M + + OTU1/ODU1 + + M +--o 3 > > 4 o--+ + + + + +--+ + + with 4 ODU1 + + +--o 4 > > ----- + + ----- ----- + + ----- > > + + + + > > ------------- ---------------- ------------- > > > > Again what is the switching type of the label request from > NE A to NE C (TDM or Lambda)? > > And what is the returned label from NE C to NE A? > > Just to be sure in the above example i guess you ment for the second > link 1x0Ch with OTU2/ODU2 with 4 ODU1 since having TDM > > Since device A, B and C are all ODU1 switches the switching will be > always > TDM (if this field is used cfr. the remark indicated here above). > Remember > here that TDM is a shortcut to specify switching of all the digital > switching > layers supporting TDM capabilities (this includes VC-3/VC-4/ODUk/etc.) > > The relative complexity in the second example shown here above arise > more from > the interconnection of GMPLS to non-GMPLS capable devices (in addition > performing > conversion of the encoding type) rather than the "switching > type" issue. > > It reminds me Zhi's discussion on GMPLS to non-GMPLS > communication here > addind that your transmission competences it gives a very > nice example. > > Briefly LSR A sees ODU mapping while C sees ODU multiplexing such that > building the label association is needed as additional > mechanisms here. > > - dimitri. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Nov 2001 07:25:14 -0800 Message-ID: From: "Mannie, Eric" To: 'Ben Mack-Crane' , Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... gmpls-sonet-sdh-02 Date: Tue, 6 Nov 2001 16:21:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hello Ben, >1) Under Signal Type there are four transforms described and it > is suggested that these four may be applied in the specified > order. I don't think transparency makes much sense after specifying > concatenation transforms. This should be clarified. We saw that point when we wrote the specification. That's one particular case where the practical usage of the combination is not the most obvious :-) We gave examples of that encoding (see examples number 5 and 6). The point is that this draft is a toolbox. Some tools are more relevant than others at some time. Technically, if somebody wants a VC-4-4c with the MS DCC being transported transparently over an STM-64 network, why not ? Maybe to carry some extra signaling or routing in that DCC. I could think at the normal IP traffic being transported in the concatenated payload and the management traffic running over the DCC, why not ? Technically it works fine and has some benefit (e.g. the DCC may not be congested when the payload may be congested). I would not bet that nobody is using that feature. I don't think that it is the job of this draft to explicitly preclude some scenarios. The concatenation combined with the transparency came also as a side effect of the generalization of the transforms (to be orthogonal in the specification). It is just a combination that is available if someone needs it, not more (and you don't have to support it to be compliant of course). >2) In the transparency section it states "Section/Regenerator > Section layer transparency means that the entire frames must > be delivered unmodified" and "Line/Multiplex Section layer > transparency means that the LOH/MSOH must be delivered > unmodified." This would seem to preclude the forms of TDM > multiplexing supported by some equipment (e.g., 4xOC-48 into > "OC-192"). I think we should add language that allows for > this. Of course, we wrote also immediately after "This implies that pointers cannot be adjusted" to attract the attention of the reader on that point (that wording was validated by our ITU-T folks). We didn't want to put tutorial information on SDH/SONET in that draft. Note that they are other types of transparencies that we also defined allowing to combine multiplexing and transparency as you said (see the SDH/SONET extensions draft - they are in a separate draft). Indeed that draft defines some simple general encoding to request circuits. The beauty of the draft is that while the protocol extension is straightforward (just a few fields), I don't know any type of circuit that could not be requested (i.e. any type of circuit can be requested). Kind regards, Eric -----Original Message----- From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] Sent: Tuesday, October 30, 2001 12:03 AM To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... gmpls-sonet-sdh-02 A couple of comments on draft-ietf-ccamp-gmpls-sonet-sdh-02.txt 1) Under Signal Type there are four transforms described and it is suggested that these four may be applied in the specified order. I don't think transparency makes much sense after specifying concatenation transforms. This should be clarified. 2) In the transparency section it states "Section/Regenerator Section layer transparency means that the entire frames must be delivered unmodified" and "Line/Multiplex Section layer transparency means that the LOH/MSOH must be delivered unmodified." This would seem to preclude the forms of TDM multiplexing supported by some equipment (e.g., 4xOC-48 into "OC-192"). I think we should add language that allows for this. Regards, Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Nov 2001 06:33:15 -0800 Message-ID: <3BE7F381.3B4D30E7@lucent.com> Date: Tue, 06 Nov 2001 09:28:17 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Zhi-Wei Lin CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zhi, You may need the "adaptation function descriptor" as an attribute to the "virtual port" for the CAC and path selection at the source node. Yet, I am not sure whether this makes things easier or more complicated. Yangguang Zhi-Wei Lin wrote: > > Hi John, Eric, > > I'm not sure if we need to include adaptation function in GMPLS. My > understanding of the adaptation function is that this is a transport > level capability for "adapting" or mapping the signal. > > From the GMPLS perspective, there is some local action that takes place > (the magic you mentioned?) to adapt the signal, but the signaling impact > is simply changing the encoding type and/or GPID and/or the SONET/SDH > SENDER_TSPEC to another value based on the local adaptation (or no > change at all)...depends on what adaptation you perform... > > I think this has gone beyond switching type discussion...or am I wrong? > > Zhi > > Eric Gray wrote: > > > John, > > > > The simplest such proposal is for 'adaptation functions' that are logically > > distinct from protocol entities to be disallowed. If the adaptation function > > is required to participate in signaling (either as a direct participant, or through > > proxy), then a lot of the complexity disappears. > > > > You wrote: > > > > > >>"As mentioned by Zhi, one of the OXCs in the path would > >>need to do the adaptation from GigE to Ethetnet over GFP" > >> > >>There is a considerable amount of magic contained in the > >>above sentence. I think it's well understood by everyone > >>what needs to be done. The more interesting question is > >>how, and a proposal for how adaptation functions should be > >>incorporated into GMPLS would be timely. > >> > >>-----Original Message----- > >>From: Jonathan Sadler [mailto:Jonathan.Sadler@tellabs.com] > >>Sent: Friday, November 02, 2001 3:03 PM > >>To: Yakov Rekhter > >>Cc: Ewart Tempest; ccamp@ops.ietf.org > >>Subject: Re: Moving right along ... Switching Type > >> > >>Yakov, et al - > >> > >>The OC-48 port could be terminating Ethernet over GFP, in which case PPP > >>is not in use. As mentioned by Zhi, one of the OXCs in the path would > >>need to do the adaptation from GigE to Ethetnet over GFP. Further, > >>since GigE is speed wise slower than OC-48, such a configuration would > >>not generate any service degradation... > >> > >>Jonathan Sadler > >> > >>Yakov Rekhter wrote: > >> > >>>Ewart, > >>> > >>> > >>>>See embedded comment below. > >>>> > >>>response in-line... > >>> > >>> > >>>>Ewart > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Yakov Rekhter [mailto:yakov@juniper.net] > >>>>>Sent: Wednesday, October 31, 2001 8:19 PM > >>>>>To: Zhi-Wei Lin > >>>>>Cc: ccamp@ops.ietf.org > >>>>>Subject: Re: Moving right along ... Switching Type > >>>>> > >>>>> > >>>>>Zhi-Wei, > >>>>> > >>>>> > >>>>>>Maybe this is one where we need to ask individuals with > >>>>>> > >>>>>operational > >>>>> > >>>>>>experience and have some experience with service > >>>>>> > >>>>>provisioning whether > >>>>> > >>>>>>having one end with Ethernet and another end with OC-48 > >>>>>> > >>>>>sounds like a > >>>>> > >>>>>>configuration that makes sense? > >>>>>> > >>>>>Let me see if I understand your proposal. Consider the following > >>>>>example: > >>>>> > >>>>> R1---OXC1---OXC2----R2 > >>>>> > >>>>>where the TE interface on R1 is a collection of GigE ports, and the TE > >>>>>interface on R2 is a collection of OC-48 ports. Are you saying that > >>>>>establishing an LSP between R1 to R2 makes sense ? > >>>>> > >>>>[EWART]: Correct. OXC1 may be capable of performing signal conversion > >>>> > >>or, > >> > >>>>more likely, there may be some intermediate non-GMPLS device between R1 > >>>> > >>& > >> > >>>>OXC1 that performs such a conversion (refer to e-mail entitled "Query on > >>>>Encoding field wrt presence of technology conversion devices - > >>>>OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and > >>>> > >>which, > >> > >>>>for the benefit of those that were not, I have repeated below) because > >>>> > >>the > >> > >>>>OXC has no GigE interface port. > >>>> > >>>>"Within the GMPLS related routing documents > >>>>(draft-ietf-ccamp-ospf-gmpls-extensions & > >>>> > >>draft-ietf-isis-gmpls-extensions), > >> > >>>>there is an Encoding field contained in the Interface Switching > >>>> > >>Capability > >> > >>>>Descriptor sub-TLV of the Link/IS Reachability TLV. > >>>> > >>>In case you missed it, I'll repeat what I said before: > >>> > >>> Please note that R1 (a router) uses Ethernet encapsulation when > >>> sending data on the GigE port. Please also note that R2 (also > >>> a router) expects to have HDLC encapsulation when receiving data > >>> on its OC-48 port. As Maarten said in his e-mail, " 1GE port > >>> on R1 and OC-48 port on R2 "don't speak the same language". > >>> > >>> > >>>>My request for GMPLS to support FiberChannel is driven by a need for > >>>> > >>clients > >> > >>>>to be able to attach to the ASTN using FiberChannel. However, the ASTN > >>>>devices at the edge (e.g. LSR A in the diagram below) may not be > >>>> > >>equipped > >> > >>>>with FiberChannel ports. In this situation, the FiberChannel coming from > >>>> > >>the > >> > >>>>client device (client A in the diagram below) has to pass through a > >>>>technology conversion device that maps the FiberChannel to something > >>>> > >>which > >> > >>>>LSR A is capable of supporting. For example, there are devices readily > >>>>available on the market today that map FiberChannel to POS. Client A is > >>>>opaque to this conversion being done - when client A wants to establish > >>>> > >>an > >> > >>>>LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > >>>>signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > >>>>signalling is handled by LSR A, and not by the non-GMPLS savvy > >>>> > >>technology > >> > >>>>conversion device. Similarly, any signalling performed by LSR A to > >>>> > >>client A > >> > >>>>wrt this same link will use FiberChannel based GMPLS signalling, even > >>>> > >>though > >> > >>>>the link which manifests itself on a FiberChannel port on client A > >>>> > >>manifests > >> > >>>>itself on a SONET port on LSR A. However, in terms of the GMPLS > >>>> > >>signalling > >> > >>>>that LSR A propagates downstream, within a SONET based ASTN, this will > >>>> > >>be > >> > >>>>SONET based GMPLS signalling. > >>>> > >>>> SONET SONET (LSP Enc. Type = SONET, > >>>> | G-PID = one of POS*) > >>>> | | | | > >>>> technology v v v v > >>>>client A --- conversion ---- LSR A ------- LSR B ------ LSR C > >>>> > >>-------client B > >> > >>>> ^ device > >>>> | \-------------------------------/ > >>>> | ASTN > >>>> FiberChannel > >>>> (LSP Enc. Type = FiberChannel, > >>>> G-PID = FC-3) > >>>> > >>>>My question is that in the above instance, the LSP established between > >>>>client A and client B will have an Encoding Type of FiberChannel from > >>>> > >>client > >> > >>>>A's perspective, and of type SONET from client B's perspective. How do > >>>> > >>the > >> > >>>>OSPF-TE/ISIS-TE extensions handle the above case?" > >>>> > >>>I have even simpler question - how would you carry IP packets over such > >>>an LSP, given that client A is going to encapsulate IP into (FC Network > >>>Header + LLC/SNAP Header) (see rfc2625), while client B would expect > >>>IP packets to be carried over PPP ? In other words, where in your picture > >>>is the device that converts (FC Network Header + LLC/SNAP) into the > >>>encapsulation used by PPP ? > >>> > >>>Yakov. > >>> > > > > -- > > Eric Gray (mailto:eric.gray@sandburst.com) > > http://www.mindspring.com/~ewgray > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Nov 2001 05:38:17 -0800 Cc: Heiles Juergen , ccamp@ops.ietf.org Message-ID: <3BE7E772.56631898@lucent.com> Date: Tue, 06 Nov 2001 14:36:50 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: Heiles Juergen , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------35129A361318C4F5E5ACA09F" This is a multi-part message in MIME format. --------------35129A361318C4F5E5ACA09F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, Juergen's example 1 shows (as far as I understand) two ports on a larger ODU cross connect equipment. Both ports connect to the ODU fabric. Both ports are part of one ODU LINK; this ODU LINK contains 8 ODU1 Link Connections. The upper port maps the 4 ODU1 signals into 4 OTU1 signals. Then the 4 OTU1 signals are mapped into OCh signals and then multiplexed into the OTM-4.1 signal. The lower port multiplexes the 4 ODU1 signals into an ODU2 signal. The ODU2 signal is mapped into an OTU2 signal and then this OTU2 signal is output as an OTM-0.2 signal. All 8 ODU1 ports on the ODU fabric are equal from a routing perspective. So all 8 ODU1 ports at the ODU fabric are endpoints of ODU1 link connections. They should be represented in the same manner. I.e. they are all "G.709 ODU1" types. "G.709 OCh" is not relevant here (it is not within the scope of the ODU1 layer). Within the OCh layer network, there is an OCh LINK with 5 OCh link connections. Those OCh link connection carry OCh Permanent Connections (PC); i.e. OCh signals in this example are non-switched ones. Another reason why there is no OCh related signalling present. ---- Example 2 shows an example of the serial compound link we addressed before. The non-GMPLS/ASON node is totally irrelevant... there is an ODU link with 4 ODU1 (serial compound) link connections between nodes A and C. These link connections are to be identified by "G.709 ODU1" type. Simple and straigthforward... works always... :-) Regards, Maarten Dimitri Papadimitriou wrote: > > Juergen, see inline... > > Heiles Juergen wrote: > > > > Following the discussion on the Switching Type and looking on the proposed G.709 extensions for GMPLS I would like to get some feedback on the examples shown below. > > How to handle the examples concerning label request and returned label is important for my understanding of GMPLS. > > The examples are based on G.709 ODUs. A ODU can be transported via WDM systems or using TDM in a higher bit rate ODU. So we can have a mixture of both methods. > > > > Juergen > > > > Example 1: > > > > Two network elements A and B with ODU1 cross-connect are interconnected by two types of signals. > > - a four channel WDM OTM-4.1 interface with 4 optical channels each carrying an OTU1/ODU1 > > - a single channel OTM-1.2 with one optical channel carrying a OTU2/ODU2 and 4 ODU1 multiplexed into the ODU2. > > > > ----------------- ---------------- > > NE A + + NE B > > + + > > ODU1 ----- + + ----- ODU1 > > 1 o---+ + + OTM-4.1 + + +---o 1 > > 2 o---+ w + + 4xOCh with OTU1/ODU1 + + W +---o 2 > > + D +--------------------------------+ D + > > 3 o---+ M + + + + M +---o 3 > > 4 o---+ + + + + +---o 4 > > ----- + + ----- > > + + > > ODU1 ----- + + ----- ODU1 > > 5 o---+ + + OTM-0.2 + + +---o 5 > > 6 o---+ T + + 1xOCh with OTU2/ODU2 + + T +---o 6 > > + D +--------------------------------+ D + > > 7 o---+ M + + with 4 ODU1 + + M +---o 7 > > 8 o---+ + + + + +---o 8 > > ----- + + ----- > > + + > > ----------------- ----------------- > > > > Now setting up a ODU1 connection between A and B. 8 ODU1 connections are available, 4 using WDM technology and 4 using TDM technology. > > For the connection itself I don't care which of the 8 is used and I don't care about the specific technology. > > How does the label request from NE a to NE B look like? > > - the LSP encoding type is "G.709 digital path layer" > > - the signal type is ODU1 > > - but what is the switching type "TDM" or "Lambda"? Both are available. > > Both entities aren't ODU1 switches ? i think you have indicate in the > picture here "the interface multiplexing" capabilities not the switching > ones. > > So I guess that these devices are both ODU1 switches. Therefore, if > the switching type is used (notice that it is not necessary here since > there is only one switching capability assigned to the "end of the > link") the switching will be TDM > > The differences comes from the Encoding type in the first case > (upper link) it will be G.709 OCh (WDM interface) in the second > case G.709 ODUk (TDM interface) > > > Furthermore what kind of label is returned by NE B to NE A? > > - for ODU 5 to 8 a "G.709 digital path layer label" with signal type ODU1 and a indication of the time slot within the ODU2 > > - but how about ODU1 to 4, a G.709 OCh signal type with the indication of the wavelength is not correct. > > or is each ODU 1 to 4 seen as individual link? > > In such a case (for the OTM4.1) each of the OCh will have a dedicate ID > that will be included within the request: setup of an ODU1 LSP > - LSP encoding type: G.709 digital path layer > - signal type: ODU1 > - switching type: "TDM" (not necessary) > - If_Index: 1 (for instance to indicate the first optical channel) > > > Example 2: > > > > NE A and NE C that provide ODU1 cross-connections are interconnected via NE B that is not GMPLS aware and that performs a conversion between WDM and TDM multiplexing. > > - between NE A and NE B a four channel WDM OTM-4.1 signal is used with 4 optical channels, each carrying a OTU1/ODU1. > > - between NE B and NE C a single channel OTM-0.2 signal is used with one optical channel carrying a OTU2/ODU2 with 4 ODU1 multiplexed into the ODU2. > > > > ------------- ---------------- ------------- > > NE A + + NE B + + NE C > > + + ODU1 + + > > ODU1 ----- + + ----- ----- + + ----- ODU1 > > 1 o--+ + + OTM-4.1 + + +--+ + + OTM-0.2 + + +--o 1 > > 2 o--+ w + + 4xOCh with + + W +--+ T + + 1xOCh with + + T +--o 2 > > + D +----------------+ D + + D +-----------------+ D + > > 3 o--+ M + + OTU1/ODU1 + + M +--+ M + + OTU1/ODU1 + + M +--o 3 > > 4 o--+ + + + + +--+ + + with 4 ODU1 + + +--o 4 > > ----- + + ----- ----- + + ----- > > + + + + > > ------------- ---------------- ------------- > > > > Again what is the switching type of the label request from NE A to NE C (TDM or Lambda)? > > And what is the returned label from NE C to NE A? > > Just to be sure in the above example i guess you ment for the second > link 1x0Ch with OTU2/ODU2 with 4 ODU1 since having TDM > > Since device A, B and C are all ODU1 switches the switching will be > always > TDM (if this field is used cfr. the remark indicated here above). > Remember > here that TDM is a shortcut to specify switching of all the digital > switching > layers supporting TDM capabilities (this includes VC-3/VC-4/ODUk/etc.) > > The relative complexity in the second example shown here above arise > more from > the interconnection of GMPLS to non-GMPLS capable devices (in addition > performing > conversion of the encoding type) rather than the "switching type" issue. > > It reminds me Zhi's discussion on GMPLS to non-GMPLS communication here > addind that your transmission competences it gives a very nice example. > > Briefly LSR A sees ODU mapping while C sees ODU multiplexing such that > building the label association is needed as additional mechanisms here. > > - dimitri. --------------35129A361318C4F5E5ACA09F 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 --------------35129A361318C4F5E5ACA09F-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Nov 2001 05:03:24 -0800 Cc: Yakov Rekhter , ccamp@ops.ietf.org Message-ID: <3BE7DF0A.E2B90B53@lucent.com> Date: Tue, 06 Nov 2001 14:00:58 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Ewart Tempest Original-CC: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------2F0C8F0AAAAA2D7DF6D35F68" This is a multi-part message in MIME format. --------------2F0C8F0AAAAA2D7DF6D35F68 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ewart, Yakov, Let's address Ewart's example by means of a layer network model... once this model is designed, the answers are normally just there... (see also the powerpoint file at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/ASON/ewart_example.ppt ) Client A and Client B equipment have an IP layer network with an IP connection function (i.e. they are routers). Client A equipment has a physical interface port of type FiberChannel (FC), Client B equipment has a physical interface port of type STM-N/OC-N (e.g. STM-16/OC-48). The Technology Conversion Device (TCD) has on one side a FC port and on the other side a STM-N/OC-N port (e.g. STM-1). Between the two ports is an IP connection function; i.e. the TCD operates at the IP layer network and forwards IP packets from a FC port to a STM-N port. The mapping of IP signals in the STM-N port is via POS (in this example) into a VC-4 signal and then the VC-4 signal is mapped into a STM-1. Note - I assumed thata TCD is doing "FC into STM-1 conversion". Is this what does boxes are doing? The STM-1 signal is terminated in the next equipment (LSR A), which I have assumed to be a SDH/SONET equipment. The VC-4 signal (carrying the IP stream) is forwarded to an egress STM-N port (connected to LSR B)... LSR B is not shown in the figure... Similarly, LSR B forwards the VC-4 signal to LSR C, where it is forwarded to client B equipment. Client B equipment terminates the STM-N signal, extracts the VC-4 signals and terminates the VC-4 signals. This makes the IP signals (i.e. the packet flows) available to the IP connection function. So Client A, TCD and CLient B operate at the IP layer network. The IP fabrics in these equipment are (to be) connected via IP links: Client A TCD client B | | | | ==== IP_link ==== ==== IP_link ==== ^ supported by VC-4 trail The IP LINK between TCD and client B equipment is (to be) supported by a VC-4 trail. The VC-4 trail is (to be) supported by VC-4 subnetwork connections (within the Fabrics) and VC-4 link connections (within VC-4 LINKs). All the above described the intended connectivity... but how can this be created in a switched network...? 3 cases are now to be considered: --------------------------------- 1) If the TCD doesn't belong to the provider's network, it is part of the USER domain. In such case, the USER must request a VC-4 connection through the provider's network (LSR A to LSR C), while the network just sees a VC-4 LINK at its UNI. The VC-4 connection request will result in the creation of the VC-4 trail between TCD and client B, and thus the set up of the IP LINK between these two equipment. 2) If the TCD is part of the provider's network, there is a fiber between the USER's client A and the PROVIDER's TCD equipment, which carries the FC signal. Both ends of the fiber terminate the FC signal, and make the IP signals available to the higher layers in the equipment. As such, the TCD terminates an IP LINK and deals with client A as an IP USER... The far end has a VC-4 LINK towards client B, and deals with client B as a VC4 USER... This mismatch can only be resolved by means of provisioning... i.e. via network management an IP LINK is created between TCD and Client B, by setting up a VC-4 connection between TCD and the VC-4 link between LSR C and client B. 3) If the TCD is part of the provider's network and the conversion is a fully transparent function... i.e. "in = out", then the USER equipment will get a kind of "VIRTUAL PORT". In such case, the TCD effectively is a box which replaces server layer X by server layer Y. As this is hard coded, client A equipment should learn over its signalling interface with the network that it has a VIRTUAL VC-4/POS PORT, rather than the physical FC port. If client A now needs to create a connection with client B equipment, it will request a VC-4 connection between its "virtual VC-4 port" and the "VC-4 link to client B". Assuming that we have to deal with either case 1 or 3, the connection request in both cases will be for a VC-4 connection. Regards, Maarten PS. the idea of a "virtual port" is new (at least for me); I need more examples to see if this is a generic solution... for now it allows me to solve this issue and I am having the feeling that I can use this solution in other cases I have come along in the past. --------------2F0C8F0AAAAA2D7DF6D35F68 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 --------------2F0C8F0AAAAA2D7DF6D35F68-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 22:34:25 -0800 Message-ID: <3BE783B1.EA089BA7@alcatel.be> Date: Tue, 06 Nov 2001 07:31:13 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: Heiles Juergen CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------8C1B0640D3720417C7713748" This is a multi-part message in MIME format. --------------8C1B0640D3720417C7713748 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen, see inline... Heiles Juergen wrote: > > Following the discussion on the Switching Type and looking on the proposed G.709 extensions for GMPLS I would like to get some feedback on the examples shown below. > How to handle the examples concerning label request and returned label is important for my understanding of GMPLS. > The examples are based on G.709 ODUs. A ODU can be transported via WDM systems or using TDM in a higher bit rate ODU. So we can have a mixture of both methods. > > Juergen > > Example 1: > > Two network elements A and B with ODU1 cross-connect are interconnected by two types of signals. > - a four channel WDM OTM-4.1 interface with 4 optical channels each carrying an OTU1/ODU1 > - a single channel OTM-1.2 with one optical channel carrying a OTU2/ODU2 and 4 ODU1 multiplexed into the ODU2. > > ----------------- ---------------- > NE A + + NE B > + + > ODU1 ----- + + ----- ODU1 > 1 o---+ + + OTM-4.1 + + +---o 1 > 2 o---+ w + + 4xOCh with OTU1/ODU1 + + W +---o 2 > + D +--------------------------------+ D + > 3 o---+ M + + + + M +---o 3 > 4 o---+ + + + + +---o 4 > ----- + + ----- > + + > ODU1 ----- + + ----- ODU1 > 5 o---+ + + OTM-0.2 + + +---o 5 > 6 o---+ T + + 1xOCh with OTU2/ODU2 + + T +---o 6 > + D +--------------------------------+ D + > 7 o---+ M + + with 4 ODU1 + + M +---o 7 > 8 o---+ + + + + +---o 8 > ----- + + ----- > + + > ----------------- ----------------- > > Now setting up a ODU1 connection between A and B. 8 ODU1 connections are available, 4 using WDM technology and 4 using TDM technology. > For the connection itself I don't care which of the 8 is used and I don't care about the specific technology. > How does the label request from NE a to NE B look like? > - the LSP encoding type is "G.709 digital path layer" > - the signal type is ODU1 > - but what is the switching type "TDM" or "Lambda"? Both are available. Both entities aren't ODU1 switches ? i think you have indicate in the picture here "the interface multiplexing" capabilities not the switching ones. So I guess that these devices are both ODU1 switches. Therefore, if the switching type is used (notice that it is not necessary here since there is only one switching capability assigned to the "end of the link") the switching will be TDM The differences comes from the Encoding type in the first case (upper link) it will be G.709 OCh (WDM interface) in the second case G.709 ODUk (TDM interface) > Furthermore what kind of label is returned by NE B to NE A? > - for ODU 5 to 8 a "G.709 digital path layer label" with signal type ODU1 and a indication of the time slot within the ODU2 > - but how about ODU1 to 4, a G.709 OCh signal type with the indication of the wavelength is not correct. > or is each ODU 1 to 4 seen as individual link? In such a case (for the OTM4.1) each of the OCh will have a dedicate ID that will be included within the request: setup of an ODU1 LSP - LSP encoding type: G.709 digital path layer - signal type: ODU1 - switching type: "TDM" (not necessary) - If_Index: 1 (for instance to indicate the first optical channel) > Example 2: > > NE A and NE C that provide ODU1 cross-connections are interconnected via NE B that is not GMPLS aware and that performs a conversion between WDM and TDM multiplexing. > - between NE A and NE B a four channel WDM OTM-4.1 signal is used with 4 optical channels, each carrying a OTU1/ODU1. > - between NE B and NE C a single channel OTM-0.2 signal is used with one optical channel carrying a OTU2/ODU2 with 4 ODU1 multiplexed into the ODU2. > > ------------- ---------------- ------------- > NE A + + NE B + + NE C > + + ODU1 + + > ODU1 ----- + + ----- ----- + + ----- ODU1 > 1 o--+ + + OTM-4.1 + + +--+ + + OTM-0.2 + + +--o 1 > 2 o--+ w + + 4xOCh with + + W +--+ T + + 1xOCh with + + T +--o 2 > + D +----------------+ D + + D +-----------------+ D + > 3 o--+ M + + OTU1/ODU1 + + M +--+ M + + OTU1/ODU1 + + M +--o 3 > 4 o--+ + + + + +--+ + + with 4 ODU1 + + +--o 4 > ----- + + ----- ----- + + ----- > + + + + > ------------- ---------------- ------------- > > Again what is the switching type of the label request from NE A to NE C (TDM or Lambda)? > And what is the returned label from NE C to NE A? Just to be sure in the above example i guess you ment for the second link 1x0Ch with OTU2/ODU2 with 4 ODU1 since having TDM Since device A, B and C are all ODU1 switches the switching will be always TDM (if this field is used cfr. the remark indicated here above). Remember here that TDM is a shortcut to specify switching of all the digital switching layers supporting TDM capabilities (this includes VC-3/VC-4/ODUk/etc.) The relative complexity in the second example shown here above arise more from the interconnection of GMPLS to non-GMPLS capable devices (in addition performing conversion of the encoding type) rather than the "switching type" issue. It reminds me Zhi's discussion on GMPLS to non-GMPLS communication here addind that your transmission competences it gives a very nice example. Briefly LSR A sees ODU mapping while C sees ODU multiplexing such that building the label association is needed as additional mechanisms here. - dimitri. --------------8C1B0640D3720417C7713748 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------8C1B0640D3720417C7713748-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 20:41:56 -0800 Message-ID: <3BE5D11C.F879E99A@nayna.com> Date: Sun, 04 Nov 2001 15:37:00 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Maarten Vissers CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------1D73D4B5887498FF00E0EC09" This is a multi-part message in MIME format. --------------1D73D4B5887498FF00E0EC09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Maarten: Thank you for the reply. Some comments in line. Maarten Vissers wrote: > Sudheer, > > See in-line... > > Sudheer Dharanikota wrote: > > > > Hi Maarten: > > > > Following ASON model... I have noticed the assumption that a set of > > access groups will form a subnet if and only if they at at the same > > layer. With this in mind I have few comments below... > > > > Maarten Vissers wrote: > > > > > In a layered network approach (e.g. ASON), the switching type is obsolete... the > > > routing is performed within a single layer network, using the links (ITU-T term) > > > that are available in that layer network. > > > > > > > What do you mean switching type is obsolete? Does this mean you do not consider > > it in G.7713 (DCM document)? > > I mean the switching type is not needed. > > G.7713 does not have a "switching type" parameter included. This information is > implicitly present; each message is within the scope of a particular layer > network. > I agree that G.7713 does not consider "switching type". There are many differences between ASON model and GMPLS model here. Some of them may be "assertions" because of my view on the trend. I may be wrong. 1. For example your concept of layer and GMPLS concept of layer are different. ITU considers sub-layers as routable layers. IETF on the other hand considers OSI 7 layers as routable layers :-) 2. GMPLS assumes a single control plane for all types of layers where as ASON model assumes control layer independence is possible for different layers. 3. ASON tries to hide or make the client and server layer information independent of each other. GMPLS on the otherhand leaves this interaction flexible either through "Forwarding Adjacencies" and/or using "switching type". Sorry if I am reopening some of the ITU decisions here.. but it is possible to achieve whatever you would like to achieve with layer independence in ASON is a subset (in my opinion) of what GMPLS can do. > > > > > > > > > >From a layer network's perspective, nodes have just a single switching > > > capability (i.e. of that layer network)... nodes who do not have that switching > > > capabiltiy are invisible... and nodes with this and other switching capabilities > > > will only be presented with this layer network's switching capability; the other > > > switching capabilities are invisible. > > > > > > > Does this mean a port (to be precise an interface - IETF terminology) on a node > > with multiple switching capabilities (reconfigurable adaptation functions :-)) will > > be part of multiple subnetworks? > > Such port will/may be part of: > > - multiple layer networks; e.g. a STM-N port supporting VC-3, VC-4 and VC-4-4c > is part of the VC-3 layer network, the VC-4 layer network and the VC-4-4c layer > network. > To reduce complexity, it is possible to develop one protocol carrying the > messages for all HOVC/STS layer networks. Then there will be a 1-to-1 relation > between port and protocol. We have to address this in the coming period when > working on the protocol specific implementation specifications. > THis is the approach taken by GMPLS. 1 port 1 protocol. This can be achieved through switching type. Let me qualify my statement... 1. When there is not adoptation need to be done.... If the customre always wants to take only GigE ports and some of the intermediate devices support an adoptation of GigE <-> SONET then using "switching type" one can decide the correct path and encapsulation before establishing the path. This is a major achiecvement in propagating "multiple switching types" (in my opinion). Here I am probably rephrasing what Yakov and John have already mentioned. 2. In cases where adoptation need to be performed (either due to non-availability of an encapsulation or an intentional need of an encapsulation adoptation)... This is the case you folks eloquently communicated in the last few days. In this case we still need "switching type" to select the path and some additional information to allow changing of encapsulation or extension to the path vector to impose/signal the encapsulation adoptation at the intermediate nodes. Remember one another way to achieve the functionality is using forwarding adjacencies. > > - multiple subnetworks; e.g. a STM-64 port with 64 VC-4 connection points > could have all 64 VC-4 CPs located within one VC-4 subnetwork, or > could have 32 VC-4 CPs in subnetwork 1, 10 in subnetwork 2, 7 in subnetwork 3, > etc. > This latter is the case when VC-4 VPNs are present... e.g. the first 32 VC-4 CPs > are allocated to the Switched Public Network subnetwork, 10 to the non-switched > subnetwork and the other VC-4 CPs are allocated to a number of VC-4 switched > VPNs. > IMHO, VPN is a different animal and has very little to do with the "switching type". Especially in the scenario you have mentioned. Regards, sudheer > > Note - If these VPNs are dedicated VPNs (i.e. VC-4 CPs are exclusively allocated > to one VPN), each VPN has its own dedicated Connection Controller (CC), Route > Controller (RC) and Link Resource Managers (LRM) components (refer to G.8080) as > well as its own dedicated links. > > Regards, > > Maarten > > > > > > > > > Perhaps a additional sentence should be added to clarify that the switching type > > > is obsolete for the case of a layered network approach. > > > > > > > I would not do this in such a hurry :-) > > > > Regards, > > > > sudheer > > > > > > > > Regards, > > > > > > Maarten > > > > > > Dimitri Papadimitriou wrote: > > > > > > > > Hi, > > > > > > > > We have two approaches either "traffic-parameters" are used > > > > (in SENDER_TSPEC) then i think the Switching Type capability > > > > is useless or they aren't then such field could be optionaly > > > > used when applicable (some examples are given in the routing > > > > document). > > > > > > > > Wouldn't be the right way to proceed by defining an "unknown" > > > > or "unspecified" value used when "traffic-parameters" are > > > > included within the Path Message and optional use the ones > > > > proposed in the current version of the specification when they > > > > aren't. This field is thus optional and MUST only be used when > > > > traffic parameters are not defined. I think this solves both > > > > approaches. > > > > > > > > I think that also some additional text is needed in order to > > > > clarify the semantic; the following one can be proposed (after > > > > having discussed with some individuals): > > > > "The Switching Type field is provided to allow nodes having > > > > multiple switching layer capabilities to indicate their > > > > preference. This field should only be used to indicate the > > > > link switching preference but not end-to-end switching > > > > preference". > > > > > > > > Notice that some proposal concerning the applicability scope > > > > have been proposed but never really committed within the I-D. > > > > > > > > Cheers, > > > > - dimitri. > > > > > > > > Zhi-Wei Lin wrote: > > > > > > > > > > Hi John, > > > > > > > > > > > The section you mentioned, from what I can tell, is an example list > > > > > > of some possible combinations of different equipment functions. I see > > > > > > them as examples. But as I said, from routing perspective, it may make > > > > > > sense but not signaling. What you've pointed out is the routing document... > > > > > > From signaling perspective, if I removed the switching capability > > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > > > > possible combinations of switching capabilities supported on a link, an > > > > > > intermediate node can deduce, from other fields in the Path message, what > > > > > > switching capability is desired. > > > > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > > different switching capabilities on each side and the possible > > > > > connections and then demonstrate that what switching capability is > > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > > encoding type says and the sender_tspec says is what the switching type > > > > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens the door > > > > > > for the possibility where somewhere within my network I might change the > > > > > > switching type in order to satisfy a request (because the switching type > > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > > > > and it goes through an all-optical network that can provide OCh1 (2.5G > > > > > service). In the SONET network it switches the STS-48c layer, while in > > > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > > > > connection, where one part of network may work PDH-based and switching > > > > > E1 while another part may be SDH-based and switching VC-12, but the > > > > > connection or service is essentially the same. They're not really > > > > > client-server layers but similar layers from different technologies... > > > > > > > > > > > I think it does make sense. I think you have to assume that within > > > > > > the switched transport network there will be many kinds of interfaces > > > > > > connecting to the transport network. If you can't offer this capability, > > > > > > then essentially what you've done is segment the transport network into > > > > > > sub-networks based on what interfaces they have and only the like-type > > > > > > interfaces can connect to each other. If you look at the IP world, you > > > > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > > > > together and talking to each other without a problem. This is capability > > > > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > > > > reason to restrict this). What really matters is that the service is > > > > > > delivered. Granted there will be some inefficiencies in this, but that's > > > > > > really a policy decision whether users are willing to accept this type > > > > > > of connection. > > > > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > > > > you were describing in your previous example was an LSP, one end of which > > > > > > was > > > > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with operational > > > > > experience and have some experience with service provisioning whether > > > > > having one end with Ethernet and another end with OC-48 sounds like a > > > > > configuration that makes sense? > > > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > > essentially what you have is multiple switched networks, each serving > > > > > one particular type of customer interface, i.e., a switched network for > > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > > > Is this one of those "violent agreements" where we're concentrating on > > > > > two different levels but saying the same thing? --------------1D73D4B5887498FF00E0EC09 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" begin:vcard n:Dharanikota;Sudheer x-mozilla-html:FALSE url:http://www.cs.odu.edu/~sudheer org:Nayna Networks Inc. version:2.1 email;internet:sudheer@nayna.com title:Network Architect adr;quoted-printable:;;481 Sycamore Drive=0D=0A;Milpitas;CA;95035;USA fn:Sudheer Dharanikota end:vcard --------------1D73D4B5887498FF00E0EC09-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 16:23:44 -0800 Message-ID: <3BE72C36.5050605@lucent.com> Date: Mon, 05 Nov 2001 19:17:58 -0500 From: Zhi-Wei Lin Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Eric Gray CC: John Drake , Jonathan.Sadler@tellabs.com, Yakov Rekhter , Ewart Tempest , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi John, Eric, I'm not sure if we need to include adaptation function in GMPLS. My understanding of the adaptation function is that this is a transport level capability for "adapting" or mapping the signal. From the GMPLS perspective, there is some local action that takes place (the magic you mentioned?) to adapt the signal, but the signaling impact is simply changing the encoding type and/or GPID and/or the SONET/SDH SENDER_TSPEC to another value based on the local adaptation (or no change at all)...depends on what adaptation you perform... I think this has gone beyond switching type discussion...or am I wrong? Zhi Eric Gray wrote: > John, > > The simplest such proposal is for 'adaptation functions' that are logically > distinct from protocol entities to be disallowed. If the adaptation function > is required to participate in signaling (either as a direct participant, or through > proxy), then a lot of the complexity disappears. > > You wrote: > > >>"As mentioned by Zhi, one of the OXCs in the path would >>need to do the adaptation from GigE to Ethetnet over GFP" >> >>There is a considerable amount of magic contained in the >>above sentence. I think it's well understood by everyone >>what needs to be done. The more interesting question is >>how, and a proposal for how adaptation functions should be >>incorporated into GMPLS would be timely. >> >>-----Original Message----- >>From: Jonathan Sadler [mailto:Jonathan.Sadler@tellabs.com] >>Sent: Friday, November 02, 2001 3:03 PM >>To: Yakov Rekhter >>Cc: Ewart Tempest; ccamp@ops.ietf.org >>Subject: Re: Moving right along ... Switching Type >> >>Yakov, et al - >> >>The OC-48 port could be terminating Ethernet over GFP, in which case PPP >>is not in use. As mentioned by Zhi, one of the OXCs in the path would >>need to do the adaptation from GigE to Ethetnet over GFP. Further, >>since GigE is speed wise slower than OC-48, such a configuration would >>not generate any service degradation... >> >>Jonathan Sadler >> >>Yakov Rekhter wrote: >> >>>Ewart, >>> >>> >>>>See embedded comment below. >>>> >>>response in-line... >>> >>> >>>>Ewart >>>> >>>> >>>>>-----Original Message----- >>>>>From: Yakov Rekhter [mailto:yakov@juniper.net] >>>>>Sent: Wednesday, October 31, 2001 8:19 PM >>>>>To: Zhi-Wei Lin >>>>>Cc: ccamp@ops.ietf.org >>>>>Subject: Re: Moving right along ... Switching Type >>>>> >>>>> >>>>>Zhi-Wei, >>>>> >>>>> >>>>>>Maybe this is one where we need to ask individuals with >>>>>> >>>>>operational >>>>> >>>>>>experience and have some experience with service >>>>>> >>>>>provisioning whether >>>>> >>>>>>having one end with Ethernet and another end with OC-48 >>>>>> >>>>>sounds like a >>>>> >>>>>>configuration that makes sense? >>>>>> >>>>>Let me see if I understand your proposal. Consider the following >>>>>example: >>>>> >>>>> R1---OXC1---OXC2----R2 >>>>> >>>>>where the TE interface on R1 is a collection of GigE ports, and the TE >>>>>interface on R2 is a collection of OC-48 ports. Are you saying that >>>>>establishing an LSP between R1 to R2 makes sense ? >>>>> >>>>[EWART]: Correct. OXC1 may be capable of performing signal conversion >>>> >>or, >> >>>>more likely, there may be some intermediate non-GMPLS device between R1 >>>> >>& >> >>>>OXC1 that performs such a conversion (refer to e-mail entitled "Query on >>>>Encoding field wrt presence of technology conversion devices - >>>>OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and >>>> >>which, >> >>>>for the benefit of those that were not, I have repeated below) because >>>> >>the >> >>>>OXC has no GigE interface port. >>>> >>>>"Within the GMPLS related routing documents >>>>(draft-ietf-ccamp-ospf-gmpls-extensions & >>>> >>draft-ietf-isis-gmpls-extensions), >> >>>>there is an Encoding field contained in the Interface Switching >>>> >>Capability >> >>>>Descriptor sub-TLV of the Link/IS Reachability TLV. >>>> >>>In case you missed it, I'll repeat what I said before: >>> >>> Please note that R1 (a router) uses Ethernet encapsulation when >>> sending data on the GigE port. Please also note that R2 (also >>> a router) expects to have HDLC encapsulation when receiving data >>> on its OC-48 port. As Maarten said in his e-mail, " 1GE port >>> on R1 and OC-48 port on R2 "don't speak the same language". >>> >>> >>>>My request for GMPLS to support FiberChannel is driven by a need for >>>> >>clients >> >>>>to be able to attach to the ASTN using FiberChannel. However, the ASTN >>>>devices at the edge (e.g. LSR A in the diagram below) may not be >>>> >>equipped >> >>>>with FiberChannel ports. In this situation, the FiberChannel coming from >>>> >>the >> >>>>client device (client A in the diagram below) has to pass through a >>>>technology conversion device that maps the FiberChannel to something >>>> >>which >> >>>>LSR A is capable of supporting. For example, there are devices readily >>>>available on the market today that map FiberChannel to POS. Client A is >>>>opaque to this conversion being done - when client A wants to establish >>>> >>an >> >>>>LSP on the FiberChannel link, it does so using FiberChannel based GMPLS >>>>signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the >>>>signalling is handled by LSR A, and not by the non-GMPLS savvy >>>> >>technology >> >>>>conversion device. Similarly, any signalling performed by LSR A to >>>> >>client A >> >>>>wrt this same link will use FiberChannel based GMPLS signalling, even >>>> >>though >> >>>>the link which manifests itself on a FiberChannel port on client A >>>> >>manifests >> >>>>itself on a SONET port on LSR A. However, in terms of the GMPLS >>>> >>signalling >> >>>>that LSR A propagates downstream, within a SONET based ASTN, this will >>>> >>be >> >>>>SONET based GMPLS signalling. >>>> >>>> SONET SONET (LSP Enc. Type = SONET, >>>> | G-PID = one of POS*) >>>> | | | | >>>> technology v v v v >>>>client A --- conversion ---- LSR A ------- LSR B ------ LSR C >>>> >>-------client B >> >>>> ^ device >>>> | \-------------------------------/ >>>> | ASTN >>>> FiberChannel >>>> (LSP Enc. Type = FiberChannel, >>>> G-PID = FC-3) >>>> >>>>My question is that in the above instance, the LSP established between >>>>client A and client B will have an Encoding Type of FiberChannel from >>>> >>client >> >>>>A's perspective, and of type SONET from client B's perspective. How do >>>> >>the >> >>>>OSPF-TE/ISIS-TE extensions handle the above case?" >>>> >>>I have even simpler question - how would you carry IP packets over such >>>an LSP, given that client A is going to encapsulate IP into (FC Network >>>Header + LLC/SNAP Header) (see rfc2625), while client B would expect >>>IP packets to be carried over PPP ? In other words, where in your picture >>>is the device that converts (FC Network Header + LLC/SNAP) into the >>>encapsulation used by PPP ? >>> >>>Yakov. >>> > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 15:42:05 -0800 Date: Mon, 5 Nov 2001 18:40:44 -0500 From: Vijay Gill To: cc: Subject: Agenda time for CCAMP (Salt Lake) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII well, looks like it is that time for the agenda formation again. Please send requests to me and kireeti. It would be useful if the presentations could be kept to differences between approaches, rather than presenting what should be an I-D. thanks /vijay Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 13:04:54 -0800 Message-ID: From: Heiles Juergen To: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Mon, 5 Nov 2001 21:57:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Following the discussion on the Switching Type and looking on the proposed G.709 extensions for GMPLS I would like to get some feedback on the examples shown below. How to handle the examples concerning label request and returned label is important for my understanding of GMPLS. The examples are based on G.709 ODUs. A ODU can be transported via WDM systems or using TDM in a higher bit rate ODU. So we can have a mixture of both methods. Juergen Example 1: Two network elements A and B with ODU1 cross-connect are interconnected by two types of signals. - a four channel WDM OTM-4.1 interface with 4 optical channels each carrying an OTU1/ODU1 - a single channel OTM-1.2 with one optical channel carrying a OTU2/ODU2 and 4 ODU1 multiplexed into the ODU2. ----------------- ---------------- NE A + + NE B + + ODU1 ----- + + ----- ODU1 1 o---+ + + OTM-4.1 + + +---o 1 2 o---+ w + + 4xOCh with OTU1/ODU1 + + W +---o 2 + D +--------------------------------+ D + 3 o---+ M + + + + M +---o 3 4 o---+ + + + + +---o 4 ----- + + ----- + + ODU1 ----- + + ----- ODU1 5 o---+ + + OTM-0.2 + + +---o 5 6 o---+ T + + 1xOCh with OTU2/ODU2 + + T +---o 6 + D +--------------------------------+ D + 7 o---+ M + + with 4 ODU1 + + M +---o 7 8 o---+ + + + + +---o 8 ----- + + ----- + + ----------------- ----------------- Now setting up a ODU1 connection between A and B. 8 ODU1 connections are available, 4 using WDM technology and 4 using TDM technology. For the connection itself I don't care which of the 8 is used and I don't care about the specific technology. How does the label request from NE a to NE B look like? - the LSP encoding type is "G.709 digital path layer" - the signal type is ODU1 - but what is the switching type "TDM" or "Lambda"? Both are available. Furthermore what kind of label is returned by NE B to NE A? - for ODU 5 to 8 a "G.709 digital path layer label" with signal type ODU1 and a indication of the time slot within the ODU2 - but how about ODU1 to 4, a G.709 OCh signal type with the indication of the wavelength is not correct. or is each ODU 1 to 4 seen as individual link? Example 2: NE A and NE C that provide ODU1 cross-connections are interconnected via NE B that is not GMPLS aware and that performs a conversion between WDM and TDM multiplexing. - between NE A and NE B a four channel WDM OTM-4.1 signal is used with 4 optical channels, each carrying a OTU1/ODU1. - between NE B and NE C a single channel OTM-0.2 signal is used with one optical channel carrying a OTU2/ODU2 with 4 ODU1 multiplexed into the ODU2. ------------- ---------------- ------------- NE A + + NE B + + NE C + + ODU1 + + ODU1 ----- + + ----- ----- + + ----- ODU1 1 o--+ + + OTM-4.1 + + +--+ + + OTM-0.2 + + +--o 1 2 o--+ w + + 4xOCh with + + W +--+ T + + 1xOCh with + + T +--o 2 + D +----------------+ D + + D +-----------------+ D + 3 o--+ M + + OTU1/ODU1 + + M +--+ M + + OTU1/ODU1 + + M +--o 3 4 o--+ + + + + +--+ + + with 4 ODU1 + + +--o 4 ----- + + ----- ----- + + ----- + + + + ------------- ---------------- ------------- Again what is the switching type of the label request from NE A to NE C (TDM or Lambda)? And what is the returned label from NE C to NE A? Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 12:57:05 -0800 Message-ID: From: Heiles Juergen To: "'ccamp@ops.ietf.org'" Cc: "'Mannie, Eric'" Subject: SDH/SONET label Date: Mon, 5 Nov 2001 21:48:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" All, let me start a final attempt on the label issue, even so we already spent a lot of time on it with out progress. Juergen 1. The proposal is to use the same SUKLM coding for SDH and SONET. The reason is that SDH and SONET have the same multiplex structure with the exception that SONET doesn't support sub-structured STS-3c-SPEs and SDH doesn't support VT-3. A SDH VC-4 and a SONET STS-3c-SPE are identical signals, the same applies to SDH VC-11 in a higher order VC-3 and SONET VT-1.5 in a STS-1-SPE. So why should we use different SUKLM coding for identical signals as it is the case with the current definition. Using different codings means that we always have to check and test both codings when we introduce new features. It might even happen that we can use a new feature only for one coding and not for the other due to the differences in coding. We should learn from the interwroking problems in the passt due to differences in SONET and SDH and try to avoid such differences. So the proposal has technical benefits in my view. It saves implementation and test efforts and problems in the future. 2. My concrete proposal was to use the SDH coding also for SONET by introducing a STS-3 group. T1.105 already defines this in section 10.1.1 "From the Standard OC-N Rates (table 1), it is observed that the rates above OC-1 are multiples of the OC-3 rate. Three STS-1 input signals shall be interleaved one byte at a time to form the STS-3 signal..... To form a higher level signal STS-N (N = 3M; M = 1,4,8,16,64), M STS-3s shall be interleaved one byte at a time....." Eric mentioned that he sees problems with the proposal in case of STS-X SPE forwarding adjacencies that are not multiples of 3 (X<>3N, e.g. STS-5 SPE) as they don't fill full STS-3 groups. However if this is the case the same problem already applies to the currently defined SDH higher order VC-3 coding. Eric mentioned further that it is not a big problem as it is possible to work with partial filled STS-3 groups. So not an issue in my view. 3. Eric mentioned that the existing definition is validate and he doesn't want to introduce late changes that force vendors to change their implementation. My proposal is not a new definition it uses the already defined and validated SDH coding for SONET. So if the SDH coding is validated my proposal works. Vendors just can take the SDH implementation and use if also for SONET. Furthermore what is the purpose of a last call if no changes can be introduced. The proposal to use the same coding is already on the table for over half a year. It was rejected/ignored without any reasonable arguments in my view. 4. Looking further on the current label definition I found two inconsistencies. First the STS-3c-SPE signal type is not considered. In the signal type definition it is state "A dedicated signal type is assigned to a SONET STS-3c SPE instead of coding it as a contiguous concatenation of three STS-1 SPEs. This is done in order to provide easy interworking between SONET and SDH signaling." The label definition mentions contiguous concatenation, but it is not clear about STS-3c-SPE as it is not coded as contiguous concatenation. The introduction of the STS-3 group now also indicates that if a STS-3 group is already occupied by one or more STS-1 SPE it can no longer be used by a STS-3c-SPE. This is in according to the T1.105 defnitions for a STS-3c "When STS-3c signals are multiplexed to a higher rate, each STS-3c shall be wholly contained within an STS-3 as shown in figure 40, Two-stage interleaving (i.e., occur only on tributary input boundaries 1-3, 4-6, 7-9, etc.)." Second the definition of the L value has a problem. It says " 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4 or STS-1 SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. " The second sentence says that it is not significant for unstructured STS-1 SPE while the third sentence says that L=1 has to be used for a unstructured STS-1 SPE. I repeat my proposal below with slight modifications due to the inconsistencies indicated above: The format of the label for SDH and/or SONET TDM-LSR link is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same signaling scheme is used in order to provide easy interworkign between SDH and SONET signaling. For the S field a STS-3 group,which corresponds with the SDH AUG-1 level is introduce. The U field indicates the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. When hierarchical SDH/SONET LSPs are used, an LSP with a given bandwidth can be used to tunnel lower order LSPs. The higher order SDH/SONET LSP behaves as a virtual link with a given bandwidth (e.g. VC-3), it may also be used as a Forwarding Adjacency. A lower order SDH/SONET LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is non-significant and is set to zero. For instance, a VC-3 LSP can be advertised as a forwarding adjacency. In that case the labels allocated between the two ends of that LSP (i.e. for that "link") will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3. 1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a AUG-1/STS-3 group or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4 indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 group. 3. K is only significant for VC-4/STS-3c and must be ignored for higher order VC-3/STS-1-SPE. For SDH it indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further subdivided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. For a SONET STS-3c-SPE it is fixed to K=1 as SONET doesn't support substructured STS-3c-SPE. 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4/STS-3c-SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 5. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, STS-3c-SPE, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further subdivided and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 SPE inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE inside the corresponding TUG-2/VT Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 1st VT-1.5 8 2nd VC-11 2nd VT-1.5 9 3rd VC-11 3rd VT-1.5 10 4th VC-11 4th VT-1.5 In case of contiguous concatenation, the label that is used is the lowest label of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant. For instance, when requesting an VC-4-16c the label is S>0, U=0, K=0, L=0, M=0. Examples of labels: Example 1: S>0, U=1, K=1, L=0, M=0 Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. Example 2: S>0, U=1, K>1, L=1, M=0 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Example 3: S>0, U>1, K=0, L=1, M=0 Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 4: S>0, U>1, K=0, L>1, M=1 Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 5: S>0, U>1, K=0, L>1, M=9 Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 6: S>0, U=1, K>1, L>1, M=5 Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of the Sth AUG-1. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 08:05:41 -0800 Message-ID: <3BE6B81B.A5A68362@sandburst.com> Date: Mon, 05 Nov 2001 11:02:35 -0500 From: Eric Gray MIME-Version: 1.0 To: John Drake Cc: Jonathan.Sadler@tellabs.com, Yakov Rekhter , Ewart Tempest , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, The simplest such proposal is for 'adaptation functions' that are logically distinct from protocol entities to be disallowed. If the adaptation function is required to participate in signaling (either as a direct participant, or through proxy), then a lot of the complexity disappears. You wrote: > "As mentioned by Zhi, one of the OXCs in the path would > need to do the adaptation from GigE to Ethetnet over GFP" > > There is a considerable amount of magic contained in the > above sentence. I think it's well understood by everyone > what needs to be done. The more interesting question is > how, and a proposal for how adaptation functions should be > incorporated into GMPLS would be timely. > > -----Original Message----- > From: Jonathan Sadler [mailto:Jonathan.Sadler@tellabs.com] > Sent: Friday, November 02, 2001 3:03 PM > To: Yakov Rekhter > Cc: Ewart Tempest; ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > Yakov, et al - > > The OC-48 port could be terminating Ethernet over GFP, in which case PPP > is not in use. As mentioned by Zhi, one of the OXCs in the path would > need to do the adaptation from GigE to Ethetnet over GFP. Further, > since GigE is speed wise slower than OC-48, such a configuration would > not generate any service degradation... > > Jonathan Sadler > > Yakov Rekhter wrote: > > > > Ewart, > > > > > See embedded comment below. > > > > response in-line... > > > > > > > > Ewart > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > > Sent: Wednesday, October 31, 2001 8:19 PM > > > > To: Zhi-Wei Lin > > > > Cc: ccamp@ops.ietf.org > > > > Subject: Re: Moving right along ... Switching Type > > > > > > > > > > > > Zhi-Wei, > > > > > > > > > Maybe this is one where we need to ask individuals with > > > > operational > > > > > experience and have some experience with service > > > > provisioning whether > > > > > having one end with Ethernet and another end with OC-48 > > > > sounds like a > > > > > configuration that makes sense? > > > > > > > > Let me see if I understand your proposal. Consider the following > > > > example: > > > > > > > > R1---OXC1---OXC2----R2 > > > > > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > > establishing an LSP between R1 to R2 makes sense ? > > > > > > [EWART]: Correct. OXC1 may be capable of performing signal conversion > or, > > > more likely, there may be some intermediate non-GMPLS device between R1 > & > > > OXC1 that performs such a conversion (refer to e-mail entitled "Query on > > > Encoding field wrt presence of technology conversion devices - > > > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and > which, > > > for the benefit of those that were not, I have repeated below) because > the > > > OXC has no GigE interface port. > > > > > > "Within the GMPLS related routing documents > > > (draft-ietf-ccamp-ospf-gmpls-extensions & > draft-ietf-isis-gmpls-extensions), > > > there is an Encoding field contained in the Interface Switching > Capability > > > Descriptor sub-TLV of the Link/IS Reachability TLV. > > > > In case you missed it, I'll repeat what I said before: > > > > Please note that R1 (a router) uses Ethernet encapsulation when > > sending data on the GigE port. Please also note that R2 (also > > a router) expects to have HDLC encapsulation when receiving data > > on its OC-48 port. As Maarten said in his e-mail, " 1GE port > > on R1 and OC-48 port on R2 "don't speak the same language". > > > > > My request for GMPLS to support FiberChannel is driven by a need for > clients > > > to be able to attach to the ASTN using FiberChannel. However, the ASTN > > > devices at the edge (e.g. LSR A in the diagram below) may not be > equipped > > > with FiberChannel ports. In this situation, the FiberChannel coming from > the > > > client device (client A in the diagram below) has to pass through a > > > technology conversion device that maps the FiberChannel to something > which > > > LSR A is capable of supporting. For example, there are devices readily > > > available on the market today that map FiberChannel to POS. Client A is > > > opaque to this conversion being done - when client A wants to establish > an > > > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > > > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > > > signalling is handled by LSR A, and not by the non-GMPLS savvy > technology > > > conversion device. Similarly, any signalling performed by LSR A to > client A > > > wrt this same link will use FiberChannel based GMPLS signalling, even > though > > > the link which manifests itself on a FiberChannel port on client A > manifests > > > itself on a SONET port on LSR A. However, in terms of the GMPLS > signalling > > > that LSR A propagates downstream, within a SONET based ASTN, this will > be > > > SONET based GMPLS signalling. > > > > > > SONET SONET (LSP Enc. Type = SONET, > > > | G-PID = one of POS*) > > > | | | | > > > technology v v v v > > > client A --- conversion ---- LSR A ------- LSR B ------ LSR C > -------client B > > > ^ device > > > | \-------------------------------/ > > > | ASTN > > > FiberChannel > > > (LSP Enc. Type = FiberChannel, > > > G-PID = FC-3) > > > > > > My question is that in the above instance, the LSP established between > > > client A and client B will have an Encoding Type of FiberChannel from > client > > > A's perspective, and of type SONET from client B's perspective. How do > the > > > OSPF-TE/ISIS-TE extensions handle the above case?" > > > > I have even simpler question - how would you carry IP packets over such > > an LSP, given that client A is going to encapsulate IP into (FC Network > > Header + LLC/SNAP Header) (see rfc2625), while client B would expect > > IP packets to be carried over PPP ? In other words, where in your picture > > is the device that converts (FC Network Header + LLC/SNAP) into the > > encapsulation used by PPP ? > > > > Yakov. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 05 Nov 2001 05:50:45 -0800 Message-ID: From: John Drake To: Jonathan.Sadler@tellabs.com, Yakov Rekhter Cc: Ewart Tempest , ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Mon, 5 Nov 2001 05:45:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" "As mentioned by Zhi, one of the OXCs in the path would need to do the adaptation from GigE to Ethetnet over GFP" There is a considerable amount of magic contained in the above sentence. I think it's well understood by everyone what needs to be done. The more interesting question is how, and a proposal for how adaptation functions should be incorporated into GMPLS would be timely. -----Original Message----- From: Jonathan Sadler [mailto:Jonathan.Sadler@tellabs.com] Sent: Friday, November 02, 2001 3:03 PM To: Yakov Rekhter Cc: Ewart Tempest; ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Yakov, et al - The OC-48 port could be terminating Ethernet over GFP, in which case PPP is not in use. As mentioned by Zhi, one of the OXCs in the path would need to do the adaptation from GigE to Ethetnet over GFP. Further, since GigE is speed wise slower than OC-48, such a configuration would not generate any service degradation... Jonathan Sadler Yakov Rekhter wrote: > > Ewart, > > > See embedded comment below. > > response in-line... > > > > > Ewart > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: Wednesday, October 31, 2001 8:19 PM > > > To: Zhi-Wei Lin > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... Switching Type > > > > > > > > > Zhi-Wei, > > > > > > > Maybe this is one where we need to ask individuals with > > > operational > > > > experience and have some experience with service > > > provisioning whether > > > > having one end with Ethernet and another end with OC-48 > > > sounds like a > > > > configuration that makes sense? > > > > > > Let me see if I understand your proposal. Consider the following > > > example: > > > > > > R1---OXC1---OXC2----R2 > > > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > establishing an LSP between R1 to R2 makes sense ? > > > > [EWART]: Correct. OXC1 may be capable of performing signal conversion or, > > more likely, there may be some intermediate non-GMPLS device between R1 & > > OXC1 that performs such a conversion (refer to e-mail entitled "Query on > > Encoding field wrt presence of technology conversion devices - > > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, > > for the benefit of those that were not, I have repeated below) because the > > OXC has no GigE interface port. > > > > "Within the GMPLS related routing documents > > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), > > there is an Encoding field contained in the Interface Switching Capability > > Descriptor sub-TLV of the Link/IS Reachability TLV. > > In case you missed it, I'll repeat what I said before: > > Please note that R1 (a router) uses Ethernet encapsulation when > sending data on the GigE port. Please also note that R2 (also > a router) expects to have HDLC encapsulation when receiving data > on its OC-48 port. As Maarten said in his e-mail, " 1GE port > on R1 and OC-48 port on R2 "don't speak the same language". > > > My request for GMPLS to support FiberChannel is driven by a need for clients > > to be able to attach to the ASTN using FiberChannel. However, the ASTN > > devices at the edge (e.g. LSR A in the diagram below) may not be equipped > > with FiberChannel ports. In this situation, the FiberChannel coming from the > > client device (client A in the diagram below) has to pass through a > > technology conversion device that maps the FiberChannel to something which > > LSR A is capable of supporting. For example, there are devices readily > > available on the market today that map FiberChannel to POS. Client A is > > opaque to this conversion being done - when client A wants to establish an > > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > > signalling is handled by LSR A, and not by the non-GMPLS savvy technology > > conversion device. Similarly, any signalling performed by LSR A to client A > > wrt this same link will use FiberChannel based GMPLS signalling, even though > > the link which manifests itself on a FiberChannel port on client A manifests > > itself on a SONET port on LSR A. However, in terms of the GMPLS signalling > > that LSR A propagates downstream, within a SONET based ASTN, this will be > > SONET based GMPLS signalling. > > > > SONET SONET (LSP Enc. Type = SONET, > > | G-PID = one of POS*) > > | | | | > > technology v v v v > > client A --- conversion ---- LSR A ------- LSR B ------ LSR C -------client B > > ^ device > > | \-------------------------------/ > > | ASTN > > FiberChannel > > (LSP Enc. Type = FiberChannel, > > G-PID = FC-3) > > > > My question is that in the above instance, the LSP established between > > client A and client B will have an Encoding Type of FiberChannel from client > > A's perspective, and of type SONET from client B's perspective. How do the > > OSPF-TE/ISIS-TE extensions handle the above case?" > > I have even simpler question - how would you carry IP packets over such > an LSP, given that client A is going to encapsulate IP into (FC Network > Header + LLC/SNAP Header) (see rfc2625), while client B would expect > IP packets to be carried over PPP ? In other words, where in your picture > is the device that converts (FC Network Header + LLC/SNAP) into the > encapsulation used by PPP ? > > Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 19:15:47 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA13601D3B9BC@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: Yakov Rekhter Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Fri, 2 Nov 2001 22:10:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16415.0A437B50" 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_01C16415.0A437B50 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Friday, November 02, 2001 1:49 PM > To: Tempest, Ewart [SKY:XW44:EXCH] > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > > Ewart, > > > See embedded comment below. > > response in-line... > > > > > Ewart > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: Wednesday, October 31, 2001 8:19 PM > > > To: Zhi-Wei Lin > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... Switching Type > > > > > > > > > Zhi-Wei, > > > > > > > Maybe this is one where we need to ask individuals with > > > operational > > > > experience and have some experience with service > > > provisioning whether > > > > having one end with Ethernet and another end with OC-48 > > > sounds like a > > > > configuration that makes sense? > > > > > > Let me see if I understand your proposal. Consider the following > > > example: > > > > > > R1---OXC1---OXC2----R2 > > > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > establishing an LSP between R1 to R2 makes sense ? > > > > [EWART]: Correct. OXC1 may be capable of performing signal conversion or, > > more likely, there may be some intermediate non-GMPLS device between R1 & > > OXC1 that performs such a conversion (refer to e-mail entitled "Query on > > Encoding field wrt presence of technology conversion devices - > > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, > > for the benefit of those that were not, I have repeated below) because the > > OXC has no GigE interface port. > > > > "Within the GMPLS related routing documents > > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), > > there is an Encoding field contained in the Interface Switching Capability > > Descriptor sub-TLV of the Link/IS Reachability TLV. > > In case you missed it, I'll repeat what I said before: > > Please note that R1 (a router) uses Ethernet encapsulation when > sending data on the GigE port. Please also note that R2 (also > a router) expects to have HDLC encapsulation when receiving data > on its OC-48 port. As Maarten said in his e-mail, " 1GE port > on R1 and OC-48 port on R2 "don't speak the same language". [EWART]: In the anology I mentioned above, OXC1 possesses a technology conversion function that, in this instance, strips off the layer 1 & 2 headers off each GigE packet, and maps the resulting IP packet, POS encoded onto SONET, changing the LSP encoding type and G-PID accordingly. This function could alternatively be performed by an intermediate (non-GMPLS) device. GMPLS does not currently factor in the presence of such devices, and it is unreasonable to assume that the LSP encoding type and G-PID should remain the same for the length of an LSP. > > > My request for GMPLS to support FiberChannel is driven by a need for clients > > to be able to attach to the ASTN using FiberChannel. However, the ASTN > > devices at the edge (e.g. LSR A in the diagram below) may not be equipped > > with FiberChannel ports. In this situation, the FiberChannel coming from the > > client device (client A in the diagram below) has to pass through a > > technology conversion device that maps the FiberChannel to something which > > LSR A is capable of supporting. For example, there are devices readily > > available on the market today that map FiberChannel to POS. Client A is > > opaque to this conversion being done - when client A wants to establish an > > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > > signalling is handled by LSR A, and not by the non-GMPLS savvy technology > > conversion device. Similarly, any signalling performed by LSR A to client A > > wrt this same link will use FiberChannel based GMPLS signalling, even though > > the link which manifests itself on a FiberChannel port on client A manifests > > itself on a SONET port on LSR A. However, in terms of the GMPLS signalling > > that LSR A propagates downstream, within a SONET based ASTN, this will be > > SONET based GMPLS signalling. > > > > SONET SONET (LSP Enc. Type = SONET, > > | G-PID = one of POS*) > > | | | | > > technology v v v v > > client A --- conversion ---- LSR A ------- LSR B ------ LSR C -------client B > > ^ device > > | \-------------------------------/ > > | ASTN > > FiberChannel > > (LSP Enc. Type = FiberChannel, > > G-PID = FC-3) > > > > My question is that in the above instance, the LSP established between > > client A and client B will have an Encoding Type of FiberChannel from client > > A's perspective, and of type SONET from client B's perspective. How do the > > OSPF-TE/ISIS-TE extensions handle the above case?" > > I have even simpler question - how would you carry IP packets over such > an LSP, given that client A is going to encapsulate IP into (FC Network > Header + LLC/SNAP Header) (see rfc2625), while client B would expect > IP packets to be carried over PPP ? In other words, where in your picture > is the device that converts (FC Network Header + LLC/SNAP) into the > encapsulation used by PPP ? [EWART]: The technology conversion device would perform this function - it would strip the LLC/SNAP header, and POS encode the IP packets. The PPP session would be between the technology conversion device and client B in this instance. > > Yakov. > ------_=_NextPart_001_01C16415.0A437B50 Content-Type: text/html; charset="iso-8859-1" RE: Moving right along ... Switching Type

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Friday, November 02, 2001 1:49 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ... Switching Type
>
>
> Ewart,
>
> > See embedded comment below.
>
> response in-line...
>
> >
> > Ewart
> >
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > > Sent: Wednesday, October 31, 2001 8:19 PM
> > > To: Zhi-Wei Lin
> > > Cc: ccamp@ops.ietf.org
> > > Subject: Re: Moving right along ... Switching Type
> > >
> > >
> > > Zhi-Wei,
> > >
> > > > <z>Maybe this is one where we need to ask individuals with
> > > operational
> > > > experience and have some experience with service
> > > provisioning whether
> > > > having one end with Ethernet and another end with OC-48
> > > sounds like a
> > > > configuration that makes sense?
> > >
> > > Let me see if I understand your proposal. Consider the following
> > > example:
> > >
> > >    R1---OXC1---OXC2----R2
> > >
> > > where the TE interface on R1 is a collection of GigE ports, and the TE
> > > interface on R2 is a collection of OC-48 ports. Are you saying that
> > > establishing an LSP between R1 to R2 makes sense ?
> >
> > [EWART]: Correct. OXC1 may be capable of performing signal conversion or,
> > more likely, there may be some intermediate non-GMPLS device between R1 &
> > OXC1 that performs such a conversion (refer to e-mail entitled "Query on
> > Encoding field wrt presence of technology conversion devices -
> > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which,
> > for the benefit of those that were not, I have repeated below) because the
> > OXC has no GigE interface port.
> >
> > "Within the GMPLS related routing documents
> > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions),
> > there is an Encoding field contained in the Interface Switching Capability
> > Descriptor sub-TLV of the Link/IS Reachability TLV.
>
> In case you missed it, I'll repeat what I said before:
>
>    Please note that R1 (a router) uses Ethernet encapsulation when
>    sending data on the GigE port. Please also note that R2 (also
>    a router) expects to have HDLC encapsulation when receiving data
>    on its OC-48 port.  As Maarten said in his e-mail, " 1GE port
>    on R1 and OC-48 port on R2 "don't speak the same language".

[EWART]: In the anology I mentioned above, OXC1 possesses a technology conversion function that, in this instance, strips off the layer 1 & 2 headers off each GigE packet, and maps the resulting IP packet, POS encoded onto SONET, changing the LSP encoding type and G-PID accordingly. This function could alternatively be performed by an intermediate (non-GMPLS) device. GMPLS does not currently factor in the presence of such devices, and it is unreasonable to assume that the LSP encoding type and G-PID should remain the same for the length of an LSP.

>
> > My request for GMPLS to support FiberChannel is driven by a need for clients
> > to be able to attach to the ASTN using FiberChannel. However, the ASTN
> > devices at the edge (e.g. LSR A in the diagram below) may not be equipped
> > with FiberChannel ports. In this situation, the FiberChannel coming from the
> > client device (client A in the diagram below) has to pass through a
> > technology conversion device that maps the FiberChannel to something which
> > LSR A is capable of supporting. For example, there are devices readily
> > available on the market today that map FiberChannel to POS. Client A is
> > opaque to this conversion being done - when client A wants to establish an
> > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS
> > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the
> > signalling is handled by LSR A, and not by the non-GMPLS savvy technology
> > conversion device. Similarly, any signalling performed by LSR A to client A
> > wrt this same link will use FiberChannel based GMPLS signalling, even though
> > the link which manifests itself on a FiberChannel port on client A manifests
> > itself on a SONET port on LSR A. However, in terms of the GMPLS signalling
> > that LSR A propagates downstream, within a SONET based ASTN, this will be
> > SONET based GMPLS signalling.
> >    
> >                         SONET          SONET (LSP Enc. Type = SONET,
> >                           |                 G-PID = one of POS*)
> >                           |            |             |            |
> >              technology   v            v             v            v
> > client A --- conversion ---- LSR A ------- LSR B ------ LSR C -------client B
> >            ^      device
> >            |                           \-------------------------------/
> >            |                                              ASTN
> >       FiberChannel
> >     (LSP Enc. Type = FiberChannel,
> >      G-PID = FC-3)
> >
> > My question is that in the above instance, the LSP established between
> > client A and client B will have an Encoding Type of FiberChannel from client
> > A's perspective, and of type SONET from client B's perspective. How do the
> > OSPF-TE/ISIS-TE extensions handle the above case?"
>
> I have even simpler question - how would you carry IP packets over such
> an LSP, given that client A is going to encapsulate IP into (FC Network
> Header + LLC/SNAP Header) (see rfc2625), while client B would expect
> IP packets to be carried over PPP ? In other words, where in your picture
> is the device that converts (FC Network Header + LLC/SNAP) into the
> encapsulation used by PPP ?

[EWART]: The technology conversion device would perform this function - it would strip the LLC/SNAP header, and POS encode the IP packets. The PPP session would be between the technology conversion device and client B in this instance.

>
> Yakov.
>

------_=_NextPart_001_01C16415.0A437B50-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 15:08:51 -0800 Message-ID: <3BE32611.E629FA38@tellabs.com> Date: Fri, 02 Nov 2001 17:02:41 -0600 From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform MIME-Version: 1.0 To: Yakov Rekhter CC: Ewart Tempest , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, et al - The OC-48 port could be terminating Ethernet over GFP, in which case PPP is not in use. As mentioned by Zhi, one of the OXCs in the path would need to do the adaptation from GigE to Ethetnet over GFP. Further, since GigE is speed wise slower than OC-48, such a configuration would not generate any service degradation... Jonathan Sadler Yakov Rekhter wrote: > > Ewart, > > > See embedded comment below. > > response in-line... > > > > > Ewart > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > > Sent: Wednesday, October 31, 2001 8:19 PM > > > To: Zhi-Wei Lin > > > Cc: ccamp@ops.ietf.org > > > Subject: Re: Moving right along ... Switching Type > > > > > > > > > Zhi-Wei, > > > > > > > Maybe this is one where we need to ask individuals with > > > operational > > > > experience and have some experience with service > > > provisioning whether > > > > having one end with Ethernet and another end with OC-48 > > > sounds like a > > > > configuration that makes sense? > > > > > > Let me see if I understand your proposal. Consider the following > > > example: > > > > > > R1---OXC1---OXC2----R2 > > > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > establishing an LSP between R1 to R2 makes sense ? > > > > [EWART]: Correct. OXC1 may be capable of performing signal conversion or, > > more likely, there may be some intermediate non-GMPLS device between R1 & > > OXC1 that performs such a conversion (refer to e-mail entitled "Query on > > Encoding field wrt presence of technology conversion devices - > > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, > > for the benefit of those that were not, I have repeated below) because the > > OXC has no GigE interface port. > > > > "Within the GMPLS related routing documents > > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), > > there is an Encoding field contained in the Interface Switching Capability > > Descriptor sub-TLV of the Link/IS Reachability TLV. > > In case you missed it, I'll repeat what I said before: > > Please note that R1 (a router) uses Ethernet encapsulation when > sending data on the GigE port. Please also note that R2 (also > a router) expects to have HDLC encapsulation when receiving data > on its OC-48 port. As Maarten said in his e-mail, " 1GE port > on R1 and OC-48 port on R2 "don't speak the same language". > > > My request for GMPLS to support FiberChannel is driven by a need for clients > > to be able to attach to the ASTN using FiberChannel. However, the ASTN > > devices at the edge (e.g. LSR A in the diagram below) may not be equipped > > with FiberChannel ports. In this situation, the FiberChannel coming from the > > client device (client A in the diagram below) has to pass through a > > technology conversion device that maps the FiberChannel to something which > > LSR A is capable of supporting. For example, there are devices readily > > available on the market today that map FiberChannel to POS. Client A is > > opaque to this conversion being done - when client A wants to establish an > > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > > signalling is handled by LSR A, and not by the non-GMPLS savvy technology > > conversion device. Similarly, any signalling performed by LSR A to client A > > wrt this same link will use FiberChannel based GMPLS signalling, even though > > the link which manifests itself on a FiberChannel port on client A manifests > > itself on a SONET port on LSR A. However, in terms of the GMPLS signalling > > that LSR A propagates downstream, within a SONET based ASTN, this will be > > SONET based GMPLS signalling. > > > > SONET SONET (LSP Enc. Type = SONET, > > | G-PID = one of POS*) > > | | | | > > technology v v v v > > client A --- conversion ---- LSR A ------- LSR B ------ LSR C -------client B > > ^ device > > | \-------------------------------/ > > | ASTN > > FiberChannel > > (LSP Enc. Type = FiberChannel, > > G-PID = FC-3) > > > > My question is that in the above instance, the LSP established between > > client A and client B will have an Encoding Type of FiberChannel from client > > A's perspective, and of type SONET from client B's perspective. How do the > > OSPF-TE/ISIS-TE extensions handle the above case?" > > I have even simpler question - how would you carry IP packets over such > an LSP, given that client A is going to encapsulate IP into (FC Network > Header + LLC/SNAP Header) (see rfc2625), while client B would expect > IP packets to be carried over PPP ? In other words, where in your picture > is the device that converts (FC Network Header + LLC/SNAP) into the > encapsulation used by PPP ? > > Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 11:23:42 -0800 Message-ID: <3BE2F2A1.2060000@acm.org> Date: Fri, 02 Nov 2001 14:23:13 -0500 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: ccamp@ops.ietf.org CC: yakov@juniper.net, gkailad@acm.org Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te-05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit One characteristic of traditional transport networks is that control plane failures do not affect established lightpaths or TDM channels. This is reflected by requirement 144 in draft-ietf-ipo-carrier-requirements-00: "Control plane failures shall not cause failure of established data plane connections." Note that there is no time limit imposed on how long a control plane failure can last without affecting established data plane connections. The Restart Time field in the Restart_Cap object supports a maximum value of about 49 days. In case of transport networks, this would mean that in case of a controller failure due to say, a natural disaster, if the node is not accessible, established connections will fail after 49 days even if data plane is not affected, which is unacceptable. Even if this is fixed so that a node can advertise that the restart time is infinite, there is another issue. In existing transport networks, established data plane connections do not fail even if multiple controllers fail. Accordingly, the requirement from draft-ietf-ipo-carrier-requirements-00 quoted above requires that there be no failure in the data plane in case of "control plane failures." This would effectively mean that the recovery time could also be indeterminate. Consider the following example with four nodes: A ---- B ---- C ---- D If B and C fail, and C restarts, it can not complete synchronization with D until B restarts and exchanges state with C. I believe this level of resiliency is not possible with the procedure specified. Just advertising 0xffffffff for recovery time will not be enough, as this could cause state to be held indefinitely when it should be deleted. So I suggest one of the following: - remove the restart section from the draft and consider it as a separate draft, so that the rest can move forward. - add a constraint in the beginning of section 9.5, after the first sentence: "The recovery mechanism specified in this section addresses restart issues only in case of PSC devices, and does not fulfil the requirements for transport networks. Recovery procedures for transport networks is for further study." - postpone the last call, and look at adding a solution that would also satisfy the requirements of transport networks. From a transport network perspective, this could be a starting point for discussion: - A new object called PERSISTENT_SESSION is introduced to indicate that a session is long lasting. This will be sent in the Path message associated with transport network sessions. This will be reflected back in the Resv message. The fact that a session is persistent is preserved along with forwarding plane information. - A new message (LRefresh) is introduced to synchronize the forwarding plane information for persistent sessions between peers, and it is transmitted periodically. - A new object called flags is added and this will be carried in Hello messages. This object has one field called flags, and a node supporting persistent sessions will set bit 0 of the Flags field. Support for persistent sessions implies support for the PERSISTENT_SESSION object as well as LRefresh. - For sessions that are marked persistent, state will be cleared only under these conditions: - State will never be cleared based on timeout. Exceptions listed below. - State will be cleared based on timeout only after sending the Resv with the D bit set in the Admin_Status object upstream, and only if graceful deletion was initiated by the headend. This information will be preserved along with forwarding plane information. - Reception of PathTear. - If a node learns that it has some state in the forwarding plane that is not in sync with that of the peer, the forwarding plane state as well as associated control plane state will be cleared on a timer basis. This timer will be more coarse-grained than the refresh timers for the control plane. - If a peer does not support persistent sessions, state that has to be refreshed by that peer will be timed out in the usual manner. Restart procedure as specified for PSC devices may be used if the two nodes support it. - Specify clearly what help is needed from outside RSVP. To support recovery of hierarchical LSPs, RSVP needs the following information upon restart: - Mapping between interface id. assigned by the peer and the interface id. assigned locally. (Related qn.: There was a suggestion on the list (from Yakov) that a node can learn this from the recovered link state database. But if the restart time is going to be indeterminate, isn't it possible that the TE-LSAs have expired when the node restarts? If so, a node might instead preserve this information across restart. But in any case, RSVP needs this information upon restart.) - Peers (LSR ids) with which Hello adjacencies were established dynamically as a result of FA-LSPs. Comments? Cheers, Gopal Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 11:14:51 -0800 Message-ID: <3BE2EFE3.2080302@acm.org> Date: Fri, 02 Nov 2001 14:11:31 -0500 From: Gopal Kailad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org, gkailad@acm.org Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yakov, Yakov Rekhter wrote: >Gopal, > >[clipped...] > >>>>>>If a node supports PSC as well as TDM or LSC interfaces, it >>>>>>might want to advertise different set of parameters in the >>>>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM >>>>>>LSPs which form bearer channels in transport networks. >>>>>>Currently this is not possible. >>>>>> >>>>>>>Can you give us explicit examples as to why and what do >>>>>>>you gain by giving different values for PSC, TDM ? >>>>>>> >>>>>>In case of PSC devices, it may be OK to remove state that >>>>>>is not resynchronized at the end of the recovery period, >>>>>> >>>>>and the recovery period advertised might reflect that. >>>>> >>>>>> >>>>>>But for LSPs in transport networks, one might want to >>>>>>have a different recovery period to avoid any LSP from >>>>>>going down because of recovery timer expiry. >>>>>> >>>>>There is no requirement for a node to advertise exactly the >>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces >>>>>the node could advertise that it will remove the state that >>>>>isn't syncronized at the end of the recovery period, while >>>>>on the TDM interface precisely the same node could advertise >>>>>that the LSPs would be kept even after the recovery time expires. >>>>> >>>>But to set up LSPs over TDM/LSC interfaces, the PSC interface >>>>is going to be used for signaling - since control and data >>>>planes are decoupled! So, how will this help? >>>> >>>Help with what ? You asserted that it "is not possible" for >>>"a node that supports PSC as well as TDM and LSC interfaces.. >>>to advertise different set of parameters in the RESTART_CAP >>>object for data LSPs as opposed to SONET/WDM LSPs." >>> >>>I pointed out to you that your assertion is incorrect, as >>>there is no requirement for a node to advertise exactly the >>>same Restart_Cap on all of its interfaces. >>> >>I believe your assertion is misleading - If two nodes A and >>B have multiple TDM/LSC links (with out of band signaling) >>between them as well as a PSC link, (they are all unnumbered >>interfaces), there will be only one Hello adjacency between >>A and B, resulting in just one Restart_cap object advertised >>in each direction. >> >>In that case, how can one advertise different values in the >>Restart_cap object for TDM/LSC LSPs as opposed to data LSPs? >> >>Since there is only one adjacency, the suggestion above to >>treat the node failure as control channel failure does not >>work either, as the restarting node might want to get >>resynchronized for data LSPs. >> >>I believe your assertion is possible only if all interfaces >>are numbered. >> > >That is incorrect - what I described is possible if only the >control channel is numbered (note that a control channel, just >like any other link, could have multiple IP addresses assigned to it). > Good point - but this would result in more configuration work for the operator. Anyways, there are other problems as well and it appears that just being able to advertise a separate set of Restart/recovery timers for transport network sessions may not be enough, making this a non-issue. Please see my other email on transport networks and RSVP. Thanks, Gopal > > >>If so, this is a huge constraint - please >>refer draft-ietf-ipo-carrier-requirements-00, sec 7.4. >> > >In the context of UNI the (multiple) IP addresses assigned >to a control channel could be locally defined. As such > > >it would meet the requirements of section 7.4 of the draft >you mentioned. > > > >Yakov. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 10:52:11 -0800 Message-Id: <200111021848.fA2ImU073965@merlot.juniper.net> To: "Ewart Tempest" cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25046.1004726910.1@juniper.net> Date: Fri, 02 Nov 2001 10:48:30 -0800 From: Yakov Rekhter Ewart, > See embedded comment below. response in-line... > > Ewart > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Wednesday, October 31, 2001 8:19 PM > > To: Zhi-Wei Lin > > Cc: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... Switching Type > > > > > > Zhi-Wei, > > > > > Maybe this is one where we need to ask individuals with > > operational > > > experience and have some experience with service > > provisioning whether > > > having one end with Ethernet and another end with OC-48 > > sounds like a > > > configuration that makes sense? > > > > Let me see if I understand your proposal. Consider the following > > example: > > > > R1---OXC1---OXC2----R2 > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > interface on R2 is a collection of OC-48 ports. Are you saying that > > establishing an LSP between R1 to R2 makes sense ? > > [EWART]: Correct. OXC1 may be capable of performing signal conversion or, > more likely, there may be some intermediate non-GMPLS device between R1 & > OXC1 that performs such a conversion (refer to e-mail entitled "Query on > Encoding field wrt presence of technology conversion devices - > OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, > for the benefit of those that were not, I have repeated below) because the > OXC has no GigE interface port. > > "Within the GMPLS related routing documents > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), > there is an Encoding field contained in the Interface Switching Capability > Descriptor sub-TLV of the Link/IS Reachability TLV. In case you missed it, I'll repeat what I said before: Please note that R1 (a router) uses Ethernet encapsulation when sending data on the GigE port. Please also note that R2 (also a router) expects to have HDLC encapsulation when receiving data on its OC-48 port. As Maarten said in his e-mail, " 1GE port on R1 and OC-48 port on R2 "don't speak the same language". > My request for GMPLS to support FiberChannel is driven by a need for clients > to be able to attach to the ASTN using FiberChannel. However, the ASTN > devices at the edge (e.g. LSR A in the diagram below) may not be equipped > with FiberChannel ports. In this situation, the FiberChannel coming from the > client device (client A in the diagram below) has to pass through a > technology conversion device that maps the FiberChannel to something which > LSR A is capable of supporting. For example, there are devices readily > available on the market today that map FiberChannel to POS. Client A is > opaque to this conversion being done - when client A wants to establish an > LSP on the FiberChannel link, it does so using FiberChannel based GMPLS > signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the > signalling is handled by LSR A, and not by the non-GMPLS savvy technology > conversion device. Similarly, any signalling performed by LSR A to client A > wrt this same link will use FiberChannel based GMPLS signalling, even though > the link which manifests itself on a FiberChannel port on client A manifests > itself on a SONET port on LSR A. However, in terms of the GMPLS signalling > that LSR A propagates downstream, within a SONET based ASTN, this will be > SONET based GMPLS signalling. > > SONET SONET (LSP Enc. Type = SONET, > | G-PID = one of POS*) > | | | | > technology v v v v > client A --- conversion ---- LSR A ------- LSR B ------ LSR C -------client B > ^ device > | \-------------------------------/ > | ASTN > FiberChannel > (LSP Enc. Type = FiberChannel, > G-PID = FC-3) > > My question is that in the above instance, the LSP established between > client A and client B will have an Encoding Type of FiberChannel from client > A's perspective, and of type SONET from client B's perspective. How do the > OSPF-TE/ISIS-TE extensions handle the above case?" I have even simpler question - how would you carry IP packets over such an LSP, given that client A is going to encapsulate IP into (FC Network Header + LLC/SNAP Header) (see rfc2625), while client B would expect IP packets to be carried over PPP ? In other words, where in your picture is the device that converts (FC Network Header + LLC/SNAP) into the encapsulation used by PPP ? Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 08:03:06 -0800 Message-ID: <3549C09B853DD5119B540002A52CDD348F0838@zcard0ka.ca.nortel.com> From: "David Allan" To: "'ccamp@ops.ietf.org'" Subject: Question about draft-kompella-ospf-gmpls-extensions-02 Date: Fri, 2 Nov 2001 10:52:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163B6.5E726EC0" 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_01C163B6.5E726EC0 Content-Type: text/plain; charset="iso-8859-1" Question on the sub-TLV list in section 5. What is "32768-32772 - reserved for Cisco specific extensions" ? Can any of us get a block? thx Dave ------_=_NextPart_001_01C163B6.5E726EC0 Content-Type: text/html; charset="iso-8859-1" Question about draft-kompella-ospf-gmpls-extensions-02

Question on the sub-TLV list in section 5.

What is "32768-32772 - reserved for Cisco specific extensions" ?

Can any of us get a block?

thx
Dave

------_=_NextPart_001_01C163B6.5E726EC0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Nov 2001 07:24:32 -0800 Cc: ccamp@ops.ietf.org Message-ID: <3BE2B923.F91BE660@lucent.com> Date: Fri, 02 Nov 2001 16:17:55 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Sudheer Dharanikota Original-CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------55875C3C63D00DEFDD834885" This is a multi-part message in MIME format. --------------55875C3C63D00DEFDD834885 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sudheer, See in-line... Sudheer Dharanikota wrote: > > Hi Maarten: > > Following ASON model... I have noticed the assumption that a set of > access groups will form a subnet if and only if they at at the same > layer. With this in mind I have few comments below... > > Maarten Vissers wrote: > > > In a layered network approach (e.g. ASON), the switching type is obsolete... the > > routing is performed within a single layer network, using the links (ITU-T term) > > that are available in that layer network. > > > > What do you mean switching type is obsolete? Does this mean you do not consider > it in G.7713 (DCM document)? I mean the switching type is not needed. G.7713 does not have a "switching type" parameter included. This information is implicitly present; each message is within the scope of a particular layer network. > > > > > >From a layer network's perspective, nodes have just a single switching > > capability (i.e. of that layer network)... nodes who do not have that switching > > capabiltiy are invisible... and nodes with this and other switching capabilities > > will only be presented with this layer network's switching capability; the other > > switching capabilities are invisible. > > > > Does this mean a port (to be precise an interface - IETF terminology) on a node > with multiple switching capabilities (reconfigurable adaptation functions :-)) will > be part of multiple subnetworks? Such port will/may be part of: - multiple layer networks; e.g. a STM-N port supporting VC-3, VC-4 and VC-4-4c is part of the VC-3 layer network, the VC-4 layer network and the VC-4-4c layer network. To reduce complexity, it is possible to develop one protocol carrying the messages for all HOVC/STS layer networks. Then there will be a 1-to-1 relation between port and protocol. We have to address this in the coming period when working on the protocol specific implementation specifications. - multiple subnetworks; e.g. a STM-64 port with 64 VC-4 connection points could have all 64 VC-4 CPs located within one VC-4 subnetwork, or could have 32 VC-4 CPs in subnetwork 1, 10 in subnetwork 2, 7 in subnetwork 3, etc. This latter is the case when VC-4 VPNs are present... e.g. the first 32 VC-4 CPs are allocated to the Switched Public Network subnetwork, 10 to the non-switched subnetwork and the other VC-4 CPs are allocated to a number of VC-4 switched VPNs. Note - If these VPNs are dedicated VPNs (i.e. VC-4 CPs are exclusively allocated to one VPN), each VPN has its own dedicated Connection Controller (CC), Route Controller (RC) and Link Resource Managers (LRM) components (refer to G.8080) as well as its own dedicated links. Regards, Maarten > > > > > Perhaps a additional sentence should be added to clarify that the switching type > > is obsolete for the case of a layered network approach. > > > > I would not do this in such a hurry :-) > > Regards, > > sudheer > > > > > Regards, > > > > Maarten > > > > Dimitri Papadimitriou wrote: > > > > > > Hi, > > > > > > We have two approaches either "traffic-parameters" are used > > > (in SENDER_TSPEC) then i think the Switching Type capability > > > is useless or they aren't then such field could be optionaly > > > used when applicable (some examples are given in the routing > > > document). > > > > > > Wouldn't be the right way to proceed by defining an "unknown" > > > or "unspecified" value used when "traffic-parameters" are > > > included within the Path Message and optional use the ones > > > proposed in the current version of the specification when they > > > aren't. This field is thus optional and MUST only be used when > > > traffic parameters are not defined. I think this solves both > > > approaches. > > > > > > I think that also some additional text is needed in order to > > > clarify the semantic; the following one can be proposed (after > > > having discussed with some individuals): > > > "The Switching Type field is provided to allow nodes having > > > multiple switching layer capabilities to indicate their > > > preference. This field should only be used to indicate the > > > link switching preference but not end-to-end switching > > > preference". > > > > > > Notice that some proposal concerning the applicability scope > > > have been proposed but never really committed within the I-D. > > > > > > Cheers, > > > - dimitri. > > > > > > Zhi-Wei Lin wrote: > > > > > > > > Hi John, > > > > > > > > > The section you mentioned, from what I can tell, is an example list > > > > > of some possible combinations of different equipment functions. I see > > > > > them as examples. But as I said, from routing perspective, it may make > > > > > sense but not signaling. What you've pointed out is the routing document... > > > > > From signaling perspective, if I removed the switching capability > > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > > > possible combinations of switching capabilities supported on a link, an > > > > > intermediate node can deduce, from other fields in the Path message, what > > > > > switching capability is desired. > > > > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > > different switching capabilities on each side and the possible > > > > connections and then demonstrate that what switching capability is > > > > desired can be deduced...hmmm...can't I just say that whatever the > > > > encoding type says and the sender_tspec says is what the switching type > > > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > > > > > > > And if I removed the switching capability field, then it opens the door > > > > > for the possibility where somewhere within my network I might change the > > > > > switching type in order to satisfy a request (because the switching type > > > > > requested is non-existent or exhausted). > > > > > > > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > > > and it goes through an all-optical network that can provide OCh1 (2.5G > > > > service). In the SONET network it switches the STS-48c layer, while in > > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > > > connection, where one part of network may work PDH-based and switching > > > > E1 while another part may be SDH-based and switching VC-12, but the > > > > connection or service is essentially the same. They're not really > > > > client-server layers but similar layers from different technologies... > > > > > > > > > I think it does make sense. I think you have to assume that within > > > > > the switched transport network there will be many kinds of interfaces > > > > > connecting to the transport network. If you can't offer this capability, > > > > > then essentially what you've done is segment the transport network into > > > > > sub-networks based on what interfaces they have and only the like-type > > > > > interfaces can connect to each other. If you look at the IP world, you > > > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > > > together and talking to each other without a problem. This is capability > > > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > > > reason to restrict this). What really matters is that the service is > > > > > delivered. Granted there will be some inefficiencies in this, but that's > > > > > really a policy decision whether users are willing to accept this type > > > > > of connection. > > > > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > > > you were describing in your previous example was an LSP, one end of which > > > > > was > > > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > > > > > > > Maybe this is one where we need to ask individuals with operational > > > > experience and have some experience with service provisioning whether > > > > having one end with Ethernet and another end with OC-48 sounds like a > > > > configuration that makes sense? > > > > > > > > Again, the point here is that if this doesn't make sense, then > > > > essentially what you have is multiple switched networks, each serving > > > > one particular type of customer interface, i.e., a switched network for > > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > > > Is this one of those "violent agreements" where we're concentrating on > > > > two different levels but saying the same thing? --------------55875C3C63D00DEFDD834885 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 --------------55875C3C63D00DEFDD834885-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 09:24:58 -0800 Message-ID: <3BE18394.EFFCD99F@nayna.com> Date: Thu, 01 Nov 2001 09:17:08 -0800 From: Sudheer Dharanikota MIME-Version: 1.0 To: Maarten Vissers CC: Dimitri Papadimitriou , Zhi-Wei Lin , John Drake , "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Maarten: Following ASON model... I have noticed the assumption that a set of access groups will form a subnet if and only if they at at the same layer. With this in mind I have few comments below... Maarten Vissers wrote: > In a layered network approach (e.g. ASON), the switching type is obsolete... the > routing is performed within a single layer network, using the links (ITU-T term) > that are available in that layer network. > What do you mean switching type is obsolete? Does this mean you do not consider it in G.7713 (DCM document)? > > >From a layer network's perspective, nodes have just a single switching > capability (i.e. of that layer network)... nodes who do not have that switching > capabiltiy are invisible... and nodes with this and other switching capabilities > will only be presented with this layer network's switching capability; the other > switching capabilities are invisible. > Does this mean a port (to be precise an interface - IETF terminology) on a node with multiple switching capabilities (reconfigurable adaptation functions :-)) will be part of multiple subnetworks? > > Perhaps a additional sentence should be added to clarify that the switching type > is obsolete for the case of a layered network approach. > I would not do this in such a hurry :-) Regards, sudheer > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Hi, > > > > We have two approaches either "traffic-parameters" are used > > (in SENDER_TSPEC) then i think the Switching Type capability > > is useless or they aren't then such field could be optionaly > > used when applicable (some examples are given in the routing > > document). > > > > Wouldn't be the right way to proceed by defining an "unknown" > > or "unspecified" value used when "traffic-parameters" are > > included within the Path Message and optional use the ones > > proposed in the current version of the specification when they > > aren't. This field is thus optional and MUST only be used when > > traffic parameters are not defined. I think this solves both > > approaches. > > > > I think that also some additional text is needed in order to > > clarify the semantic; the following one can be proposed (after > > having discussed with some individuals): > > "The Switching Type field is provided to allow nodes having > > multiple switching layer capabilities to indicate their > > preference. This field should only be used to indicate the > > link switching preference but not end-to-end switching > > preference". > > > > Notice that some proposal concerning the applicability scope > > have been proposed but never really committed within the I-D. > > > > Cheers, > > - dimitri. > > > > Zhi-Wei Lin wrote: > > > > > > Hi John, > > > > > > > The section you mentioned, from what I can tell, is an example list > > > > of some possible combinations of different equipment functions. I see > > > > them as examples. But as I said, from routing perspective, it may make > > > > sense but not signaling. What you've pointed out is the routing document... > > > > From signaling perspective, if I removed the switching capability > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > > possible combinations of switching capabilities supported on a link, an > > > > intermediate node can deduce, from other fields in the Path message, what > > > > switching capability is desired. > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > different switching capabilities on each side and the possible > > > connections and then demonstrate that what switching capability is > > > desired can be deduced...hmmm...can't I just say that whatever the > > > encoding type says and the sender_tspec says is what the switching type > > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > > > > And if I removed the switching capability field, then it opens the door > > > > for the possibility where somewhere within my network I might change the > > > > switching type in order to satisfy a request (because the switching type > > > > requested is non-existent or exhausted). > > > > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > > and it goes through an all-optical network that can provide OCh1 (2.5G > > > service). In the SONET network it switches the STS-48c layer, while in > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > > connection, where one part of network may work PDH-based and switching > > > E1 while another part may be SDH-based and switching VC-12, but the > > > connection or service is essentially the same. They're not really > > > client-server layers but similar layers from different technologies... > > > > > > > I think it does make sense. I think you have to assume that within > > > > the switched transport network there will be many kinds of interfaces > > > > connecting to the transport network. If you can't offer this capability, > > > > then essentially what you've done is segment the transport network into > > > > sub-networks based on what interfaces they have and only the like-type > > > > interfaces can connect to each other. If you look at the IP world, you > > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > > together and talking to each other without a problem. This is capability > > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > > reason to restrict this). What really matters is that the service is > > > > delivered. Granted there will be some inefficiencies in this, but that's > > > > really a policy decision whether users are willing to accept this type > > > > of connection. > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > > you were describing in your previous example was an LSP, one end of which > > > > was > > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > > > > Maybe this is one where we need to ask individuals with operational > > > experience and have some experience with service provisioning whether > > > having one end with Ethernet and another end with OC-48 sounds like a > > > configuration that makes sense? > > > > > > Again, the point here is that if this doesn't make sense, then > > > essentially what you have is multiple switched networks, each serving > > > one particular type of customer interface, i.e., a switched network for > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > Is this one of those "violent agreements" where we're concentrating on > > > two different levels but saying the same thing? Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 08:25:53 -0800 Message-ID: <3BE1774E.9D529F22@lucent.com> Date: Thu, 01 Nov 2001 11:24:46 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, > To handle the case where the path of an LSP transits one or more TE links > which are advertised as having more than one of the following switching > capabilities (PSC, TDM, LSC, FSC) and the LSP is requesting a switching > capability of (PSC, LSC, or FSC). > The LSP encoding type clearly specifies what the LSP wants. I don't think you need ST filed anymore. Am I missing something? Tabggyabg Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 08:05:01 -0800 Message-ID: <3BE1702B.8AD932CC@lucent.com> Date: Thu, 01 Nov 2001 10:54:19 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Ewart Tempest CC: Yakov Rekhter , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Ewart Tempest wrote: > > Yakov, > Ewart, One way is to abstract the port, so that in OSPF/ISIS-TE database, port = conventional port info (with attributes) + adaptation functions the port card can support. This is indeed straightforward because a NE can be views as ports + switching fabric; here ports are abstract entities that include adaptation functions. Then CSPF also need to consider this new parameter to calculate an e2e path. Yangguang > See embedded comment below. > > Ewart > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Wednesday, October 31, 2001 8:19 PM > > To: Zhi-Wei Lin > > Cc: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... Switching Type > > > > > > Zhi-Wei, > > > > > Maybe this is one where we need to ask individuals with > > operational > > > experience and have some experience with service > > provisioning whether > > > having one end with Ethernet and another end with OC-48 > > sounds like a > > > configuration that makes sense? > > > > Let me see if I understand your proposal. Consider the following > > example: > > > > R1---OXC1---OXC2----R2 > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > interface on R2 is a collection of OC-48 ports. Are you saying that > > establishing an LSP between R1 to R2 makes sense ? > > [EWART]: Correct. OXC1 may be capable of performing signal conversion or, more > likely, there may be some intermediate non-GMPLS device between R1 & OXC1 that > performs such a conversion (refer to e-mail entitled "Query on Encoding field > wrt presence of technology conversion devices - OSPF-TE/ISIS-TE extensions", > 23rd Oct., on which you were copied and which, for the benefit of those that > were not, I have repeated below) because the OXC has no GigE interface port. > > "Within the GMPLS related routing documents > (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), > there is an Encoding field contained in the Interface Switching Capability > Descriptor sub-TLV of the Link/IS Reachability TLV. > > My request for GMPLS to support FiberChannel is driven by a need for clients > to be able to attach to the ASTN using FiberChannel. However, the ASTN devices > at the edge (e.g. LSR A in the diagram below) may not be equipped with > FiberChannel ports. In this situation, the FiberChannel coming from the client > device (client A in the diagram below) has to pass through a technology > conversion device that maps the FiberChannel to something which LSR A is > capable of supporting. For example, there are devices readily available on the > market today that map FiberChannel to POS. Client A is opaque to this > conversion being done - when client A wants to establish an LSP on the > FiberChannel link, it does so using FiberChannel based GMPLS signalling (i.e. > LSP Enc. Type = FiberChannel, G-PID = FC-3) - the signalling is handled by LSR > A, and not by the non-GMPLS savvy technology conversion device. Similarly, any > signalling performed by LSR A to client A wrt this same link will use > FiberChannel based GMPLS signalling, even though the link which manifests > itself on a FiberChannel port on client A manifests itself on a SONET port on > LSR A. However, in terms of the GMPLS signalling that LSR A propagates > downstream, within a SONET based ASTN, this will be SONET based GMPLS > signalling. > > > SONET SONET (LSP Enc. Type = SONET, > | G-PID = one of POS*) > | | | | > technology v v v > v client A ------ conversion ------ LSR A ------- LSR > B ------ LSR C ------- client B > > ^ device > | \-------------------------------/ > | ASTN > FiberChannel > (LSP Enc. Type = FiberChannel, > G-PID = FC-3) > > My question is that in the above instance, the LSP established between client > A and client B will have an Encoding Type of FiberChannel from client A's > perspective, and of type SONET from client B's perspective. How do the > OSPF-TE/ISIS-TE extensions handle the above case?" > > > > > Yakov. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 08:04:10 -0800 Message-ID: <3BE17259.69E7CF52@lucent.com> Date: Thu, 01 Nov 2001 11:03:37 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: Yakov Rekhter CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, I guess Ewart gave an example. Just a clarification: to R1 and R2, the connection can be treated as a single entity, while to the optical network, it's two trails interconnected by the adaptation function. That's why I said that there were actually two LSPs within. Yangguang Yakov Rekhter wrote: > > Yangguang, > > > > Let me see if I understand your proposal. Consider the following > > > example: > > > > > > R1---OXC1---OXC2----R2 > > > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > establishing an LSP between R1 to R2 makes sense ? > > > > > > > If you have adaptation function in either OXCs, it then makes sense. And > > sure, you can also treat the R1-R2 connection as two LSPs separated by the > > adaptation function. > > Please note that R1 (a router) uses Ethernet encapsulation when sending > data on the GigE port. Please also note that R2 (also a router) expects > to have HDLC encapsulation when receiving data on its OC-48 port. > As Maarten said in his e-mail, " 1GE port on R1 and OC-48 port on > R2 "don't speak the same language". > > So, with this in mind perhaps you could elaborate on what sense does > it make to have an LSP between R1 and R2. > > Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:44:03 -0800 Message-ID: <3BE16AA3.D42DD309@tellabs.com> Date: Thu, 01 Nov 2001 09:30:43 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: mvissers@lucent.com, yakov@juniper.net, zwlin@lucent.com, ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree that the G.805 model is extremely useful in analyzing networks, and thus in designing control protocols for networks. I think that some of the confusion regarding the semantics of fields (like Switching Type) may be due to the lack of a coherent model of the network under control. If we have a coherent network model it should be easy to clearly define what the control parameters mean. G.805 is the best model I've seen so far... Regards, Ben neil.2.harrison@bt.com wrote: > > Watching this discussion unfold it seems that many would benefit from a read > of G.805 on functional arch and what layering/partitioning mean. I saw > someone (Zhi I think) refer to 'adaptation' (ie the required functionality > at client<=>server boundaries) but I wonder if most people understand what > he meant by this?....which is also at the root of what Maarten is talking > about below, ie it all depends on where trails start and terminate....or put > another way 'clinet layer link connections = server layer trails', where > each clinet layer link connection can be served by a different technology > trail. You can't start a trail using technology X and terminate it using > technology Y, this makes no sense as Maarten states below.....in transport > networks trail termination points must come in matching (technology) pairs. > > regards, Neil > > > -----Original Message----- > > From: Maarten Vissers [mailto:mvissers@lucent.com] > > Sent: 01 November 2001 11:03 > > To: Yakov Rekhter > > Cc: Zhi-Wei Lin; ccamp@ops.ietf.org > > Subject: Re: Moving right along ... Switching Type > > > > > > Yakov, > > > > It depends on what your definition of "OXC" is... > > > > - if it is a box with fibers connected to it it can be a > > SDH/SONET ADM or cross > > connect, in which case it makes a lot of sense... the 1GE > > physical interfaces > > are terminated and the packets are mapped via GFP (Rec. G.7041) into > > STS-3c-Xv/VC-4-Xv or STS-1-Xv signals for further transport. > > It is becoming > > popular already to do this... > > I.e. the transport network is very capable to mix and match > > different interface > > types at its edges. Some other examples: DS3 - network - > > OC48, 100ME - network - > > 1GE, E1 - network - STM1, 1000BaseX - network - 1000BaseT > > > > - if it is a box with just an optical fabric, it doesn't make > > sense of course... > > 1GE port on R1 and OC-48 port on R2 "don't speak the same language". > > > > Regards, > > > > Maarten > > > > Yakov Rekhter wrote: > > > > > > Zhi-Wei, > > > > > > > Maybe this is one where we need to ask individuals > > with operational > > > > experience and have some experience with service > > provisioning whether > > > > having one end with Ethernet and another end with OC-48 > > sounds like a > > > > configuration that makes sense? > > > > > > Let me see if I understand your proposal. Consider the following > > > example: > > > > > > R1---OXC1---OXC2----R2 > > > > > > where the TE interface on R1 is a collection of GigE ports, > > and the TE > > > interface on R2 is a collection of OC-48 ports. Are you saying that > > > establishing an LSP between R1 to R2 makes sense ? > > > > > > Yakov. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:38:40 -0800 Message-ID: <3BE1694E.B9713B84@tellabs.com> Date: Thu, 01 Nov 2001 09:25:02 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Maarten Vissers CC: Dimitri Papadimitriou , Zhi-Wei Lin , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maarten, I agree with what you're saying with respect to a single layer network. I think it also applies to operation of multi-layer networks because the routing and signaling are essentially done by considering only one layer (the layer of the LSP being created) by filtering out (by constraints) irrelevant information (about other network layers). This is why I can't see why Switching Type is needed in any case. Rregards, Ben Maarten Vissers wrote: > > In a layered network approach (e.g. ASON), the switching type is obsolete... the > routing is performed within a single layer network, using the links (ITU-T term) > that are available in that layer network. > > From a layer network's perspective, nodes have just a single switching > capability (i.e. of that layer network)... nodes who do not have that switching > capabiltiy are invisible... and nodes with this and other switching capabilities > will only be presented with this layer network's switching capability; the other > switching capabilities are invisible. > > Perhaps a additional sentence should be added to clarify that the switching type > is obsolete for the case of a layered network approach. > > Regards, > > Maarten > > Dimitri Papadimitriou wrote: > > > > Hi, > > > > We have two approaches either "traffic-parameters" are used > > (in SENDER_TSPEC) then i think the Switching Type capability > > is useless or they aren't then such field could be optionaly > > used when applicable (some examples are given in the routing > > document). > > > > Wouldn't be the right way to proceed by defining an "unknown" > > or "unspecified" value used when "traffic-parameters" are > > included within the Path Message and optional use the ones > > proposed in the current version of the specification when they > > aren't. This field is thus optional and MUST only be used when > > traffic parameters are not defined. I think this solves both > > approaches. > > > > I think that also some additional text is needed in order to > > clarify the semantic; the following one can be proposed (after > > having discussed with some individuals): > > "The Switching Type field is provided to allow nodes having > > multiple switching layer capabilities to indicate their > > preference. This field should only be used to indicate the > > link switching preference but not end-to-end switching > > preference". > > > > Notice that some proposal concerning the applicability scope > > have been proposed but never really committed within the I-D. > > > > Cheers, > > - dimitri. > > > > Zhi-Wei Lin wrote: > > > > > > Hi John, > > > > > > > The section you mentioned, from what I can tell, is an example list > > > > of some possible combinations of different equipment functions. I see > > > > them as examples. But as I said, from routing perspective, it may make > > > > sense but not signaling. What you've pointed out is the routing document... > > > > From signaling perspective, if I removed the switching capability > > > > field, there is nothing lost...do you agree? > > > > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > > possible combinations of switching capabilities supported on a link, an > > > > intermediate node can deduce, from other fields in the Path message, what > > > > switching capability is desired. > > > > > > > > > > Wow...ok...so I have to list all the different combinations of > > > different switching capabilities on each side and the possible > > > connections and then demonstrate that what switching capability is > > > desired can be deduced...hmmm...can't I just say that whatever the > > > encoding type says and the sender_tspec says is what the switching type > > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > > > > And if I removed the switching capability field, then it opens the door > > > > for the possibility where somewhere within my network I might change the > > > > switching type in order to satisfy a request (because the switching type > > > > requested is non-existent or exhausted). > > > > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > > capability for another in the middle of an LSP makes sense. > > > > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > > and it goes through an all-optical network that can provide OCh1 (2.5G > > > service). In the SONET network it switches the STS-48c layer, while in > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > > connection, where one part of network may work PDH-based and switching > > > E1 while another part may be SDH-based and switching VC-12, but the > > > connection or service is essentially the same. They're not really > > > client-server layers but similar layers from different technologies... > > > > > > > I think it does make sense. I think you have to assume that within > > > > the switched transport network there will be many kinds of interfaces > > > > connecting to the transport network. If you can't offer this capability, > > > > then essentially what you've done is segment the transport network into > > > > sub-networks based on what interfaces they have and only the like-type > > > > interfaces can connect to each other. If you look at the IP world, you > > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > > together and talking to each other without a problem. This is capability > > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > > reason to restrict this). What really matters is that the service is > > > > delivered. Granted there will be some inefficiencies in this, but that's > > > > really a policy decision whether users are willing to accept this type > > > > of connection. > > > > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > > you were describing in your previous example was an LSP, one end of which > > > > was > > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > > > > Maybe this is one where we need to ask individuals with operational > > > experience and have some experience with service provisioning whether > > > having one end with Ethernet and another end with OC-48 sounds like a > > > configuration that makes sense? > > > > > > Again, the point here is that if this doesn't make sense, then > > > essentially what you have is multiple switched networks, each serving > > > one particular type of customer interface, i.e., a switched network for > > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > > > Is this one of those "violent agreements" where we're concentrating on > > > two different levels but saying the same thing? Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:33:43 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA13601CF43B3@zcard04u.ca.nortel.com> From: "Ewart Tempest" To: Yakov Rekhter Cc: ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Thu, 1 Nov 2001 10:22:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C162E9.00435800" 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_01C162E9.00435800 Content-Type: text/plain; charset="iso-8859-1" Yakov, See embedded comment below. Ewart > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Wednesday, October 31, 2001 8:19 PM > To: Zhi-Wei Lin > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > > Zhi-Wei, > > > Maybe this is one where we need to ask individuals with > operational > > experience and have some experience with service > provisioning whether > > having one end with Ethernet and another end with OC-48 > sounds like a > > configuration that makes sense? > > Let me see if I understand your proposal. Consider the following > example: > > R1---OXC1---OXC2----R2 > > where the TE interface on R1 is a collection of GigE ports, and the TE > interface on R2 is a collection of OC-48 ports. Are you saying that > establishing an LSP between R1 to R2 makes sense ? [EWART]: Correct. OXC1 may be capable of performing signal conversion or, more likely, there may be some intermediate non-GMPLS device between R1 & OXC1 that performs such a conversion (refer to e-mail entitled "Query on Encoding field wrt presence of technology conversion devices - OSPF-TE/ISIS-TE extensions", 23rd Oct., on which you were copied and which, for the benefit of those that were not, I have repeated below) because the OXC has no GigE interface port. "Within the GMPLS related routing documents (draft-ietf-ccamp-ospf-gmpls-extensions & draft-ietf-isis-gmpls-extensions), there is an Encoding field contained in the Interface Switching Capability Descriptor sub-TLV of the Link/IS Reachability TLV. My request for GMPLS to support FiberChannel is driven by a need for clients to be able to attach to the ASTN using FiberChannel. However, the ASTN devices at the edge (e.g. LSR A in the diagram below) may not be equipped with FiberChannel ports. In this situation, the FiberChannel coming from the client device (client A in the diagram below) has to pass through a technology conversion device that maps the FiberChannel to something which LSR A is capable of supporting. For example, there are devices readily available on the market today that map FiberChannel to POS. Client A is opaque to this conversion being done - when client A wants to establish an LSP on the FiberChannel link, it does so using FiberChannel based GMPLS signalling (i.e. LSP Enc. Type = FiberChannel, G-PID = FC-3) - the signalling is handled by LSR A, and not by the non-GMPLS savvy technology conversion device. Similarly, any signalling performed by LSR A to client A wrt this same link will use FiberChannel based GMPLS signalling, even though the link which manifests itself on a FiberChannel port on client A manifests itself on a SONET port on LSR A. However, in terms of the GMPLS signalling that LSR A propagates downstream, within a SONET based ASTN, this will be SONET based GMPLS signalling. SONET SONET (LSP Enc. Type = SONET, | G-PID = one of POS*) | | | | technology v v v v client A ------ conversion ------ LSR A ------- LSR B ------ LSR C ------- client B ^ device | \-------------------------------/ | ASTN FiberChannel (LSP Enc. Type = FiberChannel, G-PID = FC-3) My question is that in the above instance, the LSP established between client A and client B will have an Encoding Type of FiberChannel from client A's perspective, and of type SONET from client B's perspective. How do the OSPF-TE/ISIS-TE extensions handle the above case?" > > Yakov. > > ------_=_NextPart_001_01C162E9.00435800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Moving right along ... Switching Type

Yakov,

See embedded comment below.

Ewart

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Wednesday, October 31, 2001 8:19 = PM
> To: Zhi-Wei Lin
> Cc: ccamp@ops.ietf.org
> Subject: Re: Moving right along ... Switching = Type
>
>
> Zhi-Wei,
>
> > <z>Maybe this is one where we need = to ask individuals with
> operational
> > experience and have some experience with = service
> provisioning whether
> > having one end with Ethernet and another = end with OC-48
> sounds like a
> > configuration that makes sense?
>
> Let me see if I understand your proposal. = Consider the following
> example:
>
>    R1---OXC1---OXC2----R2
>
> where the TE interface on R1 is a collection of = GigE ports, and the TE
> interface on R2 is a collection of OC-48 ports. = Are you saying that
> establishing an LSP between R1 to R2 makes = sense ?

[EWART]: Correct. OXC1 may be capable of performing = signal conversion or, more likely, there may be some intermediate = non-GMPLS device between R1 & OXC1 that performs such a conversion = (refer to e-mail entitled "Query on Encoding field wrt presence of = technology conversion devices - OSPF-TE/ISIS-TE extensions", 23rd = Oct., on which you were copied and which, for the benefit of those that = were not, I have repeated below) because the OXC has no GigE interface = port.

"Within the GMPLS related routing documents = (draft-ietf-ccamp-ospf-gmpls-extensions & = draft-ietf-isis-gmpls-extensions), there is an Encoding field contained = in the Interface Switching Capability Descriptor sub-TLV of the Link/IS = Reachability TLV.

My request for GMPLS to support FiberChannel is = driven by a need for clients to be able to attach to the ASTN using = FiberChannel. However, the ASTN devices at the edge (e.g. LSR A in the = diagram below) may not be equipped with FiberChannel ports. In this = situation, the FiberChannel coming from the client device (client A in = the diagram below) has to pass through a technology conversion device = that maps the FiberChannel to something which LSR A is capable of = supporting. For example, there are devices readily available on the = market today that map FiberChannel to POS. Client A is opaque to this = conversion being done - when client A wants to establish an LSP on the = FiberChannel link, it does so using FiberChannel based GMPLS signalling = (i.e. LSP Enc. Type =3D FiberChannel, G-PID =3D FC-3) - the signalling = is handled by LSR A, and not by the non-GMPLS savvy technology = conversion device. Similarly, any signalling performed by LSR A to = client A wrt this same link will use FiberChannel based GMPLS = signalling, even though the link which manifests itself on a = FiberChannel port on client A manifests itself on a SONET port on LSR = A. However, in terms of the GMPLS signalling that LSR A propagates = downstream, within a SONET based ASTN, this will be SONET based GMPLS = signalling.

       =20
          &nb= sp;           &nb= sp;     = SONET          SONET (LSP = Enc. Type =3D SONET,
          &nb= sp;           &nb= sp;       = |            = ;     G-PID =3D one of POS*)
          &nb= sp;           &nb= sp;       = |            = |            = ; |            = |
          &nb= sp;     technology    = v            = v            = ; v            = v            = ;            = ; client A ------ conversion ------ LSR A ------- LSR B ------ LSR C = ------- client B

           = ^      device
           = |            =             = \-------------------------------/
           = |            =         =         =         =       ASTN
      FiberChannel
        (LSP Enc. = Type =3D FiberChannel,
         = G-PID =3D FC-3)

My question is that in the above instance, the LSP = established between client A and client B will have an Encoding Type of = FiberChannel from client A's perspective, and of type SONET from client = B's perspective. How do the OSPF-TE/ISIS-TE extensions handle the above = case?"

>
> Yakov.
>
>

------_=_NextPart_001_01C162E9.00435800-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:31:02 -0800 Message-ID: <3BE16775.3ACB0943@tellabs.com> Date: Thu, 01 Nov 2001 09:17:09 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: Dimitri Papadimitriou CC: Zhi-Wei Lin , John Drake , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, I am still trying to understand the semantics of Switching Type. Your proposal MIGHT work in some situations, but it is not so useful to propose solutions until we understand what Switching Type means. I am worried that it means different things to different people, or has different meaning in different situations. It would be a mistake to simply gloss over this by saying sometimes we use it and sometimes we don't. Regards, Ben Dimitri Papadimitriou wrote: > > Hi, > > We have two approaches either "traffic-parameters" are used > (in SENDER_TSPEC) then i think the Switching Type capability > is useless or they aren't then such field could be optionaly > used when applicable (some examples are given in the routing > document). > > Wouldn't be the right way to proceed by defining an "unknown" > or "unspecified" value used when "traffic-parameters" are > included within the Path Message and optional use the ones > proposed in the current version of the specification when they > aren't. This field is thus optional and MUST only be used when > traffic parameters are not defined. I think this solves both > approaches. > > I think that also some additional text is needed in order to > clarify the semantic; the following one can be proposed (after > having discussed with some individuals): > "The Switching Type field is provided to allow nodes having > multiple switching layer capabilities to indicate their > preference. This field should only be used to indicate the > link switching preference but not end-to-end switching > preference". > > Notice that some proposal concerning the applicability scope > have been proposed but never really committed within the I-D. > > Cheers, > - dimitri. > > Zhi-Wei Lin wrote: > > > > Hi John, > > > > > The section you mentioned, from what I can tell, is an example list > > > of some possible combinations of different equipment functions. I see > > > them as examples. But as I said, from routing perspective, it may make > > > sense but not signaling. What you've pointed out is the routing document... > > > From signaling perspective, if I removed the switching capability > > > field, there is nothing lost...do you agree? > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > possible combinations of switching capabilities supported on a link, an > > > intermediate node can deduce, from other fields in the Path message, what > > > switching capability is desired. > > > > > > > Wow...ok...so I have to list all the different combinations of > > different switching capabilities on each side and the possible > > connections and then demonstrate that what switching capability is > > desired can be deduced...hmmm...can't I just say that whatever the > > encoding type says and the sender_tspec says is what the switching type > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > And if I removed the switching capability field, then it opens the door > > > for the possibility where somewhere within my network I might change the > > > switching type in order to satisfy a request (because the switching type > > > requested is non-existent or exhausted). > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > capability for another in the middle of an LSP makes sense. > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > and it goes through an all-optical network that can provide OCh1 (2.5G > > service). In the SONET network it switches the STS-48c layer, while in > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > connection, where one part of network may work PDH-based and switching > > E1 while another part may be SDH-based and switching VC-12, but the > > connection or service is essentially the same. They're not really > > client-server layers but similar layers from different technologies... > > > > > I think it does make sense. I think you have to assume that within > > > the switched transport network there will be many kinds of interfaces > > > connecting to the transport network. If you can't offer this capability, > > > then essentially what you've done is segment the transport network into > > > sub-networks based on what interfaces they have and only the like-type > > > interfaces can connect to each other. If you look at the IP world, you > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > together and talking to each other without a problem. This is capability > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > reason to restrict this). What really matters is that the service is > > > delivered. Granted there will be some inefficiencies in this, but that's > > > really a policy decision whether users are willing to accept this type > > > of connection. > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > you were describing in your previous example was an LSP, one end of which > > > was > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > Maybe this is one where we need to ask individuals with operational > > experience and have some experience with service provisioning whether > > having one end with Ethernet and another end with OC-48 sounds like a > > configuration that makes sense? > > > > Again, the point here is that if this doesn't make sense, then > > essentially what you have is multiple switched networks, each serving > > one particular type of customer interface, i.e., a switched network for > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > Is this one of those "violent agreements" where we're concentrating on > > two different levels but saying the same thing? Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:18:07 -0800 Message-ID: <3BE16480.22E616A1@tellabs.com> Date: Thu, 01 Nov 2001 09:04:32 -0600 From: Ben Mack-Crane MIME-Version: 1.0 To: John Drake CC: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, I remain confused. Your first comment below seems to indicate that Switching Type means HOW a link multiplexes the LSPs it can carry. In the second comment it appears that Switching Type indicates WHAT (type of LSPs) can be carried over the link. Which of these is Switching Type supposed to convey (WHAT or HOW)? Regards, Ben John Drake wrote: > > -----Original Message----- > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > Sent: Wednesday, October 31, 2001 2:10 PM > To: John Drake > Cc: ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > John, > > I had read the routing drafts (as thet are referenced from the signaling > drafts), and was expressing confusion as a result. > > The Switching Type values are very broad (each includes several possible > encapsulations, including NULL, of the LSP being created). What exactly > they include is not clear. For example I don't know where G.709 switching > would be included. In fact, even the names are a bit confusing, for example > "TDM Capable" -- I don't see what multiplexing has to do with switching > (one can switch among both multiplexed and non-multiplexed interfaces). > I assume "TDM Capable" means SONET/SDH and maybe PDH... > > JD: All of the above. Switching Capability is just a rename of Link > Multiplex. > > I have always thought that the LSP Encoding Type, along with the TSPEC, > was sufficient to indicate what was being setup (switched) and that how > that LSP was encapsulated on each link was a local issue. For example, > a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given > link along its path, even switched in those forms over several hops, but > this is not an end-to-end concern. In fact, restricting the switching > type in this case would only artificially restrict the set of available > routes. > > JD: The LSP encoding type doesn't indicate a link's multiplexing > capabilities. The switching capability, nee multiplexing capability, > is used to indicate the type of LSPs that can be multiplexed on that > link. > > Similarly, I think that if one wants to set up an OC-48 RS transparent > LSP, it may be switched at some hop(s) over Lambda-Switch capable > links and at some hops over TDM Capable links or even Fiber Switch capable > links, and that is just fine. Why one would want to restrict this > is not clear. > > JD: The way that this would be done in GMPLS is through the use of LSP > hierarchy. > > Regards, > Ben > > John Drake wrote: > > > > Ben, > > > > I think part of the problem is that you also need to read the GMPLS > routing > > drafts: > > > > > http://search.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-00.txt > > > > There are also comments in your text. > > > > Thanks, > > > > John > > > > -----Original Message----- > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > Sent: Monday, October 29, 2001 9:53 AM > > To: Kireeti Kompella > > Cc: ccamp@ops.ietf.org > > Subject: Re: Moving right along ... Switching Type > > > > In reviewing the GMPLS signaling drafts I have been unable to > > get a clear understanding of the need for and use of the Switching > > Type field in the Generalized Label Request object. > > > > JD: The Switching Type field is for handling the situation where there > > are multiple switching capabilities per interface (see section 6.4.6 of > > draft-ietf-ccamp-gmpls-routing-00.txt) > > > > This appears to be an attempt to address LSP setup involving multiple > > layer networks, but it does not adequately address the issues involved. > > > > JD: Would you please provide some additional prose explaining your > > reasoning on this? > > > > That it "Indicates the type of switching that should be performed on a > > particular link." makes it seem to be a local concern, while others > > have indicated it is an end-to-end field. For example, George Swallow > > says "It is my understanding that for a given LSP it does not change, > > but is carried end-to-end and applies at all intermediate hops along > > the path." > > > > JD: I think George's interpretation is correct, and I don't think the > > other text you quoted contradicts George. If a given TE link supports > > multiple switching types, the node controlling that link needs to know > > what switching type a given LSP wants to use. > > > > As an end-to-end item I have trouble understanding how the originating > node > > would determine how to set this (on what basis one determines what > switching > > choice to make in all cases). In fact, I'm not sure why the originating > > node would care what type of switching is used as long as the LSP is > > delivered > > to the egress faithfully. > > > > JD: The orgin node uses the switching capability information in the link > > state > > database in its CSPF calculation to ensure that switching capability is > > consistent > > along the path of the LSP. > > > > Regards, > > Ben Mack-Crane Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 07:13:51 -0800 Message-ID: <3BE163E6.9C0A3A47@alcatel.be> Date: Thu, 01 Nov 2001 16:01:58 +0100 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NA (NSG) MIME-Version: 1.0 To: George Swallow CC: Yakov Rekhter , ccamp@ops.ietf.org, Maarten Vissers , John Drake Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------54894DBE570AB46316BC090D" This is a multi-part message in MIME format. --------------54894DBE570AB46316BC090D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George, all, I think the proposed rewording solves the issue of layering raised by Maarten (concerning the ASON/ASTN model), while clearly preserving the current proposal concerning ST field usage. If this is accepted an additional statement (as proposed) would be added in the Sonet/SDH I-D where the the corresponding traffic-parameters are defined. Moreover, such proposal can be extended when only one switching type is supported (as clarified by John). Regards, - dimitri. George Swallow wrote: > > > > Wouldn't be the right way to proceed by defining an "unknown" > > > or "unspecified" value used when "traffic-parameters" are > > > included within the Path Message and optional use the ones > > > proposed in the current version of the specification when they > > > aren't. This field is thus optional and MUST only be used when > > "MUST only" seems a bit strong. I don't see why one should have to > reject a Sonet connection that had a Switching Type of TDM. > > Perhaps "only MUST" was the intent. > > I think the actual wording should be something to the effect, > > When the switching type is implied traffic-parameters the Switching > Type field is ignored. The Switching Type field SHOULD be set to > either the implied value or to UNKNOWN. When the switching type is > not implied by the traffic-parameters it MUST be set to one of the > values [pointer to appropriate list] other than the value UNKNOWN. > > The definition of the traffic parameters of Sonet should also carry a > note that the ST of TDM is implied. > > ...George > > > > traffic parameters are not defined. I think this solves both > > > approaches. > > > > Agreed. > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 --------------54894DBE570AB46316BC090D Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NA (NSG) - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------54894DBE570AB46316BC090D-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 06:11:07 -0800 Message-Id: <200111011409.fA1E9O076680@merlot.juniper.net> To: Yangguang Xu cc: ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62719.1004623764.1@juniper.net> Date: Thu, 01 Nov 2001 06:09:24 -0800 From: Yakov Rekhter Yangguang, > > Let me see if I understand your proposal. Consider the following > > example: > > > > R1---OXC1---OXC2----R2 > > > > where the TE interface on R1 is a collection of GigE ports, and the TE > > interface on R2 is a collection of OC-48 ports. Are you saying that > > establishing an LSP between R1 to R2 makes sense ? > > > > If you have adaptation function in either OXCs, it then makes sense. And > sure, you can also treat the R1-R2 connection as two LSPs separated by the > adaptation function. Please note that R1 (a router) uses Ethernet encapsulation when sending data on the GigE port. Please also note that R2 (also a router) expects to have HDLC encapsulation when receiving data on its OC-48 port. As Maarten said in his e-mail, " 1GE port on R1 and OC-48 port on R2 "don't speak the same language". So, with this in mind perhaps you could elaborate on what sense does it make to have an LSP between R1 and R2. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 06:11:02 -0800 Message-Id: <200111011407.JAA07592@telescope.cisco.com> To: Yakov Rekhter cc: Dimitri Papadimitriou , ccamp@ops.ietf.org, swallow@cisco.com Subject: Re: Moving right along ... Switching Type Date: Thu, 01 Nov 2001 09:07:36 -0500 From: George Swallow > > Wouldn't be the right way to proceed by defining an "unknown" > > or "unspecified" value used when "traffic-parameters" are > > included within the Path Message and optional use the ones > > proposed in the current version of the specification when they > > aren't. This field is thus optional and MUST only be used when "MUST only" seems a bit strong. I don't see why one should have to reject a Sonet connection that had a Switching Type of TDM. Perhaps "only MUST" was the intent. I think the actual wording should be something to the effect, When the switching type is implied traffic-parameters the Switching Type field is ignored. The Switching Type field SHOULD be set to either the implied value or to UNKNOWN. When the switching type is not implied by the traffic-parameters it MUST be set to one of the values [pointer to appropriate list] other than the value UNKNOWN. The definition of the traffic parameters of Sonet should also carry a note that the ST of TDM is implied. ...George > > traffic parameters are not defined. I think this solves both > > approaches. > > Agreed. ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 04:06:43 -0800 Message-Id: <200111011203.HAA11068@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-lmp-02.txt Date: Thu, 01 Nov 2001 07:03:24 -0500 --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 : Link Management Protocol (LMP) Author(s) : J. Lang et al. Filename : draft-ietf-ccamp-lmp-02.txt Pages : 65 Date : 31-Oct-01 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with control channels and data links. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and is used to manage TE links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-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-lmp-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-lmp-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: <20011031112030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lmp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011031112030.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 03:44:12 -0800 Message-ID: From: neil.2.harrison@bt.com To: mvissers@lucent.com, yakov@juniper.net Cc: zwlin@lucent.com, ccamp@ops.ietf.org Subject: RE: Moving right along ... Switching Type Date: Thu, 1 Nov 2001 11:41:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Watching this discussion unfold it seems that many would benefit from a read of G.805 on functional arch and what layering/partitioning mean. I saw someone (Zhi I think) refer to 'adaptation' (ie the required functionality at client<=>server boundaries) but I wonder if most people understand what he meant by this?....which is also at the root of what Maarten is talking about below, ie it all depends on where trails start and terminate....or put another way 'clinet layer link connections = server layer trails', where each clinet layer link connection can be served by a different technology trail. You can't start a trail using technology X and terminate it using technology Y, this makes no sense as Maarten states below.....in transport networks trail termination points must come in matching (technology) pairs. regards, Neil > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: 01 November 2001 11:03 > To: Yakov Rekhter > Cc: Zhi-Wei Lin; ccamp@ops.ietf.org > Subject: Re: Moving right along ... Switching Type > > > Yakov, > > It depends on what your definition of "OXC" is... > > - if it is a box with fibers connected to it it can be a > SDH/SONET ADM or cross > connect, in which case it makes a lot of sense... the 1GE > physical interfaces > are terminated and the packets are mapped via GFP (Rec. G.7041) into > STS-3c-Xv/VC-4-Xv or STS-1-Xv signals for further transport. > It is becoming > popular already to do this... > I.e. the transport network is very capable to mix and match > different interface > types at its edges. Some other examples: DS3 - network - > OC48, 100ME - network - > 1GE, E1 - network - STM1, 1000BaseX - network - 1000BaseT > > - if it is a box with just an optical fabric, it doesn't make > sense of course... > 1GE port on R1 and OC-48 port on R2 "don't speak the same language". > > Regards, > > Maarten > > Yakov Rekhter wrote: > > > > Zhi-Wei, > > > > > Maybe this is one where we need to ask individuals > with operational > > > experience and have some experience with service > provisioning whether > > > having one end with Ethernet and another end with OC-48 > sounds like a > > > configuration that makes sense? > > > > Let me see if I understand your proposal. Consider the following > > example: > > > > R1---OXC1---OXC2----R2 > > > > where the TE interface on R1 is a collection of GigE ports, > and the TE > > interface on R2 is a collection of OC-48 ports. Are you saying that > > establishing an LSP between R1 to R2 makes sense ? > > > > Yakov. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 03:07:54 -0800 Cc: Zhi-Wei Lin , ccamp@ops.ietf.org Message-ID: <3BE12BD9.F0A23B0A@lucent.com> Date: Thu, 01 Nov 2001 12:02:49 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Yakov Rekhter Original-CC: Zhi-Wei Lin , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------C65AED3ACC0D80984F807D6D" This is a multi-part message in MIME format. --------------C65AED3ACC0D80984F807D6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yakov, It depends on what your definition of "OXC" is... - if it is a box with fibers connected to it it can be a SDH/SONET ADM or cross connect, in which case it makes a lot of sense... the 1GE physical interfaces are terminated and the packets are mapped via GFP (Rec. G.7041) into STS-3c-Xv/VC-4-Xv or STS-1-Xv signals for further transport. It is becoming popular already to do this... I.e. the transport network is very capable to mix and match different interface types at its edges. Some other examples: DS3 - network - OC48, 100ME - network - 1GE, E1 - network - STM1, 1000BaseX - network - 1000BaseT - if it is a box with just an optical fabric, it doesn't make sense of course... 1GE port on R1 and OC-48 port on R2 "don't speak the same language". Regards, Maarten Yakov Rekhter wrote: > > Zhi-Wei, > > > Maybe this is one where we need to ask individuals with operational > > experience and have some experience with service provisioning whether > > having one end with Ethernet and another end with OC-48 sounds like a > > configuration that makes sense? > > Let me see if I understand your proposal. Consider the following > example: > > R1---OXC1---OXC2----R2 > > where the TE interface on R1 is a collection of GigE ports, and the TE > interface on R2 is a collection of OC-48 ports. Are you saying that > establishing an LSP between R1 to R2 makes sense ? > > Yakov. --------------C65AED3ACC0D80984F807D6D 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 --------------C65AED3ACC0D80984F807D6D-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Nov 2001 02:33:27 -0800 Cc: Zhi-Wei Lin , John Drake , "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Message-ID: <3BE1244E.9E1F6EFE@lucent.com> Date: Thu, 01 Nov 2001 11:30:38 +0100 From: Maarten Vissers Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri Papadimitriou Original-CC: Zhi-Wei Lin , John Drake , "'Ben Mack-Crane'" , Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: Moving right along ... Switching Type Content-Type: multipart/mixed; boundary="------------655584A9C12472CF75FD4212" This is a multi-part message in MIME format. --------------655584A9C12472CF75FD4212 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In a layered network approach (e.g. ASON), the switching type is obsolete... the routing is performed within a single layer network, using the links (ITU-T term) that are available in that layer network. >From a layer network's perspective, nodes have just a single switching capability (i.e. of that layer network)... nodes who do not have that switching capabiltiy are invisible... and nodes with this and other switching capabilities will only be presented with this layer network's switching capability; the other switching capabilities are invisible. Perhaps a additional sentence should be added to clarify that the switching type is obsolete for the case of a layered network approach. Regards, Maarten Dimitri Papadimitriou wrote: > > Hi, > > We have two approaches either "traffic-parameters" are used > (in SENDER_TSPEC) then i think the Switching Type capability > is useless or they aren't then such field could be optionaly > used when applicable (some examples are given in the routing > document). > > Wouldn't be the right way to proceed by defining an "unknown" > or "unspecified" value used when "traffic-parameters" are > included within the Path Message and optional use the ones > proposed in the current version of the specification when they > aren't. This field is thus optional and MUST only be used when > traffic parameters are not defined. I think this solves both > approaches. > > I think that also some additional text is needed in order to > clarify the semantic; the following one can be proposed (after > having discussed with some individuals): > "The Switching Type field is provided to allow nodes having > multiple switching layer capabilities to indicate their > preference. This field should only be used to indicate the > link switching preference but not end-to-end switching > preference". > > Notice that some proposal concerning the applicability scope > have been proposed but never really committed within the I-D. > > Cheers, > - dimitri. > > Zhi-Wei Lin wrote: > > > > Hi John, > > > > > The section you mentioned, from what I can tell, is an example list > > > of some possible combinations of different equipment functions. I see > > > them as examples. But as I said, from routing perspective, it may make > > > sense but not signaling. What you've pointed out is the routing document... > > > From signaling perspective, if I removed the switching capability > > > field, there is nothing lost...do you agree? > > > > > > > > > JD: No. I will try again. What you have to demonstrate is that for all > > > possible combinations of switching capabilities supported on a link, an > > > intermediate node can deduce, from other fields in the Path message, what > > > switching capability is desired. > > > > > > > Wow...ok...so I have to list all the different combinations of > > different switching capabilities on each side and the possible > > connections and then demonstrate that what switching capability is > > desired can be deduced...hmmm...can't I just say that whatever the > > encoding type says and the sender_tspec says is what the switching type > > used (I'm lazy, it takes too long to run through all the combinations) > > > > > > > > And if I removed the switching capability field, then it opens the door > > > for the possibility where somewhere within my network I might change the > > > switching type in order to satisfy a request (because the switching type > > > requested is non-existent or exhausted). > > > > > > > > > JD: Please give an example of where substituting one value of switching > > > capability for another in the middle of an LSP makes sense. > > > > > > > Well, for example, you have a SONET network that can provide STS-48c, > > and it goes through an all-optical network that can provide OCh1 (2.5G > > service). In the SONET network it switches the STS-48c layer, while in > > OTN network it switches the OCh layer. This is very similar to E1/VC-12 > > connection, where one part of network may work PDH-based and switching > > E1 while another part may be SDH-based and switching VC-12, but the > > connection or service is essentially the same. They're not really > > client-server layers but similar layers from different technologies... > > > > > I think it does make sense. I think you have to assume that within > > > the switched transport network there will be many kinds of interfaces > > > connecting to the transport network. If you can't offer this capability, > > > then essentially what you've done is segment the transport network into > > > sub-networks based on what interfaces they have and only the like-type > > > interfaces can connect to each other. If you look at the IP world, you > > > might have a switch with 100 Mbps and another with 10 Mbps connected > > > together and talking to each other without a problem. This is capability > > > that is also needed, where one end could be 1 Gbps Ethernet and another > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no > > > reason to restrict this). What really matters is that the service is > > > delivered. Granted there will be some inefficiencies in this, but that's > > > really a policy decision whether users are willing to accept this type > > > of connection. > > > > > > > > > JD: What you're describing here is PSC LSPs and they work just fine. What > > > you were describing in your previous example was an LSP, one end of which > > > was > > > PSC and the other end of which was TDM. And that doesn't make sense. > > > > > > > Maybe this is one where we need to ask individuals with operational > > experience and have some experience with service provisioning whether > > having one end with Ethernet and another end with OC-48 sounds like a > > configuration that makes sense? > > > > Again, the point here is that if this doesn't make sense, then > > essentially what you have is multiple switched networks, each serving > > one particular type of customer interface, i.e., a switched network for > > 1 Gb Ethernet, a switched network for OC-48, etc. > > > > Is this one of those "violent agreements" where we're concentrating on > > two different levels but saying the same thing? --------------655584A9C12472CF75FD4212 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 --------------655584A9C12472CF75FD4212--