Subject: Re: Bandwidth modification in GMPLS
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Sat, 01 Dec 2001 00:42:59 -0700

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 <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>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

Delivery-date: Fri, 30 Nov 2001 23:33:42 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: LSC Interface Doubt ...
Date: Sat, 01 Dec 2001 00:31:16 -0700

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

Delivery-date: Fri, 30 Nov 2001 15:14:33 -0800
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Cc: ccamp <[email-masked]>, q14/15 <[email-masked]>
Subject: RE: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
Date: Fri, 30 Nov 2001 18:11:47 -0500

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:[email-masked]]
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

Delivery-date: Fri, 30 Nov 2001 12:15:12 -0800
Date: Fri, 30 Nov 2001 15:09:09 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: question on draft-ietf-ccamp-ospf-gmpls-extensions-01.txt, draft-katz-yeung-ospf-traffic-06.txt

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

Delivery-date: Fri, 30 Nov 2001 11:36:22 -0800
To: Edward Harrison <[email-masked]>
cc: "Karmakar, Soumen" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Fri, 30 Nov 2001 11:32:16 -0800
From: Yakov Rekhter <[email-masked]>

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.

Delivery-date: Fri, 30 Nov 2001 10:36:11 -0800
From: Edward Harrison <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>, "Karmakar, Soumen" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
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

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:[email-masked]
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:[email-masked]]
Sent: 29 November 2001 19:06
To: Karmakar, Soumen
Cc: [email-masked]'
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.

Delivery-date: Fri, 30 Nov 2001 07:15:10 -0800
Date: Fri, 30 Nov 2001 10:14:18 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: comments on rsvp-te-06

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

Delivery-date: Fri, 30 Nov 2001 02:57:51 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 30 Nov 2001 02:46:57 -0800
Cc: [email-masked]
Date: Fri, 30 Nov 2001 11:45:25 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Bandwidth modification in GMPLS

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:[email-masked]
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--

Delivery-date: Thu, 29 Nov 2001 18:25:10 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Bandwidth modification in GMPLS
Date: Thu, 29 Nov 2001 19:17:08 -0700

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: [email-masked]
Delivery-date: Thu, 29 Nov 2001 14:19:33 -0800
Date: Thu, 29 Nov 2001 14:12:47 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
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.

Delivery-date: Thu, 29 Nov 2001 13:36:35 -0800
Date: Thu, 29 Nov 2001 16:34:26 -0500
From: Ron Bonica <[email-masked]>
Subject: FW: I-D ACTION:draft-bonica-tunneltrace-02.txt
To: [email-masked]

F.Y.I.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> 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:
> 	[email-masked].
> 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.
> 

Delivery-date: Thu, 29 Nov 2001 12:47:47 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: SE style of reservation in GMPLS
Date: Thu, 29 Nov 2001 13:44:21 -0700

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

Delivery-date: Thu, 29 Nov 2001 11:09:33 -0800
To: "Karmakar, Soumen" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Thu, 29 Nov 2001 11:05:34 -0800
From: Yakov Rekhter <[email-masked]>

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.

Delivery-date: Thu, 29 Nov 2001 10:14:15 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 29 Nov 2001 10:08:59 -0800
From: Shahram Davari <[email-masked]>
To: "'Dave Cooper'" <[email-masked]>, "Dekany, Steven" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: 52nd IETF - MPLS OAM BOF announcement
Date: Thu, 29 Nov 2001 10:02:48 -0800

Hi,

Sure, We will do both.

-Shahram

> -----Original Message-----
> From: Dave Cooper [mailto:[email-masked]]
> Sent: Thursday, November 29, 2001 12:36 PM
> To: Dekany, Steven; Shahram Davari; [email-masked];
> [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Thursday, November 29, 2001 10:40 AM
> > To: [email-masked]; [email-masked]; [email-masked]
> > 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
> > 
> > 
> 

Delivery-date: Thu, 29 Nov 2001 09:43:25 -0800
From: "Dave Cooper" <[email-masked]>
To: "Dekany, Steven" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: 52nd IETF - MPLS OAM BOF announcement
Date: Thu, 29 Nov 2001 09:35:58 -0800

> 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:[email-masked]]
> Sent: Thursday, November 29, 2001 10:40 AM
> To: [email-masked]; [email-masked]; [email-masked]
> 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
> 
> 

Delivery-date: Thu, 29 Nov 2001 09:37:19 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 29 Nov 2001 09:37:12 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 29 Nov 2001 09:37:03 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 29 Nov 2001 09:17:31 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Asymmetric optical links in GMPLS
Date: Thu, 29 Nov 2001 10:14:12 -0700

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

Delivery-date: Thu, 29 Nov 2001 08:59:30 -0800
From: "Dekany, Steven" <[email-masked]>
To: Shahram Davari <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: 52nd IETF - MPLS OAM BOF announcement
Date: Thu, 29 Nov 2001 11:53:50 -0500

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:[email-masked]]
Sent: Thursday, November 29, 2001 10:40 AM
To: [email-masked]; [email-masked]; [email-masked]
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

Delivery-date: Thu, 29 Nov 2001 08:55:10 -0800
Date: Thu, 29 Nov 2001 11:52:40 -0500
From: Carmine Daloia <[email-masked]>
To: Jonathan Lang <[email-masked]>
CC: Sudheer Dharanikota <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FW: [T1X1.5] Re: Suppression of Downstream Alarms...

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."
>
<Carmine> Why did you not include the "pre-G.709" portion of the text?

>
>
>1. Introduction
><snip>
>
>   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 
><snip>
>
>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.
>
<Carmine> 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.
>
<Carmine> 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.
>
>
>
><snip>
>
>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
><snip>
>
>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.
>
><snip>
>
>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."
>
><snip>
>   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.
>
<Carmine> 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?

>
>
><snip>
>
>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 :-)]
>
<Carmine> 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.  
>
<Carmine> 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.
>
<Carmine> 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.  
>
<Carmine> 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
>
<Carmine> 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).
>
><snip>
>
>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.
>
<Carmine> 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:[email-masked]]
>Sent: Monday, November 26, 2001 7:43 AM
>To: Sudheer Dharanikota
>Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
>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
>

Delivery-date: Thu, 29 Nov 2001 08:42:08 -0800
From: Shahram Davari <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: 52nd IETF - MPLS OAM BOF announcement
Date: Thu, 29 Nov 2001 08:40:25 -0800

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

Delivery-date: Wed, 28 Nov 2001 17:27:20 -0800
From: Jonathan Lang <[email-masked]>
To: 'Carmine Daloia' <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Jonathan Lang <[email-masked]>
Subject: FW: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 28 Nov 2001 17:19:24 -0800

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
<snip>

   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 
<snip>

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.

<snip>

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
<snip>

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.

<snip>

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."

<snip>
   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.

<snip>

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).

<snip>

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:[email-masked]]
Sent: Monday, November 26, 2001 7:43 AM
To: Sudheer Dharanikota
Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
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

Delivery-date: Wed, 28 Nov 2001 13:38:56 -0800
Date: Wed, 28 Nov 2001 15:37:53 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Two week Last Call on LMP

Oops.  I re-read my message and found a confusing statement.  See
inline.

[email-masked] 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

Delivery-date: Wed, 28 Nov 2001 13:31:43 -0800
Date: Wed, 28 Nov 2001 15:29:11 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Two week Last Call on LMP

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

Delivery-date: Wed, 28 Nov 2001 02:58:03 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 27 Nov 2001 16:06:17 -0800
From: Jonathan Lang <[email-masked]>
To: 'Baktha Muralidharan' <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>
Subject: RE: Comments on LMP
Date: Tue, 27 Nov 2001 15:57:32 -0800

Baktha,
  Thanks for the comments.  Please see responses inline.

Thanks,
Jonathan

>-----Original Message-----
>From: Baktha Muralidharan [mailto:[email-masked]]
>Sent: Tuesday, November 20, 2001 11:22 AM
>To: [email-masked]
>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>
==========================================================================

<snip>

1. Introduction 
    
<snip>
    
   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. 
    
 <snip>
 
   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.
    
<snip>

3. Control Channel Management 
        
3.2. Hello Protocol 
    
<snip>
    
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.

    
<snip>
    
4. Link Property Correlation 
    
<snip>
    
   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).

<snip>

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.

<snip>
    
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.
    
<snip>

12. 
   LMP Finite State Machines 
    
<snip>
    
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

<snip>

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.

<snip>

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.

<snip>
    
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: 
    
   <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> 
                        <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
[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. 
    
<snip>
    
13.5. 
     Hello Message (MsgType = 4) 
    
   The format of the Hello message is as follows: 
    
   <Hello Message> ::= <Common Header> <LOCAL_CCID> <Hello> 

BM>                                                 ^^^^^^ Should be in
upper case
[Jonathan]thanks.

<snip>
    
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. 
    
   <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                                 <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?
[Jonathan]It provides information as to why the link will not be brought up.
This can be used to correct a misconfiguration.

<snip>
    
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.
 
<snip>
    
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.
    
<snip>
    
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.

Delivery-date: Tue, 27 Nov 2001 08:07:21 -0800
From: "Robin Qiu" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Two week Last Call on LMP
Date: Tue, 27 Nov 2001 11:04:58 -0500

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 <VERIFY_ID> be put at the end of the
   object list for both EndVerifyAck and Test, i.e.
   <EndVerifyAck>::=<CommonHeader><MESSAGE_ID_ACK><VERIFY_ID>
   <Test>::=<CommonHeader><LOCAL_INTERFACE_ID><VERIFY_ID>
   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:[email-masked]]
Sent: Monday, November 12, 2001 9:00 PM
To: [email-masked]
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

Delivery-date: Mon, 26 Nov 2001 22:15:43 -0800
From: Jonathan Lang <[email-masked]>
To: 'S Ramesh' <[email-masked]>
Cc: 'George Young' <[email-masked]>, [email-masked]
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

Ramesh,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 11:35 PM
> To: Jonathan Lang
> Cc: 'George Young'; [email-masked]
> 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:[email-masked]]
> > > Sent: Wednesday, November 21, 2001 5:41 AM
> > > To: Jonathan Lang
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > >Sent: Tuesday, November 20, 2001 11:49 AM
> > > >To: George Young
> > > >Cc: [email-masked]
> > > >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:[email-masked]]
> > > >> Sent: Tuesday, November 20, 2001 8:34 AM
> > > >> To: Jonathan Lang
> > > >> Cc: [email-masked]
> > > >> 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
> > > >> [email-masked].
> > > >>
> > > >> 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:[email-masked]]
> > > >> >Sent: Monday, November 19, 2001 5:21 PM
> > > >> >To: 'S Ramesh'; George Young
> > > >> >Cc: [email-masked]; 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:[email-masked]]
> > > >> >> Sent: Thursday, November 15, 2001 11:15 PM
> > > >> >> To: George Young
> > > >> >> Cc: [email-masked]
> > > >> >> 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:[email-masked]]
> > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> > > >> >> > >To: [email-masked]
> > > >> >> > >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.
> > > >> >> > >
> > > >> >> > >
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
> 

Delivery-date: Mon, 26 Nov 2001 16:24:03 -0800
From: Jonathan Lang <[email-masked]>
To: 'S Ramesh' <[email-masked]>
Cc: 'George Young' <[email-masked]>, [email-masked]
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

Ramesh,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 9:50 PM
> To: Jonathan Lang
> Cc: 'George Young'; [email-masked]
> 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:[email-masked]]
> > > Sent: Wednesday, November 21, 2001 5:41 AM
> > > To: Jonathan Lang
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > >Sent: Tuesday, November 20, 2001 11:49 AM
> > > >To: George Young
> > > >Cc: [email-masked]
> > > >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:[email-masked]]
> > > >> Sent: Tuesday, November 20, 2001 8:34 AM
> > > >> To: Jonathan Lang
> > > >> Cc: [email-masked]
> > > >> 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
> > > >> [email-masked].
> > > >>
> > > >> 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:[email-masked]]
> > > >> >Sent: Monday, November 19, 2001 5:21 PM
> > > >> >To: 'S Ramesh'; George Young
> > > >> >Cc: [email-masked]; 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:[email-masked]]
> > > >> >> Sent: Thursday, November 15, 2001 11:15 PM
> > > >> >> To: George Young
> > > >> >> Cc: [email-masked]
> > > >> >> 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:[email-masked]]
> > > >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> > > >> >> > >To: [email-masked]
> > > >> >> > >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.
> > > >> >> > >
> > > >> >> > >
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
> 

Delivery-date: Mon, 26 Nov 2001 07:43:38 -0800
Date: Mon, 26 Nov 2001 10:42:45 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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

<html>
<head>
</head>
<body>
Hi Sudheer, Jonathan, and all,<br>
<br>
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.<br>
<br>
Please let me know what you think of the proposed text.<br>
The notation I used is as follows:<br>
[Insert: .... new proposed text....]<br>
[Delete: .... text that I propose to be deleted...]<br>
<br>
Thanks<br>
Carmine<br>
<br>
Sudheer Dharanikota wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <pre wrap=""><br>Carmine Daloia wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">Hi Sudheer,<br><br>My last comment wasn't meant to be an argument :-)<br><br>Maybe if I propose some text specific to the suppression<br>of downstream alarms that would help clarify the scope of<br>applicability. The text would state that when client<br>devices (e.g., SONET/SDH cross-connects, IP routers) are<br>interconnected via a standard OTN network then the<br>suppression of downstream alarms is already handled in the<br>transport/user plane via the OTN overhead (both in-band<br>via the digitial overhead as well as out-of-band via<br>non-associated overhead). Also the text would address PXCs<br>within a standard OTN network. In this case, again the<br>suppression of downstream alarms is handled via the OTN<br>overhead.<br><br>The implementation proposed in LMP for suppression of<br>downstream alarms applies to PXCs or client devices (e.g,<br>SONET/SDH cross-connects or IP routers) interconnected via<br>a non-standard DWDM network. In this case, it is as
summed<br>that the non-standard DWDM network does not provide the<br>neccesary overhead within the transport/user plane to<br>suppress alarms on PXCs and client devices and therefore<br>LMP provides a mechanism to carry such alarm suppression<br>messages in the control plane.<br><br>I'll take a crack at specific text so that the group can<br>review it. Does this sound like something that would be<br>helpful.<br><br><br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Sure.<br><br>Regards,<br><br>sudheer<br><br></pre>
    <blockquote type="cite">
      <pre wrap=""><br></pre>
      </blockquote>
      </blockquote>
      <br>
      </body>
      </html>

--------------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: 
    
   <Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID> 
                        <LOCAL_NODE_ID> <CONFIG> 
    
   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 

   <ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID> 
                           <REMOTE_CCID> <MESSAGE_ID_ACK> 
                           <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 = 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> ::= <Common Header> <LOCAL_CCID> 
                            <LOCAL_NODE_ID>  <REMOTE_CCID> 
                            <MESSAGE_ID_ACK> <REMOTE_NODE_ID> 
                            <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 ô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 

   <Hello Message> ::= <Common Header> <LOCAL_CCID> <Hello> 
    
   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: 
    
   <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID> 
                             <MESSAGE_ID> [<REMOTE_LINK_ID>] 
                             <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 = 6) 
    
   When a BeginVerify message is received and Test messages are ready 
   to be processed, a BeginVerifyAck message MUST be transmitted. 
     
   <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>] 
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK> 
                                <VERIFY_ID> 
    
   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. 
    
   <BeginVerifyNack Message> ::= <Common Header> <LOCAL_LINK_ID> 
                                 <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 ô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: 
    
   <EndVerify Message> ::= <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 =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: 
    
   <EndVerifyAck Message> ::= <Common Header> <VERIFY_ID> 
                              <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 = 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> ::= <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                                                   [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.   
    
   <TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID> 
                                   <MESSAGE_ID> <LOCAL_INTERFACE_ID> 
                                   <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 = 12) 
    
   The TestStatusFailure message is transmitted over the control 
   channel and is used to indicate that the Test message was not 
   received. 
    
   <TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID> 
                                   <VERIFY_ID> 
    
   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. 
    
   <TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                               <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 = 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 

   <LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK> 
                             <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 = 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> ::=  <Common Header> <MESSAGE_ID_ACK> 
    
   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. 
    
   <LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK> 
                                 <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. 
    
   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: 
    
   <ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID> 
                               <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 = 18) 
    
   The ChannelStatusAck message is used to acknowledge receipt of the 
   ChannelStatus Message.  The format is as follows: 
    
   <ChannelStatusAck Message> ::= <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 = 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> ::= <Common Header> <LOCAL_LINK_ID> 
                                      <MESSAGE_ID> 
                                      [<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 = 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> ::= <Common Header> <MESSAGE_ID_ACK>  
                                       <CHANNEL_STATUS> 

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: [email-masked]               email: [email-masked] 
    
   John Drake                              Kireeti Kompella 
   Calient Networks                        Juniper Networks, Inc. 
   5853 Rue Ferrari                        385 Ravendale Drive 
   San Jose, CA 95138                      Mountain View, CA 94043 
   email: [email-masked]               email: [email-masked] 
    
   Yakov Rekhter                           Lou Berger 
   Juniper Networks, Inc.                  Movaz Networks  
   385 Ravendale Drive                     email: [email-masked] 
   Mountain View, CA 94043 
   email: [email-masked]                   
    
   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:[email-masked]                 email: [email-masked] 

   Hal Sandick                             Alex Zinin 
   Nortel Networks                         Nexsi Systems 
   email: [email-masked]      1959 Concourse Drive 
                                           San Jose, CA 95131 
                                           email:  [email-masked]  
   Bala Rajagopalan 
   Tellium Optical Systems 
   2 Crescent Place 
   Oceanport, NJ 07757-0901 
   email: [email-masked] 

    

 
Lang et al                                                   [Page 65] 

--------------080401080800090005080500--

Delivery-date: Mon, 26 Nov 2001 07:02:23 -0800
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Date: Mon, 26 Nov 2001 15:55:37 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Subject: Re: draft-bellato-ccamp-g709-framework-01.txt

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:[email-masked]]
> 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:[email-masked]
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--

Delivery-date: Mon, 26 Nov 2001 06:07:16 -0800
Date: Mon, 26 Nov 2001 09:08:50 -0500
From: Carmine Daloia <[email-masked]>
To: Jonathan Lang <[email-masked]>
CC: Sudheer Dharanikota <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
>Sent: Wednesday, November 21, 2001 9:51 AM
>To: Sudheer Dharanikota
>Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
>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:[email-masked]]Sent: Monday, November 19, 2001 6:44 AMTo:
>[email-masked]: [email-masked]; [email-masked]: 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
>

Delivery-date: Mon, 26 Nov 2001 05:37:29 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Subject: RE: draft-bellato-ccamp-g709-framework-01.txt
Date: Mon, 26 Nov 2001 14:25:35 +0100

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:[email-masked]]
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

Delivery-date: Mon, 26 Nov 2001 04:19:46 -0800
To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Mon, 26 Nov 2001 13:16:16 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: draft-bellato-ccamp-g709-framework-01.txt

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:[email-masked]
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--

Delivery-date: Fri, 23 Nov 2001 04:08:45 -0800
Date: Fri, 23 Nov 2001 17:40:49 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: "[email-masked]" <[email-masked]>
Subject: LMP doubts

"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

Delivery-date: Fri, 23 Nov 2001 02:26:59 -0800
To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Fri, 23 Nov 2001 11:26:02 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: draft-bellato-ccamp-g709-framework-01.txt

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:[email-masked]
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--

Delivery-date: Fri, 23 Nov 2001 01:51:34 -0800
Cc: ccamp <[email-masked]>, q14/15 <[email-masked]>
Date: Fri, 23 Nov 2001 10:48:41 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: ccamp <[email-masked]>, q14/15 <[email-masked]>
Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt

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:[email-masked]
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--

Delivery-date: Thu, 22 Nov 2001 09:39:02 -0800
From: "Roese, Josef" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
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:[email-masked]
http://www.t-nova.de

Delivery-date: Thu, 22 Nov 2001 08:10:28 -0800
Date: Thu, 22 Nov 2001 17:01:36 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: ccamp <[email-masked]>
Subject: Re: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------4DB29A324E9913D393DB7446--

Delivery-date: Thu, 22 Nov 2001 07:40:43 -0800
Date: Thu, 22 Nov 2001 16:38:26 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt

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:[email-masked]
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--

Delivery-date: Thu, 22 Nov 2001 06:39:27 -0800
Cc: Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Thu, 22 Nov 2001 15:36:52 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Randy Bush <[email-masked]>
Original-CC: Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

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:[email-masked]
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--

Delivery-date: Thu, 22 Nov 2001 05:34:47 -0800
From: "Gino Carrozzo" <[email-masked]>
To: "ccamp" <[email-masked]>
Subject: relationship between adjacency and link
Date: Thu, 22 Nov 2001 14:28:11 +0100
Organization: Dip. Ingegneria della Informazione

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.

Delivery-date: Wed, 21 Nov 2001 23:32:47 -0800
Date: Thu, 22 Nov 2001 13:05:06 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: Jonathan Lang <[email-masked]>
CC: "'George Young'" <[email-masked]>, [email-masked]
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.

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:[email-masked]]
> > Sent: Wednesday, November 21, 2001 5:41 AM
> > To: Jonathan Lang
> > Cc: [email-masked]
> > 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:[email-masked]]
> > >Sent: Tuesday, November 20, 2001 11:49 AM
> > >To: George Young
> > >Cc: [email-masked]
> > >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:[email-masked]]
> > >> Sent: Tuesday, November 20, 2001 8:34 AM
> > >> To: Jonathan Lang
> > >> Cc: [email-masked]
> > >> 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
> > >> [email-masked].
> > >>
> > >> 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:[email-masked]]
> > >> >Sent: Monday, November 19, 2001 5:21 PM
> > >> >To: 'S Ramesh'; George Young
> > >> >Cc: [email-masked]; 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:[email-masked]]
> > >> >> Sent: Thursday, November 15, 2001 11:15 PM
> > >> >> To: George Young
> > >> >> Cc: [email-masked]
> > >> >> 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:[email-masked]]
> > >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> > >> >> > >To: [email-masked]
> > >> >> > >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.
> > >> >> > >
> > >> >> > >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >

Delivery-date: Wed, 21 Nov 2001 21:49:02 -0800
Date: Thu, 22 Nov 2001 11:19:48 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: Jonathan Lang <[email-masked]>
CC: "'George Young'" <[email-masked]>, [email-masked]
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. 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:[email-masked]]
> > Sent: Wednesday, November 21, 2001 5:41 AM
> > To: Jonathan Lang
> > Cc: [email-masked]
> > 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:[email-masked]]
> > >Sent: Tuesday, November 20, 2001 11:49 AM
> > >To: George Young
> > >Cc: [email-masked]
> > >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:[email-masked]]
> > >> Sent: Tuesday, November 20, 2001 8:34 AM
> > >> To: Jonathan Lang
> > >> Cc: [email-masked]
> > >> 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
> > >> [email-masked].
> > >>
> > >> 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:[email-masked]]
> > >> >Sent: Monday, November 19, 2001 5:21 PM
> > >> >To: 'S Ramesh'; George Young
> > >> >Cc: [email-masked]; 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:[email-masked]]
> > >> >> Sent: Thursday, November 15, 2001 11:15 PM
> > >> >> To: George Young
> > >> >> Cc: [email-masked]
> > >> >> 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:[email-masked]]
> > >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> > >> >> > >To: [email-masked]
> > >> >> > >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.
> > >> >> > >
> > >> >> > >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >

Delivery-date: Wed, 21 Nov 2001 12:04:47 -0800
From: Jonathan Lang <[email-masked]>
To: 'Carmine Daloia' <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 11:57:01 -0800

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:[email-masked]]
Sent: Wednesday, November 21, 2001 9:51 AM
To: Sudheer Dharanikota
Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]Sent: Monday, November 19, 2001 6:44 AMTo:
[email-masked]: [email-masked]; [email-masked]: 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

Delivery-date: Wed, 21 Nov 2001 11:03:16 -0800
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>
Cc: [email-masked]
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

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:[email-masked]]
> Sent: Wednesday, November 21, 2001 5:41 AM
> To: Jonathan Lang
> Cc: [email-masked]
> 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:[email-masked]]
> >Sent: Tuesday, November 20, 2001 11:49 AM
> >To: George Young
> >Cc: [email-masked]
> >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:[email-masked]]
> >> Sent: Tuesday, November 20, 2001 8:34 AM
> >> To: Jonathan Lang
> >> Cc: [email-masked]
> >> 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
> >> [email-masked].
> >> 
> >> 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:[email-masked]]
> >> >Sent: Monday, November 19, 2001 5:21 PM
> >> >To: 'S Ramesh'; George Young
> >> >Cc: [email-masked]; 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:[email-masked]]
> >> >> Sent: Thursday, November 15, 2001 11:15 PM
> >> >> To: George Young
> >> >> Cc: [email-masked]
> >> >> 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:[email-masked]]
> >> >> > >Sent: Monday, November 12, 2001 9:00 PM
> >> >> > >To: [email-masked]
> >> >> > >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.
> >> >> > >
> >> >> > >
> >> >> 
> >> >> 
> >> >
> >> 
> >
> 

Delivery-date: Wed, 21 Nov 2001 10:58:55 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Notify Message in GMPLS
Date: Wed, 21 Nov 2001 11:57:50 -0700

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 <[email-masked]>
>To: 'manoj juneja' <[email-masked]>, "[email-masked]'"  
><[email-masked]>
>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:[email-masked]]
> > Sent: Tuesday, November 20, 2001 5:09 PM
> > To: [email-masked]
> > 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

Delivery-date: Wed, 21 Nov 2001 10:42:35 -0800
From: Jonathan Lang <[email-masked]>
To: 'manoj juneja' <[email-masked]>, "[email-masked]'" <[email-masked]>
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:[email-masked]]
> Sent: Tuesday, November 20, 2001 5:09 PM
> To: [email-masked]
> 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
> 
> 

Delivery-date: Wed, 21 Nov 2001 10:30:16 -0800
From: Jonathan Lang <[email-masked]>
To: 'Carmine Daloia' <[email-masked]>, Sudheer Dharanikota <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 10:20:53 -0800

Carmine,
  Please see comments inline.

Thanks,
Jonathan

<snip>
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:[email-masked]]Sent: Monday, November 19, 2001 6:44 AMTo:
[email-masked]: [email-masked]; [email-masked]: 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

Delivery-date: Wed, 21 Nov 2001 10:09:11 -0800
Date: Wed, 21 Nov 2001 10:04:43 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------6B93A34D6F014244D3C132E7--

Delivery-date: Wed, 21 Nov 2001 10:02:25 -0800
Date: Wed, 21 Nov 2001 06:58:48 -0500
From: [email-masked]
Reply-To: =?iso-8859-1?Q?Mats_Bergstr=F6m?= <[email-masked]>
Subject: I-D ACTION:draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt
To: Mats Bergstrom <[email-masked]>
cc: [email-masked]

---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:
	[email-masked].
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

---2133890903-1144747756-1006364899=:15031--

Delivery-date: Wed, 21 Nov 2001 10:01:43 -0800
Date: Wed, 21 Nov 2001 06:58:14 -0500
From: [email-masked]
Reply-To: =?iso-8859-1?Q?Mats_Bergstr=F6m?= <[email-masked]>
Subject: I-D ACTION:draft-venkatachalam-interarea-mpls-te-02.txt
To: Mats Bergstrom <[email-masked]>
cc: [email-masked]

---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:
	[email-masked].
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

---2133890903-824023566-1006364845=:15031--

Delivery-date: Wed, 21 Nov 2001 09:59:20 -0800
Date: Wed, 21 Nov 2001 12:51:01 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>>>>>>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>>>>>>To: [email-masked]
>>>>>>>>>Cc: [email-masked]; [email-masked]
>>>>>>>>>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

<html>
<head>
</head>
<body>
Hi Sudheer,<br>
<br>
My last comment wasn't meant to be an argument :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'll take a crack at specific text so that the group can review it. Does
this sound like something that would be helpful.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Sudheer Dharanikota wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">   Hi again: 
  <p>Carmine Daloia wrote: </p>
  <blockquote type="CITE">
    <blockquote type="cite" cite="mid:[email-masked]">
      <blockquote type="CITE">&nbsp; <br>
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. <br>
&nbsp;</blockquote>
 Ok Let us address the issues separately... 
        <p>1. Communication between Line System and Cross connect </p>
        <p>Defining a bit-oriented (physical) interface and protocol is not
really the task (in my opinion) <br>
of IETF. <br>
I am not sure if are creating a problem to solve with the alarm suppression. 
        <br>
Let me explain...</p>
        </blockquote>
        <blockquote type="cite" cite="mid:[email-masked]">Let
us assume we can correlate and suppress the alarms between the Line systems 
          <br>
and corss connects. Then we donot need an elaborate bit-oriented protocol. 
This <br>
has an assumption that we are talking about not hundereds of failures but
a couple of <br>
failures (for example fiber cuts).</blockquote>
 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.</blockquote>
 Agreed we need to focus on LMP not DWDM-LMP :-) But... <br>
the intention of the OLI document was to underdstand the requirements. <br>
I thought most of us vouch for these requirements. Let us put the <br>
requirements in the back-burner. If it is bit-oriented protocol it <br>
does not interest most of us :-) 
          <blockquote type="CITE">&nbsp; 
            <blockquote type="cite" cite="mid:[email-masked]">
2. Communication between cross connects 
              <p>THis is needed to localize a fault which in turn can be
used as a trigger for local <br>
restoration.</p>
              </blockquote>
 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. <br>
&nbsp;</blockquote>
 Again... span protection can be performed easily with the current <br>
mechanisms supported by LMP in out-of-band communication <br>
scenarios. 
              <p>In case of overlaping restoration scenarios such as span
and end-to-end <br>
it is required to have a localization + an attempt to recover + (if this
fails) <br>
report to end-to-end entities for recovery. THis also vouch for the <br>
inclusion of such mechanisms in LMP. </p>
              <blockquote type="CITE">&nbsp; <br>
Will this duplication cause major issues in a network. I doubt it... but
it just doesn't seem right from an architecture perspective. 
                <blockquote type="cite" cite="mid:[email-masked]">
&nbsp;</blockquote>
                  </blockquote>
 Well I guess I cannot buy this argument :-) 
                  <p>Cheers, </p>
                  <p>sudheer </p>
                  <blockquote type="CITE">
                    <blockquote type="cite" cite="mid:[email-masked]">
&nbsp; <br>
&nbsp; 
                      <p>- sudheer </p>
                      <blockquote type="CITE">&nbsp; <br>
Thanks <br>
Carmine 
                        <p>Sudheer Dharanikota wrote: </p>
                        <blockquote type="cite" cite="mid:[email-masked]">
Carmine... 
                          <p>Again can you suggest a way to communicate such
signals <br>
between line systems and cross connects when inband <br>
communication is not supported between these two systems? </p>
                          <p>Cheers, </p>
                          <p>sudheer </p>
                          <p>Carmine Daloia wrote: </p>
                          <blockquote type="CITE">Jonathan, 
                            <p>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. </p>
                            <p>Thanks <br>
Carmine </p>
                            <p>Carmine Daloia wrote: </p>
                            <blockquote type="cite" cite="mid:[email-masked]">
Jonathan, 
                              <p>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. </p>
                              <p>Let's look at the following network. </p>
                              <p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3
--- OLSC --- OXC4 </p>
                              <p>Note that the OLS consists of DWDM Mux/Dmux
Terminals and Optical Amplifiers. </p>
                              <p>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... </p>
                              <p>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. </p>
                              <p>Thanks <br>
Carmine </p>
                              <p>Jonathan Lang wrote: </p>
                              <blockquote type="cite" cite="mid:[email-masked]">
                                <pre wrap="">Carmine,<br>&nbsp; Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
                                <blockquote type="cite">
                                  <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems&nbsp;<br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the&nbsp;<br>power monitoring system in all of the downstream nodes may detect LOL&nbsp;<br>and indicate a failure. To avoid multiple alarms stemming from the same&nbsp;<br>failure, LMP
 provides a&nbsp;<br>failure noti<br>fication through the Cha<br>nn<br>elStatus&nbsp;<br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.</pre>
                                  </blockquote>
                                  <pre wrap=""><!---->great!<br><br></pre>
                                  <blockquote type="cite">
                                    <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this&nbsp;<br>capability is already provided by the overhead in SDH/SONET and G.709&nbsp;<br>OTN. G.709 OTN handles suppression of alarms in both all-optical&nbsp;<br>networks as well as opaque networks. I don't think we need to burden the&nbsp;<br>control plane with such functions when the transport plane handles this&nbsp;<br>in standard networks. In fact the transport plane handles suppression of&nbsp;<br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;<br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;<br>a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;<br>an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;<br>downstream Cross-connects would not detect LOL upon faults occurring&nbsp;<br>upstr
eam. The 3R&nbsp;<br>points on th<br>e OLS Line Systems would insert some type&nbsp;<br>of signal dow<br>ns<br>tream. Therefore the mechanism described in Section 6.2&nbsp;<br>does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;<br>that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;<br>in an all-optical network may alarm due to upstream faults. These alarms&nbsp;<br>also need to be suppressed. LMP seems to only address the suppression of&nbsp;<br>downstream alarms on cross-connects without taking into consideration&nbsp;<br>the network that sits between the cross-connects. Is LMP also expected&nbsp;<br>to have to be processed on Optical Amplifiers? This seems to be&nbsp;<br>undesirable, especially given all the various applications that seem to&nbsp;<br>be included into the LMP protocol that would not have anything to do&nbsp;<br>with Optical Amplifieris.</pre>
                                    </blockquote>
                                    <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
                                    <blockquote type="cite">
                                      <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      </blockquote>
                                      <br>
                                      </body>
                                      </html>

--------------040804030604040308000406--

Delivery-date: Wed, 21 Nov 2001 09:40:55 -0800
Date: Wed, 21 Nov 2001 09:31:28 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
>> >> >> > > Sent: Monday, November 19, 2001 6:44 AM
>> >> >> > > To: [email-masked]
>> >> >> > > Cc: [email-masked]; [email-masked]
>> >> >> > > 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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFCC" link="#990000" vlink="#999900" alink="#CC6600">
Hi again:
<p>Carmine Daloia wrote:
<blockquote TYPE=CITE>
<blockquote type="cite" cite="mid:[email-masked]">
<blockquote type="CITE">&nbsp;
<br>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.
<br>&nbsp;</blockquote>
Ok Let us address the issues separately...
<p>1. Communication between Line System and Cross connect
<p>Defining a bit-oriented (physical) interface and protocol is not really
the task (in my opinion)
<br>of IETF.
<br>I am not sure if are creating a problem to solve with the alarm suppression.
<br>Let me explain...</blockquote>

<blockquote type="cite" cite="mid:[email-masked]">Let us assume
we can correlate and suppress the alarms between the Line systems
<br>and corss connects. Then we donot need an elaborate bit-oriented protocol.
This
<br>has an assumption that we are talking about not hundereds of failures
but a couple of
<br>failures (for example fiber cuts).</blockquote>
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.</blockquote>
Agreed we need to focus on LMP not DWDM-LMP :-) But...
<br>the intention of the OLI document was to underdstand the requirements.
<br>I thought most of us vouch for these requirements. Let us put the
<br>requirements in the back-burner. If it is bit-oriented protocol it
<br>does not interest most of us :-)
<blockquote TYPE=CITE>&nbsp;
<blockquote type="cite" cite="mid:[email-masked]">2. Communication
between cross connects
<p>THis is needed to localize a fault which in turn can be used as a trigger
for local
<br>restoration.</blockquote>
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.
<br>&nbsp;</blockquote>
Again... span protection can be performed easily with the current
<br>mechanisms supported by LMP in out-of-band communication
<br>scenarios.
<p>In case of overlaping restoration scenarios such as span and end-to-end
<br>it is required to have a localization + an attempt to recover + (if
this fails)
<br>report to end-to-end entities for recovery. THis also vouch for the
<br>inclusion of such mechanisms in LMP.
<blockquote TYPE=CITE>&nbsp;
<br>Will this duplication cause major issues in a network. I doubt it...
but it just doesn't seem right from an architecture perspective.
<blockquote type="cite" cite="mid:[email-masked]">&nbsp;</blockquote>
</blockquote>
Well I guess I cannot buy this argument :-)
<p>Cheers,
<p>sudheer
<blockquote TYPE=CITE>
<blockquote type="cite" cite="mid:[email-masked]">&nbsp;
<br>&nbsp;
<p>- sudheer
<blockquote type="CITE">&nbsp;
<br>Thanks
<br>Carmine
<p>Sudheer Dharanikota wrote:
<blockquote type="cite" cite="mid:[email-masked]">Carmine...
<p>Again can you suggest a way to communicate such signals
<br>between line systems and cross connects when inband
<br>communication is not supported between these two systems?
<p>Cheers,
<p>sudheer
<p>Carmine Daloia wrote:
<blockquote type="CITE">Jonathan,
<p>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.
<p>Thanks
<br>Carmine
<p>Carmine Daloia wrote:
<blockquote type="cite" cite="mid:[email-masked]">Jonathan,
<p>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.
<p>Let's look at the following network.
<p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
<p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.
<p>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...
<p>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.
<p>Thanks
<br>Carmine
<p>Jonathan Lang wrote:
<blockquote type="cite" cite="mid:[email-masked]">
<pre wrap="">Carmine,
&nbsp; Please see inline.

Thanks,
Jonathan

</pre>

<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]
Sent: Monday, November 19, 2001 6:44 AM
To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Subject: LMP: Suppression of Downstream Alarms...

Hi all,

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

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

I agree that the suppression of downstream alarms is an important issue.</pre>
</blockquote>

<pre wrap=""><!---->great!

</pre>

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

If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;
a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;
an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;
downstream Cross-connects would not detect LOL upon faults occurring&nbsp;
upstream. The 3R&nbsp;
points on th
e OLS Line Systems would insert some type&nbsp;
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2&nbsp;
does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;
that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;
in an all-optical network may alarm due to upstream faults. These alarms&nbsp;
also need to be suppressed. LMP seems to only address the suppression of&nbsp;
downstream alarms on cross-connects without taking into consideration&nbsp;
the network that sits between the cross-connects. Is LMP also expected&nbsp;
to have to be processed on Optical Amplifiers? This seems to be&nbsp;
undesirable, especially given all the various applications that seem to&nbsp;
be included into the LMP protocol that would not have anything to do&nbsp;
with Optical Amplifieris.</pre>
</blockquote>

<pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
<a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).

</pre>

<blockquote type="cite">
<pre wrap="">Any other views?

Carmine

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------8078553F7B350F317A94E247--

Delivery-date: Wed, 21 Nov 2001 09:29:21 -0800
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, Carmine Daloia <[email-masked]>
Cc: [email-masked]
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 09:20:46 -0800

George,
  This note makes a lot of sense.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 6:37 AM
> To: Carmine Daloia
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, November 21, 2001 9:23 AM
> To: George Young
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, November 21, 2001 8:29 AM
> To: Carmine Daloia
> Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
> 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:[email-masked]]
> Sent: Monday, November 19, 2001 6:44 AM
> To:  [email-masked]
> Cc:  [email-masked];  [email-masked]
> 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
> 
> 
> 
> 
> 
> 

Delivery-date: Wed, 21 Nov 2001 09:04:20 -0800
From: Randy Bush <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
Cc: Maarten Vissers <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt
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

Delivery-date: Wed, 21 Nov 2001 09:00:34 -0800
Date: Wed, 21 Nov 2001 17:58:43 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Randy Bush <[email-masked]>
CC: Maarten Vissers <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------44BF390032AB6CB4C1E3D139--

Delivery-date: Wed, 21 Nov 2001 08:52:32 -0800
From: Randy Bush <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt
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

Delivery-date: Wed, 21 Nov 2001 08:47:24 -0800
Date: Wed, 21 Nov 2001 11:49:08 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>>>>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>>>>To: [email-masked]
>>>>>>>Cc: [email-masked]; [email-masked]
>>>>>>>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

<html>
<head>
</head>
<body>
Hi Sudheer,<br>
<br>
See inline.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Sudheer Dharanikota wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">   Hi again: 
  <p>Carmine Daloia wrote: </p>
  <blockquote type="CITE">Sudheer, 
    <p>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. <br>
&nbsp;</p>
    </blockquote>
 Ok Let us address the issues separately... 
    <p>1. Communication between Line System and Cross connect </p>
    <p>Defining a bit-oriented (physical) interface and protocol is not really 
the task (in my opinion) <br>
of IETF.<br>
I am not sure if are creating a problem to solve with the alarm suppression. 
    <br>
Let me explain... </p>
    </blockquote>
    <blockquote type="cite" cite="mid:[email-masked]">
      <p>Let us assume we can correlate and suppress the alarms between the
Line systems <br>
and corss connects. Then we donot need an elaborate bit-oriented protocol. 
This <br>
has an assumption that we are talking about not hundereds of failures but
a couple of <br>
failures (for example fiber cuts).</p>
      </blockquote>
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.<br>
      <blockquote type="cite" cite="mid:[email-masked]">
        <p> </p>
        <p>2. Communication between cross connects </p>
        <p>THis is needed to localize a fault which in turn can be used as
a trigger for local <br>
restoration.</p>
        </blockquote>
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.<br>
        <br>
Will this duplication cause major issues in a network. I doubt it... but
it just doesn't seem right from an architecture perspective.<br>
        <blockquote type="cite" cite="mid:[email-masked]">
          <p> <br>
&nbsp; </p>
          <p>- sudheer </p>
          <blockquote type="CITE">&nbsp; <br>
Thanks <br>
Carmine 
            <p>Sudheer Dharanikota wrote: </p>
            <blockquote type="cite" cite="mid:[email-masked]">
Carmine... 
              <p>Again can you suggest a way to communicate such signals <br>
between line systems and cross connects when inband <br>
communication is not supported between these two systems? </p>
              <p>Cheers, </p>
              <p>sudheer </p>
              <p>Carmine Daloia wrote: </p>
              <blockquote type="CITE">Jonathan, 
                <p>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. </p>
                <p>Thanks <br>
Carmine </p>
                <p>Carmine Daloia wrote: </p>
                <blockquote type="cite" cite="mid:[email-masked]">
Jonathan, 
                  <p>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. </p>
                  <p>Let's look at the following network. </p>
                  <p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC ---
OXC4 </p>
                  <p>Note that the OLS consists of DWDM Mux/Dmux Terminals
and Optical Amplifiers. </p>
                  <p>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... </p>
                  <p>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. </p>
                  <p>Thanks <br>
Carmine </p>
                  <p>Jonathan Lang wrote: </p>
                  <blockquote type="cite" cite="mid:[email-masked]">
                    <pre wrap="">Carmine,<br>&nbsp; Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
                    <blockquote type="cite">
                      <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems&nbsp;<br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the&nbsp;<br>power monitoring system in all of the downstream nodes may detect LOL&nbsp;<br>and indicate a failure. To avoid multiple alarms stemming from the same&nbsp;<br>failure, LMP provides a 
failure noti<br>fication through the Cha<br>nn<br>elStatus&nbsp;<br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.</pre>
                      </blockquote>
                      <pre wrap=""><!---->great!<br><br></pre>
                      <blockquote type="cite">
                        <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this&nbsp;<br>capability is already provided by the overhead in SDH/SONET and G.709&nbsp;<br>OTN. G.709 OTN handles suppression of alarms in both all-optical&nbsp;<br>networks as well as opaque networks. I don't think we need to burden the&nbsp;<br>control plane with such functions when the transport plane handles this&nbsp;<br>in standard networks. In fact the transport plane handles suppression of&nbsp;<br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;<br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;<br>a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;<br>an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;<br>downstream Cross-connects would not detect LOL upon faults occurring&nbsp;<br>upstream. The 3R 
points on th<br>e OLS Line Systems would insert some type&nbsp;<br>of signal dow<br>ns<br>tream. Therefore the mechanism described in Section 6.2&nbsp;<br>does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;<br>that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;<br>in an all-optical network may alarm due to upstream faults. These alarms&nbsp;<br>also need to be suppressed. LMP seems to only address the suppression of&nbsp;<br>downstream alarms on cross-connects without taking into consideration&nbsp;<br>the network that sits between the cross-connects. Is LMP also expected&nbsp;<br>to have to be processed on Optical Amplifiers? This seems to be&nbsp;<br>undesirable, especially given all the various applications that seem to&nbsp;<br>be included into the LMP protocol that would not have anything to do&nbsp;<br>with Optical Amplifieris.</pre>
                        </blockquote>
                        <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
                        <blockquote type="cite">
                          <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
                          </blockquote>
                          </blockquote>
                          </blockquote>
                          </blockquote>
                          </blockquote>
                          </blockquote>
                          </blockquote>
                          <br>
                          </body>
                          </html>

--------------060407020908050009020402--

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)
Date:  Wed, 21 Nov 2001 11:17:59 -0500
From: "George Young" <[email-masked]>
To: <[email-masked]>

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:

 <<RE: Two week Last Call on LMP (Sections 12.3.3 and 12.3.4)>>=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: <[email-masked]>
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" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]
>Sent: Tuesday, November 20, 2001 11:49 AM
>To: George Young
>Cc: [email-masked]
>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:[email-masked]]
>> Sent: Tuesday, November 20, 2001 8:34 AM
>> To: Jonathan Lang
>> Cc: [email-masked]
>> 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
>> [email-masked].
>>=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:[email-masked]]
>> >Sent: Monday, November 19, 2001 5:21 PM
>> >To: 'S Ramesh'; George Young
>> >Cc: [email-masked]; 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:[email-masked]]
>> >> Sent: Thursday, November 15, 2001 11:15 PM
>> >> To: George Young
>> >> Cc: [email-masked]
>> >> 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:[email-masked]]
>> >> > >Sent: Monday, November 12, 2001 9:00 PM
>> >> > >To: [email-masked]
>> >> > >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--

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...
Date:  Wed, 21 Nov 2001 11:15:02 -0500
From: "George Young" <[email-masked]>
To: <[email-masked]>

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:

 <<RE: [T1X1.5] Re: Suppression of Downstream Alarms...>>  <<RE:
[T1X1.5] Re: Suppression of Downstream Alarms...>>=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: <[email-masked]>
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" <[email-masked]>
To: "Carmine Daloia" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]
Sent: Wednesday, November 21, 2001 9:23 AM
To: George Young
Cc: [email-masked]
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:[email-masked]]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Monday, November 19, 2001 6:44 AM
To:  [email-masked]
Cc:  [email-masked];  [email-masked]
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: <[email-masked]>
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" <[email-masked]>
To: "Carmine Daloia" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]
Sent: Wednesday, November 21, 2001 8:29 AM
To: Carmine Daloia
Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Monday, November 19, 2001 6:44 AM
To:  [email-masked]
Cc:  [email-masked];  [email-masked]
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--

Delivery-date: Wed, 21 Nov 2001 08:05:19 -0800
Date: Wed, 21 Nov 2001 17:01:10 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------37D4C642377700967AB87A75--

Delivery-date: Wed, 21 Nov 2001 08:03:47 -0800
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 21 Nov 2001 16:55:50 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

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:[email-masked]
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--

Delivery-date: Wed, 21 Nov 2001 08:02:43 -0800
Date: Wed, 21 Nov 2001 16:51:58 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
> > > >> > Sent: Monday, November 19, 2001 6:44 AM
> > > >> > To: [email-masked]
> > > >> > Cc: [email-masked]; [email-masked]
> > > >> > 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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------B4CBE31CB61BED0EACE832CB--

Delivery-date: Wed, 21 Nov 2001 07:48:33 -0800
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 21 Nov 2001 16:40:30 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
> > >> > Sent: Monday, November 19, 2001 6:44 AM
> > >> > To: [email-masked]
> > >> > Cc: [email-masked]; [email-masked]
> > >> > 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:[email-masked]
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--

Delivery-date: Wed, 21 Nov 2001 07:48:24 -0800
Date: Wed, 21 Nov 2001 07:39:46 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: George Young <[email-masked]>, [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked] ]
>> >>       Sent: Wednesday, November 21, 2001 8:29 AM
>> >>       To: Carmine Daloia
>> >>       Cc: Jonathan Lang; [email-masked] ;
>> >>       [email-masked] ; [email-masked]
>> >>       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:[email-masked]]
>> >>      >> > Sent: Monday, November 19, 2001 6:44
>> >>      >> > AM
>> >>      >> > To: [email-masked]
>> >>      >> > Cc: [email-masked]; [email-masked]
>> >>      >> > 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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFCC" link="#990000" vlink="#999900" alink="#CC6600">
Hi Carmen:
<p>It is common to deploy a local restoration for faster recovery for some
faults
<br>(such as fiber cut) and end-to-end recovery for little slower recovery
for
<br>faults such as node failures.
<p>In such a scenario... what do you mean by head-end and tail-end :-)
<p>Cheers,
<p>sudheer
<br>&nbsp;
<p>Carmine Daloia wrote:
<blockquote TYPE=CITE>Hi Sudheer,
<p>See inline.
<p>Thanks
<br>Carmine
<p>Sudheer Dharanikota wrote:
<blockquote type="cite" cite="mid:[email-masked]">Hi Carmine:
<p>Carmine Daloia wrote:
<blockquote type="CITE">Hi George,
<p>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.
<p>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.&nbsp; 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?
<br>&nbsp;</blockquote>
YOur solution precludes local restoration options.</blockquote>

<p><br>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.
<blockquote type="cite" cite="mid:[email-masked]">Cheers,
<p>sudheer
<blockquote type="CITE">&nbsp;
<br>Thanks
<br>Carmine
<p>George Young wrote:
<blockquote type="cite" cite="mid:[email-masked]"><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>Hello
Carmine,</span><span class="473554113-21112001"> Meriton Networks intends
to use LMP as a fault localization mechanism in a network of</span><span class="473554113-21112001">
our&nbsp;</span><span class="473554113-21112001"> transparent optical switches,
currently in the pre-production phase.</span><span class="473554113-21112001">
I've done some discrete event simulation work to characterize the performance
of an IP</span><span class="473554113-21112001"> network in support LMP
management signals, and the resulting signalling messages needed</span><span class="473554113-21112001">
to initiate protection/restoration, and based on the results, have not
seen any need to change&nbsp;</span><span class="473554113-21112001"> our
design direction.</span><span class="473554113-21112001"> I've also written
and submitted an IETF draft&nbsp;</span><span class="473554113-21112001"><a href="http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt">
http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt</span><span class="473554113-21112001"></a>dealing
with the importance of control network performance, particularly when extended
across&nbsp;</span><span class="473554113-21112001"> multiple&nbsp;</span><span class="473554113-21112001">
networks, and would appreciate any comments you might have.</span><span class="473554113-21112001">
Regards,</span><span class="473554113-21112001"> George R. Young</span><span class="473554113-21112001">
Meriton Networks Inc.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>329 March Rd.,
Kanata, ON, Canada, K2K 2E1</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>phone: +1 613-270-9279
Ext 287</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>fax: +1 613-270-9268</font></font></font></span>
<blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,255); ">
<div class="OutlookMessageHeader" dir="Ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>
]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, November
21, 2001 8:29 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Carmine Daloia</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> Jonathan Lang; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>
; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>
; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a></font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [T1X1.5] Re:
Suppression of Downstream Alarms...</font></font></div>
Jonathan,
<p>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.
<p>Thanks
<br>Carmine
<p>Carmine Daloia wrote:
<blockquote cite="mid:[email-masked]" type="cite">Jonathan,
<p>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.
<p>Let's look at the following network.
<p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
<p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.
<p>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...
<p>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.
<p>Thanks
<br>Carmine
<p>Jonathan Lang wrote:
<blockquote cite="mid:[email-masked]" type="cite">
<pre wrap="">Carmine,
&nbsp; Please see inline.

Thanks,
Jonathan

</pre>

<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]
Sent: Monday, November 19, 2001 6:44 AM
To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Subject: LMP: Suppression of Downstream Alarms...

Hi all,

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

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

I agree that the suppression of downstream alarms is an important issue.</pre>
</blockquote>

<pre wrap=""><!---->great!

</pre>

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

If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;
a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;
an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;
downstream Cross-connects would not detect LOL upon faults occurring&nbsp;
upstream. The 3R poin
ts on the OLS Line Systems would insert some type&nbsp;
of signal
&nbsp;dow
ns
tream. Therefore the mechanism described in Section 6.2&nbsp;
does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;
that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;
in an all-optical network may alarm due to upstream faults. These alarms&nbsp;
also need to be suppressed. LMP seems to only address the suppression of&nbsp;
downstream alarms on cross-connects without taking into consideration&nbsp;
the network that sits between the cross-connects. Is LMP also expected&nbsp;
to have to be processed on Optical Amplifiers? This seems to be&nbsp;
undesirable, especially given all the various applications that seem to&nbsp;
be included into the LMP protocol that would not have anything to do&nbsp;
with Optical Amplifieris.</pre>
</blockquote>

<pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
<a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).

</pre>

<blockquote type="cite">
<pre wrap="">Any other views?

Carmine

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------E7360CBE9EF382D223DB7C3C--

Delivery-date: Wed, 21 Nov 2001 07:44:22 -0800
Date: Wed, 21 Nov 2001 07:35:53 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
CC: Carmine Daloia <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

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:[email-masked]]
> > >> > Sent: Monday, November 19, 2001 6:44 AM
> > >> > To: [email-masked]
> > >> > Cc: [email-masked]; [email-masked]
> > >> > 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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------5FA23FC1629C90D7D707D4CD--

Delivery-date: Wed, 21 Nov 2001 07:43:00 -0800
Date: Wed, 21 Nov 2001 07:34:27 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
>> >> >>  Sent: Monday, November 19, 2001 6:44 AM
>> >> >>  To: [email-masked]
>> >> >>  Cc: [email-masked]; [email-masked]
>> >> >>  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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFCC" link="#990000" vlink="#999900" alink="#CC6600">
Hi again:
<p>Carmine Daloia wrote:
<blockquote TYPE=CITE>Sudheer,
<p>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.
<br>&nbsp;</blockquote>
Ok Let us address the issues separately...
<p>1. Communication between Line System and Cross connect
<p>Defining a bit-oriented (physical) interface and protocol is not really
the task (in my opinion)
<br>of IETF. I am not sure if are creating a problem to solve with the
alarm suppression.
<br>Let me explain...
<p>Let us assume we can correlate and suppress the alarms between the Line
systems
<br>and corss connects. Then we donot need an elaborate bit-oriented protocol.
This
<br>has an assumption that we are talking about not hundereds of failures
but a couple of
<br>failures (for example fiber cuts).
<p>2. Communication between cross connects
<p>THis is needed to localize a fault which in turn can be used as a trigger
for local
<br>restoration.
<br>&nbsp;
<p>- sudheer
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Carmine
<p>Sudheer Dharanikota wrote:
<blockquote type="cite" cite="mid:[email-masked]">Carmine...
<p>Again can you suggest a way to communicate such signals
<br>between line systems and cross connects when inband
<br>communication is not supported between these two systems?
<p>Cheers,
<p>sudheer
<p>Carmine Daloia wrote:
<blockquote type="CITE">Jonathan,
<p>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.
<p>Thanks
<br>Carmine
<p>Carmine Daloia wrote:
<blockquote type="cite" cite="mid:[email-masked]">Jonathan,
<p>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.
<p>Let's look at the following network.
<p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
<p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.
<p>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...
<p>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.
<p>Thanks
<br>Carmine
<p>Jonathan Lang wrote:
<blockquote type="cite" cite="mid:[email-masked]">
<pre wrap="">Carmine,
&nbsp; Please see inline.

Thanks,
Jonathan

</pre>

<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]
Sent: Monday, November 19, 2001 6:44 AM
To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Subject: LMP: Suppression of Downstream Alarms...

Hi all,

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

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

I agree that the suppression of downstream alarms is an important issue.</pre>
</blockquote>

<pre wrap=""><!---->great!

</pre>

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

If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;
a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;
an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;
downstream Cross-connects would not detect LOL upon faults occurring&nbsp;
upstream. The 3R points on th
e OLS Line Systems would insert some type&nbsp;
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2&nbsp;
does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;
that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;
in an all-optical network may alarm due to upstream faults. These alarms&nbsp;
also need to be suppressed. LMP seems to only address the suppression of&nbsp;
downstream alarms on cross-connects without taking into consideration&nbsp;
the network that sits between the cross-connects. Is LMP also expected&nbsp;
to have to be processed on Optical Amplifiers? This seems to be&nbsp;
undesirable, especially given all the various applications that seem to&nbsp;
be included into the LMP protocol that would not have anything to do&nbsp;
with Optical Amplifieris.</pre>
</blockquote>

<pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
<a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).

</pre>

<blockquote type="cite">
<pre wrap="">Any other views?

Carmine

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------BBFA08C5A8B1E8B78CEF630F--

Delivery-date: Wed, 21 Nov 2001 07:36:09 -0800
Date: Wed, 21 Nov 2001 16:26:19 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Sudheer Dharanikota <[email-masked]>
CC: Carmine Daloia <[email-masked]>, Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

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:[email-masked]]
> >> > Sent: Monday, November 19, 2001 6:44 AM
> >> > To: [email-masked]
> >> > Cc: [email-masked]; [email-masked]
> >> > 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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------41EB337E149FDCA3F6913650--

Delivery-date: Wed, 21 Nov 2001 07:34:49 -0800
Date: Wed, 21 Nov 2001 10:29:51 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: George Young <[email-masked]>, [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked] ]
>>>     Sent: Wednesday, November 21, 2001 8:29 AM
>>>     To: Carmine Daloia
>>>     Cc: Jonathan Lang; [email-masked] ; [email-masked] ;
>>>     [email-masked]
>>>     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:[email-masked]]
>>>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>>>To: [email-masked]
>>>>>>Cc: [email-masked]; [email-masked]
>>>>>>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

<html>
<head>
</head>
<body>
Hi Sudheer,<br>
<br>
See inline.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Sudheer Dharanikota wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">   Hi Carmine: 
  <p>Carmine Daloia wrote: </p>
  <blockquote type="CITE">Hi George, 
    <p>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. </p>
    <p>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.&nbsp; 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? <br>
&nbsp;</p>
    </blockquote>
 YOur solution precludes local restoration options.</blockquote>
    <br>
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.<br>
    <blockquote type="cite" cite="mid:[email-masked]"> 
      <p>Cheers, </p>
      <p>sudheer </p>
      <blockquote type="CITE">&nbsp; <br>
Thanks <br>
Carmine 
        <p>George Young wrote: </p>
        <blockquote type="cite" cite="mid:[email-masked]"><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
Hello Carmine,</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
Meriton Networks intends to use LMP as a fault localization mechanism in
a network of</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
our&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
transparent optical switches, currently in the pre-production phase.</font></font></font></span>
&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
I've done some discrete event simulation work to characterize the performance 
of an IP</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
network in support LMP management signals, and the resulting signalling messages 
needed</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
to initiate protection/restoration, and based on the results, have not seen 
any need to change&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
our design direction.</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
I've also written and submitted an IETF draft&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1"><a href="http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt">
http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt</a>
          </font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
dealing with the importance of control network performance, particularly
when extended across&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
multiple&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
networks, and would appreciate any comments you might have.</font></font></font></span>
&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
Regards,</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
George R. Young</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000ff"><font size="-1">
Meriton Networks Inc.</font></font></font><br>
          <font face="Arial"><font color="#0000ff"><font size="-1">329 March
Rd., Kanata, ON, Canada, K2K 2E1</font></font></font><br>
          <font face="Arial"><font color="#0000ff"><font size="-1">phone:
+1 613-270-9279 Ext 287</font></font></font><br>
          <font face="Arial"><font color="#0000ff"><font size="-1">fax: +1
613-270-9268</font></font></font></span>
          <blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,255); ">
            <div class="OutlookMessageHeader" dir="Ltr"><font face="Tahoma"><font size="-1">
-----Original Message-----</font></font><br>
            <font face="Tahoma"><font size="-1"><b>From:</b> Carmine Daloia
[<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>
]</font></font><br>
            <font face="Tahoma"><font size="-1"><b>Sent:</b> Wednesday, November 
21, 2001 8:29 AM</font></font><br>
            <font face="Tahoma"><font size="-1"><b>To:</b> Carmine Daloia</font></font><br>
            <font face="Tahoma"><font size="-1"><b>Cc:</b> Jonathan Lang;
            <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">
[email-masked]</a>
; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>
; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>
            </font></font><br>
            <font face="Tahoma"><font size="-1"><b>Subject:</b> Re: [T1X1.5]
Re: Suppression of Downstream Alarms...</font></font><br>
&nbsp;</div>
 Jonathan, 
            <p>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. </p>
            <p>Thanks <br>
Carmine </p>
            <p>Carmine Daloia wrote: </p>
            <blockquote cite="mid:[email-masked]" type="cite">
Jonathan, 
              <p>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. </p>
              <p>Let's look at the following network. </p>
              <p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 
              </p>
              <p>Note that the OLS consists of DWDM Mux/Dmux Terminals and
Optical Amplifiers. </p>
              <p>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... </p>
              <p>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. </p>
              <p>Thanks <br>
Carmine </p>
              <p>Jonathan Lang wrote: </p>
              <blockquote cite="mid:[email-masked]" type="cite">
                <pre wrap="">Carmine,<br>&nbsp; Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
                <blockquote type="cite">
                  <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems&nbsp;<br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the&nbsp;<br>power monitoring system in all of the downstream nodes may detect LOL&nbsp;<br>and indicate a failure. To avoid multiple alarms stemming from the same&nbsp;<br>failure, LMP provides a fail
ure notification through the<br>&nbsp;Cha<br>nn<br>elStatus&nbsp;<br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.</pre>
                  </blockquote>
                  <pre wrap=""><!---->great!<br><br></pre>
                  <blockquote type="cite">
                    <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this&nbsp;<br>capability is already provided by the overhead in SDH/SONET and G.709&nbsp;<br>OTN. G.709 OTN handles suppression of alarms in both all-optical&nbsp;<br>networks as well as opaque networks. I don't think we need to burden the&nbsp;<br>control plane with such functions when the transport plane handles this&nbsp;<br>in standard networks. In fact the transport plane handles suppression of&nbsp;<br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;<br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;<br>a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;<br>an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;<br>downstream Cross-connects would not detect LOL upon faults occurring&nbsp;<br>upstream. The 3R poin
ts on the OLS Line Systems would insert some type&nbsp;<br>of signal<br>&nbsp;dow<br>ns<br>tream. Therefore the mechanism described in Section 6.2&nbsp;<br>does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;<br>that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;<br>in an all-optical network may alarm due to upstream faults. These alarms&nbsp;<br>also need to be suppressed. LMP seems to only address the suppression of&nbsp;<br>downstream alarms on cross-connects without taking into consideration&nbsp;<br>the network that sits between the cross-connects. Is LMP also expected&nbsp;<br>to have to be processed on Optical Amplifiers? This seems to be&nbsp;<br>undesirable, especially given all the various applications that seem to&nbsp;<br>be included into the LMP protocol that would not have anything to do&nbsp;<br>with Optical Amplifieris.</pre>
                    </blockquote>
                    <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
                    <blockquote type="cite">
                      <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
                      </blockquote>
                      </blockquote>
                      </blockquote>
                      </blockquote>
                      </blockquote>
                      </blockquote>
                      </blockquote>
                      <br>
                      </body>
                      </html>

--------------010807000000030807010105--

Delivery-date: Wed, 21 Nov 2001 07:23:07 -0800
Date: Wed, 21 Nov 2001 10:24:23 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>>To: [email-masked]
>>>>>Cc: [email-masked]; [email-masked]
>>>>>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

<html>
<head>
</head>
<body>
Sudheer,<br>
<br>
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.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Sudheer Dharanikota wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">   Carmine... 
  <p>Again can you suggest a way to communicate such signals <br>
between line systems and cross connects when inband <br>
communication is not supported between these two systems? </p>
  <p>Cheers, </p>
  <p>sudheer </p>
  <p>Carmine Daloia wrote: </p>
  <blockquote type="CITE">Jonathan, 
    <p>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. </p>
    <p>Thanks <br>
Carmine </p>
    <p>Carmine Daloia wrote: </p>
    <blockquote type="cite" cite="mid:[email-masked]">Jonathan, 
      <p>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. </p>
      <p>Let's look at the following network. </p>
      <p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 </p>
      <p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical
Amplifiers. </p>
      <p>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... </p>
      <p>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. </p>
      <p>Thanks <br>
Carmine </p>
      <p>Jonathan Lang wrote: </p>
      <blockquote type="cite" cite="mid:[email-masked]">
        <pre wrap="">Carmine,<br>&nbsp; Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
        <blockquote type="cite">
          <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]<br></a>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems&nbsp;<br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the&nbsp;<br>power monitoring system in all of the downstream nodes may detect LOL&nbsp;<br>and indicate a failure. To avoid multiple alarms stemming from the same&nbsp;<br>failure, LMP provides a failure noti
fication through the Cha<br>nn<br>elStatus&nbsp;<br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.</pre>
          </blockquote>
          <pre wrap=""><!---->great!<br><br></pre>
          <blockquote type="cite">
            <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this&nbsp;<br>capability is already provided by the overhead in SDH/SONET and G.709&nbsp;<br>OTN. G.709 OTN handles suppression of alarms in both all-optical&nbsp;<br>networks as well as opaque networks. I don't think we need to burden the&nbsp;<br>control plane with such functions when the transport plane handles this&nbsp;<br>in standard networks. In fact the transport plane handles suppression of&nbsp;<br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;<br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;<br>a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;<br>an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;<br>downstream Cross-connects would not detect LOL upon faults occurring&nbsp;<br>upstream. The 3R points on th
e OLS Line Systems would insert some type&nbsp;<br>of signal dow<br>ns<br>tream. Therefore the mechanism described in Section 6.2&nbsp;<br>does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;<br>that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;<br>in an all-optical network may alarm due to upstream faults. These alarms&nbsp;<br>also need to be suppressed. LMP seems to only address the suppression of&nbsp;<br>downstream alarms on cross-connects without taking into consideration&nbsp;<br>the network that sits between the cross-connects. Is LMP also expected&nbsp;<br>to have to be processed on Optical Amplifiers? This seems to be&nbsp;<br>undesirable, especially given all the various applications that seem to&nbsp;<br>be included into the LMP protocol that would not have anything to do&nbsp;<br>with Optical Amplifieris.</pre>
            </blockquote>
            <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
            <blockquote type="cite">
              <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
              </blockquote>
              </blockquote>
              </blockquote>
              </blockquote>
              </blockquote>
              <br>
              </body>
              </html>

--------------010708010306060809020607--

Delivery-date: Wed, 21 Nov 2001 07:17:55 -0800
Date: Wed, 21 Nov 2001 07:14:28 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: George Young <[email-masked]>, [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
>>      Sent: Wednesday, November 21, 2001 8:29 AM
>>      To: Carmine Daloia
>>      Cc: Jonathan Lang; [email-masked];
>>      [email-masked]; [email-masked]
>>      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:[email-masked]]
>>      >> > Sent: Monday, November 19, 2001 6:44 AM
>>      >> > To: [email-masked]
>>      >> > Cc: [email-masked]; [email-masked]
>>      >> > 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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFCC" link="#990000" vlink="#999900" alink="#CC6600">
Hi Carmine:
<p>Carmine Daloia wrote:
<blockquote TYPE=CITE>Hi George,
<p>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.
<p>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.&nbsp; 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?
<br>&nbsp;</blockquote>
YOur solution precludes local restoration options.
<p>Cheers,
<p>sudheer
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Carmine
<p>George Young wrote:
<blockquote type="cite" cite="mid:[email-masked]"><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>Hello
Carmine,</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>Meriton
Networks intends to use LMP as a fault localization mechanism in a network
of</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>our&nbsp;</span><span class="473554113-21112001">transparent
optical switches, currently in the pre-production phase.</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>I've
done some discrete event simulation work to characterize the performance
of an IP</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>network
in support LMP management signals, and the resulting signalling messages
needed</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>to
initiate protection/restoration, and based on the results, have not seen
any need to change&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>our
design direction.</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>I've
also written and submitted an IETF draft&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1><a href="http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt">http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt</a></font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>dealing
with the importance of control network performance, particularly when extended
across&nbsp;</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>multiple&nbsp;</span><span class="473554113-21112001">networks,
and would appreciate any comments you might have.</font></font></font></span>&nbsp;<span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>Regards,</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>George
R. Young</font></font></font></span><span class="473554113-21112001"><font face="Arial"><font color="#0000FF"><font size=-1>Meriton
Networks Inc.</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>329 March Rd.,
Kanata, ON, Canada, K2K 2E1</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>phone: +1 613-270-9279
Ext 287</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>fax: +1 613-270-9268</font></font></font></span>
<blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,255); ">
<div class="OutlookMessageHeader" dir="Ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, November
21, 2001 8:29 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Carmine Daloia</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> Jonathan Lang; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>;
<a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>;
<a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a></font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [T1X1.5] Re:
Suppression of Downstream Alarms...</font></font>
<br>&nbsp;</div>
Jonathan,
<p>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.
<p>Thanks
<br>Carmine
<p>Carmine Daloia wrote:
<blockquote cite="mid:[email-masked]" type="cite">Jonathan,
<p>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.
<p>Let's look at the following network.
<p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
<p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.
<p>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...
<p>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.
<p>Thanks
<br>Carmine
<p>Jonathan Lang wrote:
<blockquote cite="mid:[email-masked]" type="cite">
<pre wrap="">Carmine,
&nbsp; Please see inline.

Thanks,
Jonathan

</pre>

<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]
Sent: Monday, November 19, 2001 6:44 AM
To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Subject: LMP: Suppression of Downstream Alarms...

Hi all,

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

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

I agree that the suppression of downstream alarms is an important issue.</pre>
</blockquote>

<pre wrap=""><!---->great!

</pre>

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

If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;
a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;
an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;
downstream Cross-connects would not detect LOL upon faults occurring&nbsp;
upstream. The 3R points on the OLS Line Systems would insert some type&nbsp;
of signal
&nbsp;dow
ns
tream. Therefore the mechanism described in Section 6.2&nbsp;
does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;
that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;
in an all-optical network may alarm due to upstream faults. These alarms&nbsp;
also need to be suppressed. LMP seems to only address the suppression of&nbsp;
downstream alarms on cross-connects without taking into consideration&nbsp;
the network that sits between the cross-connects. Is LMP also expected&nbsp;
to have to be processed on Optical Amplifiers? This seems to be&nbsp;
undesirable, especially given all the various applications that seem to&nbsp;
be included into the LMP protocol that would not have anything to do&nbsp;
with Optical Amplifieris.</pre>
</blockquote>

<pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
<a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).

</pre>

<blockquote type="cite">
<pre wrap="">Any other views?

Carmine

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------A54F2507737F464180A10D77--

Delivery-date: Wed, 21 Nov 2001 07:17:37 -0800
Date: Wed, 21 Nov 2001 10:19:04 -0500
From: Carmine Daloia <[email-masked]>
To: Sudheer Dharanikota <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

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:[email-masked]]
>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>To: [email-masked]
>>>>Cc: [email-masked]; [email-masked]
>>>>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
>>>>
>>>>

Delivery-date: Wed, 21 Nov 2001 07:14:48 -0800
Date: Wed, 21 Nov 2001 07:11:14 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

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:[email-masked]]
>> >>  Sent: Monday, November 19, 2001 6:44 AM
>> >>  To: [email-masked]
>> >>  Cc: [email-masked]; [email-masked]
>> >>  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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFCC" link="#990000" vlink="#999900" alink="#CC6600">
Carmine...
<p>Again can you suggest a way to communicate such signals
<br>between line systems and cross connects when inband
<br>communication is not supported between these two systems?
<p>Cheers,
<p>sudheer
<p>Carmine Daloia wrote:
<blockquote TYPE=CITE>Jonathan,
<p>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.
<p>Thanks
<br>Carmine
<p>Carmine Daloia wrote:
<blockquote type="cite" cite="mid:[email-masked]">Jonathan,
<p>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.
<p>Let's look at the following network.
<p>OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
<p>Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.
<p>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...
<p>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.
<p>Thanks
<br>Carmine
<p>Jonathan Lang wrote:
<blockquote type="cite" cite="mid:[email-masked]">
<pre wrap="">Carmine,
&nbsp; Please see inline.

Thanks,
Jonathan

</pre>

<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Carmine Daloia [<a href="mailto:[email-masked]" class="moz-txt-link-freetext">mailto:[email-masked]</a>]
Sent: Monday, November 19, 2001 6:44 AM
To: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Cc: <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]</a>; <a href="mailto:[email-masked]" class="moz-txt-link-abbreviated">[email-masked]
</a>Subject: LMP: Suppression of Downstream Alarms...

Hi all,

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

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

I agree that the suppression of downstream alarms is an important issue.</pre>
</blockquote>

<pre wrap=""><!---->great!

</pre>

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

If we look at a pre-OTN ("non-standard") scenario consisting of&nbsp;
Cross-connects, Optical Line Systems, and Optical Amplifiers supporting&nbsp;
a DWDM networked solution, we can analyze two scenarios. One scenario is&nbsp;
an opaque network (e.g., the OLS supports 3R). In this scenario, the&nbsp;
downstream Cross-connects would not detect LOL upon faults occurring&nbsp;
upstream. The 3R points on the OLS Line Systems would insert some type&nbsp;
of signal dow
ns
tream. Therefore the mechanism described in Section 6.2&nbsp;
does not apply. Another scenario is an all-optical pre-OTN network. Note&nbsp;
that other equipment besides Cross-connects (e.g., Optical Amplifiers)&nbsp;
in an all-optical network may alarm due to upstream faults. These alarms&nbsp;
also need to be suppressed. LMP seems to only address the suppression of&nbsp;
downstream alarms on cross-connects without taking into consideration&nbsp;
the network that sits between the cross-connects. Is LMP also expected&nbsp;
to have to be processed on Optical Amplifiers? This seems to be&nbsp;
undesirable, especially given all the various applications that seem to&nbsp;
be included into the LMP protocol that would not have anything to do&nbsp;
with Optical Amplifieris.</pre>
</blockquote>

<pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI
Requirements document
(<a href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and
corresponding LMP-WDM protocol document (new version to be uploaded
tomorrow, but old version can be found at
<a href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt" class="moz-txt-link-freetext">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).

</pre>

<blockquote type="cite">
<pre wrap="">Any other views?

Carmine

</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------FAFAD5E10173C32B6E34E4CB--

Delivery-date: Wed, 21 Nov 2001 07:14:21 -0800
Date: Wed, 21 Nov 2001 07:08:42 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

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:[email-masked]]
>> > Sent: Monday, November 19, 2001 6:44 AM
>> > To: [email-masked]
>> > Cc: [email-masked]; [email-masked]
>> > 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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------F691D07249C14E7CE3B827C5--

Delivery-date: Wed, 21 Nov 2001 06:51:22 -0800
Date: Wed, 21 Nov 2001 15:47:21 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Germano Gasparini <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms... and more

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:[email-masked]
--------------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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------7BE596F8CF1DB4A964583FF5--

Delivery-date: Wed, 21 Nov 2001 06:20:52 -0800
Date: Wed, 21 Nov 2001 09:22:49 -0500
From: Carmine Daloia <[email-masked]>
To: George Young <[email-masked]>
CC: [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>     Sent: Wednesday, November 21, 2001 8:29 AM
>     To: Carmine Daloia
>     Cc: Jonathan Lang; [email-masked]; [email-masked]; [email-masked]
>     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:[email-masked]]
>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>To: [email-masked]
>>>>Cc: [email-masked]; [email-masked]
>>>>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

<html>
<head>
</head>
<body>
Hi George,<br>
<br>
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.<br>
<br>
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. &nbsp;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?<br>
<br>
Thanks<br>
Carmine<br>
<br>
George Young wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <meta content="MSHTML 5.50.4522.1801" name="GENERATOR">
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
Hello  Carmine,</span></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
Meriton Networks intends to use LMP as a fault  localization mechanism&nbsp;in
a network of</span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
our  </span></font><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
transparent optical switches, currently in the  pre-production phase.</span></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
I've  done some discrete event simulation work to characterize the performance
of an  IP</span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
network&nbsp;in support LMP management signals, and the  resulting signalling
messages needed</span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
to  initiate protection/restoration, and based on the results, have not seen
any  need to change </span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
our  design direction.</span></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
I've  also written and submitted an IETF draft </span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001"><a href="http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt">
http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-00.txt</a>
  </span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
dealing with the importance of control network  performance, particularly
when extended across </span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
multiple </span></font><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
networks, and would appreciate any  comments you might have.</span></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
Regards,</span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001">
George  R. Young</span></font></div>
  <div><font face="Arial" color="#0000ff" size="2"><span class="473554113-21112001"><font face="Arial" size="2">
Meriton Networks  Inc.</font><br>
  <font face="Arial" size="2">329 March Rd., Kanata, ON, Canada, K2K  2E1</font><br>
  <font face="Arial" size="2">phone: +1 613-270-9279 Ext 287</font><br>
  <font face="Arial" size="2">fax: +1 613-270-9268</font></span></font></div>
  <blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,255); ">
    <div class="OutlookMessageHeader" dir="Ltr" align="Left"><font face="Tahoma" size="2">
-----Original Message-----<br>
    <b>From:</b> Carmine Daloia    [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>
    <b>Sent:</b> Wednesday, November 21, 2001 8:29    AM<br>
    <b>To:</b> Carmine Daloia<br>
    <b>Cc:</b> Jonathan Lang;    <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
    <b>Subject:</b> Re:    [T1X1.5] Re: Suppression of Downstream    Alarms...<br>
    <br>
    </font></div>
Jonathan,<br>
    <br>
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.<br>
    <br>
Thanks<br>
Carmine<br>
    <br>
Carmine Daloia wrote:<br>
    <blockquote cite="mid:[email-masked]" type="cite">Jonathan,<br>
      <br>
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.<br>
      <br>
Let's look at the following network.<br>
      <br>
OXC1 --- OLSA ---      OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4<br>
      <br>
Note that the OLS consists      of DWDM Mux/Dmux Terminals and Optical Amplifiers.<br>
      <br>
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...<br>
      <br>
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.<br>
      <br>
Thanks<br>
Carmine<br>
      <br>
Jonathan Lang wrote:<br>
      <blockquote cite="mid:[email-masked]" type="cite">
        <pre wrap="">Carmine,<br>  Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
        <blockquote type="cite">
          <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems <br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the <br>power monitoring system in all of the downstream nodes may detect LOL <br>and indicate a failure. To avoid multiple alarms stemming from the same <br>failure, LMP provides a failure notification through the
 Cha<br>nn<br>elStatus <br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.<br></pre>
          </blockquote>
          <pre wrap=""><!---->great!<br><br></pre>
          <blockquote type="cite">
            <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this <br>capability is already provided by the overhead in SDH/SONET and G.709 <br>OTN. G.709 OTN handles suppression of alarms in both all-optical <br>networks as well as opaque networks. I don't think we need to burden the <br>control plane with such functions when the transport plane handles this <br>in standard networks. In fact the transport plane handles suppression of <br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of <br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting <br>a DWDM networked solution, we can analyze two scenarios. One scenario is <br>an opaque network (e.g., the OLS supports 3R). In this scenario, the <br>downstream Cross-connects would not detect LOL upon faults occurring <br>upstream. The 3R points on the OLS Line Systems would insert some type <br>of signal
 dow<br>ns<br>tream. Therefore the mechanism described in Section 6.2 <br>does not apply. Another scenario is an all-optical pre-OTN network. Note <br>that other equipment besides Cross-connects (e.g., Optical Amplifiers) <br>in an all-optical network may alarm due to upstream faults. These alarms <br>also need to be suppressed. LMP seems to only address the suppression of <br>downstream alarms on cross-connects without taking into consideration <br>the network that sits between the cross-connects. Is LMP also expected <br>to have to be processed on Optical Amplifiers? This seems to be <br>undesirable, especially given all the various applications that seem to <br>be included into the LMP protocol that would not have anything to do <br>with Optical Amplifieris.<br></pre>
            </blockquote>
            <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
            <blockquote type="cite">
              <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
              </blockquote>
              </blockquote>
              <br>
              </blockquote>
              <br>
              </blockquote>
              </blockquote>
              <br>
              </body>
              </html>

--------------020802070302010102080307--

Delivery-date: Wed, 21 Nov 2001 05:27:01 -0800
Date: Wed, 21 Nov 2001 08:28:57 -0500
From: Carmine Daloia <[email-masked]>
To: Carmine Daloia <[email-masked]>
CC: Jonathan Lang <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>>>Sent: Monday, November 19, 2001 6:44 AM
>>>To: [email-masked]
>>>Cc: [email-masked]; [email-masked]
>>>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

<html>
<head>
</head>
<body>
Jonathan,<br>
<br>
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.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Carmine Daloia wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">   Jonathan,<br>
  <br>
 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.<br>
  <br>
 Let's look at the following network.<br>
  <br>
 OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4<br>
  <br>
 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.<br>
  <br>
 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...<br>
  <br>
 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.<br>
  <br>
 Thanks<br>
 Carmine<br>
  <br>
 Jonathan Lang wrote:<br>
  <blockquote type="cite" cite="mid:[email-masked]">
    <pre wrap="">Carmine,<br>  Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems <br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the <br>power monitoring system in all of the downstream nodes may detect LOL <br>and indicate a failure. To avoid multiple alarms stemming from the same <br>failure, LMP provides a failure notification through the Cha
nn<br>elStatus <br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.<br></pre>
      </blockquote>
      <pre wrap=""><!---->great!<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this <br>capability is already provided by the overhead in SDH/SONET and G.709 <br>OTN. G.709 OTN handles suppression of alarms in both all-optical <br>networks as well as opaque networks. I don't think we need to burden the <br>control plane with such functions when the transport plane handles this <br>in standard networks. In fact the transport plane handles suppression of <br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of <br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting <br>a DWDM networked solution, we can analyze two scenarios. One scenario is <br>an opaque network (e.g., the OLS supports 3R). In this scenario, the <br>downstream Cross-connects would not detect LOL upon faults occurring <br>upstream. The 3R points on the OLS Line Systems would insert some type <br>of signal dow
ns<br>tream. Therefore the mechanism described in Section 6.2 <br>does not apply. Another scenario is an all-optical pre-OTN network. Note <br>that other equipment besides Cross-connects (e.g., Optical Amplifiers) <br>in an all-optical network may alarm due to upstream faults. These alarms <br>also need to be suppressed. LMP seems to only address the suppression of <br>downstream alarms on cross-connects without taking into consideration <br>the network that sits between the cross-connects. Is LMP also expected <br>to have to be processed on Optical Amplifiers? This seems to be <br>undesirable, especially given all the various applications that seem to <br>be included into the LMP protocol that would not have anything to do <br>with Optical Amplifieris.<br></pre>
        </blockquote>
        <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
        <blockquote type="cite">
          <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
          </blockquote>
          </blockquote>
          <br>
          </blockquote>
          <br>
          </body>
          </html>

--------------060201060807070400080503--

Delivery-date: Wed, 21 Nov 2001 05:20:15 -0800
Date: Wed, 21 Nov 2001 08:19:08 -0500
From: Carmine Daloia <[email-masked]>
To: Jonathan Lang <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

--------------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:[email-masked]]
>>Sent: Monday, November 19, 2001 6:44 AM
>>To: [email-masked]
>>Cc: [email-masked]; [email-masked]
>>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

<html>
<head>
</head>
<body>
Jonathan,<br>
<br>
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.<br>
<br>
Let's look at the following network.<br>
<br>
OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4<br>
<br>
Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers.<br>
<br>
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...<br>
<br>
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.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Jonathan Lang wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <pre wrap="">Carmine,<br>  Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 6:44 AM<br>To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Subject: LMP: Suppression of Downstream Alarms...<br><br><br>Hi all,<br><br>As I read through Section 6 "Fault Management", one issue that it seems <br>to be addressing is "Suppression of Downstream Alarms".<br><br>In section 6.2, it states that "If data links fail between two PXCs, the <br>power monitoring system in all of the downstream nodes may detect LOL <br>and indicate a failure. To avoid multiple alarms stemming from the same <br>failure, LMP provides a failure notification through the Chann
elStatus <br>message...".<br><br>I agree that the suppression of downstream alarms is an important issue.<br></pre>
    </blockquote>
    <pre wrap=""><!---->great!<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">If we look at standard networks (both SONET/SDH and OTN), this <br>capability is already provided by the overhead in SDH/SONET and G.709 <br>OTN. G.709 OTN handles suppression of alarms in both all-optical <br>networks as well as opaque networks. I don't think we need to burden the <br>control plane with such functions when the transport plane handles this <br>in standard networks. In fact the transport plane handles suppression of <br>alarms on all equipment in the network (not just cross-connects).<br><br>If we look at a pre-OTN ("non-standard") scenario consisting of <br>Cross-connects, Optical Line Systems, and Optical Amplifiers supporting <br>a DWDM networked solution, we can analyze two scenarios. One scenario is <br>an opaque network (e.g., the OLS supports 3R). In this scenario, the <br>downstream Cross-connects would not detect LOL upon faults occurring <br>upstream. The 3R points on the OLS Line Systems would insert some type <br>of signal downs
tream. Therefore the mechanism described in Section 6.2 <br>does not apply. Another scenario is an all-optical pre-OTN network. Note <br>that other equipment besides Cross-connects (e.g., Optical Amplifiers) <br>in an all-optical network may alarm due to upstream faults. These alarms <br>also need to be suppressed. LMP seems to only address the suppression of <br>downstream alarms on cross-connects without taking into consideration <br>the network that sits between the cross-connects. Is LMP also expected <br>to have to be processed on Optical Amplifiers? This seems to be <br>undesirable, especially given all the various applications that seem to <br>be included into the LMP protocol that would not have anything to do <br>with Optical Amplifieris.<br></pre>
      </blockquote>
      <pre wrap=""><!---->For interaction between cross-connects and Line Systems, please see OLI<br>Requirements document<br>(<a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt">http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt</a>) and<br>corresponding LMP-WDM protocol document (new version to be uploaded<br>tomorrow, but old version can be found at<br><a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt">http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt</a>).<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Any other views?<br><br>Carmine<br><br></pre>
        </blockquote>
        </blockquote>
        <br>
        </body>
        </html>

--------------050006010208070300030502--

Delivery-date: Wed, 21 Nov 2001 04:54:36 -0800
Date: Wed, 21 Nov 2001 13:27:01 +0100
From: Germano Gasparini <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re2: Precisation on Suppression of Downstream Alarms...

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:[email-masked]

Delivery-date: Wed, 21 Nov 2001 04:11:57 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 21 Nov 2001 04:11:50 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 21 Nov 2001 04:07:15 -0800
From: "Joe Dumont" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Position of Rsvp DIFFSERV in Rsvp Path Messages
Date: Wed, 21 Nov 2001 22:56:30 +1100

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

Delivery-date: Wed, 21 Nov 2001 02:09:10 -0800
Date: Wed, 21 Nov 2001 10:51:44 +0100
From: Germano Gasparini <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Suppression of Downstream Alarms...

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

[email-masked] 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:[email-masked]]
> > Sent: 20 November 2001 21:04
> > To: 'Carmine Daloia'; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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: [email-masked]
> >
> >
> > -----Original Message-----
> > From: Carmine Daloia [mailto:[email-masked]]
> > Sent: Monday, 19 November, 2001 09:44
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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:[email-masked]

Delivery-date: Wed, 21 Nov 2001 00:01:20 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: SDH Concatenation
Date: Wed, 21 Nov 2001 08:59:47 +0100

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:[email-masked]]
> Sent: Wednesday, November 21, 2001 12:11 AM
> To: [email-masked]
> 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
> 
> 

Delivery-date: Tue, 20 Nov 2001 23:30:43 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 07:28:23 -0000

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:[email-masked]]
> Sent: 20 November 2001 21:04
> To: 'Carmine Daloia'; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: [email-masked]
> 
> 
> -----Original Message-----
> From: Carmine Daloia [mailto:[email-masked]]
> Sent: Monday, 19 November, 2001 09:44
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> 
> 

Delivery-date: Tue, 20 Nov 2001 17:17:27 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Notify Message in GMPLS
Date: Tue, 20 Nov 2001 18:09:24 -0700

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: [email-masked]
Delivery-date: Tue, 20 Nov 2001 17:07:40 -0800
Date: Tue, 20 Nov 2001 17:01:34 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
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 [email-masked] .)
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.

Delivery-date: Tue, 20 Nov 2001 16:33:06 -0800
From: Jonathan Lang <[email-masked]>
To: 'Carmine Daloia' <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Suppression of Downstream Alarms...
Date: Tue, 20 Nov 2001 16:23:58 -0800

Carmine,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Carmine Daloia [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 6:44 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> 

Delivery-date: Tue, 20 Nov 2001 16:03:01 -0800
From: "Malcolm Betts" <[email-masked]>
To: "'Carmine Daloia'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
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: [email-masked]

-----Original Message-----
From: Carmine Daloia [mailto:[email-masked]]
Sent: Monday, 19 November, 2001 09:44
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

Delivery-date: Tue, 20 Nov 2001 15:14:36 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: SDH Concatenation
Date: Tue, 20 Nov 2001 16:10:30 -0700

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

Delivery-date: Tue, 20 Nov 2001 11:29:28 -0800
Date: Tue, 20 Nov 2001 14:21:58 -0500
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on LMP

--=====================_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:

    <Config Message> ::=3D <Common Header> <LOCAL_CCID> <MESSAGE_ID>
                         <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                                                   [Page 37]

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

    <ConfigAck Message> ::=3D <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
                            <REMOTE_CCID> <MESSAGE_ID_ACK>
                            <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>
                             <LOCAL_NODE_ID>  <REMOTE_CCID>
                             <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
                             <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                                                   [Page 38]

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

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

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:

    <BeginVerify Message> ::=3D <Common Header> <LOCAL_LINK_ID>
                              <MESSAGE_ID> [<REMOTE_LINK_ID>]
                              <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>]
                                 <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                 <VERIFY_ID>

    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.

    <BeginVerifyNack Message> ::=3D <Common Header> <LOCAL_LINK_ID>
                                  <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                                                   [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>
                               <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                                                   [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>
                                    <MESSAGE_ID> <LOCAL_INTERFACE_ID>
                                    <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>
                                    <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>
                                <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                                                   [Page 42]

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

    <LinkSummary Message> ::=3D <Common Header> <MESSAGE_ID> <TE_LINK>
                              <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>
                                  <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                                                   [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>
                                <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>
                                       <MESSAGE_ID>
                                       [<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>
                                        <CHANNEL_STATUS>

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: [email-masked]               email: [email-masked]

    John Drake                              Kireeti Kompella
    Calient Networks                        Juniper Networks, Inc.
    5853 Rue Ferrari                        385 Ravendale Drive
    San Jose, CA 95138                      Mountain View, CA 94043
    email: [email-masked]               email: [email-masked]

    Yakov Rekhter                           Lou Berger
    Juniper Networks, Inc.                  Movaz Networks
    385 Ravendale Drive                     email: [email-masked]
    Mountain View, CA 94043
    email: [email-masked]

    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:[email-masked]                 email: [email-masked]

    Hal Sandick                             Alex Zinin
    Nortel Networks                         Nexsi Systems
    email: [email-masked]      1959 Concourse Drive
                                            San Jose, CA 95131
                                            email:  [email-masked]
    Bala Rajagopalan
    Tellium Optical Systems
    2 Crescent Place
    Oceanport, NJ 07757-0901
    email: [email-masked]

Lang et al                                                   [Page 65]

--=====================_22429171==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<font face=3D"Courier New, Courier">Hello,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> Please
find attached my comments; Beside the few I list immediately below,
I<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have embedded most of my comments in the
document, to make it easier to read.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab> My
comments are prefixed BM&gt;<br>
<br>
Thanks,<br>
/Baktha<br>
<br>
----------------------------------------------------------------------------=
-------------------<br>
1. Remove all references to TLVs. We have changed over to Objects.<br>
<br>
2. Draft requires that link summary be sent periodically until an
ack/nack or timeout.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; Whenever a link summary is sent, the expected
outcomes are either a timeout or an<br>
&nbsp;&nbsp;&nbsp;&nbsp; ack/nack, isn't it?<br>
&nbsp;&nbsp;&nbsp;&nbsp; It is not clear then as to whether we recommend
that the &quot;periodic transmission of<br>
&nbsp;&nbsp;&nbsp;&nbsp; link summary&quot; to be stopped upon a timeout.
If that is not what we are recommending, <br>
&nbsp;&nbsp;&nbsp;&nbsp; i.e. we are recommending sending of link summary
regardless of whether we get a response<br>
&nbsp;&nbsp;&nbsp;&nbsp; or not, the above statement is unnecessary and I
believe is actually confusing.<br>
<br>
3. [Parameter] Negotiability is described in terms of objects. Some
objects have subobjects<br>
&nbsp;&nbsp;&nbsp; and/or several attributes. Negotiability at these
&quot;lower granularities&quot; need to be spelt out.<br>
<br>
&nbsp;&nbsp; For example, consider the DATA LINK object; it is
negotiable. And so, are its subobjects.<br>
&nbsp;&nbsp; The data link sub-object carry interface switching
capability, bandwidth and encoding type.<br>
&nbsp;&nbsp; Can we interpret then that ALL of these are negotiable
parameters?. If they are, spelling<br>
&nbsp;&nbsp; them out would help.<br>
<br>
4. Under TE Link FSM, evDCDown is interpreted as &quot;Last data channel
of TE Link has been removed<br>
&nbsp;&nbsp; Under data bearing link evDCDown is described as &quot;data
link is no longer available&quot;.<br>
&nbsp;&nbsp; Administratively shutting down a data bearing link could fit
the &quot;no longer available&quot;<br>
&nbsp;&nbsp; description. Yet, the data bearing link could well be a
member of a TE Link (i.e. might not<br>
&nbsp;&nbsp; have been removed). Suggest using the same=20
description.<br>
<br>
<br>
Please see rest of the comments to be embedded; look for lines starting
with BM&gt;<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
November 2001 <br>
<br>
Network Working
Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
Jonathan P. Lang (Calient Networks) <br>
Internet
Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Krishna Mitra (Calient Networks) <br>
Expiration Date: May
2002&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
John Drake (Calient Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Kireeti Kompella (Juniper Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Yakov Rekhter (Juniper Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Lou Berger (Movaz Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Debanjan Saha (Tellium) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Debashis Basak (Accelight Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
Hal Sandick (Nortel Networks) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Alex Zinin (Nexsi Systems) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bala Rajagopalan (Tellium) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
November 2001 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Link Management Protocol (LMP) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
draft-ietf-ccamp-lmp-02.txt <br>
&nbsp;<br>
&nbsp;Status of this Memo <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This document is an Internet-Draft and is in full
conformance with <br>
&nbsp;&nbsp; all provisions of Section 10 of RFC2026 [RFC2026]. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Internet-Drafts are working documents of the Internet
Engineering <br>
&nbsp;&nbsp; Task Force (IETF), its areas, and its working groups. Note
that <br>
&nbsp;&nbsp; other groups may also distribute working documents as
Internet-<br>
&nbsp;&nbsp; Drafts. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Internet-Drafts are draft documents valid for a maximum of
six <br>
&nbsp;&nbsp; months and may be updated, replaced, or obsoleted by other
documents <br>
&nbsp;&nbsp; at any time. It is inappropriate to use Internet- Drafts as
<br>
&nbsp;&nbsp; reference material or to cite them other than as &quot;work
in progress.&quot; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The list of current Internet-Drafts can be accessed at=20
<br>
&nbsp;&nbsp;
<a href=3D"http://www.ietf.org/ietf/1id-abstracts.txt" eudora=3D"autourl">ht=
tp://www.ietf.org/ietf/1id-abstracts.txt</a>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The list of Internet-Draft Shadow Directories can be accessed=
 at <br>
&nbsp;&nbsp; <a href=3D"http://www.ietf.org/shadow.html"=
 eudora=3D"autourl">http://www.ietf.org/shadow.html</a>. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;Abstract <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Future networks will consist of photonic switches, optical <br>
&nbsp;&nbsp; crossconnects, and routers that may be configured with control=
 <br>
&nbsp;&nbsp; channels and data links.&nbsp; Furthermore, multiple data links=
 may be <br>
&nbsp;&nbsp; combined to form a single traffic engineering (TE) link for=
 routing <br>
&nbsp;&nbsp; purposes. This draft specifies a link management protocol (LMP)=
 that <br>
&nbsp;&nbsp; runs between neighboring nodes and is used to manage TE=
 links.&nbsp; <br>
&nbsp;&nbsp; Specifically, LMP will be used to maintain control channel <br>
&nbsp;&nbsp; connectivity, verify the physical connectivity of the=
 data-bearing <br>
&nbsp;&nbsp; channels, correlate the link property information, and manage=
 link <br>
&nbsp;&nbsp; failures.&nbsp; A unique feature of the fault management=
 technique is <br>
&nbsp;&nbsp; that it is able to localize failures in both opaque and=
 transparent <br>
&nbsp;&nbsp; networks, independent of the encoding scheme used for the data.=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 1] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
Table of Contents <br>
&nbsp;&nbsp; 1&nbsp; Introduction=
 ................................................&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp; 2&nbsp; LMP Overview=
 ................................................&nbsp;&nbsp; 4 <br>
&nbsp;&nbsp; 3 Control Channel Management=
 ...................................&nbsp;&nbsp; 6 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.1 Parameter Negotiation=
 ...................................&nbsp;&nbsp; 7 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2 Hello Protocol=
 ..........................................&nbsp;&nbsp; 8 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2.1&nbsp; Hello=
 Parameter Negotiation ......................&nbsp;&nbsp; 8 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2.2&nbsp; Fast=
 Keep-alive ..................................&nbsp;&nbsp; 9 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2.3&nbsp; Control=
 Channel Down .............................&nbsp; 10 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.2.4&nbsp; Degraded=
 (DEG) State .............................&nbsp; 10 <br>
&nbsp;&nbsp; 4&nbsp; Link Property Correlation=
 ...................................&nbsp; 10 <br>
&nbsp;&nbsp; 5&nbsp; Verifying Link Connectivity=
 .................................&nbsp; 12 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5.1 Example of Link Connectivity Verification=
 ...............&nbsp; 14 <br>
&nbsp;&nbsp; 6&nbsp; Fault Management=
 ............................................&nbsp; 15 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.1 Fault Detection=
 .........................................&nbsp; 15 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.2 Fault Localization Procedure=
 ............................&nbsp; 15 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.3 Examples of Fault Localization=
 ..........................&nbsp; 16 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.4 Channel Activation Indication=
 ...........................&nbsp; 17 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6.5 Channel Deactivation Indication=
 .........................&nbsp; 18 <br>
&nbsp;&nbsp; 7&nbsp; Message_Id Usage=
 ............................................&nbsp; 18 <br>
&nbsp;&nbsp; 8&nbsp; Graceful Restart=
 ............................................&nbsp; 19 <br>
&nbsp;&nbsp; 9&nbsp; Addressing=
 ..................................................&nbsp; 20 <br>
&nbsp;&nbsp; 10 LMP Authentication=
 ..........................................&nbsp; 20 <br>
&nbsp;&nbsp; 11 IANA Considerations=
 .........................................&nbsp; 21 <br>
&nbsp;&nbsp; 12 LMP Finite State Machine=
 ....................................&nbsp; 22 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.1 Control Channel FSM=
 ....................................&nbsp; 22 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.1.1&nbsp; Control=
 Channel States ..........................&nbsp; 22 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.1.2&nbsp; Control=
 Channel Events ..........................&nbsp; 22 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.1.3&nbsp; Control=
 Channel FSM Description .................&nbsp; 25 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.2 TE Link FSM=
 ............................................&nbsp; 26 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.2.1&nbsp; TE link=
 States ..................................&nbsp; 26 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.2.2&nbsp; TE link=
 Events ..................................&nbsp; 26 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.2.3&nbsp; TE link=
 FSM Description .........................&nbsp; 27 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.3 Data Link FSM=
 ..........................................&nbsp; 27 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.3.1&nbsp; Data=
 Link States ................................&nbsp; 28 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.3.2&nbsp; Data=
 Link Events ................................&nbsp; 28 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.3.3&nbsp; Active=
 Data Link FSM Description ................&nbsp; 30 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12.3.4&nbsp; Passive=
 Data Link FSM Description ...............&nbsp; 31 <br>
&nbsp;&nbsp; 13 LMP Message Formats=
 .........................................&nbsp; 32 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.1 Common Header=
 ..........................................&nbsp; 32 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.2 LMP Object Format=
 ......................................&nbsp; 34 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.3Authentication=
 ..........................................&nbsp; 34 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.4 Parameter Negotiation=
 ..................................&nbsp; 37 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.5 Hello=
 ..................................................&nbsp; 38 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.6 Link Verification=
 ......................................&nbsp; 39 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.7 Link Summary=
 ...........................................&nbsp; 42 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13.8 Fault Management=
 .......................................&nbsp; 43 <br>
&nbsp;&nbsp; 14 LMP Object Definitions=
 ......................................&nbsp; 45 <br>
&nbsp;&nbsp; 15 Security Conderations=
 .......................................&nbsp; 63 <br>
&nbsp;&nbsp; 16 References=
 ..................................................&nbsp; 64 <br>
&nbsp;&nbsp; 17 Acknowledgments=
 .............................................&nbsp; 65 <br>
&nbsp;&nbsp; 18 Authors' Addresses&nbsp;=
 .........................................&nbsp; 65 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 2] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; Changes from previous version: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp; Added IANI Considerations section. <br>
<br>
BM&gt; Should be IANA<br>
<br>
&nbsp;&nbsp; o&nbsp; Added clarifying text to the MessageId section. <br>
&nbsp;&nbsp; o&nbsp; Added clarifying text to the ChannelStatus section for=
 fault <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; localization. <br>
&nbsp;&nbsp; o&nbsp; Added Data Link Subobject to DATA_LINK object. <br>
&nbsp;&nbsp;&nbsp; <br>
1. Introduction <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Future networks will consist of photonic switches (PXCs),=
 optical <br>
&nbsp;&nbsp; crossconnects (OXCs), routers, switches, DWDM systems, and=
 add-drop <br>
&nbsp;&nbsp; multiplexors (ADMs) that use a common control plane [e.g., <br>
&nbsp;&nbsp; Generalized MPLS (GMPLS)] to dynamically allocate resources and=
 to <br>
&nbsp;&nbsp; provide network survivability using protection and restoration=
 <br>
&nbsp;&nbsp; techniques.&nbsp; A pair of nodes (e.g., two PXCs) may be=
 connected by <br>
&nbsp;&nbsp; thousands of fibers, and each fiber may be used to transmit=
 multiple <br>
&nbsp;&nbsp; wavelengths if DWDM is used.&nbsp; Furthermore, multiple fibers=
 and/or <br>
&nbsp;&nbsp; multiple wavelengths may be combined into a single traffic-<br>
&nbsp;&nbsp; engineering (TE) link for routing purposes.&nbsp; To enable=
 communication <br>
&nbsp;&nbsp; between nodes for routing, signaling, and link management,=
 control <br>
&nbsp;&nbsp; channels must be established between the node pair; however,=
 the <br>
&nbsp;&nbsp; interface over which the control messages are sent/received may=
 not <br>
&nbsp;&nbsp; be the same interface over which the data flows.&nbsp; This=
 draft <br>
&nbsp;&nbsp; specifies a link management protocol (LMP) that runs between=
 <br>
&nbsp;&nbsp; neighboring nodes and is used to manage TE links. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In this draft, the naming convention of [LAMBDA] is followed,=
 and <br>
&nbsp;&nbsp; OXC is used to refer to all categories of optical=
 crossconnects, <br>
&nbsp;&nbsp; irrespective of the internal switching fabric. Furthermore, a=
 <br>
&nbsp;&nbsp; distinction is made between crossconnects that require=
 opto-<br>
&nbsp;&nbsp; electronic conversion, called digital crossconnects (DXCs), and=
 <br>
&nbsp;&nbsp; those that are all-optical, called photonic switches or=
 photonic <br>
&nbsp;&nbsp; crossconnects (PXCs) - referred to as pure crossconnects in=
 <br>
&nbsp;&nbsp; [LAMBDA], because the transparent nature of PXCs introduces new=
 <br>
&nbsp;&nbsp; restrictions for monitoring and managing the data links.&nbsp;=
 LMP can be <br>
&nbsp;&nbsp; used for any type of node, enhancing the functionality of <br>
&nbsp;&nbsp; traditional DXCs and routers, while enabling PXCs and DWDMs to=
 <br>
&nbsp;&nbsp; intelligently interoperate in heterogeneous optical networks.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In GMPLS, the control channels between two adjacent nodes are=
 no <br>
&nbsp;&nbsp; longer required to use the same physical medium as the=
 data-bearing <br>
&nbsp;&nbsp; links between those nodes. For example, a control channel could=
 use <br>
&nbsp;&nbsp; a separate wavelength or fiber, an Ethernet link, or an IP=
 tunnel <br>
&nbsp;&nbsp; through a separate management network.&nbsp; A consequence of=
 allowing <br>
&nbsp;&nbsp; the control channel(s) between two nodes to be physically=
 diverse <br>
&nbsp;&nbsp; from the associated data links is that the health of a control=
 <br>
&nbsp;&nbsp; channel does not necessarily correlate to the health of the=
 data <br>
&nbsp;&nbsp; links, and vice-versa.&nbsp; Therefore, a clean separation=
 between the <br>
&nbsp;&nbsp; fate of the control channel and data-bearing links must be=
 made.&nbsp; <br>
&nbsp;&nbsp; New mechanisms must be developed to manage the data-bearing=
 links, <br>
&nbsp;&nbsp; both in terms of link provisioning and fault management. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 3] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; For the purposes of this document, a data-bearing link may be=
 either <br>
&nbsp;&nbsp; a &quot;port&quot; or a &quot;component link&quot; depending on=
 its multiplexing <br>
&nbsp;&nbsp; capability; component links are multiplex capable, whereas=
 ports are <br>
&nbsp;&nbsp; not multiplex capable.&nbsp; This distinction is important=
 since the <br>
&nbsp;&nbsp; management of such links (including, for example, resource <br>
&nbsp;&nbsp; allocation, label assignment, and their physical verification)=
 is <br>
&nbsp;&nbsp; different based on their multiplexing capability.&nbsp; For=
 example, a <br>
&nbsp;&nbsp; SONET crossconnect with OC-192 interfaces may be able to=
 demultiplex <br>
&nbsp;&nbsp; the OC-192 stream into four OC-48 streams.&nbsp; If multiple=
 interfaces <br>
&nbsp;&nbsp; are grouped together into a single TE link using link bundling=
 <br>
&nbsp;&nbsp; [BUNDLE], then the link resources must be identified using=
 three <br>
&nbsp;&nbsp; levels: TE link Id, component interface Id, and timeslot=
 label.&nbsp; <br>
&nbsp;&nbsp; Resource allocation happens at the lowest level (timeslots),=
 but <br>
&nbsp;&nbsp; physical connectivity happens at the component link=
 level.&nbsp; As <br>
&nbsp;&nbsp; another example, consider the case where a PXC transparently=
 <br>
&nbsp;&nbsp; switches OC-192 lightpaths.&nbsp; If multiple interfaces are=
 once again <br>
&nbsp;&nbsp; grouped together into a single TE link, then link bundling=
 [BUNDLE] <br>
&nbsp;&nbsp; is not required and only two levels of identification are=
 required:&nbsp; <br>
&nbsp;&nbsp; TE link Id and port Id.&nbsp; In this case, both resource=
 allocation and <br>
&nbsp;&nbsp; physical connectivity happen at the lowest level (i.e. port=
 level). <br>
<br>
BM&gt; It looks like a TE Link is a &quot;group of interfaces&quot;,=
 regardless<br>
BM&gt; of whether they are bundled.<br>
BM&gt; Why &quot;group&quot; multiple interfaces (into a TE Link), if=
 bundling<br>
BM&gt; and the associated benefits are the not the objective?<br>
<br>
&nbsp;&nbsp; To ensure interworking between data links with different <br>
&nbsp;&nbsp; multiplexing capabilities, LMP capable devices SHOULD allow=
 sub-<br>
&nbsp;&nbsp; channels of a component link to be locally configured as=
 (logical) <br>
&nbsp;&nbsp; data links.&nbsp; For example, if a Router with 4 OC-48=
 interfaces is <br>
&nbsp;&nbsp; connected through a 4:1 MUX to an OXC with OC-192c interfaces,=
 the <br>
&nbsp;&nbsp; OXC SHOULD be able to configure each OC-48 sub-channel as a=
 data <br>
&nbsp;&nbsp; link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP is designed to support aggregation of one or more=
 data-bearing <br>
&nbsp;&nbsp; links into a TE link (either ports into TE links, or component=
 links <br>
&nbsp;&nbsp; into TE links). <br>
<br>
BM&gt;<br>
BM&gt; An example of &quot;unbundled aggregation of data links into a<br>
BM&gt; TE Link&quot; would greatly help to clear up<br>
BM&gt;<br>
<br>
2. LMP Overview <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The two core procedures of LMP are control channel management=
 and <br>
&nbsp;&nbsp; link property correlation.&nbsp; Control channel management is=
 used to <br>
&nbsp;&nbsp; establish and maintain control channels between adjacent=
 nodes.&nbsp; <br>
&nbsp;&nbsp; This is done using a Config message exchange and a fast=
 keep-alive <br>
&nbsp;&nbsp; mechanism between the nodes.&nbsp; The latter is required if=
 lower-level <br>
&nbsp;&nbsp; mechanisms are not available to detect control channel=
 failures.&nbsp; <br>
&nbsp;&nbsp; Link property correlation is used to synchronize the TE link=
 <br>
&nbsp;&nbsp; properties and verify configuration. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP requires that a pair of nodes have at least one active=
 bi-<br>
&nbsp;&nbsp; directional control channel between them.&nbsp; The two=
 directions of the <br>
<br>
BM&gt; Aren't control channels always bidirectional?. The successful<br>
BM&gt; config message exchange always marks the &quot;bidirectional<br>
BM&gt; control channel establishment&quot;, isn't it?<br>
BM&gt; Suggest removing the word bidirectional from references to IPCC.<br>
<br>
&nbsp;&nbsp; control channel are coupled together using the LMP Config=
 message <br>
&nbsp;&nbsp; exchange.&nbsp; All LMP messages are IP encoded [except in some=
 cases, <br>
&nbsp;&nbsp; the Test Message which may be limited by the transport=
 mechanism for <br>
&nbsp;&nbsp; in-band messaging].&nbsp; The link level encoding of the=
 control channel <br>
&nbsp;&nbsp; is outside the scope of this document. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 4] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; An =93LMP adjacency=94 is formed between two nodes when at=
 least one bi-<br>
&nbsp;&nbsp; directional control channel is established between them.&nbsp;=
 Multiple <br>
&nbsp;&nbsp; control channels may be active simultaneously for each=
 adjacency; <br>
&nbsp;&nbsp; control channel parameters, however, MUST be individually=
 negotiated <br>
&nbsp;&nbsp; for each control channel.&nbsp; If the LMP fast keep-alive is=
 used over a <br>
&nbsp;&nbsp; control channel, LMP Hello messages MUST be exchanged by the=
 <br>
&nbsp;&nbsp; adjacent nodes over the control channel.&nbsp; Other LMP=
 messages MAY be <br>
&nbsp;&nbsp; transmitted over any of the active control channels between a=
 pair <br>
&nbsp;&nbsp; of adjacent nodes.&nbsp; One or more active control channels=
 may be <br>
&nbsp;&nbsp; grouped into a logical control channel for signaling, routing,=
 and <br>
&nbsp;&nbsp; link property correlation purposes. <br>
&nbsp;&nbsp; <br>
BM&gt; This (the concept of logical control channel) applies to an=
 implementation's<br>
BM&gt; treatment of multiple control channels and should be removed to avoid=
 confusion.<br>
BM&gt; Logical control channels are not discussed elsewhere in the=
 document.<br>
<br>
&nbsp;&nbsp; The link property correlation function of LMP is designed to=
 <br>
&nbsp;&nbsp; aggregate multiple data links (ports or component links) into a=
 TE <br>
&nbsp;&nbsp; link and to synchronize the properties of the TE link.&nbsp; As=
 part of <br>
&nbsp;&nbsp; the link property correlation function, a LinkSummary message=
 <br>
&nbsp;&nbsp; exchange is defined.&nbsp; The LinkSummary message includes the=
 local and <br>
&nbsp;&nbsp; remote TE Link Ids, a list of all data glinks that comprise the=
 TE <br>
BM&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; links<br>
<br>
&nbsp;&nbsp; link, and various link properties.&nbsp; A LinkSummaryAck or=
 <br>
&nbsp;&nbsp; LinkSummaryNack message MUST be sent in response to the receipt=
 of a <br>
&nbsp;&nbsp; LinkSummary message indicating agreement or disagreement on the=
 link <br>
&nbsp;&nbsp; properties. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP messages are transmitted reliably using Message Ids and=
 <br>
&nbsp;&nbsp; retransmissions.&nbsp; Message Ids are carried in MESSAGE_ID=
 objects.&nbsp; No <br>
&nbsp;&nbsp; more than one MESSAGE_ID object may be included in an LMP=
 message.&nbsp; <br>
&nbsp;&nbsp; For control channel specific messages, the Message Id is within=
 the <br>
&nbsp;&nbsp; scope of the control channel over which is the message is sent.=
 For <br>
&nbsp;&nbsp; TE link specific messages, the Message Id is within the scope=
 of the <br>
&nbsp;&nbsp; LMP adjacency.&nbsp; This value of the Message Id is=
 incremented and only <br>
&nbsp;&nbsp; decreases when the value wraps. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In this draft, two additional LMP procedures are defined: link=
 <br>
&nbsp;&nbsp; connectivity verification and fault management.&nbsp; These=
 procedures <br>
&nbsp;&nbsp; are particularly useful when the control channels are=
 physically <br>
&nbsp;&nbsp; diverse from the data-bearing links.&nbsp;&nbsp; Link=
 connectivity <br>
&nbsp;&nbsp; verification is used to verify the physical connectivity of the=
 <br>
&nbsp;&nbsp; data-bearing links between the nodes and exchange the Interface=
 Ids; <br>
&nbsp;&nbsp; Interface Ids are used in GMPLS signaling, either as Port=
 labels or <br>
&nbsp;&nbsp; Component Interface Ids, depending on the configuration.&nbsp;=
 The link <br>
&nbsp;&nbsp; verification procedure uses in-band Test messages that are sent=
 over <br>
&nbsp;&nbsp; the data-bearing links and TestStatus messages that are=
 transmitted <br>
&nbsp;&nbsp; back over the control channel.&nbsp; Note that the Test message=
 is the <br>
&nbsp;&nbsp; only LMP message that must be transmitted over the data-bearing=
 <br>
&nbsp;&nbsp; link.&nbsp; The fault management scheme uses ChannelStatus=
 message <br>
&nbsp;&nbsp; exchanges between adjacent nodes to localize failures in both=
 opaque <br>
&nbsp;&nbsp; and transparent networks, independent of the encoding scheme=
 used <br>
&nbsp;&nbsp; for the data.&nbsp; As a result, both local span and end-to-end=
 path <br>
&nbsp;&nbsp; protection/restoration procedures can be initiated. <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 5] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; For the LMP link connectivity verification procedure, the free=
 <br>
&nbsp;&nbsp; (unallocated) data-bearing links MUST be opaque (i.e., able to=
 be <br>
&nbsp;&nbsp; terminated); however, once a data link is allocated, it may=
 become <br>
&nbsp;&nbsp; transparent.&nbsp; The LMP link connectivity verification=
 procedure is <br>
&nbsp;&nbsp; coordinated using a BeginVerify message exchange over a control=
 <br>
&nbsp;&nbsp; channel.&nbsp; To support various degrees of transparency=
 (e.g., <br>
&nbsp;&nbsp; examining overhead bytes, terminating the payload, etc.), and=
 hence, <br>
&nbsp;&nbsp; different mechanisms to transport the Test messages, a Verify=
 <br>
&nbsp;&nbsp; Transport Mechanism is included in the BeginVerify and <br>
&nbsp;&nbsp; BeginVerifyAck messages.&nbsp; Note that there is no=
 requirement that all <br>
&nbsp;&nbsp; data-bearing links must be terminated simultaneously, but at a=
 <br>
&nbsp;&nbsp; minimum, it must be possible to terminate them one at a=
 time.&nbsp; There <br>
&nbsp;&nbsp; is also no requirement that the control channel and TE link use=
 the <br>
&nbsp;&nbsp; same physical medium; however, the control channel MUST=
 terminate on <br>
&nbsp;&nbsp; the same two nodes that the TE link spans.&nbsp; Since the=
 BeginVerify <br>
<br>
BM&gt; This is true for ALL LMP procedures, not just for connectivity<br>
BM&gt; verification. i.e. CC, by definition, is between a pair of=
 neighbors.<br>
<br>
&nbsp;&nbsp; message exchange coordinates the Test procedure, it also=
 naturally <br>
&nbsp;&nbsp; coordinates the transition of the data links between opaque and=
 <br>
&nbsp;&nbsp; transparent mode. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LMP fault management procedure is based on a ChannelStatus=
 <br>
&nbsp;&nbsp; exchange using the following messages:&nbsp; ChannelStatus,=
 <br>
&nbsp;&nbsp; ChannelStatusAck, ChannelStatusRequest, and=
 ChannelStatusResponse.&nbsp; <br>
&nbsp;&nbsp; The ChannelStatus message is sent unsolicitated and is used to=
 <br>
&nbsp;&nbsp; notify an LMP neighbor about the status of one or more data=
 channels <br>
&nbsp;&nbsp; of a TE link.&nbsp; The ChannelStatusAck message is used to=
 acknowledge&nbsp; <br>
&nbsp;&nbsp; receipt of the ChannelStatus message.&nbsp; The=
 ChannelStatusRequest <br>
&nbsp;&nbsp; message is used to query an LMP neighbor for the status of one=
 or <br>
&nbsp;&nbsp; more data channels of a TE Link.&nbsp; Upon receipt of the <br>
&nbsp;&nbsp; ChannelStatusRequest message, a node MUST send a <br>
&nbsp;&nbsp; ChannelStatusResponse message indicating the states of the=
 queried <br>
&nbsp;&nbsp; data links. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The organization of the remainder of this document is as=
 follows.&nbsp; <br>
&nbsp;&nbsp; In Section 3, the role of the control channel and the messages=
 used <br>
&nbsp;&nbsp; to establish and maintain link connectivity is discussed.&nbsp;=
 In <br>
&nbsp;&nbsp; Section 4, the link property correlation function using the=
 <br>
&nbsp;&nbsp; LinkSummary message exchange is described.&nbsp; The link=
 verification <br>
&nbsp;&nbsp; procedure is discussed in Section 5.&nbsp; In Section 6, it is=
 shown how <br>
&nbsp;&nbsp; LMP will be used to isolate link and channel failures within=
 the <br>
&nbsp;&nbsp; optical network.&nbsp; Several finite state machines (FSMs) are=
 given in <br>
&nbsp;&nbsp; Section 8, and the message formats are defined in Section 9.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
3. Control Channel Management <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To initiate an LMP adjacency between two nodes, one or more=
 bi-<br>
&nbsp;&nbsp; directional control channels MUST be activated.&nbsp; The=
 control <br>
&nbsp;&nbsp; channels can be used to exchange control-plane information such=
 as <br>
&nbsp;&nbsp; link provisioning and fault management information (implemented=
 <br>
&nbsp;&nbsp; using a messaging protocol such as LMP, proposed in this=
 draft), <br>
&nbsp;&nbsp; path management and label distribution information (implemented=
 <br>
&nbsp;&nbsp; using a signaling protocol such as RSVP-TE [RSVP-TE] or CR-LDP=
 [CR-<br>
&nbsp;&nbsp; LDP]), and network topology and state distribution information=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 6] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; (implemented using traffic engineering extensions of protocols=
 such <br>
&nbsp;&nbsp; as OSPF [OSPF-TE] and IS-IS [ISIS-TE]). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; For the purposes of LMP, the exact implementation of the=
 control <br>
&nbsp;&nbsp; channel is not specified; it could be, for example, a separate=
 <br>
&nbsp;&nbsp; wavelength or fiber, an Ethernet link, an IP tunnel through a=
 <br>
&nbsp;&nbsp; separate management network, or the overhead bytes of a=
 data-bearing <br>
&nbsp;&nbsp; link.&nbsp; Rather, a node-wide unique 32-bit non-zero integer=
 control <br>
&nbsp;&nbsp; channel identifier (CCId) is assigned at each end of the=
 control <br>
&nbsp;&nbsp; channel.&nbsp; This identifier comes from the same space as the=
 <br>
&nbsp;&nbsp; unnumbered interface Id.&nbsp; Furthermore, LMP is run directly=
 over IP.&nbsp; <br>
&nbsp;&nbsp; Thus, the link level encoding of the control channel is not=
 part of <br>
&nbsp;&nbsp; the LMP specification. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The control channel can be either explicitly configured or <br>
&nbsp;&nbsp; automatically selected, however, for the purpose of this=
 document <br>
&nbsp;&nbsp; the control channel is assumed to be explicitly configured.=
 Note <br>
&nbsp;&nbsp; that for in-band signaling, a control channel could be=
 explicitly <br>
&nbsp;&nbsp; configured on a particular data-bearing link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Control channels exist independently of TE links and multiple=
 <br>
&nbsp;&nbsp; control channels may be active simultaneously between a pair of=
 <br>
&nbsp;&nbsp; nodes.&nbsp; Individual control channels can be realized in=
 different <br>
&nbsp;&nbsp; ways; one might be implemented in-fiber while another one may=
 be <br>
&nbsp;&nbsp; implemented out-of-fiber.&nbsp; As such, control channel=
 parameters MUST <br>
&nbsp;&nbsp; be negotiated over each individual control channel, and LMP=
 Hello <br>
&nbsp;&nbsp; packets MUST be exchanged over each control channel to maintain=
 LMP <br>
&nbsp;&nbsp; connectivity if other mechanisms are not available.&nbsp; Since=
 control <br>
&nbsp;&nbsp; channels are electrically terminated at each node, it may be=
 <br>
&nbsp;&nbsp; possible to detect control channel failures using lower layers=
 <br>
&nbsp;&nbsp; (e.g., SONET/SDH). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; There are four LMP messages that are used to manage individual=
 <br>
&nbsp;&nbsp; control channels.&nbsp; They are the Config, ConfigAck,=
 ConfigNack, and <br>
&nbsp;&nbsp; Hello messages. These messages MUST be transmitted on the=
 channel to <br>
&nbsp;&nbsp; which they refer.&nbsp; All other LMP messages may be=
 transmitted over <br>
&nbsp;&nbsp; any of the active control channels between a pair of LMP=
 adjacent <br>
&nbsp;&nbsp; nodes. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In order to maintain an LMP adjacency, it is necessary to have=
 at <br>
&nbsp;&nbsp; least one active control channel between a pair of adjacent=
 nodes <br>
&nbsp;&nbsp; (recall that multiple control channels can be active=
 simultaneously <br>
&nbsp;&nbsp; between a pair of nodes).&nbsp; In the event of a control=
 channel <br>
&nbsp;&nbsp; failure, alternate active control channels can be used and it=
 may be <br>
&nbsp;&nbsp; possible to activate additional control channels as mentioned=
 below. <br>
&nbsp;&nbsp;&nbsp; <br>
3.1. Parameter Negotiation <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Control channel activation begins with a parameter negotiation=
 <br>
&nbsp;&nbsp; exchange using Config, ConfigAck, and ConfigNack=
 messages.&nbsp; The <br>
&nbsp;&nbsp; contents of these messages are built using LMP objects, which=
 can be <br>
&nbsp;&nbsp; either negotiable or non-negotiable (identified by the N bit in=
 the <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 7] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; object header).&nbsp; Negotiable objects can be used to let LMP=
 peers <br>
&nbsp;&nbsp; agree on certain values.&nbsp; Non-negotiable objects are used=
 for the <br>
&nbsp;&nbsp; announcement of specific values that do not need, or do not=
 allow, <br>
&nbsp;&nbsp; negotiation. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To begin control channel activation, a node MUST transmit a=
 Config <br>
&nbsp;&nbsp; message to the remote node.&nbsp; The Config message contains=
 the Control <br>
&nbsp;&nbsp; Channel ID (CCID), the sender=92s Node ID, a MessageId for=
 reliable <br>
&nbsp;&nbsp; messaging, and a CONFIG Object.&nbsp; It is possible that both=
 the local <br>
&nbsp;&nbsp; and remote nodes initiate the configuration procedure at the=
 same <br>
&nbsp;&nbsp; time.&nbsp; To avoid ambiguities, the node with the higher Node=
 Id wins <br>
&nbsp;&nbsp; the contention; the node with the lower Node Id MUST stop <br>
&nbsp;&nbsp; transmitting the Config message and respond to the Config=
 message it <br>
&nbsp;&nbsp; received. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ConfigAck message is used to acknowledge receipt of the=
 Config <br>
&nbsp;&nbsp; message and express agreement on ALL of the configured=
 parameters <br>
&nbsp;&nbsp; (both negotiable and non-negotiable).&nbsp; The ConfigNack=
 message is <br>
&nbsp;&nbsp; used to acknowledge receipt of the Config message, indicate=
 which <br>
&nbsp;&nbsp; (if any) non-negotiable CONFIG objects are unacceptable, and=
 propose <br>
&nbsp;&nbsp; alternate values for the negotiable parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If a node receives a ConfigNack message with acceptable=
 alternate <br>
&nbsp;&nbsp; values for negotiable parameters, the node SHOULD transmit a=
 Config <br>
&nbsp;&nbsp; message using these values for those parameters.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If a node receives a ConfigNack message with unacceptable=
 alternate <br>
&nbsp;&nbsp; values, the node MAY continue to retransmit Config=
 messages.&nbsp; Note <br>
&nbsp;&nbsp; that the problem may be solved by an operator changing=
 parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In the case where multiple control channels use the same=
 physical <br>
&nbsp;&nbsp; interface, the parameter negotiation exchange is performed for=
 each <br>
&nbsp;&nbsp; control channel.&nbsp; The various LMP parameter negotiation=
 messages are <br>
&nbsp;&nbsp; associated with their corresponding control channels by their=
 node-<br>
&nbsp;&nbsp; wide unique identifiers (CCIds). <br>
&nbsp;&nbsp;&nbsp; <br>
3.2. Hello Protocol <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Once a control channel is activated between two adjacent nodes,=
 the <br>
&nbsp;&nbsp; LMP Hello protocol can be used to maintain control channel <br>
&nbsp;&nbsp; connectivity between the nodes and to detect control channel=
 <br>
&nbsp;&nbsp; failures.&nbsp; The LMP Hello protocol is intended to be a=
 lightweight <br>
&nbsp;&nbsp; keep-alive mechanism that will react to control channel=
 failures <br>
&nbsp;&nbsp; rapidly so that IGP Hellos are not lost and the associated=
 link-<br>
&nbsp;&nbsp; state adjacencies are not removed unnecessarily. <br>
&nbsp;&nbsp;&nbsp; <br>
3.2.1. Hello Parameter Negotiation <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Before sending Hello messages, the HelloInterval and <br>
&nbsp;&nbsp; HelloDeadInterval parameters MUST be agreed upon by the local=
 and <br>
&nbsp;&nbsp; remote nodes.&nbsp; These parameters are exchanged in the=
 Config message.&nbsp; <br>
&nbsp;&nbsp; The HelloInterval indicates how frequently LMP Hello messages=
 will <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 8] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; be sent, and is measured in milliseconds (ms).&nbsp; For=
 example, if the <br>
&nbsp;&nbsp; value were 150, then the transmitting node would send the Hello=
 <br>
&nbsp;&nbsp; message at least every 150ms.&nbsp; The HelloDeadInterval=
 indicates how <br>
&nbsp;&nbsp; long a device should wait to receive a Hello message before=
 <br>
&nbsp;&nbsp; declaring a control channel dead, and is measured in=
 milliseconds <br>
&nbsp;&nbsp; (ms).&nbsp; The HelloDeadInterval MUST be greater than the=
 HelloInterval, <br>
&nbsp;&nbsp; and SHOULD be at least 3 times the value of HelloInterval. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the fast keep-alive mechanism of LMP is not used, the <br>
&nbsp;&nbsp; HelloInterval and HelloDeadInterval MUST be set to zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a node has either sent or received a ConfigAck message, it=
 may <br>
&nbsp;&nbsp; begin sending Hello messages.&nbsp; Once it has both sent and=
 received a <br>
&nbsp;&nbsp; Hello message, the control channel moves to the UP state.&nbsp;=
 (It is <br>
&nbsp;&nbsp; also possible to move to the UP state without sending Hellos if=
 <br>
&nbsp;&nbsp; other methods are used to indicate bi-directional=
 control-channel <br>
&nbsp;&nbsp; connectivity.)&nbsp; If, however, a node receives a ConfigNack=
 message <br>
&nbsp;&nbsp; instead of a ConfigAck message, the node MUST not send Hello=
 <br>
&nbsp;&nbsp; messages and the control channel SHOULD NOT move to the UP=
 state.&nbsp; <br>
&nbsp;&nbsp; See Section 8.1 for the complete control channel FSM. <br>
&nbsp;&nbsp;&nbsp; <br>
3.2.2. Fast Keep-alive <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Each Hello message contains two sequence numbers: the first=
 sequence <br>
&nbsp;&nbsp; number (TxSeqNum) is the sequence number for the Hello message=
 being <br>
&nbsp;&nbsp; sent and the second sequence number (RcvSeqNum) is the sequence=
 <br>
&nbsp;&nbsp; number of the last Hello message received over this control=
 channel <br>
&nbsp;&nbsp; from the adjacent node. Each node increments its sequence=
 number <br>
&nbsp;&nbsp; when it sees its current sequence number reflected in Hellos=
 <br>
&nbsp;&nbsp; received from its peer. The sequence numbers start at 1 and=
 wrap <br>
&nbsp;&nbsp; around back to 2; 0 is used in the RcvSeqNum to indicate that a=
 <br>
&nbsp;&nbsp; Hello has not yet been seen. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Under normal operation, the difference between the RcvSeqNum in=
 a <br>
&nbsp;&nbsp; Hello message that is received and the local TxSeqNum that is=
 <br>
&nbsp;&nbsp; generated will be at most 1.&nbsp; This difference can be more=
 than one <br>
&nbsp;&nbsp; only when a control channel restarts or when the values wrap.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Note that the 32-bit sequence numbers MAY wrap.&nbsp; The=
 following <br>
&nbsp;&nbsp; expression may be used to test if a newly received TxSeqNum=
 value is <br>
&nbsp;&nbsp; less than a previously received value: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If ((int) old_id =96 (int) new_id &gt; 0) { <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; New value is less than old value; <br>
&nbsp;&nbsp; } <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Having sequence numbers in the Hello messages allows each node=
 to <br>
&nbsp;&nbsp; verify that its peer is receiving its Hello messages. By=
 including <br>
&nbsp;&nbsp; the RcvSeqNum in Hello packets, the local node will know which=
 Hello <br>
&nbsp;&nbsp; packets the remote node has received. <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; [Page 9] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; The following example illustrates how the sequence numbers=
 operate.&nbsp; <br>
&nbsp;&nbsp; Note that only the operation at one node is shown: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 1)&nbsp; After completing the configuration stage, Node A sends=
 Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages to Node B with=
 {TxSeqNum=3D1;RcvSeqNum=3D0}. <br>
&nbsp;&nbsp; 2)&nbsp; When Node A receives a Hello from Node B with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {TxSeqNum=3D1;RcvSeqNum=3D1}, it sends=
 Hellos to Node B with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {TxSeqNum=3D2;RcvSeqNum=3D1}. <br>
&nbsp;&nbsp; 3)&nbsp; When Node A receives a Hello from Node B with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {TxSeqNum=3D2;RcvSeqNum=3D2}, it sends=
 Hellos to Node B with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {TxSeqNum=3D3;RcvSeqNum=3D2}. <br>
&nbsp;&nbsp;&nbsp; <br>
3.2.3. Control Channel Down <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To allow bringing a control channel DOWN gracefully for <br>
&nbsp;&nbsp; administration purposes, a ControlChannelDown flag is available=
 in <br>
&nbsp;&nbsp; the Common Header of LMP packets.&nbsp; When data links are=
 still in use <br>
&nbsp;&nbsp; between a pair of nodes, a control channel SHOULD only be taken=
 down <br>
&nbsp;&nbsp; administratively when there are other active control channels=
 that <br>
&nbsp;&nbsp; can be used to manage the data links. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When bringing a control channel DOWN administratively, a node=
 MUST <br>
&nbsp;&nbsp; set the ControlChannelDown flag in all LMP messages sent over=
 the <br>
&nbsp;&nbsp; control channel.&nbsp; The node may stop sending Hello messages=
 after <br>
&nbsp;&nbsp; HelloDeadInterval seconds have passed, or if it receives an LMP=
 <br>
&nbsp;&nbsp; message over the same control channel with the=
 ControlChannelDown <br>
&nbsp;&nbsp; flag set. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a node receives an LMP packet with the ControlChannelDown=
 flag <br>
&nbsp;&nbsp; set, it SHOULD send a Hello message with the ControlChannelDown=
 flag <br>
&nbsp;&nbsp; set and move the control channel to the Down state.<br>
<br>
BM&gt; On the receiving node, suggest transitioning to CONFSND state=
 rather<br>
BM&gt; than DOWN state.. otherwise, it could not automatically get into<br>
BM&gt; config procedure- i.e. would need a trigger/event<br>
BM&gt; On the sending side, the trigger is the operator command to bring=
 up<br>
BM&gt; the control channel<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
3.2.4. Degraded State <br>
&nbsp;<br>
&nbsp;&nbsp; A consequence of allowing the control channels to be physically=
 <br>
&nbsp;&nbsp; diverse from the associated data links is that there may not be=
 any <br>
&nbsp;&nbsp; active control channels available while the data links are=
 still in <br>
&nbsp;&nbsp; use. For many applications, it is unacceptable to tear down a=
 link <br>
&nbsp;&nbsp; that is carrying user traffic simply because the control=
 channel is <br>
&nbsp;&nbsp; no longer available; however, the traffic that is using the=
 data <br>
&nbsp;&nbsp; links may no longer be guaranteed the same level of=
 service.&nbsp; Hence <br>
&nbsp;&nbsp; the TE link is in a Degraded state. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a TE link is in the Degraded state, routing and signaling=
 <br>
&nbsp;&nbsp; SHOULD be notified so that new connections are not accepted and=
 the <br>
&nbsp;&nbsp; TE link is advertised with no unreserved resources. <br>
&nbsp;&nbsp;&nbsp; <br>
4. Link Property Correlation <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; As part of LMP, a link property correlation exchange is defined=
 <br>
&nbsp;&nbsp; using the LinkSummary, LinkSummaryAck, and LinkSummaryNack=
 messages.&nbsp; <br>
&nbsp;&nbsp; The contents of these messages are built using LMP objects,=
 which <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 10] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; can be either negotiable or non-negotiable (identified by the N=
 flag <br>
&nbsp;&nbsp; in the TLV header).&nbsp; Negotiable objects can be used to let=
 both <br>
&nbsp;&nbsp; sides agree on certain link parameters.&nbsp; Non-negotiable=
 objects are <br>
&nbsp;&nbsp; used for announcement of specific values that do not need, or=
 do not <br>
&nbsp;&nbsp; allow, negotiation. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Link property correlation MUST be done before the link is=
 brought up <br>
&nbsp;&nbsp; and MAY be done at any time a link is UP and not in the=
 Verification <br>
&nbsp;&nbsp; process. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummary message is used to verify for consistency the=
 TE and <br>
&nbsp;&nbsp; data bearing link information on both sides.&nbsp; Link Summary=
 messages <br>
&nbsp;&nbsp; are also used to aggregate multiple data links (either ports or=
 <br>
&nbsp;&nbsp; component links) into a TE link; exchange, correlate (to=
 determine <br>
&nbsp;&nbsp; inconsistencies), or change TE link parameters; and exchange,=
 <br>
&nbsp;&nbsp; correlate (to determine inconsistencies), or change Interface=
 Ids <br>
&nbsp;&nbsp; (either Port Ids or Component Interface Ids). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Each TE link has an identifier (Link_Id) that is assigned at=
 each <br>
&nbsp;&nbsp; end of the link.&nbsp; These identifiers MUST be the same type=
 (i.e, <br>
&nbsp;&nbsp; IPv4, IPv6, unnumbered) at both ends.&nbsp; Similarly, each=
 interface is <br>
&nbsp;&nbsp; assigned an identifier (Interface_Id) at each end.&nbsp; These=
 <br>
&nbsp;&nbsp; identifiers MUST be the same type at both ends.<br>
<br>
BM&gt; Why the restriction that both ends of a TE Link have to use the=
 same<br>
BM&gt; identification?<br>
<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the LinkSummary message is received from a remote node and=
 the <br>
&nbsp;&nbsp; Interface Id mappings match those that are stored locally, then=
 the <br>
&nbsp;&nbsp; two nodes have agreement on the Verification procedure (see=
 Section <br>
&nbsp;&nbsp; 5).&nbsp; If the verification procedure is not used, the=
 LinkSummary <br>
&nbsp;&nbsp; message can be used to verify agreement on manual=
 configuration. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummaryAck message is used to signal agreement on the=
 <br>
&nbsp;&nbsp; Interface Id mappings and link property definitions.&nbsp;=
 Otherwise, a <br>
&nbsp;&nbsp; LinkSummaryNack message MUST be transmitted, indicating which=
 <br>
&nbsp;&nbsp; Interface mappings are not correct and/or which link properties=
 are <br>
&nbsp;&nbsp; not accepted. If a LinkSummaryNack message indicates that the=
 <br>
&nbsp;&nbsp; Interface Id mappings are not correct and the link verification=
 <br>
&nbsp;&nbsp; procedure is enabled, the link verification process SHOULD be=
 <br>
&nbsp;&nbsp; repeated for all mismatched free data links; if an allocated=
 data <br>
&nbsp;&nbsp; link has a mapping mismatch, it SHOULD be flagged and verified=
 when <br>
&nbsp;&nbsp; it becomes free.&nbsp; If a LinkSummaryNack message includes=
 negotiable <br>
&nbsp;&nbsp; parameters, then acceptable values for those parameters MUST be=
 <br>
&nbsp;&nbsp; included.&nbsp; If a LinkSummaryNack message is received and=
 includes <br>
&nbsp;&nbsp; negotiable parameters, then the initiator of the LinkSummary=
 message <br>
&nbsp;&nbsp; MUST send a new LinkSummary message.&nbsp; The new LinkSummary=
 message <br>
&nbsp;&nbsp; SHOULD include new values for the negotiable parameters.&nbsp;=
 These <br>
&nbsp;&nbsp; values SHOULD take into account the acceptable values received=
 in <br>
&nbsp;&nbsp; the LinkSummaryNack message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; It is possible that the LinkSummary message could grow quite=
 large <br>
&nbsp;&nbsp; due to the number of Data Link TLVs.&nbsp; Since the=
 LinkSummary message <br>
&nbsp;&nbsp; is IP encoded, normal IP fragmentation should be used if the=
 <br>
&nbsp;&nbsp; resulting PDU exceeds the MTU. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 11] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
5. Verifying Link Connectivity <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In this section, an optional procedure is described that may be=
 used <br>
&nbsp;&nbsp; to verify the physical connectivity of the data-bearing=
 links.&nbsp; The <br>
&nbsp;&nbsp; procedure SHOULD be done when establishing a TE link, and <br>
&nbsp;&nbsp; subsequently, on a periodic basis for all unallocated (free)=
 data <br>
&nbsp;&nbsp; links of the TE link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the link connectivity procedure is not supported for the TE=
 link, <br>
&nbsp;&nbsp; then a BeginVerifyNack message MUST be transmitted with Error=
 Code <br>
&nbsp;&nbsp; =3D1, =93Link Verification Procedure not supported for this TE=
 Link=94. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; A unique characteristic of all-optical PXCs is that the=
 data-bearing <br>
&nbsp;&nbsp; links are transparent when allocated to user traffic.&nbsp;=
 This <br>
&nbsp;&nbsp; characteristic of PXCs poses a challenge for validating the=
 <br>
&nbsp;&nbsp; connectivity of the data links since shining unmodulated light=
 <br>
&nbsp;&nbsp; through a link may not result in received light at the next=
 PXC.&nbsp; <br>
&nbsp;&nbsp; This is because there may be terminating (or opaque) elements,=
 such <br>
&nbsp;&nbsp; as DWDM equipment, between the PXCs.&nbsp; Therefore, to ensure=
 proper <br>
&nbsp;&nbsp; verification of data link connectivity, it is required that=
 until <br>
&nbsp;&nbsp; the links are allocated for user traffic, they must be=
 opaque.&nbsp; To <br>
&nbsp;&nbsp; support various degrees of opaqueness (e.g., examining overhead=
 <br>
&nbsp;&nbsp; bytes, terminating the payload, etc.), and hence different <br>
&nbsp;&nbsp; mechanisms to transport the Test messages, a Verify Transport=
 <br>
&nbsp;&nbsp; Mechanism field is included in the BeginVerify and=
 BeginVerifyAck <br>
&nbsp;&nbsp; messages.&nbsp; There is no requirement that all data links be=
 terminated <br>
&nbsp;&nbsp; simultaneously, but at a minimum, the data links MUST be able=
 to be <br>
&nbsp;&nbsp; terminated one at a time.&nbsp; Furthermore, for the link=
 verification <br>
&nbsp;&nbsp; procedure it is assumed that the nodal architecture is designed=
 so <br>
&nbsp;&nbsp; that messages can be sent and received over any data=
 link.&nbsp; Note <br>
&nbsp;&nbsp; that this requirement is trivial for DXCs (and OEO devices in=
 <br>
&nbsp;&nbsp; general) since each data link is terminated and processed <br>
&nbsp;&nbsp; electronically before being forwarded to the next OEO device,=
 but <br>
&nbsp;&nbsp; that in PXCs (and transparent devices in general) this is an=
 <br>
&nbsp;&nbsp; additional requirement. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To interconnect two nodes, a TE link is defined between them,=
 and at <br>
&nbsp;&nbsp; a minimum, there MUST be at least one active control channel=
 between <br>
&nbsp;&nbsp; the nodes.&nbsp; For link verification, a TE link MUST include=
 at least <br>
&nbsp;&nbsp; one data link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Once a control channel has been established between the two=
 nodes, <br>
&nbsp;&nbsp; data link connectivity can be verified by exchanging Test=
 messages <br>
&nbsp;&nbsp; over each of the data links specified in the TE link.&nbsp; It=
 should be <br>
&nbsp;&nbsp; noted that all LMP messages except the Test message are=
 exchanged <br>
&nbsp;&nbsp; over the control channels and that Hello messages continue to=
 be <br>
&nbsp;&nbsp; exchanged over each control channel during the data link <br>
&nbsp;&nbsp; verification process.&nbsp; The Test message is sent over the=
 data link <br>
&nbsp;&nbsp; that is being verified.&nbsp; Data links are tested in the=
 transmit <br>
&nbsp;&nbsp; direction as they are unidirectional, and therefore, it may be=
 <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 12] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; possible for both nodes to (independently) exchange the Test=
 <br>
&nbsp;&nbsp; messages simultaneously. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To initiate the link verification procedure, the local node=
 MUST <br>
&nbsp;&nbsp; send a BeginVerify message over a control channel.&nbsp; To=
 limit the <br>
&nbsp;&nbsp; scope of Link Verification to a particular TE Link, the LINK_ID=
 MUST <br>
&nbsp;&nbsp; be non-zero.&nbsp; If this field is zero, the data links can=
 span <br>
&nbsp;&nbsp; multiple TE links and/or they may comprise a TE link that is=
 yet to <br>
&nbsp;&nbsp; be configured. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The BeginVerify message also contains the number of data links=
 that <br>
&nbsp;&nbsp; are to be verified; the interval (called VerifyInterval) at=
 which <br>
&nbsp;&nbsp; the Test messages will be sent; the encoding scheme and=
 transport <br>
&nbsp;&nbsp; mechanisms that are supported; the data rate for Test messages;=
 and, <br>
&nbsp;&nbsp; when the data links correspond to fibers, the wavelength=
 identifier <br>
&nbsp;&nbsp; over which the Test messages will be transmitted. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the remote node receives a BeginVerify message and it is=
 ready to <br>
&nbsp;&nbsp; process Test messages, it MUST send a BeginVerifyAck message=
 back to <br>
&nbsp;&nbsp; the local node specifying the desired transport mechanism for=
 the <br>
&nbsp;&nbsp; TEST messages.&nbsp; The remote node includes a 32-bit node=
 unique <br>
&nbsp;&nbsp; VerifyId in the BeginVerifyAck message.&nbsp; The VerifyId is=
 then used <br>
&nbsp;&nbsp; in all corresponding verification messages to differentiate=
 them <br>
&nbsp;&nbsp; from different LMP peers and/or parallel Test procedures.&nbsp;=
 When the <br>
&nbsp;&nbsp; local node receives a BeginVerifyAck message from the remote=
 node, <br>
&nbsp;&nbsp; it may begin testing the data links by transmitting periodic=
 Test <br>
&nbsp;&nbsp; messages over each data link.&nbsp; The Test message includes=
 the <br>
&nbsp;&nbsp; VerifyId and the local Interface Id for the associated data=
 link.&nbsp; <br>
&nbsp;&nbsp; The remote node MUST send either a TestStatusSuccess or a <br>
&nbsp;&nbsp; TestStatusFailure message in response for each data link.&nbsp;=
 A <br>
&nbsp;&nbsp; TestStatusAck message MUST be sent to confirm receipt of the=
 <br>
&nbsp;&nbsp; TestStatusSuccess and TestStatusFailure messages. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; It is also permissible for the sender to terminate the Test=
 <br>
&nbsp;&nbsp; procedure without receiving a TestStatusSuccess or=
 TestStatusFailure <br>
&nbsp;&nbsp; message by sending an EndVerify message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Message correlation is done using message identifiers and the=
 Verify <br>
&nbsp;&nbsp; Id; this enables verification of data links, belonging to=
 different <br>
&nbsp;&nbsp; link bundles or LMP sessions, in parallel. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When the Test message is received, the received Interface Id=
 (used <br>
&nbsp;&nbsp; in GMPLS as either a Port/Wavelength label or Component=
 Interface <br>
&nbsp;&nbsp; Identifier depending on the configuration) is recorded and=
 mapped to <br>
&nbsp;&nbsp; the local Interface Id for that data link, and a=
 TestStatusSuccess <br>
&nbsp;&nbsp; message MUST be sent.&nbsp; The TestStatusSuccess message=
 includes the <br>
&nbsp;&nbsp; local Interface Id and the remote Interface Id (received in the=
 Test <br>
&nbsp;&nbsp; message), along with the VerifyId received in the Test=
 message.&nbsp; The <br>
&nbsp;&nbsp; receipt of a TestStatusSuccess message indicates that the Test=
 <br>
&nbsp;&nbsp; message was detected at the remote node and the physical <br>
&nbsp;&nbsp; connectivity of the data link has been verified.&nbsp; When the=
 <br>
&nbsp;&nbsp; TestStatusSuccess message is received, the local node SHOULD=
 mark <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 13] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; the data link as UP and send a TestStatusAck message to the=
 remote <br>
&nbsp;&nbsp; node.&nbsp; If, however, the Test message is not detected at=
 the remote <br>
&nbsp;&nbsp; node within an observation period (specified by the <br>
&nbsp;&nbsp; VerifyDeadInterval), the remote node will send a=
 TestStatusFailure <br>
&nbsp;&nbsp; message over the control channel indicating that the=
 verification of <br>
&nbsp;&nbsp; the physical connectivity of the data link has failed.&nbsp;=
 When the <br>
&nbsp;&nbsp; local node receives a TestStatusFailure message, it SHOULD mark=
 the <br>
&nbsp;&nbsp; data link as FAILED and send a TestStatusAck message to the=
 remote <br>
&nbsp;&nbsp; node.&nbsp; When all the data links on the list have been=
 tested, the <br>
&nbsp;&nbsp; local node SHOULD send an EndVerify message to indicate that=
 testing <br>
&nbsp;&nbsp; is complete on this link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the local/remote data link mappings are known, then the link=
 <br>
&nbsp;&nbsp; verification procedure SHOULD be optimized by testing the data=
 links <br>
&nbsp;&nbsp; in a defined order known to both nodes.&nbsp; The suggested=
 criteria for <br>
&nbsp;&nbsp; this ordering is in increasing value of the=
 Remote_Interface_ID. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Both the local and remote nodes SHOULD maintain the complete=
 list of <br>
&nbsp;&nbsp; Interface Id mappings for correlation purposes. <br>
&nbsp;&nbsp;&nbsp; <br>
5.1. Example of Link Connectivity Verification <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Figure 1 shows an example of the link verification scenario=
 that is <br>
&nbsp;&nbsp; executed when a link between PXC A and PXC B is added. In this=
 <br>
&nbsp;&nbsp; example, the TE link consists of three free ports (each=
 transmitted <br>
&nbsp;&nbsp; along a separate fiber) and is associated with a bi-directional=
 <br>
&nbsp;&nbsp; control channel (indicated by a &quot;c&quot;). The=
 verification process is as <br>
&nbsp;&nbsp; follows: PXC A sends a BeginVerify message over the control=
 channel <br>
&nbsp;&nbsp; =93c=94 to PXC B indicating it will begin verifying the=
 ports.&nbsp; PXC B <br>
&nbsp;&nbsp; receives the BeginVerify message, assigns a VerifyId to the=
 Test <br>
&nbsp;&nbsp; procedure, and returns the BeginVerifyAck message over the=
 control <br>
&nbsp;&nbsp; channel to PXC A.&nbsp; When PXC A receives the BeginVerifyAck=
 message, <br>
&nbsp;&nbsp; it begins transmitting periodic Test messages over the first=
 port <br>
&nbsp;&nbsp; (Interface Id=3D1). When PXC B receives the Test messages, it=
 maps the <br>
&nbsp;&nbsp; received Interface Id to its own local Interface Id =3D 10 and=
 <br>
&nbsp;&nbsp; transmits a TestStatusSuccess message over the control channel=
 back <br>
&nbsp;&nbsp; to PXC A.&nbsp; The TestStatusSuccess message includes both the=
 local and <br>
&nbsp;&nbsp; received Interface Ids for the port as well as the=
 VerifyId.&nbsp; PXC A <br>
&nbsp;&nbsp; will send a TestStatusAck message over the control channel back=
 to <br>
&nbsp;&nbsp; PXC B indicating it received the TestStatusSuccess=
 message.&nbsp; The <br>
&nbsp;&nbsp; process is repeated until all of the ports are verified. At=
 this <br>
&nbsp;&nbsp; point, PXC A will send an EndVerify message over the control=
 channel <br>
&nbsp;&nbsp; to PXC B to indicate that testing is complete; PXC B will=
 respond by <br>
&nbsp;&nbsp; sending an EndVerifyAck message over the control channel back=
 to PXC <br>
&nbsp;&nbsp; A. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;=
 +---------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------------------+ <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PXC=
 A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&lt;-------- c=
 ---------&gt;+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PXC=
 B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 +---------------------&gt;+=
 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 14] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; /----&gt;+=
 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 /----/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;=
 /---/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3=
 +----/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4 +---------------------&gt;+=
 14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 +---------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------------------+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 1:&nbsp; Example of link connectivity=
 between PXC A and PXC B. <br>
&nbsp;&nbsp;&nbsp; <br>
6. Fault Management <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In this section, an optional LMP procedure is described that is=
 used <br>
&nbsp;&nbsp; to manage failures by rapid notification of the status of one=
 or <br>
&nbsp;&nbsp; more data channels of a TE Link.&nbsp; The scope of this=
 procedure is <br>
&nbsp;&nbsp; within a TE link, and as such, the use of this procedure is=
 <br>
&nbsp;&nbsp; negotiated as part of the LinkSummary exchange.&nbsp; The=
 procedure can <br>
&nbsp;&nbsp; be used to rapidly isolate link failures and is designed to=
 work for <br>
&nbsp;&nbsp; both unidirectional and bi-directional LSPs. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; An important implication of using PXCs is that traditional=
 methods <br>
&nbsp;&nbsp; that are used to monitor the health of allocated data links in=
 OEO <br>
&nbsp;&nbsp; nodes (e.g., DXCs) may no longer be appropriate, since PXCs are=
 <br>
&nbsp;&nbsp; transparent to the bit-rate, format, and wavelength.&nbsp;=
 Instead, fault <br>
&nbsp;&nbsp; detection is delegated to the physical layer (i.e., loss of=
 light or <br>
&nbsp;&nbsp; optical monitoring of the data) instead of layer 2 or layer 3.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Recall that a TE link connecting two nodes may consist of a=
 number <br>
&nbsp;&nbsp; of data links. If one or more data links fail between two=
 nodes, a <br>
&nbsp;&nbsp; mechanism must be used for rapid failure notification so that=
 <br>
&nbsp;&nbsp; appropriate protection/restoration mechanisms can be=
 initiated.&nbsp; If <br>
&nbsp;&nbsp; the failure is subsequently cleared, then a mechanism must be=
 used <br>
&nbsp;&nbsp; to notify that the failure is clear and the channel status is=
 OK.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
6.1. Fault Detection <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Fault detection should be handled at the layer closest to the=
 <br>
&nbsp;&nbsp; failure; for optical networks, this is the physical (optical)=
 layer. <br>
&nbsp;&nbsp; One measure of fault detection at the physical layer is=
 detecting <br>
&nbsp;&nbsp; loss of light (LOL). Other techniques for monitoring optical=
 signals <br>
&nbsp;&nbsp; are still being developed and will not be further considered in=
 this <br>
&nbsp;&nbsp; document. However, it should be clear that the mechanism used=
 for <br>
&nbsp;&nbsp; fault notification in LMP is independent of the mechanism used=
 to <br>
&nbsp;&nbsp; detect the failure, but simply relies on the fact that a=
 failure is <br>
&nbsp;&nbsp; detected. <br>
&nbsp;&nbsp;&nbsp; <br>
6.2. Fault Localization Procedure <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 15] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; If data links fail between two PXCs, the power monitoring=
 system in <br>
&nbsp;&nbsp; all of the downstream nodes may detect LOL and indicate a=
 failure.&nbsp; <br>
&nbsp;&nbsp; To avoid multiple alarms stemming from the same failure, LMP=
 <br>
&nbsp;&nbsp; provides a failure notification through the ChannelStatus=
 message.&nbsp; <br>
&nbsp;&nbsp; This message may be used to indicate that a single data channel=
 has <br>
&nbsp;&nbsp; failed, multiple data channels have failed, or an entire TE=
 link has <br>
&nbsp;&nbsp; failed.&nbsp; Failure correlation is done locally at each node=
 upon <br>
&nbsp;&nbsp; receipt of the failure notification. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; As part of the fault localization, a downstream node=
 (downstream in <br>
&nbsp;&nbsp; terms of data flow) that detects data link failures will send a=
 <br>
&nbsp;&nbsp; ChannelStatus message to its upstream neighbor indicating that=
 a <br>
&nbsp;&nbsp; failure has occurred (bundling together the notification of all=
 of <br>
&nbsp;&nbsp; the failed data links).&nbsp; An upstream node that receives=
 the <br>
&nbsp;&nbsp; ChannelStatus message MUST send a ChannelStatusAck message to=
 the <br>
&nbsp;&nbsp; downstream node indicating it has received the ChannelStatus=
 <br>
&nbsp;&nbsp; message.&nbsp; The upstream node should correlate the failure=
 to see if <br>
&nbsp;&nbsp; the failure is also detected locally (including ingress side)=
 for <br>
&nbsp;&nbsp; the corresponding LSP(s).&nbsp; If, for example, the failure is=
 clear on <br>
&nbsp;&nbsp; the input of the upstream node or internally, then the upstream=
 node <br>
&nbsp;&nbsp; will have localized the failure.&nbsp; Once the failure is=
 correlated, <br>
&nbsp;&nbsp; the upstream node SHOULD send a ChannelStatus message to the=
 <br>
&nbsp;&nbsp; downstream node indicating that the channel is failed or is=
 ok.&nbsp; If <br>
&nbsp;&nbsp; a ChannelStatus message is not received by the downstream node,=
 it <br>
&nbsp;&nbsp; SHOULD send a ChannelStatusRequest message for the channel in=
 <br>
&nbsp;&nbsp; question.&nbsp; Once the failure has been localized, the=
 signaling <br>
&nbsp;&nbsp; protocols can be used to initiate span or path <br>
&nbsp;&nbsp; protection/restoration procedures. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If all of the data links of a TE link have failed, then the=
 upstream <br>
&nbsp;&nbsp; node MAY be notified of the TE link failure without specifying=
 each <br>
&nbsp;&nbsp; data link of the failed TE link.&nbsp; This is done by sending=
 failure <br>
&nbsp;&nbsp; notification in a ChannelStatus message identifying the TE Link=
 <br>
&nbsp;&nbsp; without including the Interface Ids in the CHANNEL_STATUS=
 object. <br>
&nbsp;&nbsp;&nbsp; <br>
6.3. Examples of Fault Localization <br>
&nbsp;<br>
&nbsp;&nbsp; In Fig. 2, a sample network is shown where four PXCs are=
 connected <br>
&nbsp;&nbsp; in a linear array configuration.&nbsp; The control channels are=
 bi-<br>
&nbsp;&nbsp; directional and are labeled with a &quot;c&quot;.&nbsp; All=
 LSPs are also bi-<br>
&nbsp;&nbsp; directional. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In the first example [see Fig. 2(a)], there is a failure on one=
 <br>
&nbsp;&nbsp; direction of the bi-directional LSP.&nbsp; PXC 4 will detect=
 the failure <br>
&nbsp;&nbsp; and will send a ChannelStatus message to PXC3 indicating the=
 failure <br>
&nbsp;&nbsp; (e.g., LOL) to the corresponding upstream node.&nbsp; When PXC3=
 receives <br>
&nbsp;&nbsp; the ChannelStatus message from PXC4, it returns a=
 ChannelStatusAck <br>
&nbsp;&nbsp; message back to PXC4 and correlates the failure locally.&nbsp;=
 When PXC3 <br>
&nbsp;&nbsp; correlates the failure and verifies that it is CLEAR, it has=
 <br>
&nbsp;&nbsp; localized the failure to the data link between PXC3 and PXC4.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 16] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; In the second example [see Fig. 2(b)], a single failure (e.g.,=
 fiber <br>
&nbsp;&nbsp; cut) affects both directions of the bi-directional LSP.&nbsp;=
 PXC2 (PXC3) <br>
&nbsp;&nbsp; will detect the failure of the upstream (downstream) direction=
 and <br>
&nbsp;&nbsp; send a ChannelStatus message to the upstream (in terms of data=
 flow) <br>
&nbsp;&nbsp; node indicating the failure (e.g., LOL).&nbsp; Simultaneously=
 (ignoring <br>
&nbsp;&nbsp; propagation delays), PXC1 (PXC4) will detect the failure on the=
 <br>
&nbsp;&nbsp; upstream (downstream) direction, and will send a ChannelStatus=
 <br>
&nbsp;&nbsp; message to the corresponding upstream (in terms of data flow)=
 node <br>
&nbsp;&nbsp; indicating the failure.&nbsp; PXC2 and PXC3 will have localized=
 the two <br>
&nbsp;&nbsp; directions of the failure. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + PXC 1=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + PXC 2=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + PXC 3=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + PXC 4 + <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-- c ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=
 ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-- c=
 ---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp; ----+---\&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp; &lt;---+---\\--+--------+-------+---\&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp; /--+---&gt;=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=
 \--+--------+-------+---\\---+-------+---##---+---//--+---- <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=
 \---+-------+--------+---/&nbsp;&nbsp; + <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; (a)&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp; ----+-------+--------+---\&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp; &lt;---+-------+--------+---\\--+---##---+--\&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=
 \--+---##---+--\\&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; (b)&nbsp;&nbsp; +&nbsp;&nbsp;=
 \\--+--------+-------+---&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;=
 \--+--------+-------+---- <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure=
 2:&nbsp;&nbsp;&nbsp;&nbsp; Two types of data link failures are shown <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (indicated by ## in=
 the figure):&nbsp; (A) a data link <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; corresponding to the=
 downstream direction of a bi-directional <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP fails, (B) two=
 data links corresponding to both <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; directions of a=
 bi-directional LSP fail.&nbsp; The control channel <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connecting two PXCs=
 is indicated with a &quot;c&quot;. <br>
&nbsp;<br>
6.4. Channel Activation Indication&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatus message may also be used to notify an LMP=
 neighbor <br>
&nbsp;&nbsp; that the data link should be actively monitored.&nbsp; This is=
 called <br>
&nbsp;&nbsp; Channel Activation Indication.&nbsp; This is particularly=
 useful in <br>
&nbsp;&nbsp; networks with transparent nodes where the status of data links=
 may <br>
&nbsp;&nbsp; need to be triggered using control channel messages.&nbsp; For=
 example, <br>
&nbsp;&nbsp; if a data link is pre-provisioned and the physical link fails=
 after <br>
&nbsp;&nbsp; verification and before inserting user traffic, a mechanism is=
 <br>
&nbsp;&nbsp; needed to indicate the data link should be active or they may=
 not be <br>
&nbsp;&nbsp; able to detect the failure. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatus message is used to indicate that a channel or=
 <br>
&nbsp;&nbsp; group of channels are now active.&nbsp; The ChannelStatusAck=
 message MUST <br>
&nbsp;&nbsp; be transmitted upon receipt of a ChannelStatus message.&nbsp;=
 When a <br>
&nbsp;&nbsp; ChannelStatus message is received, the corresponding data=
 link(s) <br>
&nbsp;&nbsp; MUST be put into the Active state.&nbsp; If upon putting them=
 into the <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 17] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; Active state, a failure is detected, the ChannelStatus message=
 MUST <br>
&nbsp;&nbsp; be transmitted as described in Section 6.2. <br>
&nbsp;&nbsp;&nbsp; <br>
6.5. Channel Deactivation Indication&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatus message may also be used to notify an LMP=
 neighbor <br>
&nbsp;&nbsp; that the data link no longer needs to be monitored.&nbsp; This=
 is the <br>
&nbsp;&nbsp; counterpart to the Channel Active Indication. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a ChannelStatus message is received with Channel Deactive=
 <br>
&nbsp;&nbsp; Indication, the corresponding data link(s) MUST be taken out of=
 the <br>
&nbsp;&nbsp; Active state. <br>
&nbsp;<br>
7. Message_Id Usage <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP=
 <br>
&nbsp;&nbsp; messages to support reliable message delivery.&nbsp; This=
 section <br>
&nbsp;&nbsp; describes the usage of these objects.&nbsp; The MESSAGE_ID and=
 <br>
&nbsp;&nbsp; MESSAGE_ID_ACK objects contain a Message_Id field.&nbsp; Only=
 one <br>
&nbsp;&nbsp; MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP=
 message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; For control channel specific messages, the Message_Id field is=
 <br>
&nbsp;&nbsp; within the scope of the CCID.&nbsp; For TE link specific=
 messages, the <br>
&nbsp;&nbsp; Message_Id field is within the scope of the LMP adjacency. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Message_Id field of the MESSAGE_ID object contains a=
 generator <br>
&nbsp;&nbsp; selected value.&nbsp; This value MUST be greater than any other=
 value <br>
&nbsp;&nbsp; previously used.&nbsp; A value is considered to be previously=
 used when <br>
&nbsp;&nbsp; it has been sent in an LMP message with the same CCID (for=
 control <br>
&nbsp;&nbsp; channel specific messages) or LMP adjacency (for TE Link=
 specific <br>
&nbsp;&nbsp; messages).&nbsp; The Message_Id field of the MESSAGE_ID_ACK=
 object <br>
&nbsp;&nbsp; contains the Message_Id field of the message being=
 acknowledged.&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Unacknowledged messages sent with the MESSAGE_ID object SHOULD=
 be <br>
&nbsp;&nbsp; retransmitted until the message is acknowledged or until a=
 retry <br>
&nbsp;&nbsp; limit is reached. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Note that the 32-bit Message_Id value MAY wrap.&nbsp; The=
 following <br>
&nbsp;&nbsp; expression may be used to test if a newly received Message_Id=
 value <br>
&nbsp;&nbsp; is less than a previously received value: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If ((int) old_id =96 (int) new_id &gt; 0) { <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; New value is less than old value; <br>
&nbsp;&nbsp; } <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Nodes processing incoming messages SHOULD check to see if a=
 newly <br>
&nbsp;&nbsp; received message is out of order and can be ignored.&nbsp;=
 Out-of-order <br>
&nbsp;&nbsp; messages can be identified by examining the value in the=
 Message_Id <br>
&nbsp;&nbsp; field. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the message is a Config message, and the Message_Id value is=
 less <br>
&nbsp;&nbsp; than the largest Message_Id value previously received from the=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 18] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; sender for the CCID, then the message SHOULD be treated as=
 being out <br>
&nbsp;&nbsp; of order. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the message is a LinkSummary message and the Message_Id=
 value is <br>
&nbsp;&nbsp; less than the largest Message_Id value previously received from=
 the <br>
&nbsp;&nbsp; sender for the TE Link, then the message SHOULD be treated as=
 being <br>
&nbsp;&nbsp; out of order.<br>
<br>
BM&gt; Isn't this logic true for link verification as well?<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the message is a ChannelStatus message and the Message_Id=
 value <br>
&nbsp;&nbsp; is less than the largest Message_Id value previously received=
 from <br>
&nbsp;&nbsp; the sender for the specified TE link, then the receiver SHOULD=
 check <br>
&nbsp;&nbsp; the Message_Id value previously received for the state of each=
 data <br>
&nbsp;&nbsp; channel included in the ChannelStatus message.&nbsp; If the=
 Message_Id <br>
&nbsp;&nbsp; value is greater than the most recently received Message_Id=
 value <br>
&nbsp;&nbsp; associated with at least one of the data channels included in=
 the <br>
&nbsp;&nbsp; message, the message MUST NOT be treated as out of order;=
 otherwise <br>
&nbsp;&nbsp; the message SHOULD be treated as being out of order. However,=
 the <br>
&nbsp;&nbsp; state of any data channel MUST NOT be updated if the Message_Id=
 <br>
&nbsp;&nbsp; value is less than the most recently received Message_Id value=
 <br>
&nbsp;&nbsp; associated with the data channel. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; All other messages MUST NOT be treated as out-of-order. <br>
&nbsp;&nbsp;&nbsp; <br>
8. Graceful Restart <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This section describes the mechanism to resynchronize the LMP=
 state <br>
&nbsp;&nbsp; after a control plane restart.&nbsp; A control plane restart=
 may occur <br>
&nbsp;&nbsp; when bringing up the first control channel after an LMP=
 adjacency <br>
&nbsp;&nbsp; has failed, or as a result of an LMP component restart.&nbsp;=
 The latter <br>
&nbsp;&nbsp; is detected by setting the =93Control Plane Restart=94 bit in=
 the Common <br>
<br>
BM&gt; Isn't the bit called LMP Restart?<br>
<br>
&nbsp;&nbsp; Header of the LMP messages.&nbsp; When the control plane fails=
 due to the <br>
&nbsp;&nbsp; loss of the control channel (rather than an LMP component=
 restart), <br>
&nbsp;&nbsp; the LMP Link information should be retained.&nbsp; It is=
 possible that a <br>
&nbsp;&nbsp; node may be capable of retaining the LMP Link information=
 across an <br>
&nbsp;&nbsp; LMP component restart.&nbsp; However, in both cases the status=
 of the <br>
&nbsp;&nbsp; data channels MUST be synchronized. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; We assume the Local Interface Ids remain stable across a=
 control <br>
&nbsp;&nbsp; plane restart. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; After the control plane of a node restarts, the control=
 channel(s) <br>
&nbsp;&nbsp; must be re-established using the procedures of Section 3.1.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the control plane failure was the result of an LMP component=
 <br>
&nbsp;&nbsp; restart, then the =93Control Plane Restart=94 flag MUST be set=
 in LMP <br>
&nbsp;&nbsp; messages until a Hello message is received with the RcvSeqNum=
 equal <br>
&nbsp;&nbsp; to the local TxSeqNum.&nbsp; This indicates that the control=
 channel is <br>
&nbsp;&nbsp; UP and the LMP neighbor has detected the restart. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Once a control channel is UP, the LMP neighbor MUST send a <br>
&nbsp;&nbsp; LinkSummary message for each TE Link across the=
 adjacency.&nbsp; All the <br>
&nbsp;&nbsp; objects of the LinkSummary message MUST have the N-bit set to 0=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 19] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; indicating that the parameters are non-negotiable.&nbsp; This=
 provides <br>
&nbsp;&nbsp; the local/remote Link Id and Interace Id mappings, the=
 associated <br>
&nbsp;&nbsp; Link/Data channel parameters, and indication of which data=
 links are <br>
&nbsp;&nbsp; currently allocated to user traffic.&nbsp; When a node receives=
 the <br>
&nbsp;&nbsp; LinkSummary message, it checks its local configuration.&nbsp;=
 If the node <br>
&nbsp;&nbsp; is capable of retaining the LMP Link information across a=
 restart, <br>
&nbsp;&nbsp; it must process the LinkSummary message as described in Section=
 4 <br>
&nbsp;&nbsp; with the exception that the allocated/deallocated flag of the=
 <br>
&nbsp;&nbsp; DATA_LINK Object received in the LinkSummary message MUST take=
 <br>
&nbsp;&nbsp; precedence over any local value.&nbsp; If, however, the node=
 was not <br>
&nbsp;&nbsp; capable of retaining the LMP Link information across a restart,=
 the <br>
&nbsp;&nbsp; node MUST accept the Link/Data channel parameters of the=
 received <br>
&nbsp;&nbsp; LinkSummary message and respond with a LinkSummaryAck message.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Upon completion of the LinkSummary exchange, the node that has=
 <br>
&nbsp;&nbsp; restarted the control plane SHOULD send a ChannelStatusRequest=
 <br>
&nbsp;&nbsp; message for that TE link.&nbsp; The node SHOULD also verify the=
 <br>
&nbsp;&nbsp; connectivity of all unallocated data channels. <br>
&nbsp;&nbsp;&nbsp; <br>
9. Addressing <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; All LMP messages are sent directly over IP (except, in some=
 cases, <br>
&nbsp;&nbsp; the Test messages are limited by the transport mechanism for=
 in-band <br>
&nbsp;&nbsp; messaging).&nbsp; The destination address of the IP packet MUST=
 be the <br>
&nbsp;&nbsp; address learned in the Configuration procedure (i.e., the=
 Source IP <br>
&nbsp;&nbsp; address found in the IP header of the received Config message).=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The manner in which a Config message is addressed may depend on=
 the <br>
&nbsp;&nbsp; signaling transport mechanism.&nbsp; When the transport=
 mechanism is a <br>
&nbsp;&nbsp; point-to-point link, Config messages SHOULD be sent to the=
 Multicast <br>
&nbsp;&nbsp; address (224.0.0.1).&nbsp; Otherwise, Config messages MUST be=
 sent to an <br>
&nbsp;&nbsp; IP address on the neighboring node.&nbsp; This is configured at=
 both ends <br>
&nbsp;&nbsp; of the control channel. <br>
&nbsp;&nbsp;&nbsp; <br>
10. <br>
&nbsp;&nbsp; LMP Authentication <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP authentication is optional (included in the Common Header)=
 and, <br>
&nbsp;&nbsp; if used, MUST be supported by both sides of the control=
 channel.&nbsp; The <br>
&nbsp;&nbsp; method used to authenticate LMP packets is based on the <br>
&nbsp;&nbsp; authentication technique used in [OSPF].&nbsp; This uses=
 cryptographic <br>
&nbsp;&nbsp; authentication using MD5. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; As a part of the LMP authentication mechanism, a flag is=
 included in <br>
&nbsp;&nbsp; the LMP common header indicating the presence of authentication=
 <br>
&nbsp;&nbsp; information.&nbsp; Authentication information itself is=
 appended to the <br>
&nbsp;&nbsp; LMP packet.&nbsp; It is not considered to be a part of the LMP=
 packet, but <br>
&nbsp;&nbsp; is transferred in the same IP packet. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When the Authentication flag is set in the LMP packet header,=
 an <br>
&nbsp;&nbsp; authentication data block is attached to the packet.&nbsp; This=
 block has <br>
&nbsp;&nbsp; a standard authentication header and a data portion.&nbsp; The=
 contents of <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 20] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; the data portion depend on the authentication type.&nbsp;=
 Currently, only <br>
&nbsp;&nbsp; MD5 is supported for LMP. <br>
&nbsp;&nbsp;&nbsp; <br>
11. <br>
&nbsp;&nbsp; IANA Considerations <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP defines the following name spaces which require management:=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; - Message Type Name Space. <br>
&nbsp;&nbsp; - Class and class type name spaces for LMP objects.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The following sections provide guidelines for managing these=
 name <br>
&nbsp;&nbsp; spaces. <br>
&nbsp;&nbsp;&nbsp; <br>
11.1. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Message Type Name Space <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP divides the name space for message types into two=
 ranges.&nbsp; The <br>
&nbsp;&nbsp; following are the guidelines for managing these ranges: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; - Message Types 0 - 49 and 60 - 255: These message types are=
 part of <br>
&nbsp;&nbsp;&nbsp;&nbsp; the LMP base protocol.&nbsp; Following the policies=
 outlined in [IANA], <br>
&nbsp;&nbsp;&nbsp;&nbsp; message types in this range are allocated through=
 an IETF <br>
&nbsp;&nbsp;&nbsp;&nbsp; Consensus action. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; - Message Types 50 - 59: Message types in this range are=
 reserved <br>
&nbsp;&nbsp;&nbsp;&nbsp; for UNI LMP extensions and the allocation in this=
 range is the <br>
&nbsp;&nbsp;&nbsp;&nbsp; responsibility of the OIF for supporting UNI=
 signaling. IANA <br>
&nbsp;&nbsp;&nbsp;&nbsp; management of this range of the Message Type name=
 space is <br>
&nbsp;&nbsp;&nbsp;&nbsp; unnecessary. <br>
&nbsp;<br>
11.2. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Object Class Name Space <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP divides the name space for object classes into two=
 ranges.&nbsp; The <br>
&nbsp;&nbsp; following are the guidelines for managing these ranges: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; - Classes 0 - 49 and 60 - 127:&nbsp; Object types in this range=
 are part <br>
&nbsp;&nbsp;&nbsp;&nbsp; of the LMP base protocol.&nbsp; Following the=
 policies outlined in <br>
&nbsp;&nbsp;&nbsp;&nbsp; [IANA], class types in this range are allocated=
 through an IETF <br>
&nbsp;&nbsp;&nbsp;&nbsp; Consensus action. Within each class, 256 class=
 types are possible. <br>
&nbsp;&nbsp;&nbsp;&nbsp; The allocation of class types for base LMP objects=
 are described <br>
&nbsp;&nbsp;&nbsp;&nbsp; in this draft and these are subject to IETF=
 consensus action. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; - Classes 50 - 59 are reserved for UNI LMP extensions and the=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp; allocation in this range is the responsibility of=
 the OIF for <br>
&nbsp;&nbsp;&nbsp;&nbsp; supporting UNI signaling. IANA management of this=
 range of the <br>
&nbsp;&nbsp;&nbsp;&nbsp; class name space, and the underlying class types,=
 is unnecessary. <br>
&nbsp;<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 21] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
12. <br>
&nbsp;&nbsp; LMP Finite State Machines <br>
&nbsp;&nbsp;&nbsp; <br>
12.1. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Control Channel FSM <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The control channel FSM defines the states and logics of=
 operation <br>
&nbsp;&nbsp; of an LMP control channel.&nbsp; The description of FSM state=
 transitions <br>
&nbsp;&nbsp; and associated actions is given in Section 3. <br>
&nbsp;&nbsp;&nbsp; <br>
12.1.1. Control Channel States <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; A control channel can be in one of the states described=
 below.&nbsp; <br>
&nbsp;&nbsp; Every state corresponds to a certain condition of the control=
 <br>
&nbsp;&nbsp; channel and is usually associated with a specific type of LMP=
 <br>
&nbsp;&nbsp; message that is periodically transmitted to the far end. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Down:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the=
 initial control channel state.&nbsp; In this <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; state, no attempt is being made to bring the control <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; channel up and no LMP messages are sent.&nbsp; The control=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; channel parameters should be set to the initial values. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; ConfigSnd:&nbsp;&nbsp; The control channel is in the parameter=
 negotiation <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; state.&nbsp; In this state the node periodically sends a <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Config message, and is expecting the other side to <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; reply with either a ConfigAck or ConfigNack message.&nbsp;=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; The FSM does not transition into the Active state until <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; the remote side positively acknowledges the parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; ConfRcv:&nbsp;&nbsp;&nbsp;&nbsp; The control channel is in the=
 parameter negotiation <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; state.&nbsp; In this state, the node is waiting for <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; acceptable configuration parameters from the remote <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; side.&nbsp; Once such parameters are received and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; acknowledged, the FSM can transition to the Active <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; state. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Active:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In this state the node=
 periodically sends a Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; message and is waiting to receive a valid Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; message.&nbsp; Once a valid Hello message is received, it=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; can transition to the UP state. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Up:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=
 CC is in an operational state.&nbsp; The node receives <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; valid Hello messages and sends Hello messages. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; GoingDown:&nbsp;&nbsp; A CC may go into this state because of=
 administrative <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; action.&nbsp; While a CC is in this state, the node sets the=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; ControlChannelDown bit in all the messages it sends. <br>
&nbsp;&nbsp;&nbsp; <br>
12.1.2. Control Channel Events <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Operation of the LMP control channel is described in terms of=
 FSM <br>
&nbsp;&nbsp; states and events.&nbsp; Control channel Events are generated=
 by the <br>
&nbsp;&nbsp; underlying protocols and software modules, as well as by the=
 packet <br>
&nbsp;&nbsp; processing routines and FSMs of associated TE links.&nbsp;=
 Every event <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 22] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; has its number and a symbolic name.&nbsp; Description of=
 possible control <br>
&nbsp;&nbsp; channel events is given below. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 1 : evBringUp:&nbsp;&nbsp;&nbsp; This is an externally=
 triggered event indicating <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that the control channel=
 negotiation should begin.&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This event, for example, may be=
 triggered by an <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operator command, by the=
 successful completion of <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a control channel bootstrap=
 procedure, or by <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration.&nbsp; Depending=
 on the configuration, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this will trigger either <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1a) the=
 sending of a Config message, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1b) a=
 period of waiting to receive a Config <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; message from the remote node. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 2 : evCCDn:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This event is=
 generated when there is indication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that the control channel is no=
 longer available. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 3 : evConfDone:&nbsp;&nbsp; This event indicates a ConfigAck=
 message has been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received, acknowledging the=
 Config parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 4 : evConfErr:&nbsp;&nbsp;&nbsp; This event indicates a=
 ConfigNack message has been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received, rejecting the Config=
 parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 5 : evNewConfOK:&nbsp; New Config message was received from=
 neighbor and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; positively Acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 6 : evNewConfErr: New Config message was received from neighbor=
 and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rejected with a ConfigNack=
 message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 7 : evContenWin:&nbsp; New Config message was received from=
 neighbor at <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the same time a Config message=
 was sent to the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; neighbor.&nbsp; The Local node=
 wins the contention.&nbsp; As <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a result, the received Config=
 message is ignored. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 8 : evContenLost: New Config message was received from neighbor=
 at <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the same time a Config message=
 was sent to the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; neighbor.&nbsp; The Local node=
 loses the contention. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8a) The=
 Config message is positively <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Acknowledged. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8b) The=
 Config message is negatively <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 9 : evAdminDown:&nbsp; The administrator has requested that the=
 control <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; channel is brought down=
 administratively.&nbsp; Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages (with=
 ControlChannelDown flag set) SHOULD <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be sent for HelloDeadInterval=
 seconds or until an <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LMP message is received over=
 the control channel <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with the ControlChannelDown=
 flag set. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 10: evNbrGoesDn:&nbsp; A packet with ControlChannelDown flag is=
 received <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the neighbor. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 23] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; 11: evHelloRcvd:&nbsp; A Hello packet with expected SeqNum has=
 been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 12: evHoldTimer:&nbsp; The HelloDeadInterval timer has expired=
 indicating <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that no Hello packet has been=
 received.&nbsp; This <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; moves the control channel back=
 into the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Negotiation state, and=
 depending on the local <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration, this will=
 trigger either <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12a)=
 the sending of periodic Config messages, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12b) a=
 period of waiting to receive Config <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; messages from the remote node. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 <br>
&nbsp;&nbsp; 13: evSeqNumErr:&nbsp; A Hello with unexpected SeqNum received=
 and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; discarded. <br>
&nbsp;<br>
&nbsp;&nbsp; 14: evReconfig:&nbsp;&nbsp; Control channel parameters have=
 been reconfigured <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and require renegotiation. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 15: evConfRet:&nbsp;&nbsp;&nbsp; A retransmission timer has=
 expired and a Config <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message is resent. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 16: evHelloRet:&nbsp;&nbsp; The HelloInterval timer has expired=
 and a Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet is sent. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 17: evDownTimer:&nbsp; A timer has expired and no messages have=
 been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received with the=
 ControlChannelDown flag set. <br>
&nbsp;<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 24] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
12.1.3. Control Channel FSM Description <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Figure 3 illustrates operation of the control channel FSM <br>
&nbsp;&nbsp; in a form of FSM state transition diagram. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-----------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&lt;--------------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---------&gt;|&nbsp; Down&nbsp;=
 |&lt;----------+&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |+---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;-------+&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;=
 | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp; ^&nbsp;&nbsp;&nbsp; 2,9,10| 2|&nbsp; 2| <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||1b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1a|&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 v&nbsp;&nbsp;&nbsp; | 2,9,10&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;=
 | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;------+|&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; 4,7,|&nbsp; |ConfSnd=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||=
 14,15+--|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;----+ ||&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3,8a|=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || +---------+ |8b&nbsp; 14,12a|=
 ||&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |+-|------&gt;+--------+&nbsp;&nbsp;&nbsp;&nbsp; | ||&nbsp; |&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;=
 +-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-----|-|+&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |6,14|&nbsp; |ConfRcv=
 |&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |&nbsp;&nbsp;&nbsp;=
 +--|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;--+ | |&nbsp;&nbsp;=
 |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp; | |=
 |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5|=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; +---------+ |=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v v=
 |6,12b | | |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp; | |=
 |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +----------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; | |=
 |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--| Active |---|-+ |&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 10,17|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 5,16|&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |-------|---+&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+ 9 |&nbsp;&nbsp;=
 13&nbsp; +-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Going=
 |&lt;--|----------+--------+&nbsp;&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Down&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11|=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 |5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v=
 |&nbsp; 6,12b|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp;=
 |&nbsp;&nbsp; |12a,14 | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +----------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |---+&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; Up&nbsp;&nbsp;=
 |-------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +------------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |---------------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; ^ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11,13,16 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 3: Control=
 Channel FSM <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 25] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; Event evCCDn always forces the FSM to the Down State.&nbsp;=
 Events <br>
&nbsp;&nbsp; evHoldTimer evReconfig always force the FSM to the Negotiation=
 state <br>
&nbsp;&nbsp; (either ConfigSnd or ConfigRcv). <br>
&nbsp;&nbsp;&nbsp; <br>
12.2. <br>
&nbsp;&nbsp;&nbsp;&nbsp; TE Link FSM <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The TE Link FSM defines the states and logics of operation of=
 an LMP <br>
&nbsp;&nbsp; TE Link. <br>
&nbsp;&nbsp;&nbsp; <br>
12.2.1. TE Link States <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; An LMP TE link can be in one of the states described below.=
 Every <br>
&nbsp;&nbsp; state corresponds to a certain condition of the TE link and is=
 <br>
&nbsp;&nbsp; usually associated with a specific type of LMP message that is=
 <br>
&nbsp;&nbsp; periodically transmitted to the far end via the associated=
 control <br>
&nbsp;&nbsp; channel or in-band via the data links. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Down:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There are no data=
 links allocated to the TE link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Init:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Data links have been=
 allocated to the TE link, but the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; configuration has not yet been synchronized with the LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; neighbor. <br>
<br>
BM&gt; I guess we are saying that once initially synchronized, subsequent=
 changes<br>
BM&gt; to TE Links that cause link summary to run could happen whilst the TE=
 Link<br>
BM&gt; is still in UP state. <br>
BM&gt; In the middle of the day, is the IDs and/or other properties<br>
BM&gt; of links are changed such that a TE Links go out of=
 synchronization,<br>
BM&gt; should we go back to &quot;Init&quot; state?, such that the above=
 definition of<br>
BM&gt; Init state is observed all the time?<br>
<br>
<br>
&nbsp;&nbsp; Up:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the=
 normal operational state of the TE link.&nbsp; At <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; least one primary CC is required to be operational <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; between the nodes sharing the TE link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Degraded:&nbsp;&nbsp; In this state, all primary CCs are down,=
 but the TE link <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; still includes some allocated data links. <br>
<br>
BM&gt; Does the term &quot;allocated&quot; here refer to &quot;allocated to=
 data traffic&quot;?<br>
BM&gt; I don't think so.. but could we be explicit?<br>
<br>
BM&gt; Related question. Whilst in Init state, if the last CC goes down,<br>
BM&gt; Shouldn't the TE Link go into degraded?<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
12.2.2. TE Link Events <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Operation of the LMP TE link is described in terms of FSM=
 states and <br>
&nbsp;&nbsp; events. TE Link events are generated by the packet processing=
 <br>
&nbsp;&nbsp; routines and by the FSMs of the associated primary control <br>
&nbsp;&nbsp; channel(s) and the data links. Every event has its number and a=
 <br>
&nbsp;&nbsp; symbolic name. Description of possible control channel events=
 is <br>
&nbsp;&nbsp; given below. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 1 : evDCUp:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One=
 or more data channels have been enabled and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assigned to the TE=
 Link. <br>
&nbsp;&nbsp; 2 : evSumAck:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LinkSummary=
 message received and positively <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; acknowledged. <br>
&nbsp;&nbsp; 3 : evSumNack:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LinkSummary=
 message received and negatively <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; acknowledged. <br>
&nbsp;&nbsp; 4 : evRcvAck:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 LinkSummaryAck message received acknowledging <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the TE Link=
 Configuration. <br>
&nbsp;&nbsp; 5 : evRcvNack:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LinkSummaryNack=
 message received. <br>
&nbsp;&nbsp; 6 : evSumRet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Retransmission timer has expired and LinkSummary <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message is resent.=
 <br>
&nbsp;&nbsp; 7 : evCCUp:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 First active control channel goes up. <br>
&nbsp;&nbsp; 8 : evCCDown:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last active=
 control channel goes down. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 26] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; 9 : evDCDown:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last data=
 channel of TE Link has been removed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
12.2.3. TE Link FSM Description <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Figure 4 illustrates operation of the LMP TE Link FSM in a form=
 of <br>
&nbsp;&nbsp; FSM state transition diagram. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3,7,8 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; v=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------&gt;|&nbsp; Down&nbsp;=
 |&lt;---------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; |&nbsp;=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 1|&nbsp;=
 |9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; v&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&lt;-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp; Init&nbsp; |&nbsp; |3,5,6&nbsp; |9 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |--+ 7,8&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 9|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=
 2,4|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp; 7&nbsp;&nbsp;=
 +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |----------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; |&nbsp; Deg&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; Up&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&lt;------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp; 8&nbsp;&nbsp; +--------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; ^=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2,3,4,5,6 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure=
 4: LMP TE Link FSM <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In the above FSM, the sub-states that may be implemented when=
 the <br>
&nbsp;&nbsp; link verification procedure is used have been omitted. <br>
<br>
BM&gt; Consider a TE Link that transitions to Down state via Degraded..=
 it<br>
BM&gt; has no data links and no CCs either. If now a DC is added to the=
 TE<br>
BM&gt; Link, shouldn't it go [back] to degraded state, rather than Init.<br>
BM&gt; When a TE Link in the Down state gets a new data link, it fits<br>
BM&gt; the definition of the degraded state.<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
12.3. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Data Link FSM <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The data link FSM defines the states and logics of operation of=
 a <br>
&nbsp;&nbsp; port or component link within an LMP TE link.&nbsp; Operation=
 of a data <br>
&nbsp;&nbsp; link is described in terms of FSM states and events.&nbsp;=
 Data-bearing <br>
&nbsp;&nbsp; links can either be in the active (transmitting) mode, where=
 Test <br>
&nbsp;&nbsp; messages are transmitted from them, or the passive (receiving)=
 mode, <br>
&nbsp;&nbsp; where Test messages are received through them.&nbsp; For=
 clarity, <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 27] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; separate FSMs are defined for the active/passive data-bearing=
 links; <br>
&nbsp;&nbsp; however, a single set of data link states and events are=
 defined.&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
12.3.1. Data Link States <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Any data link can be in one of the states described below.=
 Every <br>
&nbsp;&nbsp; state corresponds to a certain condition of the TE link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Down:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=
 data link has not been put in the resource pool <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; (i.e., the link is not =91in service=92 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Test:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The=
 data link is being tested.&nbsp; An LMP Test message <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; is periodically sent through the link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; PasvTest:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The data link is being=
 checked for incoming test <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; messages. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Up/Free:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The link has been=
 successfully tested and is now put <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; in the pool of resources (in-service).&nbsp; The=
 link has <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; not yet been allocated to data traffic. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Up/Allocated:&nbsp; The link is UP and has been allocated for=
 data <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; traffic. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Degraded:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The link was in the=
 Up/Allocated state when the last <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; CC associated with data link's TE Link has gone=
 down.&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; The link is put in the Degraded state, since it=
 is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; still being used for data LSP. <br>
&nbsp;&nbsp;&nbsp; <br>
12.3.2. Data Link Events <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Data bearing link events are generated by the packet processing=
 <br>
&nbsp;&nbsp; routines and by the FSMs of the associated control channel and=
 the <br>
&nbsp;&nbsp; TE link.&nbsp; Every event has its number and a symbolic name.=
 <br>
&nbsp;&nbsp; Description of possible data link events is given below: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 1 :evCCUp:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CC has gone up.=
 <br>
&nbsp;&nbsp; 2 :evCCDown:&nbsp;&nbsp;&nbsp;&nbsp; LMP neighbor connectivity=
 is lost.&nbsp; This indicates <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the last LMP control channel has=
 failed between <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; neighboring nodes. <br>
&nbsp;&nbsp; 3 :evStartTst:&nbsp;&nbsp; This is an external event that=
 triggers the sending <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of Test messages over the data=
 bearing link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 4 :evStartPsv:&nbsp;&nbsp; This is an external event that=
 triggers the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; listening for Test messages over the=
 data bearing <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; link. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 5 :evTestOK:&nbsp;&nbsp;&nbsp;&nbsp; Link verification was=
 successful and the link can <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be used for path establishment. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) This=
 event indicates the Link Verification <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; procedure (see Section 5) was successful <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; for this data link and a TestStatusSuccess <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 28] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; message was received over the control <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; channel. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) This=
 event indicates the link is ready for <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; path establishment, but the Link <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; Verification procedure was not used.&nbsp; For <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; in-band signaling of the control channel, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; the control channel establishment may be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; sufficient to verify the link. <br>
&nbsp;&nbsp; 6 :evTestRcv:&nbsp;&nbsp;&nbsp; Test message was received over=
 the data port and a <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TestStatusSuccess message is=
 transmitted over the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; control channel. <br>
&nbsp;&nbsp; 7 :evTestFail:&nbsp;&nbsp; Link verification returned negative=
 results.&nbsp; This <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; could be because (a) a=
 TestStatusFailure message <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; was received, or (b) an EndVerifyAck=
 message was <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received without receiving a=
 TestStatusSuccess or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TestStatusFailure message for the=
 data link. <br>
&nbsp;&nbsp; 8 :evPsvTestFail:Link verification returned negative=
 results.&nbsp; This <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicates that a Test message was not=
 detected and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; either (a) the VerifyDeadInterval has=
 expired or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) an EndVerify messages has been=
 received and the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VerifyDeadInterval has not yet=
 expired. <br>
&nbsp;&nbsp; 9 :evLnkAlloc:&nbsp;&nbsp; The data link has been allocated.=
 <br>
&nbsp;&nbsp; 10:evLnkDealloc: The data link has been deallocated. <br>
&nbsp;&nbsp; 11:evTestRet:&nbsp;&nbsp;&nbsp; A retransmission timer has=
 expired and the Test <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message is resent. <br>
&nbsp;&nbsp; 12:evSummaryFail:The LinkSummary did not match for this data=
 port. <br>
&nbsp;&nbsp; 13:evLocalizeFail:A Failure has been localized to this data=
 link. <br>
&nbsp;&nbsp; 14:evdcDown:&nbsp;&nbsp;&nbsp;&nbsp; The data channel is no=
 longer available. <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 29] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
12.3.3. Active Data Link FSM Description <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Figure 5 illustrates operation of the LMP active data link FSM=
 in a <br>
&nbsp;&nbsp; form of FSM state transition diagram. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; +------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; +-------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;-------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; +---------&gt;| Down=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 +----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;-----+ | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |5b&nbsp;&nbsp; 3|&nbsp;=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp; |2,7&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 v&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;-+&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; | Test=
 |&nbsp; |11 | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |--+&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; 5a|=
 3^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |2,12 |&nbsp;&nbsp; +---------+&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 +--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |14&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Up/Free=
 |----+ | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp; +---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 9| ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; |=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; v |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-----+&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;=
 |&lt;--------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |13&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Deg=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |Up/Alloc |------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;=
 |--------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-----+&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---------+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 5: Active LMP Data Link FSM=
 <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 30] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
12.3.4. Passive Data Link FSM Description <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Figure 6 illustrates operation of the LMP passive data link FSM=
 in a <br>
&nbsp;&nbsp; form of FSM state transition diagram. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; +------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; +-------------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&lt;------+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; +----------&gt;| Down |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; +-----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&lt;----+ | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 +------+&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |5b&nbsp;&nbsp;&nbsp; 4|&nbsp;=
 ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp; |2,8&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 v&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; +----------+&nbsp;=
 | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; | PasvTest |&nbsp;=
 | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; +----------+&nbsp;=
 | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 6|&nbsp; 4^&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |2,12 |&nbsp;&nbsp;&nbsp; +---------+&nbsp;&nbsp; | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; +---&gt;| Up/Free |14 | | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |---+ | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp; +----------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------+&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; 9| ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=
 |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; v |10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +---------+&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |13&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Deg=
 |&lt;--------|Up/Alloc |-----+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;=
 |--------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 +-----+&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---------+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6: Passive LMP Data Link FSM=
 <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 31] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
13. <br>
&nbsp;&nbsp; LMP Message Formats <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; All LMP messages are IP encoded (except, in some cases, the=
 Test <br>
&nbsp;&nbsp; messages are limited by the transport mechanism for in-band=
 <br>
&nbsp;&nbsp; messaging) with protocol number xxx - TBA (to be assigned) by=
 IANA. <br>
&nbsp;&nbsp;&nbsp; <br>
13.1. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Common Header <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; In addition to the standard IP header, all LMP messages=
 (except, in <br>
&nbsp;&nbsp; some cases, the Test messages which are limited by the=
 transport <br>
&nbsp;&nbsp; mechanism for in-band messaging) have the following common=
 header: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; | Vers&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 Flags&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Msg=
 Type&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LMP=
 Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Checksum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Vers: 4 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Protocol version number.&nbsp;=
 This is version 1. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Flags: 8 bits.&nbsp; The following values are defined.&nbsp;=
 All other values <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are reserved. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01: ControlChannelDown <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02: LMP Restart <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; This bit is set to indicate the LMP component has <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; restarted.&nbsp; This flag may be reset to 0 when a Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; message is received with RcvSeqNum equal to the local <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; TxSeqNum. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x04: LMP-WDM Support <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; When set, indicates that this node is willing and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; capable of receiving all the messages and objects <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; described in [LMP-DWDM]. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x08: Authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; When set, this bit indicates that an authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; block is attached at the end of the LMP message.&nbsp; See <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Sections 7 and 9.3 for more details. <br>
&nbsp;<br>
&nbsp;&nbsp; Msg Type: 8 bits.&nbsp; The following values are defined.&nbsp;=
 All other <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 values are reserved. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp; =3D Config <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 32] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp; =3D ConfigAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp; =3D ConfigNack <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp; =3D Hello <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp; =3D BeginVerify <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp; =3D BeginVerifyAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp; =3D BeginVerifyNack <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp; =3D EndVerify <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp; =3D EndVerifyAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 =3D Test <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11 =3D TestStatusSuccess <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12 =3D TestStatusFailure <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 13 =3D TestStatusAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 14 =3D LinkSummary <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 15 =3D LinkSummaryAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16 =3D LinkSummaryNack <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 17 =3D ChannelStatus <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 18 =3D ChannelStatusAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 19 =3D ChannelStatusRequest <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20 =3D ChannelStatusResponse <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All of the messages are sent over=
 the control channel EXCEPT <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Test message, which is sent=
 over the data link that is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; being tested. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP Length: 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The total length of this LMP=
 message in bytes, including the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; common header and any=
 variable-length objects that follow. <br>
&nbsp;<br>
&nbsp;&nbsp; Checksum: 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The standard IP checksum of the=
 entire contents of the LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message, starting with the LMP=
 message header. This checksum is <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 33] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; calculated as the 16-bit one's=
 complement of the one's <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; complement sum of all the 16-bit=
 words in the packet. If the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet's length is not an=
 integral number of 16-bit words, the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet is padded with a byte of=
 zero before calculating the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; checksum. <br>
<br>
BM&gt; One thing that will be of great help for implementation is a=
 &quot;message<br>
BM&gt; specific&quot; field (perhaps a couple of them). An example use of=
 such a field<br>
BM&gt; could be to store the number of data link objects in a link=
 summary<br>
BM&gt; and link summary ack message.<br>
<br>
&nbsp;<br>
13.2. <br>
&nbsp;&nbsp;&nbsp;&nbsp; LMP Object Format <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP messages are built using objects.&nbsp; Each object is=
 identified by <br>
&nbsp;&nbsp; its Object Class and Class-type.&nbsp; Each object has a name,=
 which is <br>
&nbsp;&nbsp; always capitalized in this document. LMP objects can be either=
 <br>
&nbsp;&nbsp; negotiable or non-negotiable (identified by the N bit in the=
 TLV <br>
&nbsp;&nbsp; header).&nbsp; Negotiable objects can be used to let the=
 devices agree on <br>
&nbsp;&nbsp; certain values.&nbsp; Non-negotiable Objects are used for=
 announcement of <br>
&nbsp;&nbsp; specific values that do not need or do not allow negotiation.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The format of the LMP object is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |N|&nbsp;&nbsp; C-Type&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp; Class&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (TLV=
 Object)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; N: 1 bit <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The N flag indicates if the=
 object is negotiable (N=3D1) or non-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; negotiable (N=3D0). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; C-Type: 7 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Class-type within an Object=
 Class.&nbsp; Values are defined in <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 14. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Class indicates the Object=
 type.&nbsp; Each Object has a name, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; which is always capitalized in=
 this document. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Length: 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Length field indicates the=
 length of the Object in bytes. <br>
&nbsp;&nbsp;&nbsp; <br>
13.3. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Authentication <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When authentication is used for LMP, the authentication itself=
 is <br>
&nbsp;&nbsp; appended to the LMP packet.&nbsp; It is not considered to be a=
 part of <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 34] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; the LMP packet, but is transmitted in the same IP packet as=
 shown <br>
&nbsp;&nbsp; below: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LMP Common=
 Header&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LMP=
 Payload&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Authentication=
 Block&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The authentication block consists of an 8 byte header followed=
 by the <br>
&nbsp;&nbsp; data portion shown as follows: <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; Auth=
 Type&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Key ID&nbsp;&nbsp;&nbsp;&nbsp; | Auth=
 Data Len | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Cryptographic Sequence=
 Number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MD5 Signature=
 (16)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Auth Type: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; This defines the type of authentication used for LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; messages.&nbsp; The following authentication types are <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; defined, all other are reserved for future use: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 0&nbsp; No authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 1&nbsp; Cryptographic authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; <br>
&nbsp;&nbsp; Key ID: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; This field is defined only for cryptographic <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; authentication. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; <br>
&nbsp;&nbsp; Auth Data Length: 8 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; This field contains the length of the data portion of the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; authentication block. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 35] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; LMP authentication is performed on a per control channel=
 basis.&nbsp; The <br>
&nbsp;&nbsp; packet authentication procedure is very similar to the one used=
 in <br>
&nbsp;&nbsp; OSPF, including multiple key support, key management, etc. The=
 <br>
&nbsp;&nbsp; details specific to LMP are defined below. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Sending authenticated packets <br>
&nbsp;&nbsp; ----------------------------- <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a packet needs to be sent over a control channel and an=
 <br>
&nbsp;&nbsp; authentication method is configured for it, the Authentication=
 flag <br>
&nbsp;&nbsp; in the LMP header is set to 1, the LMP Length field is set to=
 the <br>
&nbsp;&nbsp; length of the LMP packet only, not including the authentication=
 <br>
&nbsp;&nbsp; block. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; 1) The Checksum field in the LMP packet is set to zero (this=
 will <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; make the receiving side drop the packet if=
 authentication is not <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; supported). <br>
&nbsp;&nbsp; 2) The LMP authentication header is filled out properly. The=
 message <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; digest is calculated over the LMP packet=
 together with the LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication header. The input to the=
 message digest <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; calculation consists of the LMP packet, the=
 LMP authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; header, and the secret key. When using MD5 as=
 the authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; algorithm, the message digest calculation=
 proceeds as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) The authentication header is appended to=
 the LMP packet. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) The 16 byte MD5 key is appended after the=
 LMP authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; header. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (c) Trailing pad and length fields are added,=
 as specified in <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [MD5]. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (d) The MD5 authentication algorithm is run=
 over the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; concatenation of the=
 LMP packet, authentication header, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; secret key, pad and=
 length fields, producing a 16 byte <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message digest (see=
 [MD5]). <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (e) The MD5 digest is written over the secret=
 key (i.e., appended <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the original=
 authentication header). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The authentication block is added to the IP packet right after=
 the <br>
&nbsp;&nbsp; LMP packet, so IP packet length includes the length of both LMP=
 <br>
&nbsp;&nbsp; packet and LMP authentication blocks. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Receiving authenticated packets <br>
&nbsp;&nbsp; ------------------------------- <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When an LMP packet with the Authentication flag set has been=
 received <br>
&nbsp;&nbsp; on a control channel that is configured for authentication, it=
 must <br>
&nbsp;&nbsp; be authenticated.&nbsp; The value of the Authentication field=
 MUST match <br>
&nbsp;&nbsp; the authentication type configured for the control channel (if=
 any). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If an LMP protocol packet is accepted as authentic, processing=
 of the <br>
&nbsp;&nbsp; packet continues.&nbsp; Packets that fail authentication are=
 discarded.&nbsp; <br>
&nbsp;&nbsp; Note that the checksum field in the LMP packet header is not=
 checked <br>
&nbsp;&nbsp; when the packet is authenticated. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 36] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; (1) Locate the receiving control channel's configured key=
 having Key <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ID equal to that specified in the=
 received LMP authentication <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; block.&nbsp; If the key is not found,=
 or if the key is not valid for <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reception (i.e., current time does not=
 fall into the key's <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; active time frame), the LMP packet is=
 discarded. <br>
&nbsp;&nbsp; (2) If the cryptographic sequence number found in the LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication header is less than the=
 cryptographic sequence <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; number recorded in the control channel=
 data structure, the LMP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet is discarded. <br>
&nbsp;&nbsp; (3) Verify the message digest in the data portion of the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication block in the following=
 steps: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a) The received digest is set aside.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b) A new digest is calculated, as=
 specified in the previous <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; section. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (c) The calculated and received digests=
 are compared.&nbsp; If they <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do not match,=
 the LMP packet is discarded.&nbsp; If they do <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; match, the LMP=
 protocol packet is accepted as authentic, and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the=
 &quot;cryptographic sequence number&quot; in the control channel's <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; data structure=
 is set to the sequence number found in the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packet's LMP=
 header. <br>
&nbsp;&nbsp;&nbsp; <br>
13.4. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Parameter Negotiation Messages <br>
<br>
BM&gt; Suggest changing to &quot;Hello parameter negotiation=
 messages&quot;.<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
13.4.1. Config Message (MsgType =3D 1) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Config message is used in the control channel negotiation=
 phase <br>
&nbsp;&nbsp; of LMP.&nbsp; The contents of the Config message are built=
 using LMP <br>
&nbsp;&nbsp; objects.&nbsp; The format of the Config message is as follows:=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;Config Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_CCID&gt; &lt;MESSAGE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &lt;LOCAL_NODE_ID&gt; &lt;CONFIG&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
<br>
BM&gt; If order is to be followed for ALL messages, include it in one<br>
BM&gt; place at beginning of section 13<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The MESSAGE_ID is within the scope of the CCID. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Config message MUST be periodically transmitted until (1)=
 it <br>
&nbsp;&nbsp; receives a ConfigAck or ConfigNack message, (2) a timeout=
 expires <br>
&nbsp;&nbsp; and no ConfigAck or ConfigNack message has been received, or=
 (3) it <br>
&nbsp;&nbsp; receives a Config message from the remote node and has lost the=
 <br>
&nbsp;&nbsp; contention (e.g., the Node Id of the remote node is higher than=
 the <br>
&nbsp;&nbsp; Node Id of the local node).&nbsp; Both the retransmission=
 interval and <br>
&nbsp;&nbsp; the timeout period are local configuration parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
13.4.2. ConfigAck Message (MsgType =3D 2) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ConfigAck message is used to acknowledge receipt of the=
 Config <br>
&nbsp;&nbsp; message and indicate agreement on all parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 37] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; &lt;ConfigAck Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_CCID&gt; &lt;LOCAL_NODE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; &lt;REMOTE_CCID&gt; &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; &lt;REMOTE_NODE_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and=
 REMOTE_NODE_ID <br>
&nbsp;&nbsp; objects MUST be obtained from the Config message being=
 acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
13.4.3. ConfigNack Message (MsgType =3D 3) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ConfigNack message is used to acknowledge receipt of the=
 Config <br>
&nbsp;&nbsp; message and indicate disagreement on non-negotiable parameters=
 or <br>
&nbsp;&nbsp; propose other values for negotiable parameters.&nbsp;=
 Parameters where <br>
&nbsp;&nbsp; agreement was reached MUST NOT be included in the ConfigNack=
 <br>
&nbsp;&nbsp; Message.&nbsp; The format of the ConfigNack message is as=
 follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;ConfigNack Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_CCID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; &lt;LOCAL_NODE_ID&gt;&nbsp; &lt;REMOTE_CCID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; &lt;MESSAGE_ID_ACK&gt; &lt;REMOTE_NODE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; &lt;ERROR_CODE&gt; [&lt;CONFIG&gt;] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and=
 REMOTE_NODE_ID <br>
&nbsp;&nbsp; objects MUST be obtained from the Config message being=
 negatively <br>
&nbsp;&nbsp; acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ConfigNack uses CONFIG_ERROR_ C-Type 1. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; It is possible that multiple parameters may be invalid in the=
 Config <br>
&nbsp;&nbsp; message.&nbsp; As such, multiple bits may be set in the=
 ERROR_CODE. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If a negotiable CONFIG object is included in the ConfigNack=
 message, <br>
&nbsp;&nbsp; it MUST include acceptable values for the parameters.&nbsp; The=
 <br>
&nbsp;&nbsp; ERROR_CODE MUST indicate =93Renegotiate CONFIG parameter.=94=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the ConfigNack message includes CONFIG objects for=
 non-negotiable <br>
&nbsp;&nbsp; parameters, they MUST be copied from the CONFIG objects=
 received in <br>
&nbsp;&nbsp; the Config message.&nbsp; The ERROR_CODE MUST indicate=
 =93Unacceptable non-<br>
&nbsp;&nbsp; negotiable CONFIG parameter.=94 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the ConfigNack message is received and only includes CONFIG=
 <br>
&nbsp;&nbsp; objects that are negotiable, then a new Config message SHOULD=
 be <br>
&nbsp;&nbsp; sent.&nbsp; The values in the CONFIG object of the new Config=
 message <br>
&nbsp;&nbsp; SHOULD take into account the acceptable values included in the=
 <br>
&nbsp;&nbsp; ConfigNack message. <br>
&nbsp;&nbsp;&nbsp; <br>
13.5. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Hello Message (MsgType =3D 4) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The format of the Hello message is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 38] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; &lt;Hello Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_CCID&gt; &lt;Hello&gt; <br>
<br>
BM&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^^^^^^=
 Should be in upper case<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Hello message MUST be periodically transmitted at least=
 once <br>
&nbsp;&nbsp; every HelloInterval msec.&nbsp; If no Hello message is received=
 within <br>
&nbsp;&nbsp; the HelloDeadInterval, the control channel is assumed to have=
 <br>
&nbsp;&nbsp; failed. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Link Verification <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.1. BeginVerify Message (MsgType =3D 5) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The BeginVerify message is sent over the control channel and is=
 used <br>
&nbsp;&nbsp; to initiate the link verification process.&nbsp; The format is=
 as <br>
&nbsp;&nbsp; follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;BeginVerify Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_LINK_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt; [&lt;REMOTE_LINK_ID&gt;] <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; &lt;BEGIN_VERIFY&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; To limit the scope of Link Verification to a particular TE=
 Link, the <br>
&nbsp;&nbsp; LOCAL_LINK_ID SHOULD be non-zero.&nbsp; If this field is zero,=
 the data <br>
&nbsp;&nbsp; links can span multiple TE links and/or they may comprise a TE=
 link <br>
&nbsp;&nbsp; that is yet to be configured. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The REMOTE_LINK_ID may be included if the local/remote Link Id=
 <br>
&nbsp;&nbsp; mapping is known. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The REMOTE_LINK_ID MUST be non-zero if included. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The BeginVerify message MUST be periodically transmitted until=
 (1) <br>
&nbsp;&nbsp; the node receives either a BeginVerifyAck or BeginVerifyNack=
 message <br>
&nbsp;&nbsp; to accept or reject the verify process or (2) a timeout expires=
 and <br>
&nbsp;&nbsp; no BeginVerifyAck or BeginVerifyNack message has been=
 received.&nbsp; <br>
&nbsp;&nbsp; Both the retransmission interval and the timeout period are=
 local <br>
&nbsp;&nbsp; configuration parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.2. BeginVerifyAck Message (MsgType =3D 6) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a BeginVerify message is received and Test messages are=
 ready <br>
&nbsp;&nbsp; to be processed, a BeginVerifyAck message MUST be transmitted.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;BeginVerifyAck Message&gt; ::=3D &lt;Common Header&gt;=
 [&lt;LOCAL_LINK_ID&gt;] <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID_ACK&gt;=
 &lt;BEGIN_VERIFY_ACK&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 39] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; The LOCAL_LINK_ID may be included if the local/remote Link Id=
 <br>
&nbsp;&nbsp; mapping is known or learned through the BeginVerify message.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LOCAL_LINK_ID MUST be non-zero if included. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK object MUST be obtained from=
 the <br>
&nbsp;&nbsp; BeginVerify message being acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The VERIFY_ID object contains a node-unique value that is=
 assigned <br>
&nbsp;&nbsp; by the generator of the BeginVerifyAck message.&nbsp; This=
 value is used <br>
&nbsp;&nbsp; to uniquely identify the Verification process from multiple LMP=
 <br>
&nbsp;&nbsp; neighbors and/or parallel Test procedures between the same LMP=
 <br>
&nbsp;&nbsp; neighbors. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.3. BeginVerifyNack Message (MsgType =3D 7) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If a BeginVerify message is received and a node is unwilling or=
 <br>
&nbsp;&nbsp; unable to begin the Verification procedure, a BeginVerifyNack=
 <br>
&nbsp;&nbsp; message MUST be transmitted. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;BeginVerifyNack Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_LINK_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID_ACK&gt;=
 &lt;ERROR_CODE&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK object MUST be obtained from=
 the <br>
&nbsp;&nbsp; BeginVerify message being negatively acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the Verification process is not supported, the ERROR_CODE=
 MUST <br>
&nbsp;&nbsp; indicate =93Link Verification Procedure not supported=94. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If Verification is supported, but the node unable to begin the=
 <br>
&nbsp;&nbsp; procedure, the ERROR_CODE MUST indicate =93Unwilling to=
 verify=94.&nbsp; If a <br>
&nbsp;&nbsp; BeginVerifyNack message is received with such an ERROR_CODE,=
 the <br>
&nbsp;&nbsp; node that originated the BeginVerify SHOULD schedule a=
 BeginVerify <br>
&nbsp;&nbsp; retransmission after Rf seconds, where Rf is a locally defined=
 <br>
&nbsp;&nbsp; parameter. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the Verification Transport mechanism is not supported, the=
 <br>
&nbsp;&nbsp; ERROR_CODE MUST indicate =93Unsupported verification transport=
 <br>
&nbsp;&nbsp; mechanism=94. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If remote configuration of the TE Link Id is not supported and=
 the <br>
&nbsp;&nbsp; REMOTE_LINK_ID object (included in the BeginVerify message)=
 does not <br>
&nbsp;&nbsp; match any configured values, the ERROR_CODE MUST indicate =93TE=
 Link <br>
&nbsp;&nbsp; Id configuration error=94. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.4. EndVerify Message (MsgType =3D 8) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 40] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; The EndVerify message is sent over the control channel and is=
 used <br>
&nbsp;&nbsp; to terminate the link verification process.&nbsp; The EndVerify=
 message <br>
&nbsp;&nbsp; may be sent at any time the initiating node desires to end the=
 <br>
&nbsp;&nbsp; Verify procedure.&nbsp; The format is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;EndVerify Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID&gt; &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The EndVerify message will be periodically transmitted until=
 (1) an <br>
&nbsp;&nbsp; EndVerifyAck message has been received or (2) a timeout expires=
 and <br>
&nbsp;&nbsp; no EndVerifyAck message has been received.&nbsp; Both the=
 retransmission <br>
&nbsp;&nbsp; interval and the timeout period are local configuration=
 parameters. <br>
&nbsp;<br>
13.6.5. EndVerifyAck Message (MsgType =3D9) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The EndVerifyAck message is sent over the control channel and=
 is <br>
&nbsp;&nbsp; used to acknowledge the termination of the link verification=
 <br>
&nbsp;&nbsp; process.&nbsp; The format is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;EndVerifyAck Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK object MUST be obtained from=
 the <br>
&nbsp;&nbsp; EndVerify message being acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.6. Test Message (MsgType =3D 10) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Test message is transmitted over the data link and is used=
 to <br>
&nbsp;&nbsp; verify its physical connectivity. Unless explicitly stated in=
 the <br>
&nbsp;&nbsp; Verify Transport Mechanism description for the BEGIN_VERIFY=
 class, <br>
&nbsp;&nbsp; this is transmitted as an IP packet with payload format as=
 follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;Test Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;VERIFY_ID&gt; &lt;LOCAL_INTERFACE_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Note that this message is sent over a data link and NOT over=
 the <br>
&nbsp;&nbsp; control channel.&nbsp; The transport mechanism for the Test=
 message is <br>
&nbsp;&nbsp; negotiated using Verify Transport Mechanism field of the=
 BeginVerify <br>
&nbsp;&nbsp; Object and the Verify Transport Response field of the=
 BeginVerifyAck <br>
&nbsp;&nbsp; Object (see Sections 14.9 and 14.10). <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The local (transmitting) node sends a given Test message <br>
&nbsp;&nbsp; periodically (at least once every VerifyInterval ms) on the=
 <br>
&nbsp;&nbsp; corresponding data link until (1) it receives a correlating=
 <br>
&nbsp;&nbsp; TestStatusSuccess or TestStatusFailure message on the control=
 <br>
&nbsp;&nbsp; channel from the remote (receiving) node or (2) all active=
 control <br>
&nbsp;&nbsp; channels between the two nodes have failed. The remote node=
 will <br>
&nbsp;&nbsp; send a given TestStatus message periodically over the control=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 41] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; channel until it receives either a correlating TestStatusAck=
 message <br>
&nbsp;&nbsp; or an EndVerify message is received over the control channel.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
13.6.7. TestStatusSuccess Message (MsgType =3D 11) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The TestStatusSuccess message is transmitted over the control=
 <br>
&nbsp;&nbsp; channel and is used to transmit the mapping between the local=
 <br>
&nbsp;&nbsp; Interface Id and the Interface Id that was received in the Test=
 <br>
&nbsp;&nbsp; message.&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;TestStatusSuccess Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_LINK_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt;=
 &lt;LOCAL_INTERFACE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &lt;REMOTE_INTERFACE_ID&gt; &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the REMOTE_INTERFACE_ID object MUST be obtained=
 from <br>
&nbsp;&nbsp; the corresponding Test message being positively acknowledged.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.8. TestStatusFailure Message (MsgType =3D 12) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The TestStatusFailure message is transmitted over the control=
 <br>
&nbsp;&nbsp; channel and is used to indicate that the Test message was not=
 <br>
&nbsp;&nbsp; received. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;TestStatusFailure Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
13.6.9. TestStatusAck Message (MsgType =3D 13) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The TestStatusAck message is used to acknowledge receipt of the=
 <br>
&nbsp;&nbsp; TestStatusSuccess or TestStatusFailure messages. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;TestStatusAck Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;VERIFY_ID&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK object MUST be obtained from=
 the <br>
&nbsp;&nbsp; TestStatusSuccess or TestStatusFailure message being=
 acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
13.7. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Link Summary Messages <br>
&nbsp;&nbsp;&nbsp; <br>
13.7.1. LinkSummary Message (MsgType =3D 14) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummary message is used to synchronize the Interface=
 Ids and <br>
&nbsp;&nbsp; correlate the properties of the TE link.&nbsp; The format of=
 the <br>
&nbsp;&nbsp; LinkSummary message is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 42] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; &lt;LinkSummary Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID&gt; &lt;TE_LINK&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; &lt;DATA_LINK&gt; [&lt;DATA_LINK&gt;...] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummary message can be exchanged at any time a link is=
 not <br>
&nbsp;&nbsp; in the Verification process.&nbsp; The LinkSummary message MUST=
 be <br>
&nbsp;&nbsp; periodically transmitted until (1) the node receives a <br>
&nbsp;&nbsp; LinkSummaryAck or LinkSummaryNack message or (2) a timeout=
 expires <br>
&nbsp;&nbsp; and no LinkSummaryAck or LinkSummaryNack message has been=
 received.&nbsp; <br>
&nbsp;&nbsp; Both the retransmission interval and the timeout period are=
 local <br>
&nbsp;&nbsp; configuration parameters. <br>
&nbsp;&nbsp;&nbsp; <br>
13.7.2. LinkSummaryAck Message (MsgType =3D 15) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummaryAck message is used to indicate agreement on the=
 <br>
&nbsp;&nbsp; Interface Id synchronization and acceptance/agreement on all=
 the <br>
&nbsp;&nbsp; link parameters. It is on the reception of this message that=
 the <br>
&nbsp;&nbsp; local node makes the TE Link Id associations. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;LinkSummaryAck Message&gt; ::=3D&nbsp; &lt;Common=
 Header&gt; &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
13.7.3. LinkSummaryNack Message (MsgType =3D 16) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummaryNack message is used to indicate disagreement on=
 non-<br>
&nbsp;&nbsp; negotiated parameters or propose other values for negotiable=
 <br>
&nbsp;&nbsp; parameters.&nbsp; Parameters where agreement was reached MUST=
 NOT be <br>
&nbsp;&nbsp; included in the LinkSummaryNack Object. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;LinkSummaryNack Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ERROR_CODE&gt;=
 [&lt;DATA_LINK&gt;...] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummary TLVs MUST include acceptable values for all=
 <br>
&nbsp;&nbsp; negotiable parameters.&nbsp; If the LinkSummaryNack includes=
 LinkSummary <br>
&nbsp;&nbsp; TLVs for non-negotiable parameters, they MUST be copied from=
 the <br>
&nbsp;&nbsp; LinkSummary TLVs received in the LinkSummary message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the LinkSummaryNack message is received and only includes=
 <br>
&nbsp;&nbsp; negotiable parameters, then a new LinkSummary message SHOULD be=
 <br>
&nbsp;&nbsp; sent.&nbsp; The values received in the new LinkSummary message=
 SHOULD <br>
&nbsp;&nbsp; take into account the acceptable parameters included in the=
 <br>
&nbsp;&nbsp; LinkSummaryNack message. <br>
<br>
BM&gt; It looks like sending a linksummarynack that includes both=
 non-negotiable<br>
BM&gt; parameters as well as negotiable parameters is kind of useless..<br>
BM&gt; because the initiator will not resend a link summary in that case.=
 Yes?<br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The LinkSummaryNack message uses LINK_SUMMARY_ERROR_ C-Type 3.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
13.8. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Fault Management Messages <br>
&nbsp;&nbsp;&nbsp; <br>
13.8.1. ChannelStatus Message (MsgType =3D 17) <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 43] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatus message is sent over the control channel and=
 is <br>
&nbsp;&nbsp; used to notify an LMP neighbor of the status of a data=
 link.&nbsp; A node <br>
&nbsp;&nbsp; that receives a ChannelStatus message MUST respond with a <br>
&nbsp;&nbsp; ChannelStatusAck message.&nbsp; The format is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;ChannelStatus Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;LOCAL_LINK_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt; &lt;CHANNEL_STATUS&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the CHANNEL_STATUS object does not include any Interface=
 Ids, <br>
&nbsp;&nbsp; then this indicates the entire TE Link has failed. <br>
&nbsp;&nbsp;&nbsp; <br>
13.8.2. ChannelStatusAck Message (MsgType =3D 18) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatusAck message is used to acknowledge receipt of=
 the <br>
&nbsp;&nbsp; ChannelStatus Message.&nbsp; The format is as follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;ChannelStatusAck Message&gt; ::=3D &lt;Common Header&gt;=
 &lt;MESSAGE_ID_ACK&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK object MUST be obtained from=
 the <br>
&nbsp;&nbsp; ChannelStatus message being acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
13.8.3. ChannelStatusRequest Message (MsgType =3D 19) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatusRequest message is sent over the control=
 channel <br>
&nbsp;&nbsp; and is used to request the status of one or more data=
 link(s).&nbsp; A <br>
&nbsp;&nbsp; node that receives a ChannelStatusRequest message MUST respond=
 with <br>
&nbsp;&nbsp; a ChannelStatusResponse message.&nbsp; The format is as=
 follows: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;ChannelStatusRequest Message&gt; ::=3D &lt;Common=
 Header&gt; &lt;LOCAL_LINK_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &lt;MESSAGE_ID&gt; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [&lt;CHANNEL_STATUS_REQUEST&gt;] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the CHANNEL_STATUS_REQUEST object is not included, then the=
 <br>
&nbsp;&nbsp; ChannelStatusRequest is being used to request the status of ALL=
 of <br>
&nbsp;&nbsp; the data link(s) of the TE Link. <br>
&nbsp;&nbsp;&nbsp; <br>
13.8.4. ChannelStatusResponse Message (MsgType =3D 20) <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The ChannelStatusResponse message is used to acknowledge=
 receipt of <br>
&nbsp;&nbsp; the ChannelStatusRequest Message and notify the LMP neighbor of=
 the <br>
&nbsp;&nbsp; status of the data channel(s).&nbsp; The format is as follows:=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; &lt;ChannelStatusResponse Message&gt; ::=3D &lt;Common=
 Header&gt; &lt;MESSAGE_ID_ACK&gt;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 &lt;CHANNEL_STATUS&gt; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 44] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; The above transmission order SHOULD be followed. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the MESSAGE_ID_ACK objects MUST be obtained=
 from the <br>
&nbsp;&nbsp; ChannelStatusRequest message being acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
14. <br>
&nbsp;&nbsp; LMP Object Definitions <br>
&nbsp;&nbsp;&nbsp; <br>
14.1. <br>
&nbsp;&nbsp;&nbsp;&nbsp; CCID (Control Channel ID) Classes <br>
&nbsp;&nbsp;&nbsp; <br>
14.1.1. LOCAL_CCID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 1.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=
 CC_Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; CC_Id:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This MUST be node-wide unique and=
 non-zero.&nbsp; The CC_Id <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifies the control channel of=
 the sender associated with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
<br>
<br>
<br>
BM&gt; Suggestion: Why not reserve C-Type =3D 2 for OIF- OIF OUNI 125.7=
 allows<br>
BM&gt; CCID to be either numbered (IPv4) or unnumbered.<br>
&nbsp;<br>
14.1.2. REMOTE_CCID Class <br>
&nbsp;<br>
&nbsp;&nbsp; Class =3D 2. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=
 CC_Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; CC_Id:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the remote node=
=92s CC_Id and MUST be non-zero.&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.2. <br>
&nbsp;&nbsp;&nbsp;&nbsp; NODE_ID Classes <br>
&nbsp;&nbsp;&nbsp; <br>
14.2.1.&nbsp; LOCAL_NODE_ID Class <br>
&nbsp;<br>
&nbsp;&nbsp; Class =3D 3. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 45] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Node_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Node_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identities the node that=
 originated the LMP packet. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.2.2. REMOTE _NODE_ID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 4. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Node_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Node_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identities the remote node.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.3. <br>
&nbsp;&nbsp;&nbsp;&nbsp; LINK _ID Classes <br>
&nbsp;&nbsp;&nbsp; <br>
14.3.1. LOCAL_LINK_ID Class <br>
&nbsp;<br>
&nbsp;&nbsp; Class =3D 5 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 46] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Reserved for OIF, C-Type =3D 4 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Link_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the sender=92s=
 Link associated with the message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.3.2. REMOTE _LINK_ID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 6&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Link_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 47] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Reserved for OIF, C-Type =3D 4 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Link_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the remote node=
=92s Link Id and MUST be non-zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.4. <br>
&nbsp;&nbsp;&nbsp;&nbsp; INTERFACE_ID Classes <br>
&nbsp;&nbsp;&nbsp; <br>
14.4.1. LOCAL_INTERFACE_ID Class <br>
&nbsp;<br>
&nbsp;&nbsp; Class =3D 7 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 48] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; Interface_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the data link=
 (either port or component link).&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Interface_Id MUST be=
 node-wide unique and non-zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.4.2. REMOTE _INTERFACE_ID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 8.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Interface_Id: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the remote node=
=92s data link (either port or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; component link).&nbsp; The=
 Interface Id MUST be non-zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.5. <br>
&nbsp;&nbsp;&nbsp;&nbsp; MESSAGE_ID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 9.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 49] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; MessageId, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Message_Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Message_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Message_Id field is used to=
 identify a message.&nbsp; This value <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is incremented and only decreases=
 when the value wraps.&nbsp; This <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used for message=
 acknowledgment. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.6. <br>
&nbsp;&nbsp;&nbsp;&nbsp; MESSAGE_ID_ACK Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 10. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; MessageIdAck, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Message_Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Message_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Message_Id field is used to=
 identify the message being <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; acknowledged.&nbsp; This value is=
 copied from the MESSAGE_ID object <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the message being=
 acknowledged. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.7. <br>
&nbsp;&nbsp;&nbsp;&nbsp; CONFIG Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 11. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; HelloConfig, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 HelloInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 HelloDeadInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; HelloInterval:&nbsp; 16 bits. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Indicates how frequently the=
 Hello packets will be sent and is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; measured in milliseconds (ms).=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 50] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; HelloDeadInterval:&nbsp; 16 bits. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If no Hello packets are received=
 within the HelloDeadInterval, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the control channel is assumed to=
 have failed.&nbsp; The <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HelloDeadInterval is measured in=
 milliseconds (ms).&nbsp; The <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HelloDeadInterval MUST be greater=
 than the HelloInterval, and <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SHOULD be at least 3 times the=
 value of HelloInterval. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the fast keep-alive mechanism of LMP is not used, the <br>
&nbsp;&nbsp; HelloInterval and HelloDeadInterval MUST be set to zero. <br>
<br>
<br>
BM&gt; Given that the only parameters negotiated by Hello COnfig are<br>
BM&gt; these two parameters, if fast keep-alive mechanism is not used,<br>
BM&gt; why bother with Hello Config protocol? Why then say Hello Config<br>
BM&gt; is mandatory?<br>
&nbsp;&nbsp;&nbsp; <br>
14.8. <br>
&nbsp;&nbsp;&nbsp;&nbsp; HELLO Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 12 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Type 1 Hello, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=
 TxSeqNum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=
 RcvSeqNum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; TxSeqNum:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the current sequence=
 number for this Hello message.&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This sequence number will be=
 incremented when the sequence <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; number is reflected in the=
 RcvSeqNum of a Hello packet that is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; received over the control=
 channel. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TxSeqNum=3D0 is not allowed. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TxSeqNum=3D1 is reserved to=
 indicate that the control channel has <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; booted or restarted. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; RcvSeqNum:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the sequence number of=
 the last Hello message received <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; over the control channel.&nbsp;=
 RcvSeqNum=3D0 is reserved to indicate <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that a Hello message has not yet=
 been received. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.9. <br>
&nbsp;&nbsp;&nbsp;&nbsp; BEGIN_VERIFY Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 13. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 51] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;=
 Flags&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 VerifyInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Number of Data=
 Links&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; EncType&nbsp;&nbsp;&nbsp; |&nbsp;=
 (Reserved)&nbsp;&nbsp; |&nbsp; Verify Transport Mechanism&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=
 BitRate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Wavelength&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Flags:&nbsp; 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following flags are defined:=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 Verify all Links <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; If this bit is set, the verification process checks all <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; unallocated links; else it only verifies new ports or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; component links that are to be added to this TE link. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 Data Link Type <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; If set, the data links to be verified are ports, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; otherwise they are component links <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; VerifyInterval:&nbsp; 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the interval between=
 successive Test messages and is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; measured in milliseconds (ms).=
 <br>
&nbsp;<br>
&nbsp;&nbsp; Number of Data Links:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the number of data links=
 that will be verified. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; EncType:&nbsp; 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the encoding type of the=
 data link.&nbsp; The defined <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EncType values are consistent=
 with the Link Encoding Type <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; values of [GMPLSSIG] <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Verify Transport Mechanism:&nbsp; 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This defines the transport=
 mechanism for the Test Messages. The <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of this bit mask is=
 restricted to each link encoding <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type. The local node will set the=
 bits corresponding to the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; various mechanisms it can support=
 for transmitting LMP test <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages. The receiver chooses=
 the appropriate mechanism in the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BeginVerifyAck message. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For SONET/SDH Encoding Type, the=
 following flags are defined: <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 52] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 J0-16: Capable of=
 transmitting Test messages using J0 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; overhead bytes with string length of 16 bytes (with <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; CRC-7).&nbsp; Note that Due to the byte limitation, a <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; special Test message is defined as follows: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; The Test message is a 15-byte message, where the last 7 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; bits of each byte are usable.&nbsp; Due to the byte <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; limitation, the LMP Header is not included. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; The first usable 32 bits MUST be the VerifyId that was <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; received in the VERIFY_ID Object of the BeginVerifyAck <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; message.&nbsp; The second usable 32 bits MUST be the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Interface_Id.&nbsp; The next usable 8 bits are used to <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; determine the address type of the Interface_Id.&nbsp; For=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; IPv4, this value is 1.&nbsp; For unnumbered, this value is=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 3. The remaining bits are Reserved. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Note that this Test Message format is only valid when <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; the Interface_Id is either IPv4 or unnumbered. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 DCCS: Capable of=
 transmitting Test messages using the DCC <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Section Overhead bytes with an HDLC framing format. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x04 DCCL: Capable of=
 transmitting Test messges using the DCC <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Line Overhead bytes with an HDLC framing format. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x08 Payload: Capable of=
 transmitting Test messages in the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; payload using Packet over SONET framing using the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; encoding type specified in the EncType field. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For GigE Encoding Type, the=
 following flags are defined: TBD <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For 10GigE Encoding Type, the=
 following flags are defined: TBD <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; BitRate:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the bit rate of the data=
 link over which the Test <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages will be transmitted and=
 is expressed in bytes per <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; second. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Wavelength:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; When a data link is assigned to a port or component link that=
 is <br>
&nbsp;&nbsp; capable of transmitting multiple wavelengths (e.g., a fiber or=
 <br>
&nbsp;&nbsp; waveband-capable port), it is essential to know which=
 wavelength the <br>
&nbsp;&nbsp; test messages will be transmitted over.&nbsp; This value=
 corresponds to <br>
&nbsp;&nbsp; the wavelength at which the Test messages will be transmitted=
 over <br>
&nbsp;&nbsp; and has local significance.&nbsp; If there is no ambiguity as=
 to the <br>
&nbsp;&nbsp; wavelength over which the message will be sent, then this value=
 <br>
&nbsp;&nbsp; SHOULD be set to 0. <br>
&nbsp;&nbsp;&nbsp; <br>
14.10.&nbsp; BEGIN_VERIFY_ACK Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 14. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 53] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 VerifyDeadInterval&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;=
 Verify_Transport_Response&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; VerifyDeadInterval:&nbsp; 16 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a Test message is not detected=
 within the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VerifyDeadInterval, then a node=
 will send the TestStatusFailure <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message for that data link. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Verify_Transport_Response:&nbsp; 16 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The recipient of the BeginVerify=
 message (and the future <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; recipient of the TEST messages)=
 chooses the transport mechanism <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the various types that are=
 offered by the transmitter of <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the Test messages.&nbsp; One and=
 only one bit MUST be set in the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verification transport response.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.11.&nbsp; VERIFY_ID Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 15. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; C-Type =3D 1 <br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=
 VerifyId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; VerifyId:&nbsp; 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is used to differentiate=
 Test messages from different TE <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; links and/or LMP peers.&nbsp;=
 This is a node-unique value that is <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assigned by the recipient of the=
 BeginVerify message. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.12.&nbsp; TE_LINK Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 16. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 54] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Link_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Link_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Link_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Flags: 8 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following flags are=
 defined.&nbsp; All other values are <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reserved. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 Fault Management Supported.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 Link Verification Supported.=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 55] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Local_Link_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the node=92s=
 local Link Id and MUST be non-zero. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Remote_Link_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This identifies the remote node=
=92s Link Id and MUST be non-zero. <br>
&nbsp;&nbsp;&nbsp; <br>
14.13.&nbsp; DATA_LINK Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 17.&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Subobjects)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Interface_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Interface_Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 56] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Subobjects)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Flags&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Reserved)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local_Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Remote_Interface_Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (Subobjects)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Flags: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following flags are=
 defined.&nbsp; All other values are <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reserved. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 Interface Type: If set, the=
 data link is a port, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; otherwise it is a component link. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 Allocated Link: If set, the=
 data link is currently <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; allocated for user traffic.&nbsp; If a single <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; Interface_Id is used for both the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; transmit and receive data links, then <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; this bit only applies to the transmit <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; interface. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Local_Interface_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the local identifier of=
 the data link.&nbsp; This MUST be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node-wide unique and non-zero.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Remote_Interface_Id: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the remote identifier of=
 the data link.&nbsp; This MUST be <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; non-zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Subobjects <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The contents of the DATA_LINK=
 object consist of a series of <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; variable-length&nbsp; data&nbsp;=
 items called subobjects.&nbsp; The subobjects <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are defined in section 14.13.1=
 below. <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 57] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; A DATA_LINK object may contain more than one subobject.&nbsp;=
 If more <br>
&nbsp;&nbsp; than one subobject of the same Type appears, only the first=
 <br>
&nbsp;&nbsp; subobject of that Type is meaningful.&nbsp; Subsequent=
 subobjects of the <br>
&nbsp;&nbsp; same Type MAY be ignored. <br>
&nbsp;&nbsp;&nbsp; <br>
14.13.1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Data Link Subobjects <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The contents of the DATA_LINK object include a series of=
 variable-<br>
&nbsp;&nbsp; length data items called subobjects.&nbsp; Each subobject has=
 the form: <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 <br>
&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+&nbsp;=
 <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Subobject=
 contents)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+&nbsp;=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Type: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Type indicates the type of=
 contents of the subobject.&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Currently defined values are:=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; 1&nbsp;&nbsp; Interface Switching Capability <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Length: 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Length contains the total=
 length of the subobject in bytes, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; including the Type and Length=
 fields.&nbsp; The Length MUST be at <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; least 4, and MUST be a multiple=
 of 4. <br>
&nbsp;&nbsp;&nbsp; <br>
14.13.1.1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subobject 1:&nbsp; Interface=
 Switching Capability <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp;&nbsp; | Switching Cap=
 |&nbsp;&nbsp;&nbsp;&nbsp; EncType&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; Minimum Reservable=
 Bandwidth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; Maximum Reservable=
 Bandwidth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Switching Capability: 8 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is used to identify the=
 local Interface Switching <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability of the TE link.&nbsp;=
 See [LSP-HIER]. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; EncType:&nbsp; 8 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the encoding type of the=
 data link.&nbsp; The defined <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EncType values are consistent=
 with the Link Encoding Type <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; values of [GMPLSSIG]. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Minimum Reservable Bandwidth: 32 bits <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 58] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is measured in bytes per=
 second and represented in IEEE <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; floating point format. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Maximum Reservable Bandwidth: 32 bits <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is measured in bytes per=
 second and represented in IEEE <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; floating point format. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If the interface only supports a fixed rate, the minimum and=
 maximum <br>
&nbsp;&nbsp; bandwidth fields are set to the same value. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
14.14.&nbsp; CHANNEL_STATUS Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 18 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 59] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |A|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Channel=
 Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Active bit: 1 bit <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This indicates that the Channel is allocated to user traffic=
 and the <br>
&nbsp;&nbsp; data link should be actively monitored. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Channel_Status: 32 bits <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This indicates the status=
 condition of a data channel.&nbsp; The <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; following values are=
 defined.&nbsp; All other values are reserved. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; Signal Okay (OK):=
 Channel is operational <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp; Signal Degrade=
 (SD): A soft failure caused by a BER <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exceeding a preselected=
 threshold.&nbsp; The specific <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BER used to define the threshold is=
 configured. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp; Signal Fail (SF): A=
 hard signal failure including (but not <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited to) loss of signal (LOS),=
 loss of frame <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (LOF), or Line AIS. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object contains one or more Interface Ids followed by a=
 <br>
&nbsp;&nbsp; Channel_Status field. <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 60] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; To indicate the status of the entire TE Link, there MUST only=
 be one <br>
&nbsp;&nbsp; Interface Id and it MUST be zero. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.15.&nbsp; CHANNEL_STATUS_REQUEST Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 19 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv4, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object contains one or more Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Length of this object is 4 + 4N in bytes, where N is the=
 number <br>
&nbsp;&nbsp; of Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; IPv6, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (16=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; + <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;&nbsp;=
 +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +=
 <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
 <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 61] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object contains one or more Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Length of this object is 4 + 16N in bytes, where N is the=
 number <br>
&nbsp;&nbsp; of Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; Unnumbered, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 //&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=
 :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface Id (4=
 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object contains one or more Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The Length of this object is 4 + 4N in bytes, where N is the=
 number <br>
&nbsp;&nbsp; of Interface Ids. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This Object is non-negotiable. <br>
&nbsp;&nbsp;&nbsp; <br>
14.16.&nbsp; ERROR_CODE Class <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Class =3D 20. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; CONFIG_ERROR, C-Type =3D 1 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ERROR=
 CODE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following bit-values are=
 defined: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 =3D Unacceptable=
 non-negotiable CONFIG parameter <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 =3D Renegotiate CONFIG=
 parameter <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x04 =3D Bad Received CCID <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All other values are Reserved.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multiple bits may be set to=
 indicate multiple errors. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This Object is non-negotiable.=
 <br>
<br>
<br>
<br>
BM&gt; How about adding a bit for &quot;Ill-formed message&quot; to cover=
 <br>
BM&gt; such cases as object-order-violations?<br>
BM&gt; THese could be under a special C-Type, say, PROTOCOL_ERROR<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 62] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; BEGIN_VERIFY_ERROR, C-Type =3D 2 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ERROR=
 CODE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following bit-values are=
 defined: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 =3D Link Verification=
 Procedure not supported for this TE <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Link. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 =3D Unwilling to verify at=
 this time <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x04 =3D Unsupported verification=
 transport mechanism&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x08 =3D TE Link Id configuration=
 error <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All other values are Reserved.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multiple bits may be set to=
 indicate multiple errors. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This Object is non-negotiable.=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; If a BeginVerifyNack message is received with Error Code 2, the=
 node <br>
&nbsp;&nbsp; that originated the BeginVerify SHOULD schedule a BeginVerify=
 <br>
&nbsp;&nbsp; retransmission after Rf seconds, where Rf is a locally defined=
 <br>
&nbsp;&nbsp; parameter. <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; o&nbsp;&nbsp;&nbsp; LINK_SUMMARY_ERROR, C-Type =3D 3 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;=
 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 <br>
&nbsp;&nbsp;&nbsp; 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 <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ERROR=
 CODE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; | <br>
&nbsp;&nbsp;=
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The following bit-values are=
 defined: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x01 =3D Unacceptable=
 non-negotiable LINK_SUMMARY parameters <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x02 =3D Renegotiate LINK_SUMMARY=
 parameters <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x04 =3D Bad Received=
 Remote_Link_Id <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All other values are Reserved.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multiple bits may be set to=
 indicate multiple errors. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This Object is non-negotiable.=
 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
15. <br>
&nbsp;&nbsp; Security Considerations <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; LMP exchanges may be authenticated using the Cryptographic <br>
&nbsp;&nbsp; authentication option.&nbsp; MD5 is currently the only message=
 digest <br>
&nbsp;&nbsp; algorithm specified. <br>
&nbsp;<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 63] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
16. <br>
&nbsp;&nbsp; References<br>
&nbsp;<br>
&nbsp;&nbsp; [RFC2026]&nbsp;&nbsp; Bradner, S., &quot;The Internet Standards=
 Process -- Revision <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 3,&quot; BCP 9, RFC 2026, October 1996. <br>
&nbsp;&nbsp; [LAMBDA]&nbsp;&nbsp;&nbsp; Awduche, D. O., Rekhter, Y., Drake,=
 J., Coltun, R., <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; &quot;Multi-Protocol Lambda Switching: Combining MPLS Traffic <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Engineering Control with Optical Crossconnects,&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Internet Draft, draft-awduche-mpls-te-optical-03.txt, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; (work in progress), April 2001. <br>
&nbsp;&nbsp; [BUNDLE]&nbsp;&nbsp;&nbsp; Kompella, K., Rekhter, Y., Berger,=
 L., =93Link Bundling in <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; MPLS Traffic Engineering,=94 Internet Draft, draft-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; kompella-mpls-bundle-05.txt, (work in progress), February <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 2001. <br>
&nbsp;&nbsp; [RSVP-TE]&nbsp;&nbsp; Awduche, D. O., Berger, L., Gan, D.-H.,=
 Li, T., <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Srinivasan, V., Swallow, G., &quot;Extensions to RSVP for LSP <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Tunnels,&quot; Internet Draft, draft-ietf-mpls-rsvp-lsp-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; tunnel-08.txt, (work in progress), February 2001. <br>
&nbsp;&nbsp; [CR-LDP]&nbsp;&nbsp;&nbsp; Jamoussi, B., et al,=
 &quot;Constraint-Based LSP Setup using <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; LDP,&quot; Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; (work in progress), September 1999. <br>
&nbsp;&nbsp; [OSPF-TE]&nbsp;&nbsp; Katz, D., Yeung, D., Kompella, K.,=
 &quot;Traffic Engineering <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Extensions to OSPF,&quot; Internet Draft, draft-katz-yeung-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; ospf-traffic-04.txt, (work in progress), February 2001. <br>
&nbsp;&nbsp; [ISIS-TE]&nbsp;&nbsp; Li, T., Smit, H., &quot;IS-IS extensions=
 for Traffic <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Engineering,&quot; Internet Draft,draft-ietf-isis-traffic-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 02.txt, (work in progress), September 2000. <br>
&nbsp;&nbsp; [OSPF]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Moy, J., &quot;OSPF=
 Version 2,&quot; RFC 2328, April 1998. <br>
&nbsp;&nbsp; [LMP-DWDM]&nbsp; Fredette, A., Snyder, E., Shantigram, J., et=
 al, =93Link <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Management Protocol (LMP) for WDM Transmission Systems,=94 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Internet Draft, draft-fredette-lmp-wdm-01.txt, (work in <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; progress), March 2001. <br>
&nbsp;&nbsp; [MD5]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rivest, R., &quot;The=
 MD5 Message-Digest Algorithm,&quot; RFC <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 1321, April 1992. <br>
&nbsp;&nbsp; [GMPLSSIG]&nbsp; Ashwood-Smith, P., Banerjee, A., et al,=
 =93Generalized <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; MPLS - Signaling Functional Description,=94 Internet Draft, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; draft-ietf-mpls-generalized-signaling-06.txt, (work in <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; progress), October 2001. <br>
&nbsp;&nbsp; [LSP-HIER]&nbsp; Kompella, K. and Rekhter, Y., =93LSP Hierarchy=
 with MPLS <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; TE,=94 Internet Draft, draft-ietf-mpls-lsp-hierarchy-<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 02.txt, (work in progress), February 2001. <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 64] <br>
<br>
Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 draft-ietf-ccamp-lmp-02.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 November 2001 <br>
<br>
17. <br>
&nbsp;&nbsp; Acknowledgments <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; The authors would like to thank Ayan Banerjee, George Swallow,=
 Andre <br>
&nbsp;&nbsp; Fredette, Adrian Farrel, and Vinay Ravuri for their insightful=
 <br>
&nbsp;&nbsp; comments and suggestions.&nbsp; We would also like to thank=
 John Yu, <br>
&nbsp;&nbsp; Suresh Katukam, and Greg Bernstein for their helpful=
 suggestions for <br>
&nbsp;&nbsp; the in-band control channel applicability. <br>
&nbsp;&nbsp;&nbsp; <br>
18. <br>
&nbsp;&nbsp; Author's Addresses <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Jonathan P.=
 Lang&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Krishna=
 Mitra <br>
&nbsp;&nbsp; Calient=
 Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Calient Networks <br>
&nbsp;&nbsp; 25 Castilian=
 Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5853 Rue Ferrari=
 <br>
&nbsp;&nbsp; Goleta, CA=
 93117&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; San=
 Jose, CA 95138 <br>
&nbsp;&nbsp; Email:=
 [email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; email: [email-masked] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; John=
 Drake&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; Kireeti Kompella <br>
&nbsp;&nbsp; Calient=
 Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Juniper Networks, Inc. <br>
&nbsp;&nbsp; 5853 Rue=
 Ferrari&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 385=
 Ravendale Drive <br>
&nbsp;&nbsp; San Jose, CA=
 95138&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mountain View, CA=
 94043 <br>
&nbsp;&nbsp; email:=
 [email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; email: [email-masked] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Yakov=
 Rekhter&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; Lou Berger <br>
&nbsp;&nbsp; Juniper Networks,=
 Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Movaz Networks&nbsp; <br>
&nbsp;&nbsp; 385 Ravendale=
 Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: [email-masked]=
 <br>
&nbsp;&nbsp; Mountain View, CA 94043 <br>
&nbsp;&nbsp; email:=
 [email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Debanjan=
 Saha&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Debashis Basak <br>
&nbsp;&nbsp; Tellium Optical=
 Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; Accelight Networks <br>
&nbsp;&nbsp; 2 Crescent=
 Place&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 70=
 Abele Road, Suite 1201 <br>
&nbsp;&nbsp; Oceanport, NJ=
 07757-0901&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; Bridgeville, PA 15017-3470 <br>
&nbsp;&nbsp;=
 email:[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; email: [email-masked]=
 <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; Hal=
 Sandick&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; Alex Zinin <br>
&nbsp;&nbsp; Nortel=
 Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Nexsi Systems <br>
&nbsp;&nbsp; email:=
 [email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1959 Concourse=
 Drive <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; San Jose, CA 95131 <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; email:&nbsp; [email-masked]&nbsp; <br>
&nbsp;&nbsp; Bala Rajagopalan <br>
&nbsp;&nbsp; Tellium Optical Systems <br>
&nbsp;&nbsp; 2 Crescent Place <br>
&nbsp;&nbsp; Oceanport, NJ 07757-0901 <br>
&nbsp;&nbsp; email: [email-masked] <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; <br>
<br>
<br>
<br>
<br>
&nbsp;<br>
Lang et=
 al&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 [Page 65] <br>
</font></html>

--=====================_22429171==_.ALT--

Delivery-date: Tue, 20 Nov 2001 10:57:15 -0800
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" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>

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
[email-masked].

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:[email-masked]]
>Sent: Monday, November 19, 2001 5:21 PM
>To: 'S Ramesh'; George Young
>Cc: [email-masked]; 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:[email-masked]]
>> Sent: Thursday, November 15, 2001 11:15 PM
>> To: George Young
>> Cc: [email-masked]
>> 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:[email-masked]]
>> > >Sent: Monday, November 12, 2001 9:00 PM
>> > >To: [email-masked]
>> > >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
>

Delivery-date: Tue, 20 Nov 2001 08:55:31 -0800
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>
Cc: [email-masked]
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

George,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 8:34 AM
> To: Jonathan Lang
> Cc: [email-masked]
> 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
> [email-masked].
> 
> 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:[email-masked]]
> >Sent: Monday, November 19, 2001 5:21 PM
> >To: 'S Ramesh'; George Young
> >Cc: [email-masked]; 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:[email-masked]]
> >> Sent: Thursday, November 15, 2001 11:15 PM
> >> To: George Young
> >> Cc: [email-masked]
> >> 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:[email-masked]]
> >> > >Sent: Monday, November 12, 2001 9:00 PM
> >> > >To: [email-masked]
> >> > >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.
> >> > >
> >> > >
> >> 
> >> 
> >
> 

Delivery-date: Tue, 20 Nov 2001 07:57:02 -0800
Date: Tue, 20 Nov 2001 10:57:12 -0500
From: Carmine Daloia <[email-masked]>
To: Jonathan Lang <[email-masked]>
CC: ccamp <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Localizing Fault for Protection/Restoration

--------------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:[email-masked]]
>>Sent: Monday, November 19, 2001 11:24 AM
>>To: ccamp
>>Cc: [email-masked]; [email-masked]
>>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

<html>
<head>
</head>
<body>
Jonathan,<br>
<br>
Please see comments inline.<br>
<br>
Thanks<br>
Carmine<br>
<br>
Jonathan Lang wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <pre wrap="">Carmine,<br>  Please see inline.<br><br>Thanks,<br>Jonathan<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----<br>From: Carmine Daloia [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>Sent: Monday, November 19, 2001 11:24 AM<br>To: ccamp<br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Subject: LMP: Localizing Fault for Protection/Restoration<br><br><br>Hi all,<br><br>Another issue that is addressed in Section 6 "Fault Management" is the <br>determination of whether a detected defect is due to a fault within a <br>Protection/Restoration subnetwork or outside the subnetwork. The <br>following text is included in Section 6.2, "As part of the fault <br>localization, a downstream node (downstream in terms of data flow) that <br>detects data link failures will send a ChannelStatus message to its <br>upstream neighbor indicating that a failure has occurred (bundling <br>t
ogether the notification of all of the failed data-links).... The <br>upstream node should correlate the failure to see if the failure is also <br>detected locally (including ingress side) for the corresponding LSP(s). <br>If for example, the failure is clear on the input of the upstream node <br>or internally, then the upstream node will have localized the <br>failure.... Once the failure has been localized, the signaling protocols <br>can be used to initiate span or path protection/restoration <br>procedures."<br><br>I think we need to specify which protection/restoration architectures <br>such a ChannelStatus message would be applicable. All I currently see <br>are boxes and lines, yet we don't know at what layer the <br>protection/restoration is being performed nor do we know what type of <br>monitoring is supported (e.g., non-intrusive monitoring, tandem <br>connection monitoring, etc.). I am not saying that such a mechanism <br>would not be needed, however I think it is
 more fundamental to agree on <br>the architectures first before we attempt to agree on one particular <br>message that may be needed in some of the architectures. In fact the <br>ChannelStatus message (if specified) should be included in those <br>protection/restoration documents that specify architectures that would <br>require such a message. Note that the ChannelStatus message is actually <br>a message that is communicated between the end-points of a <br>protection/restoration subnetwork. The end-points of a <br>protection/restoration subnetwork could be adjacent cross-connects if <br>span protection/restoration is supported or the end-points could be <br>non-adjacent cross-connects if path protection/restoration is supported. <br>Lumping this ChannelStatus message into LMP automatically forces the <br>end-points to be adjacent cross-connects.<br></pre>
    </blockquote>
    <pre wrap=""><!---->LMP is a "link management protocol" that is designed to manage links between<br>peers  (this is particularly useful when the interface over which the<br>control messages are sent/received may not be the same interface over which<br>the data flows).  As such, it is not clear to me why you are proposing to<br>run LMP end-to-end across multiple cross-connects.</pre>
    </blockquote>
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?<br>
    <br>
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.<br>
    <br>
What are your thoughts?<br>
    <blockquote type="cite" cite="mid:[email-masked]">
      <pre wrap=""><br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Also, the paragraph that I quoted above indicates that once the failure <br>has been localized using the procedures described in LMP, the signaling <br>protocols can be used to initiate span or path protection/restoration. <br>Note that for path protection/restoration, the cross-connects themselves <br>are included within the protection/restoration subnetwork and therefore <br>path protection/restoration needs to restore connections when <br>cross-connects themselves fail. I don't see how the mechanism described <br>in LMP can be used when a cross-connect fails. Assume the network <br>consists of four cross-connects.<br><br>       A------B------C<br>        |                      |<br>       +------D------+<br><br>Let's assume that cross-connect B fails. According to the mechanism <br>described in LMP, Cross-connect C will send a ChannelStatus back to <br>Cross-connect B, however because B has failed, B will not be able to <br>process the ChannelStatus m
essage. Therefore I don't see how <br>LMP would <br>apply to path protection/restoration.<br></pre>
        </blockquote>
        <pre wrap=""><!---->Path protection/restoration can be initiated due to link or node failures.<br>The ChannelStatus message is used to isolate link failures.  Node failures<br>can be detected by the loss of the control channels (possibly in conjunction<br>with the loss of data channels).  This should be detected at both A and C.<br><br></pre>
        <blockquote type="cite">
          <pre wrap="">Carmine<br><br><br></pre>
          </blockquote>
          </blockquote>
          <br>
          </body>
          </html>

--------------020704050404030901000108--

Delivery-date: Tue, 20 Nov 2001 07:55:36 -0800
From: "Saha, Sayandeb" <[email-masked]>
To: 'Eric Gray' <[email-masked]>, "Saha, Sayandeb" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: position of ADMIN_STATUS object in RESV message
Date: Tue, 20 Nov 2001 10:51:29 -0500

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:[email-masked]]
Sent: Monday, November 19, 2001 10:41 AM
To: Saha, Sayandeb
Cc: [email-masked]'
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 <flow descriptor list> 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:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Tue, 20 Nov 2001 05:21:10 -0800
Cc: "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Date: Tue, 20 Nov 2001 11:28:50 +0100
From: Huub Van Helvoort <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
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:[email-masked] | The Netherlands |
------------------------------------------------------------------------
   Always remember that you are unique...    Just like everyone else.

Delivery-date: Tue, 20 Nov 2001 03:41:44 -0800
From: "Nicola Ciulli" <[email-masked]>
To: <[email-masked]>
Subject: relationship between adjacency and link
Date: Mon, 19 Nov 2001 12:33:48 +0100

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:     [email-masked]                                       |
|____________________________________________________________________|

Delivery-date: Tue, 20 Nov 2001 00:34:56 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Representation of VC-3 in STM-0 in {SUKLM} format
Date: Tue, 20 Nov 2001 09:26:31 +0100

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:[email-masked]]
> Sent: Tuesday, November 20, 2001 1:49 AM
> To: [email-masked]
> 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
> 
> 

Delivery-date: Tue, 20 Nov 2001 00:17:00 -0800
From: Heiles Juergen <[email-masked]>
To: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
Date: Tue, 20 Nov 2001 09:08:04 +0100

Manoj,

see my comments below.

Juergen

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 7:22 PM
> To: [email-masked]
> 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
> 
> 

Delivery-date: Mon, 19 Nov 2001 23:54:59 -0800
To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Tue, 20 Nov 2001 08:53:51 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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:[email-masked]]
> > 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

Delivery-date: Mon, 19 Nov 2001 22:50:54 -0800
Date: Tue, 20 Nov 2001 12:22:50 +0530
From: Rajaraman B <[email-masked]>
Organization: Hcl Technologies Limited
To: [email-masked]
Subject: Identifying RSVP (rfc-2205) and RSVP-TE while implementing

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

Delivery-date: Mon, 19 Nov 2001 17:08:32 -0800
From: Steve West <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, 'Dimitri Papadimitriou' <[email-masked]>, Steve West <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 17:02:29 -0800

Eric:

Thanks for your reply.

Please see my comments below.

Kind regards,

Steve

>    -----Original Message-----
>    From: Mannie, Eric [mailto:[email-masked]]
>    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:[email-masked]]
>    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:[email-masked]]
>    > 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:[email-masked]]
>    > > 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 ?
>    > > >
>    > > <snip, to save BW>
>    

Delivery-date: Mon, 19 Nov 2001 17:08:23 -0800
From: Steve West <[email-masked]>
To: 'Dimitri Papadimitriou' <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>,  ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 17:02:37 -0800

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:[email-masked]]
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:[email-masked]]
> 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:[email-masked]]
> > 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 ?
> > >
> > <snip, to save BW>

Delivery-date: Mon, 19 Nov 2001 16:51:30 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Representation of VC-3 in STM-0 in {SUKLM} format
Date: Mon, 19 Nov 2001 17:49:28 -0700

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

Delivery-date: Mon, 19 Nov 2001 14:30:58 -0800
From: Jonathan Lang <[email-masked]>
To: 'S Ramesh' <[email-masked]>, George Young <[email-masked]>
Cc: [email-masked], Jonathan Lang <[email-masked]>
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

Ramesh,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: S Ramesh [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 11:15 PM
> To: George Young
> Cc: [email-masked]
> 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:[email-masked]]
> > >Sent: Monday, November 12, 2001 9:00 PM
> > >To: [email-masked]
> > >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.
> > >
> > >
> 
> 

Delivery-date: Mon, 19 Nov 2001 13:50:11 -0800
From: Jonathan Lang <[email-masked]>
To: 'Carmine Daloia' <[email-masked]>, ccamp <[email-masked]>
Cc: [email-masked], [email-masked], Jonathan Lang <[email-masked]>
Subject: RE: Localizing Fault for Protection/Restoration
Date: Mon, 19 Nov 2001 13:41:41 -0800

Carmine,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Carmine Daloia [mailto:[email-masked]]
> Sent: Monday, November 19, 2001 11:24 AM
> To: ccamp
> Cc: [email-masked]; [email-masked]
> 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
> 
> 

Delivery-date: Mon, 19 Nov 2001 12:56:18 -0800
Date: Mon, 19 Nov 2001 12:52:44 -0800
From: Sudheer Dharanikota <[email-masked]>
To: drafts <[email-masked]>
CC: Sudheer Dharanikota <[email-masked]>, CCAMP WG <[email-masked]>
Subject: draft-many-ccamp-srg-01.txt

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: [email-masked]  
      Raj Jain: [email-masked]  
       
      Dimitri Papadimitriou: [email-masked] 
       
      Riad Hartani: [email-masked] 
       
      Greg Bernstein: [email-masked]  
       
      Vishal Sharma: [email-masked] 
       
      Curtis Brownmiller: [email-masked] 
       
      Yong Xue: [email-masked] 
       
      John Strand: [email-masked] 

     

   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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0AMilpitas, CA 95035 USA;;;;
fn:Sudheer Dharanikota
end:vcard

--------------2A02491C512AE08036C97FA2--

Delivery-date: Mon, 19 Nov 2001 12:12:48 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Huub van Helvoort' <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>,  Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 21:11:39 +0100

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

Delivery-date: Mon, 19 Nov 2001 11:48:29 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'George Newsome' <[email-masked]>
Cc: 'Huub van Helvoort' <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>,  ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 20:45:49 +0100

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:[email-masked]]
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

Delivery-date: Mon, 19 Nov 2001 11:27:36 -0800
Date: Mon, 19 Nov 2001 14:24:15 -0500
From: Carmine Daloia <[email-masked]>
To: ccamp <[email-masked]>
CC: [email-masked], [email-masked]
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.

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

Delivery-date: Mon, 19 Nov 2001 11:25:25 -0800
Date: Mon, 19 Nov 2001 14:15:47 -0500
From: George Newsome <[email-masked]>
Organization: Lucent Technologies, Bell Labs
To: "Mannie, Eric" <[email-masked]>
CC: "'Huub van Helvoort'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
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

Delivery-date: Mon, 19 Nov 2001 10:58:20 -0800
From: Jonathan Lang <[email-masked]>
To: 'George Young' <[email-masked]>, [email-masked]
Cc: Jonathan Lang <[email-masked]>
Subject: RE: Two week Last Call on LMP (Section 6.4 & 6.5)
Date: Mon, 19 Nov 2001 10:50:49 -0800

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:[email-masked]]
> Sent: Tuesday, November 13, 2001 1:12 PM
> To: [email-masked]
> 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:[email-masked]]
> >Sent: Monday, November 12, 2001 9:00 PM
> >To: [email-masked]
> >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.
> >
> >
> 

Delivery-date: Mon, 19 Nov 2001 10:27:45 -0800
content-class: urn:content-classes:message
Subject: RE: [T1X1.5] RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 13:02:10 -0500
From: "Grant W. Cyboron" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "q11/15" <[email-masked]>, "t1x1.5" <[email-masked]>

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<m=3D<10. Thus there could be up to a =
7
frame difference in when the source expects the sink to have accepted
the C2 value and when it actually has (a total of 875 microseconds). I
would expect this to be considered a "disruptive event." =20

Grant W. Cyboron
Parama Networks
[email-masked] <mailto:[email-masked]>=20
+1 732 544 9120, x710 (voice)
+1 732 544 9121 (fax)

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, November 19, 2001 12:12 PM
To: [email-masked]'
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

Delivery-date: Mon, 19 Nov 2001 10:26:06 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubt in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt
Date: Mon, 19 Nov 2001 11:22:09 -0700

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

Delivery-date: Mon, 19 Nov 2001 09:57:56 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Huub van Helvoort' <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 18:52:05 +0100

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

Delivery-date: Mon, 19 Nov 2001 09:20:06 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>,  Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 18:11:32 +0100

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

Delivery-date: Mon, 19 Nov 2001 08:56:09 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>,  Dimitri Papadimitriou <[email-masked]>
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:[email-masked]]
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:[email-masked]]
> 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 ?
> >
> <snip, to save BW>

Delivery-date: Mon, 19 Nov 2001 08:04:57 -0800
Original-CC: "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Cc: "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Date: Mon, 19 Nov 2001 15:27:47 +0100
From: Huub van Helvoort <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
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:[email-masked] | The Netherlands |
------------------------------------------------------------------------
   Always remember that you are unique...    Just like everyone else.

Delivery-date: Mon, 19 Nov 2001 08:01:29 -0800
Original-CC: "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Cc: "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Date: Mon, 19 Nov 2001 14:53:13 +0100
From: Huub van Helvoort <[email-masked]>
To: Maarten Vissers <[email-masked]>
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:[email-masked] | The Netherlands |
------------------------------------------------------------------------
   Always remember that you are unique...    Just like everyone else.

Delivery-date: Mon, 19 Nov 2001 07:43:23 -0800
Date: Mon, 19 Nov 2001 10:40:31 -0500
From: Eric Gray <[email-masked]>
To: "Saha, Sayandeb" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
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 <flow descriptor list> 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:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 19 Nov 2001 07:39:35 -0800
Date: Mon, 19 Nov 2001 16:35:23 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Huub van Helvoort <[email-masked]>
CC: Maarten Vissers <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked] | 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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------7389F65D86F77B4BFDDDD161--

Delivery-date: Mon, 19 Nov 2001 07:33:46 -0800
Date: Mon, 19 Nov 2001 16:31:46 +0100
To: Francois Le Faucheur <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: comments on draft-kompella-mpls-multiarea-te-02.txt
Cc: [email-masked], [email-masked]

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

Delivery-date: Mon, 19 Nov 2001 06:48:07 -0800
Date: Mon, 19 Nov 2001 09:43:41 -0500
From: Carmine Daloia <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
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

Delivery-date: Mon, 19 Nov 2001 06:07:15 -0800
Date: Mon, 19 Nov 2001 15:01:44 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>, q12/15 <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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

[email-masked] 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:
>         [email-masked].
> 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:     <[email-masked]>
--------------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:[email-masked]
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--

Delivery-date: Mon, 19 Nov 2001 04:41:27 -0800
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Mon, 19 Nov 2001 13:39:14 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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:[email-masked]]
> 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<N) trails are being used, and the operator/user wants to
> 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
> > >
> > > [email-masked] 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:
> > > >         [email-masked].
> > > > 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:     <[email-masked]>
--------------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:[email-masked]
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--

Delivery-date: Mon, 19 Nov 2001 03:48:46 -0800
Cc: "Karmakar, Soumen" <[email-masked]>, [email-masked]
Date: Mon, 19 Nov 2001 12:40:08 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Heiles Juergen <[email-masked]>
Original-CC: "Karmakar, Soumen" <[email-masked]>, [email-masked]
Subject: Re: STM-M out of STM-N (M<N)

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

Juergen,

Thanks... indeed my mistake. T=111 should be T=1, and T_flag_1 indicates
RSOH+MSOH transparency.

Regards,

Maarten

Heiles Juergen wrote:
> 
> 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:[email-masked]]
> > Sent: Monday, November 19, 2001 11:04 AM
> > To: Karmakar, Soumen
> > Cc: [email-masked]
> > Subject: Re: STM-M out of STM-N (M<N)
> >
> >
> > 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:[email-masked]]
> > > > Sent: Wednesday, November 14, 2001 12:57 AM
> > > > To: manoj juneja
> > > > Cc: [email-masked]
> > > > Subject: Re: STM-M out of STM-N (M<N)
> > > >
> > > >
> > > > 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 <[email-masked]>
> > > > > >To: manoj juneja <[email-masked]>
> > > > > >CC: [email-masked]
> > > > > >Subject: Re: STM-M out of STM-N (M<N)
> > > > > >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:[email-masked]
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--

Delivery-date: Mon, 19 Nov 2001 03:30:34 -0800
Date: Mon, 19 Nov 2001 12:21:20 +0100
To: [email-masked]
From: Francois Le Faucheur <[email-masked]>
Subject: comments on draft-kompella-mpls-multiarea-te-02.txt
Cc: [email-masked]

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

Delivery-date: Mon, 19 Nov 2001 03:22:49 -0800
Cc: "'Stephen Trowbridge'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Date: Mon, 19 Nov 2001 12:20:05 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: "'Stephen Trowbridge'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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 ?
> >
> <snip, to save BW>
--------------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:[email-masked]
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--

Delivery-date: Mon, 19 Nov 2001 02:30:12 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Dimitri Papadimitriou' <[email-masked]>, Steve West <[email-masked]>
Cc: 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Mon, 19 Nov 2001 11:27:50 +0100

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:[email-masked]]
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:[email-masked]]
> 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:[email-masked]]
> > 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 ?
> > >
> > <snip, to save BW>

Delivery-date: Mon, 19 Nov 2001 02:27:41 -0800
From: Heiles Juergen <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, "Karmakar, Soumen" <[email-masked]>
Cc: [email-masked]
Subject: RE: STM-M out of STM-N (M<N)
Date: Mon, 19 Nov 2001 11:25:25 +0100

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:[email-masked]]
> Sent: Monday, November 19, 2001 11:04 AM
> To: Karmakar, Soumen
> Cc: [email-masked]
> Subject: Re: STM-M out of STM-N (M<N)
> 
> 
> 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:[email-masked]]
> > > Sent: Wednesday, November 14, 2001 12:57 AM
> > > To: manoj juneja
> > > Cc: [email-masked]
> > > Subject: Re: STM-M out of STM-N (M<N)
> > >
> > >
> > > 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 <[email-masked]>
> > > > >To: manoj juneja <[email-masked]>
> > > > >CC: [email-masked]
> > > > >Subject: Re: STM-M out of STM-N (M<N)
> > > > >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
> > >
> 

Delivery-date: Mon, 19 Nov 2001 02:11:51 -0800
Cc: [email-masked]
Date: Mon, 19 Nov 2001 11:04:12 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Karmakar, Soumen" <[email-masked]>
Original-CC: [email-masked]
Subject: Re: STM-M out of STM-N (M<N)

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

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:[email-masked]]
> > Sent: Wednesday, November 14, 2001 12:57 AM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: STM-M out of STM-N (M<N)
> >
> >
> > 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 <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: STM-M out of STM-N (M<N)
> > > >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:[email-masked]
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--

Delivery-date: Sun, 18 Nov 2001 06:51:34 -0800
Date: Sun, 18 Nov 2001 15:44:07 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Steve West <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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:[email-masked]]
> > 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 ?
> > >
> > <snip, to save BW>
--------------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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------10629FE344570C24A478439C--

Delivery-date: Sat, 17 Nov 2001 13:32:13 -0800
From: Steve West <[email-masked]>
To: 'Dimitri Papadimitriou' <[email-masked]>,  "Mannie, Eric" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>, 'Maarten Vissers' <[email-masked]>
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Sat, 17 Nov 2001 13:26:35 -0800

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:[email-masked]]
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:[email-masked]]
> 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 ?
> >
> <snip, to save BW>

Delivery-date: Fri, 16 Nov 2001 21:31:12 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: position of ADMIN_STATUS object in RESV message
Date: Fri, 16 Nov 2001 22:28:40 -0700

Did anyone answer this one ?

>From: "Saha, Sayandeb" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>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 <flow descriptor list> 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

Delivery-date: Fri, 16 Nov 2001 16:56:05 -0800
From: "Karmakar, Soumen" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: Questions on draft-ietf-mpls-bundle-00 
Date: Fri, 16 Nov 2001 16:53:36 -0800

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:[email-masked]]
> Sent: Thursday, September 13, 2001 6:58 AM
> To: Edward Harrison
> Cc: 'Yakov Rekhter'; Nic Larkin; [email-masked]'
> 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.
> 
> 

Delivery-date: Fri, 16 Nov 2001 16:27:15 -0800
From: "Prashant Sharma" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Question regarding LSC interface..
Date: Sat, 17 Nov 2001 00:24:46 +0000

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

Delivery-date: Fri, 16 Nov 2001 16:12:35 -0800
Date: Sat, 17 Nov 2001 01:09:20 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>
CC: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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 ?
> >
> <snip, to save BW>
--------------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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------B69D64FA575D21EA85B9B5C5--

Delivery-date: Fri, 16 Nov 2001 13:21:36 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Krishna Pattabhiraman' <[email-masked]>,  Dimitri Papadimitriou <[email-masked]>, Maarten Vissers <[email-masked]>
Cc: Ramji Raghavan <[email-masked]>, ccamp <[email-masked]>,  q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Kumar Kovvali <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 22:13:21 +0100

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:[email-masked]]
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:[email-masked]]
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<N) trails are being used, and the operator/user wants to 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
> 
> [email-masked] 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:
> >         [email-masked].
> > 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.
> >
> >
----------------------------------------------------------------------------
----

Delivery-date: Fri, 16 Nov 2001 12:54:08 -0800
From: "Mannie, Eric" <[email-masked]>
To: "'Brungard, Deborah A, ALCTA'" <[email-masked]>,  'Stephen Trowbridge' <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>,  q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 21:44:35 +0100

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:[email-masked]]
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:[email-masked]]
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 ?
> 
<snip, to save BW>

Delivery-date: Fri, 16 Nov 2001 12:53:44 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>,  q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 21:45:51 +0100

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:[email-masked]]
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 ?
> 
<snip, to save BW>

Delivery-date: Fri, 16 Nov 2001 12:27:44 -0800
From: "Brungard, Deborah A, ALCTA" <[email-masked]>
To: "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 15:21:25 -0500

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:[email-masked]]
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 ?
> 
<snip, to save BW>

Delivery-date: Fri, 16 Nov 2001 10:59:33 -0800
Date: Fri, 16 Nov 2001 11:49:13 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
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 ?
> 
<snip, to save BW>

Delivery-date: Fri, 16 Nov 2001 10:59:24 -0800
From: Steve Gorshe <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
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:[email-masked]]
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<N) trails are being used, and the operator/user wants to 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

[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

[email-masked] 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:
>         [email-masked].
> 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.
> 
>   --------------------------------------------------------------------------------

Delivery-date: Fri, 16 Nov 2001 10:58:16 -0800
Date: Fri, 16 Nov 2001 14:37:33 -0500
From: Senthil Venkatachalam <[email-masked]>
Organization: Alcatel
To: Alex Zinin <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, Sudheer Dharnikota <[email-masked]>, Papadimitriou Dimitri <[email-masked]>, [email-masked]
Subject: Re: draft-venkatachalam-interarea-mpls-te-02.txt

--------------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     [email-masked]
> > Off#:, MBox:                 (703) 679-6435 [Off]
> > Alcatel USA                  (703) 679-6450 [Fax]
> > __________________________________________________________________

--
Senthil K. Venkatachalam     [email-masked]
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________

--------------4D03E9048C977AA4A4F5F9CE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I&nbsp;resubmitted two days ago..will check and do again...
<p>Senthil
<br>&nbsp;
<br>&nbsp;
<p>Alex Zinin wrote:
<blockquote TYPE=CITE>Senthil,
<p>&nbsp;&nbsp; The IETF directory says it expired. Please resubmit or
<br>&nbsp;&nbsp; post a link to it.
<p>--
<br>Alex Zinin
<p>Tuesday, November 13, 2001, 2:19:05 PM, Senthil Venkatachalam wrote:
<p>> Hi Kireeti,
<p>> We would like to request a slot to present our draft:
<br>> draft-venkatachalam-interarea-mpls-te-02.txt
<br>> at the Salt Lake City IETF.
<p>> Best Regards,
<br>> Senthil.
<p>> --
<br>> Senthil K. Venkatachalam&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]
<br>> Off#:, MBox:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(703) 679-6435 [Off]
<br>> Alcatel USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(703) 679-6450 [Fax]
<br>> __________________________________________________________________</blockquote>

<pre>--&nbsp;
Senthil K. Venkatachalam&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]
Off#:, MBox:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703) 679-6435 [Off]
Alcatel USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703) 679-6450 [Fax]
__________________________________________________________________</pre>
&nbsp;</html>

--------------4D03E9048C977AA4A4F5F9CE--

Delivery-date: Fri, 16 Nov 2001 10:38:12 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 10:28:59 -0800

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:[email-masked]]
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:[email-masked]]
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<N) trails are being used, and the operator/user wants to
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
> >
> > [email-masked] 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:
> > >         [email-masked].
> > > 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:     <[email-masked]>

Delivery-date: Fri, 16 Nov 2001 10:38:03 -0800
Date: Fri, 16 Nov 2001 13:27:25 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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<N) trails are being used, and the operator/user wants to 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
> 
> 
> [email-masked] 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:
>>        [email-masked].
>>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:     <[email-masked]>
>>

Delivery-date: Fri, 16 Nov 2001 10:22:30 -0800
Date: Fri, 16 Nov 2001 13:19:22 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
>>>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<N) trails are being used, and the operator/user wants to
>>>>>
>>>>>
>>>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
>>>>>
>>>>>[email-masked] 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:
>>>>>>       [email-masked].
>>>>>>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:     <[email-masked]>
>>>>>>
>>>>>>
>>>>>

Delivery-date: Fri, 16 Nov 2001 10:09:10 -0800
Date: Fri, 16 Nov 2001 19:05:43 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Zhi-Wei Lin <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> > 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<N) trails are being used, and the operator/user wants to
> >>>
> > 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
> >>>
> >>>[email-masked] 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:
> >>>>        [email-masked].
> >>>>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:     <[email-masked]>
> >>>>
--------------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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------28310B2D4D64EFCC08FFE254--

Delivery-date: Fri, 16 Nov 2001 09:59:22 -0800
Date: Fri, 16 Nov 2001 12:55:50 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]]
> 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<N) trails are being used, and the operator/user wants to
>>>
> 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
>>>
>>>[email-masked] 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:
>>>>        [email-masked].
>>>>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:     <[email-masked]>
>>>>

Delivery-date: Fri, 16 Nov 2001 09:49:31 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, ccamp <[email-masked]>,  q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 18:47:49 +0100

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:[email-masked]]
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<N) trails are being used, and the operator/user wants to 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

[email-masked] 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:
>         [email-masked].
> 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:     <[email-masked]>

Delivery-date: Fri, 16 Nov 2001 09:40:21 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Subject: RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Date: Fri, 16 Nov 2001 18:39:04 +0100

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:[email-masked]]
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<N) trails are being used, and the operator/user wants to
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
> >
> > [email-masked] 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:
> > >         [email-masked].
> > > 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:     <[email-masked]>

Delivery-date: Fri, 16 Nov 2001 08:49:06 -0800
From: Krishna Pattabhiraman <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>,  Maarten Vissers <[email-masked]>
Cc: Ramji Raghavan <[email-masked]>, ccamp <[email-masked]>,  q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>,  Kumar Kovvali <[email-masked]>
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:[email-masked]]
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<N) trails are being used, and the operator/user wants to 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
> 
> [email-masked] 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:
> >         [email-masked].
> > 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.
> >
> >
----------------------------------------------------------------------------
----

Delivery-date: Fri, 16 Nov 2001 08:39:34 -0800
Cc: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Fri, 16 Nov 2001 17:29:50 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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<N) trails are being used, and the operator/user wants to 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
> >
> > [email-masked] 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:
> > >         [email-masked].
> > > 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:     <[email-masked]>
--------------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:[email-masked]
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--

Delivery-date: Fri, 16 Nov 2001 08:03:41 -0800
Date: Fri, 16 Nov 2001 09:00:00 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: Maarten Vissers <[email-masked]>, ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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<N) trails are being used, and the operator/user wants to 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
> >
> > [email-masked] 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:
> > >         [email-masked].
> > > 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:     <[email-masked]>

Delivery-date: Fri, 16 Nov 2001 07:54:04 -0800
Date: Fri, 16 Nov 2001 16:51:45 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: ccamp <[email-masked]>
Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------E954D652B41F85CC919FAF95--

Delivery-date: Fri, 16 Nov 2001 07:33:21 -0800
Date: Fri, 16 Nov 2001 16:32:11 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]
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--

Delivery-date: Fri, 16 Nov 2001 07:30:09 -0800
Date: Fri, 16 Nov 2001 16:28:19 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Maarten Vissers <[email-masked]>
CC: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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<N) trails are being used, and the operator/user wants to 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
> 
> [email-masked] 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:
> >         [email-masked].
> > 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:     <[email-masked]>
--------------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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------14015CC31DDC6D333B0FC149--

Delivery-date: Fri, 16 Nov 2001 07:14:29 -0800
Date: Fri, 16 Nov 2001 16:13:57 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: Re: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]
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--

Delivery-date: Fri, 16 Nov 2001 06:57:24 -0800
Date: Fri, 16 Nov 2001 15:55:27 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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:[email-masked]
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--

Delivery-date: Fri, 16 Nov 2001 06:56:31 -0800
To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Fri, 16 Nov 2001 15:36:12 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: ccamp <[email-masked]>, q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

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<N) trails are being used, and the operator/user wants to 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

[email-masked] 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:
>         [email-masked].
> 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:     <[email-masked]>
--------------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:[email-masked]
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--

Delivery-date: Fri, 16 Nov 2001 04:00:06 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 15 Nov 2001 23:12:45 -0800
Date: Fri, 16 Nov 2001 12:45:23 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: George Young <[email-masked]>
CC: [email-masked]
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.

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:[email-masked]]
> >Sent: Monday, November 12, 2001 9:00 PM
> >To: [email-masked]
> >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.
> >
> >

Delivery-date: Thu, 15 Nov 2001 21:48:29 -0800
Date: Thu, 15 Nov 2001 21:46:40 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Senthil Venkatachalam <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>, Sudheer Dharnikota <[email-masked]>, Papadimitriou Dimitri <[email-masked]>, <[email-masked]>
Subject: Re: draft-venkatachalam-interarea-mpls-te-02.txt

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     [email-masked]
> Off#:, MBox:                 (703) 679-6435 [Off]
> Alcatel USA                  (703) 679-6450 [Fax]
> __________________________________________________________________

Delivery-date: Thu, 15 Nov 2001 11:48:35 -0800
From: "Saha, Sayandeb" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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 <flow descriptor list> 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

Delivery-date: Thu, 15 Nov 2001 10:39:31 -0800
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Hall" <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Edward Harrison" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Cheenu Srinivasan" <[email-masked]>
Subject: MIBs for GMPLS
Date: Thu, 15 Nov 2001 13:34:31 -0500

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
[email-masked]

------=_NextPart_000_00DC_01C16DDA.41BFC6F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>Please be aware that we have =
published four MIBs=20
related to monitoring and managing GMPLS systems.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>These may be found at </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-t=
c-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g=
mpls-tc-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-l=
abel-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccam=
p-gmpls-label-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-t=
e-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g=
mpls-te-mib-00.txt</A></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-gmpls-l=
sr-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-=
gmpls-lsr-mib-00.txt</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The TC MIB provides additional =
Textual=20
Conventions to supplement those in =
draft-ietf-mpls-tc-mib-02.txt</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The Label MIB is entirely new for=20
GMPLS.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The TE and LSR MIBs are based=20
on&nbsp;draft-ietf-mpls-tc-mib-02.txt and draft-ietf-mpls-lsr-mib-06.txt =

respectively.&nbsp;&nbsp;Material for the TE MIB was drawn from <A=20
href=3D"http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmpls-te=
-mib-00.txt">http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp=
ls-te-mib-00.txt</A></FONT><FONT=20
face=3DCourier size=3D2>&nbsp;which should now be seen as =
obsolete.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We have asked for a slot in the CCAMP =
WG agenda=20
at the upcoming IETF to present these to you.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>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).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>We would welcome all comments and=20
input.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Movaz Networks =

Inc.<BR>Tel: 703-847-1867<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></DIV></BOD=
Y></HTML>

------=_NextPart_000_00DC_01C16DDA.41BFC6F0--

Delivery-date: Thu, 15 Nov 2001 05:09:14 -0800
Date: Thu, 15 Nov 2001 18:41:01 +0530
From: S Ramesh <[email-masked]>
Organization: HCL Technologies Limited
To: manoj juneja <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: 

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

Delivery-date: Thu, 15 Nov 2001 00:19:46 -0800
From: Heiles Juergen <[email-masked]>
To: "'Karmakar, Soumen'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: STM-M out of STM-N (M<N)
Date: Thu, 15 Nov 2001 09:14:26 +0100

Soumen,

for full transparency (Section/Regenerator Section transparency) only bit 1 has to be set (T=100000...).
However when transporting a STM-64 over a STM-256 in a non standard way, where would you put all the STM-64 SOH. The STM-256 needs usually SOH for its own purpose. So putting 4 STM-64 in an STM-256 is a problem. Solutions with 4xSTM-N over STM-4N I have seen support only transport of part of the SOH, not the full SOH. A solution could be to transport only 3 STM-N over a STM-4N, for example by mapping a STM-N into a VC-4-Xv (X=N+1). For this case the label would be different I assume. In any case this a speculations as we talk about proprietary solutions.

Juergen

> -----Original Message-----
> From: Karmakar, Soumen [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 7:14 PM
> To: 'Maarten Vissers'; manoj juneja
> Cc: [email-masked]
> Subject: RE: STM-M out of STM-N (M<N)
> 
> 
> 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:[email-masked]]
> > Sent: Wednesday, November 14, 2001 12:57 AM
> > To: manoj juneja
> > Cc: [email-masked]
> > Subject: Re: STM-M out of STM-N (M<N)
> > 
> > 
> > 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 <[email-masked]>
> > > >To: manoj juneja <[email-masked]>
> > > >CC: [email-masked]
> > > >Subject: Re: STM-M out of STM-N (M<N)
> > > >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
> > 
> 

Delivery-date: Wed, 14 Nov 2001 18:01:52 -0800
Date: Thu, 15 Nov 2001 9:48:3 +0800
From: Wang Hui <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Simulations & experimentations??
Organization: Infonet Lab, USTC

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

Delivery-date: Wed, 14 Nov 2001 17:01:28 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Date: Wed, 14 Nov 2001 17:57:52 -0700

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

Delivery-date: Wed, 14 Nov 2001 12:46:21 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Date: Wed, 14 Nov 2001 13:44:47 -0700

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

Delivery-date: Wed, 14 Nov 2001 11:36:48 -0800
content-class: urn:content-classes:message
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
From: "George Young" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]
>Sent: Monday, November 12, 2001 9:00 PM
>To: [email-masked]
>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.
>
>

Delivery-date: Wed, 14 Nov 2001 11:05:53 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Fw: Fiber and wavelength labels
Date: Wed, 14 Nov 2001 12:03:50 -0700

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

Delivery-date: Wed, 14 Nov 2001 10:16:48 -0800
From: "Karmakar, Soumen" <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: STM-M out of STM-N (M<N)
Date: Wed, 14 Nov 2001 10:14:02 -0800

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:[email-masked]]
> Sent: Wednesday, November 14, 2001 12:57 AM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: STM-M out of STM-N (M<N)
> 
> 
> 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 <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: STM-M out of STM-N (M<N)
> > >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
> 

Delivery-date: Wed, 14 Nov 2001 01:28:51 -0800
From: Heiles Juergen <[email-masked]>
To: manoj juneja <[email-masked]>
Cc: [email-masked]
Subject: RE: STM-M out of STM-N (M<N)
Date: Wed, 14 Nov 2001 10:27:17 +0100

Manoj,

furthermore when you use semi-transparent transport of a STM-64 in a STM-256 it is not possible to transport all the SOH of the STM-64 via the STM-256 as the STM-256 uses SOH for its own purpose. You can only tunnel some of the STM-64 SOH by transporting them in unused SOH of the STM-256.

Juergen

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 9:57 AM
> To: manoj juneja
> Cc: [email-masked]
> Subject: Re: STM-M out of STM-N (M<N)
> 
> 
> 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 <[email-masked]>
> > >To: manoj juneja <[email-masked]>
> > >CC: [email-masked]
> > >Subject: Re: STM-M out of STM-N (M<N)
> > >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

Delivery-date: Wed, 14 Nov 2001 01:00:26 -0800
Cc: [email-masked]
Date: Wed, 14 Nov 2001 09:57:14 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: STM-M out of STM-N (M<N)

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

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 <[email-masked]>
> >To: manoj juneja <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: STM-M out of STM-N (M<N)
> >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:[email-masked]
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: [email-masked]
Delivery-date: Tue, 13 Nov 2001 22:02:16 -0800
Date: Tue, 13 Nov 2001 21:57:05 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
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.

Delivery-date: Tue, 13 Nov 2001 13:39:13 -0800
Date: Tue, 13 Nov 2001 17:19:05 -0500
From: Senthil Venkatachalam <[email-masked]>
Organization: Alcatel
To: Kireeti Kompella <[email-masked]>, Vijay Gill <[email-masked]>
CC: Sudheer Dharnikota <[email-masked]>, Papadimitriou Dimitri <[email-masked]>, [email-masked]
Subject: draft-venkatachalam-interarea-mpls-te-02.txt 

--------------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     [email-masked]
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________

--------------3BCA18120FF83EFDDD37E9F0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Kireeti,
<p>We would like to request a slot to present our draft:
<br>draft-venkatachalam-interarea-mpls-te-02.txt
<br>at the Salt Lake City IETF.
<p>Best Regards,
<br>Senthil.
<pre>--&nbsp;
Senthil K. Venkatachalam&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]
Off#:, MBox:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703) 679-6435 [Off]
Alcatel USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703) 679-6450 [Fax]
__________________________________________________________________</pre>
&nbsp;</html>

--------------3BCA18120FF83EFDDD37E9F0--

Delivery-date: Tue, 13 Nov 2001 13:18:36 -0800
content-class: urn:content-classes:message
Subject: RE: Two week Last Call on LMP (Section 6.4 & 6.5)
Date:  Tue, 13 Nov 2001 16:11:41 -0500
From: "George Young" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]
>Sent: Monday, November 12, 2001 9:00 PM
>To: [email-masked]
>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.
>
>

Delivery-date: Tue, 13 Nov 2001 12:02:13 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Fiber and wavelength labels
Date: Tue, 13 Nov 2001 12:52:34 -0700

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

Delivery-date: Tue, 13 Nov 2001 11:52:43 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: STM-M out of STM-N (M<N)
Date: Tue, 13 Nov 2001 12:41:03 -0700

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 <[email-masked]>
>To: manoj juneja <[email-masked]>
>CC: [email-masked]
>Subject: Re: STM-M out of STM-N (M<N)
>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: [email-masked]
Delivery-date: Tue, 13 Nov 2001 01:52:17 -0800
Date: Tue, 13 Nov 2001 01:49:29 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
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.

Delivery-date: Tue, 13 Nov 2001 01:34:05 -0800
Cc: q19/15 <[email-masked]>
Date: Tue, 13 Nov 2001 10:32:35 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>, "t1x1.5" <[email-masked]>
Original-CC: q19/15 <[email-masked]>
Subject: Re: OLI/LMP-WDM/NTIP => next step in ITU-T SG15

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 <[email-masked]>
Reply-To: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: q19/15 <[email-masked]>

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:[email-masked]/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:[email-masked]
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--

Delivery-date: Tue, 13 Nov 2001 00:59:31 -0800
Cc: [email-masked]
Date: Tue, 13 Nov 2001 09:55:03 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: STM-M out of STM-N (M<N)

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

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
--------------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:[email-masked]
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: [email-masked]
Delivery-date: Mon, 12 Nov 2001 18:05:07 -0800
Date: Mon, 12 Nov 2001 17:59:33 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
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: [email-masked]
Delivery-date: Fri, 09 Nov 2001 15:19:19 -0800
Date: Fri, 9 Nov 2001 15:13:45 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: ITU-T Study Group 15 - Access to files from Communication Statements
Cc: [email-masked], [email-masked]

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:[email-masked]/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)

Delivery-date: Fri, 09 Nov 2001 11:36:29 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: STM-M out of STM-N (M<N)
Date: Fri, 09 Nov 2001 12:34:54 -0700

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

Delivery-date: Fri, 09 Nov 2001 04:25:08 -0800
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 09 Nov 2001 13:23:47 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: SDH/SONET in GMPLS

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 <[email-masked]>
> >To: "[email-masked]'" <[email-masked]>
> >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:[email-masked]
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--

Delivery-date: Fri, 09 Nov 2001 04:16:03 -0800
Cc: [email-masked]
Date: Fri, 09 Nov 2001 13:13:45 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: manoj juneja <[email-masked]>
Original-CC: [email-masked]
Subject: Re: SDH/SONET in GMPLS

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:[email-masked]
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--

Delivery-date: Fri, 09 Nov 2001 03:08:52 -0800
Date: Fri, 09 Nov 2001 12:01:34 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "[email-masked]'" <[email-masked]>
Subject: Re: SDH/SONET label

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:[email-masked]
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--

Delivery-date: Fri, 09 Nov 2001 01:15:05 -0800
Date: Fri, 09 Nov 2001 10:10:21 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt

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:[email-masked]]
> > 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:[email-masked]]
> > > 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:[email-masked]
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--

Delivery-date: Thu, 08 Nov 2001 18:50:45 -0800
From: James  Scott <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: SDH/SONET in GMPLS
Date: Thu, 8 Nov 2001 18:42:05 -0800 

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

Delivery-date: Thu, 08 Nov 2001 18:23:55 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: SDH/SONET in GMPLS
Date: Thu, 08 Nov 2001 19:18:23 -0700

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 <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>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

Delivery-date: Thu, 08 Nov 2001 17:37:05 -0800
From: James  Scott <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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

Delivery-date: Thu, 08 Nov 2001 15:35:11 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: SDH/SONET in GMPLS
Date: Thu, 08 Nov 2001 16:28:08 -0700

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

Delivery-date: Thu, 08 Nov 2001 14:01:48 -0800
From: "Robin Qiu" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: A question regarding draft-itef-ccamp-lmp-01.txt
Date: Thu, 08 Nov 2001 16:56:59 -0500

My interpretations (plus more questions) below. Please feedback if you don't 
agree.

Robin Qiu

-----Original Message-----
From: Fugui Wang [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 3:09 PM
To: [email-masked]'
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: [email-masked]'
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

Delivery-date: Thu, 08 Nov 2001 12:42:28 -0800
From: Jonathan Lang <[email-masked]>
To: 'Fugui Wang ' <[email-masked]>, "[email-masked]' '" <[email-masked]>
Cc: Jonathan Lang <[email-masked]>
Subject: RE: A question regarding draft-itef-ccamp-lmp-01.txt
Date: Thu, 8 Nov 2001 12:36:24 -0800 

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: [email-masked]'
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: [email-masked]'
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

Delivery-date: Thu, 08 Nov 2001 12:13:08 -0800
From: Fugui Wang <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: A question regarding draft-itef-ccamp-lmp-01.txt
Date: Thu, 8 Nov 2001 15:09:02 -0500 

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: [email-masked]'
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

Delivery-date: Thu, 08 Nov 2001 09:09:57 -0800
From: "Juergen Heiles" <[email-masked]>
To: <[email-masked]>
Subject: WG: Moving right along ... Switching Type
Date: Thu, 8 Nov 2001 18:05:08 +0100

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:[email-masked]]
> Gesendet: Dienstag, 6. November 2001 07:31
> An: Heiles Juergen
> Cc: [email-masked]
> 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.
>

Delivery-date: Tue, 06 Nov 2001 07:25:14 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Ben Mack-Crane' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... gmpls-sonet-sdh-02
Date: Tue, 6 Nov 2001 16:21:36 +0100 

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:[email-masked]]
Sent: Tuesday, October 30, 2001 12:03 AM
To: Kireeti Kompella
Cc: [email-masked]
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

Delivery-date: Tue, 06 Nov 2001 06:33:15 -0800
Date: Tue, 06 Nov 2001 09:28:17 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Zhi-Wei Lin <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]]
> >>Sent: Friday, November 02, 2001 3:03 PM
> >>To: Yakov Rekhter
> >>Cc: Ewart Tempest; [email-masked]
> >>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:[email-masked]]
> >>>>>Sent: Wednesday, October 31, 2001 8:19 PM
> >>>>>To: Zhi-Wei Lin
> >>>>>Cc: [email-masked]
> >>>>>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".
> >>>
> >>>
> >>>>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:[email-masked])
> > http://www.mindspring.com/~ewgray
> >
> >
> >
> >
> >

Delivery-date: Tue, 06 Nov 2001 05:38:17 -0800
Cc: Heiles Juergen <[email-masked]>, [email-masked]
Date: Tue, 06 Nov 2001 14:36:50 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: Heiles Juergen <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]
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--

Delivery-date: Tue, 06 Nov 2001 05:03:24 -0800
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Date: Tue, 06 Nov 2001 14:00:58 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Ewart Tempest <[email-masked]>
Original-CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]/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:[email-masked]
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--

Delivery-date: Mon, 05 Nov 2001 22:34:25 -0800
Date: Tue, 06 Nov 2001 07:31:13 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: Heiles Juergen <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------8C1B0640D3720417C7713748--

Delivery-date: Mon, 05 Nov 2001 20:41:56 -0800
Date: Sun, 04 Nov 2001 15:37:00 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> > > > >
> > > > > > <z>The section you mentioned, from what I can tell, is an example list
> > > > > > of some possible combinations of different equipment functions. I see
> > > > > > them as examples. But as I said, from routing perspective, it may make
> > > > > > sense but not signaling. What you've pointed out is the routing document...
> > > > > >  From signaling perspective, if I removed the switching capability
> > > > > > field, there is nothing lost...do you agree?
> > > > > >
> > > > > >
> > > > > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > > > > possible combinations of switching capabilities supported on a link, an
> > > > > > intermediate node can deduce, from other fields in the Path message, what
> > > > > > switching capability is desired.
> > > > > >
> > > > >
> > > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > > different switching capabilities on each side and the possible
> > > > > connections and then demonstrate that what switching capability is
> > > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > > encoding type says and the sender_tspec says is what the switching type
> > > > > used (I'm lazy, it takes too long to run through all the combinations)</z>
> > > > >
> > > > > >
> > > > > > And if I removed the switching capability field, then it opens the door
> > > > > > for the possibility where somewhere within my network I might change the
> > > > > > switching type in order to satisfy a request (because the switching type
> > > > > > requested is non-existent or exhausted).</z>
> > > > > >
> > > > > >
> > > > > > JD: Please give an example of where substituting one value of switching
> > > > > > capability for another in the middle of an LSP makes sense.
> > > > > >
> > > > >
> > > > > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > > > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > > > service). In the SONET network it switches the STS-48c layer, while in
> > > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > > > connection, where one part of network may work PDH-based and switching
> > > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > > connection or service is essentially the same. They're not really
> > > > > client-server layers but similar layers from different technologies...</z>
> > > > >
> > > > > > <z>I think it does make sense. I think you have to assume that within
> > > > > > the switched transport network there will be many kinds of interfaces
> > > > > > connecting to the transport network. If you can't offer this capability,
> > > > > > then essentially what you've done is segment the transport network into
> > > > > > sub-networks based on what interfaces they have and only the like-type
> > > > > > interfaces can connect to each other. If you look at the IP world, you
> > > > > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > > > > together and talking to each other without a problem. This is capability
> > > > > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > > > > reason to restrict this). What really matters is that the service is
> > > > > > delivered. Granted there will be some inefficiencies in this, but that's
> > > > > > really a policy decision whether users are willing to accept this type
> > > > > > of connection.</z>
> > > > > >
> > > > > >
> > > > > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > > > > you were describing in your previous example was an LSP, one end of which
> > > > > > was
> > > > > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > > > > >
> > > > >
> > > > > <z>Maybe this is one where we need to ask individuals with operational
> > > > > experience and have some experience with service provisioning whether
> > > > > having one end with Ethernet and another end with OC-48 sounds like a
> > > > > configuration that makes sense?
> > > > >
> > > > > Again, the point here is that if this doesn't make sense, then
> > > > > essentially what you have is multiple switched networks, each serving
> > > > > one particular type of customer interface, i.e., a switched network for
> > > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > > >
> > > > > Is this one of those "violent agreements" where we're concentrating on
> > > > > two different levels but saying the same thing?</z>

--------------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:[email-masked]
title:Network Architect
adr;quoted-printable:;;481 Sycamore Drive=0D=0A;Milpitas;CA;95035;USA
fn:Sudheer Dharanikota
end:vcard

--------------1D73D4B5887498FF00E0EC09--

Delivery-date: Mon, 05 Nov 2001 16:23:44 -0800
Date: Mon, 05 Nov 2001 19:17:58 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Eric Gray <[email-masked]>
CC: John Drake <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>, Ewart Tempest <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]]
>>Sent: Friday, November 02, 2001 3:03 PM
>>To: Yakov Rekhter
>>Cc: Ewart Tempest; [email-masked]
>>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:[email-masked]]
>>>>>Sent: Wednesday, October 31, 2001 8:19 PM
>>>>>To: Zhi-Wei Lin
>>>>>Cc: [email-masked]
>>>>>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".
>>>
>>>
>>>>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:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
> 
> 
> 

Delivery-date: Mon, 05 Nov 2001 15:42:05 -0800
Date: Mon, 5 Nov 2001 18:40:44 -0500
From: Vijay Gill <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: Agenda time for CCAMP (Salt Lake)

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

Delivery-date: Mon, 05 Nov 2001 13:04:54 -0800
From: Heiles Juergen <[email-masked]>
To: [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Mon, 5 Nov 2001 21:57:33 +0100 

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?

Delivery-date: Mon, 05 Nov 2001 12:57:05 -0800
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>
Subject: SDH/SONET label
Date: Mon, 5 Nov 2001 21:48:59 +0100 

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. 

Delivery-date: Mon, 05 Nov 2001 08:05:41 -0800
Date: Mon, 05 Nov 2001 11:02:35 -0500
From: Eric Gray <[email-masked]>
To: John Drake <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, Ewart Tempest <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]]
> Sent: Friday, November 02, 2001 3:03 PM
> To: Yakov Rekhter
> Cc: Ewart Tempest; [email-masked]
> 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:[email-masked]]
> > > > Sent: Wednesday, October 31, 2001 8:19 PM
> > > > To: Zhi-Wei Lin
> > > > Cc: [email-masked]
> > > > 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".
> >
> > > 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:[email-masked])
http://www.mindspring.com/~ewgray

Delivery-date: Mon, 05 Nov 2001 05:50:45 -0800
From: John Drake <[email-masked]>
To: [email-masked], Yakov Rekhter <[email-masked]>
Cc: Ewart Tempest <[email-masked]>, [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Mon, 5 Nov 2001 05:45:45 -0800 

"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:[email-masked]]
Sent: Friday, November 02, 2001 3:03 PM
To: Yakov Rekhter
Cc: Ewart Tempest; [email-masked]
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:[email-masked]]
> > > Sent: Wednesday, October 31, 2001 8:19 PM
> > > To: Zhi-Wei Lin
> > > Cc: [email-masked]
> > > 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".
> 
> > 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.

Delivery-date: Fri, 02 Nov 2001 19:15:47 -0800
From: "Ewart Tempest" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Fri, 2 Nov 2001 22:10:07 -0500

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:[email-masked]]
> Sent: Friday, November 02, 2001 1:49 PM
> To: Tempest, Ewart [SKY:XW44:EXCH]
> Cc: [email-masked]
> Subject: Re: Moving right along ... Switching Type
> 
> 
> Ewart,
> 
> > See embedded comment below.
> 
> response in-line...
> 
> > 
> > Ewart
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[email-masked]]
> > > Sent: Wednesday, October 31, 2001 8:19 PM
> > > To: Zhi-Wei Lin
> > > Cc: [email-masked]
> > > 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
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: Moving right along ... Switching Type</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=2>[EWART]: In the anology I mentioned above, OXC1 possesses a technology conversion function that, in this instance, strips off the layer 1 &amp; 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.</FONT></P>

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

<P><FONT SIZE=2>[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.</FONT></P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yakov.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C16415.0A437B50--

Delivery-date: Fri, 02 Nov 2001 15:08:51 -0800
Date: Fri, 02 Nov 2001 17:02:41 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
Organization: Tellabs ONG SE Platform
To: Yakov Rekhter <[email-masked]>
CC: Ewart Tempest <[email-masked]>, [email-masked]
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:[email-masked]]
> > > Sent: Wednesday, October 31, 2001 8:19 PM
> > > To: Zhi-Wei Lin
> > > Cc: [email-masked]
> > > 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".
> 
> > 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.

Delivery-date: Fri, 02 Nov 2001 11:23:42 -0800
Date: Fri, 02 Nov 2001 14:23:13 -0500
From: Gopal Kailad <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Transport networks and draft-ietf-mpls-generalized-rsvp-te-05

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

Delivery-date: Fri, 02 Nov 2001 11:14:51 -0800
Date: Fri, 02 Nov 2001 14:11:31 -0500
From: Gopal Kailad <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)

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.
>

Delivery-date: Fri, 02 Nov 2001 10:52:11 -0800
To: "Ewart Tempest" <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... Switching Type 
Date: Fri, 02 Nov 2001 10:48:30 -0800
From: Yakov Rekhter <[email-masked]>

Ewart,

> See embedded comment below.

response in-line...

> 
> Ewart
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Wednesday, October 31, 2001 8:19 PM
> > To: Zhi-Wei Lin
> > Cc: [email-masked]
> > 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".

> 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.

Delivery-date: Fri, 02 Nov 2001 08:03:06 -0800
From: "David Allan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Question about draft-kompella-ospf-gmpls-extensions-02
Date: Fri, 2 Nov 2001 10:52:26 -0500

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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>Question about draft-kompella-ospf-gmpls-extensions-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Question on the sub-TLV list in section 5.</FONT>
</P>

<P><FONT SIZE=2>What is &quot;32768-32772 - reserved for Cisco specific extensions&quot; ?</FONT>
</P>

<P><FONT SIZE=2>Can any of us get a block?</FONT>
</P>

<P><FONT SIZE=2>thx</FONT>
<BR><FONT SIZE=2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C163B6.5E726EC0--

Delivery-date: Fri, 02 Nov 2001 07:24:32 -0800
Cc: [email-masked]
Date: Fri, 02 Nov 2001 16:17:55 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Sudheer Dharanikota <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> > > >
> > > > > <z>The section you mentioned, from what I can tell, is an example list
> > > > > of some possible combinations of different equipment functions. I see
> > > > > them as examples. But as I said, from routing perspective, it may make
> > > > > sense but not signaling. What you've pointed out is the routing document...
> > > > >  From signaling perspective, if I removed the switching capability
> > > > > field, there is nothing lost...do you agree?
> > > > >
> > > > >
> > > > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > > > possible combinations of switching capabilities supported on a link, an
> > > > > intermediate node can deduce, from other fields in the Path message, what
> > > > > switching capability is desired.
> > > > >
> > > >
> > > > <z>Wow...ok...so I have to list all the different combinations of
> > > > different switching capabilities on each side and the possible
> > > > connections and then demonstrate that what switching capability is
> > > > desired can be deduced...hmmm...can't I just say that whatever the
> > > > encoding type says and the sender_tspec says is what the switching type
> > > > used (I'm lazy, it takes too long to run through all the combinations)</z>
> > > >
> > > > >
> > > > > And if I removed the switching capability field, then it opens the door
> > > > > for the possibility where somewhere within my network I might change the
> > > > > switching type in order to satisfy a request (because the switching type
> > > > > requested is non-existent or exhausted).</z>
> > > > >
> > > > >
> > > > > JD: Please give an example of where substituting one value of switching
> > > > > capability for another in the middle of an LSP makes sense.
> > > > >
> > > >
> > > > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > > service). In the SONET network it switches the STS-48c layer, while in
> > > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > > connection, where one part of network may work PDH-based and switching
> > > > E1 while another part may be SDH-based and switching VC-12, but the
> > > > connection or service is essentially the same. They're not really
> > > > client-server layers but similar layers from different technologies...</z>
> > > >
> > > > > <z>I think it does make sense. I think you have to assume that within
> > > > > the switched transport network there will be many kinds of interfaces
> > > > > connecting to the transport network. If you can't offer this capability,
> > > > > then essentially what you've done is segment the transport network into
> > > > > sub-networks based on what interfaces they have and only the like-type
> > > > > interfaces can connect to each other. If you look at the IP world, you
> > > > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > > > together and talking to each other without a problem. This is capability
> > > > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > > > reason to restrict this). What really matters is that the service is
> > > > > delivered. Granted there will be some inefficiencies in this, but that's
> > > > > really a policy decision whether users are willing to accept this type
> > > > > of connection.</z>
> > > > >
> > > > >
> > > > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > > > you were describing in your previous example was an LSP, one end of which
> > > > > was
> > > > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > > > >
> > > >
> > > > <z>Maybe this is one where we need to ask individuals with operational
> > > > experience and have some experience with service provisioning whether
> > > > having one end with Ethernet and another end with OC-48 sounds like a
> > > > configuration that makes sense?
> > > >
> > > > Again, the point here is that if this doesn't make sense, then
> > > > essentially what you have is multiple switched networks, each serving
> > > > one particular type of customer interface, i.e., a switched network for
> > > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > > >
> > > > Is this one of those "violent agreements" where we're concentrating on
> > > > two different levels but saying the same thing?</z>
--------------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:[email-masked]
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--

Delivery-date: Thu, 01 Nov 2001 09:24:58 -0800
Date: Thu, 01 Nov 2001 09:17:08 -0800
From: Sudheer Dharanikota <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: Dimitri Papadimitriou <[email-masked]>, Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> > >
> > > > <z>The section you mentioned, from what I can tell, is an example list
> > > > of some possible combinations of different equipment functions. I see
> > > > them as examples. But as I said, from routing perspective, it may make
> > > > sense but not signaling. What you've pointed out is the routing document...
> > > >  From signaling perspective, if I removed the switching capability
> > > > field, there is nothing lost...do you agree?
> > > >
> > > >
> > > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > > possible combinations of switching capabilities supported on a link, an
> > > > intermediate node can deduce, from other fields in the Path message, what
> > > > switching capability is desired.
> > > >
> > >
> > > <z>Wow...ok...so I have to list all the different combinations of
> > > different switching capabilities on each side and the possible
> > > connections and then demonstrate that what switching capability is
> > > desired can be deduced...hmmm...can't I just say that whatever the
> > > encoding type says and the sender_tspec says is what the switching type
> > > used (I'm lazy, it takes too long to run through all the combinations)</z>
> > >
> > > >
> > > > And if I removed the switching capability field, then it opens the door
> > > > for the possibility where somewhere within my network I might change the
> > > > switching type in order to satisfy a request (because the switching type
> > > > requested is non-existent or exhausted).</z>
> > > >
> > > >
> > > > JD: Please give an example of where substituting one value of switching
> > > > capability for another in the middle of an LSP makes sense.
> > > >
> > >
> > > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > service). In the SONET network it switches the STS-48c layer, while in
> > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > connection, where one part of network may work PDH-based and switching
> > > E1 while another part may be SDH-based and switching VC-12, but the
> > > connection or service is essentially the same. They're not really
> > > client-server layers but similar layers from different technologies...</z>
> > >
> > > > <z>I think it does make sense. I think you have to assume that within
> > > > the switched transport network there will be many kinds of interfaces
> > > > connecting to the transport network. If you can't offer this capability,
> > > > then essentially what you've done is segment the transport network into
> > > > sub-networks based on what interfaces they have and only the like-type
> > > > interfaces can connect to each other. If you look at the IP world, you
> > > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > > together and talking to each other without a problem. This is capability
> > > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > > reason to restrict this). What really matters is that the service is
> > > > delivered. Granted there will be some inefficiencies in this, but that's
> > > > really a policy decision whether users are willing to accept this type
> > > > of connection.</z>
> > > >
> > > >
> > > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > > you were describing in your previous example was an LSP, one end of which
> > > > was
> > > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > > >
> > >
> > > <z>Maybe this is one where we need to ask individuals with operational
> > > experience and have some experience with service provisioning whether
> > > having one end with Ethernet and another end with OC-48 sounds like a
> > > configuration that makes sense?
> > >
> > > Again, the point here is that if this doesn't make sense, then
> > > essentially what you have is multiple switched networks, each serving
> > > one particular type of customer interface, i.e., a switched network for
> > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > >
> > > Is this one of those "violent agreements" where we're concentrating on
> > > two different levels but saying the same thing?</z>

Delivery-date: Thu, 01 Nov 2001 08:25:53 -0800
Date: Thu, 01 Nov 2001 11:24:46 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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

Delivery-date: Thu, 01 Nov 2001 08:05:01 -0800
Date: Thu, 01 Nov 2001 10:54:19 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Ewart Tempest <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

> 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:[email-masked]]
> > Sent: Wednesday, October 31, 2001 8:19 PM
> > To: Zhi-Wei Lin
> > Cc: [email-masked]
> > 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 = 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.
> >
> >

Delivery-date: Thu, 01 Nov 2001 08:04:10 -0800
Date: Thu, 01 Nov 2001 11:03:37 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Yakov Rekhter <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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.

Delivery-date: Thu, 01 Nov 2001 07:44:03 -0800
Date: Thu, 01 Nov 2001 09:30:43 -0600
From: Ben Mack-Crane <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Moving right along ... Switching Type

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

[email-masked] 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:[email-masked]]
> > Sent: 01 November 2001 11:03
> > To: Yakov Rekhter
> > Cc: Zhi-Wei Lin; [email-masked]
> > 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,
> > >
> > > > <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 ?
> > >
> > > Yakov.
> >

Delivery-date: Thu, 01 Nov 2001 07:38:40 -0800
Date: Thu, 01 Nov 2001 09:25:02 -0600
From: Ben Mack-Crane <[email-masked]>
To: Maarten Vissers <[email-masked]>
CC: Dimitri Papadimitriou <[email-masked]>, Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> > >
> > > > <z>The section you mentioned, from what I can tell, is an example list
> > > > of some possible combinations of different equipment functions. I see
> > > > them as examples. But as I said, from routing perspective, it may make
> > > > sense but not signaling. What you've pointed out is the routing document...
> > > >  From signaling perspective, if I removed the switching capability
> > > > field, there is nothing lost...do you agree?
> > > >
> > > >
> > > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > > possible combinations of switching capabilities supported on a link, an
> > > > intermediate node can deduce, from other fields in the Path message, what
> > > > switching capability is desired.
> > > >
> > >
> > > <z>Wow...ok...so I have to list all the different combinations of
> > > different switching capabilities on each side and the possible
> > > connections and then demonstrate that what switching capability is
> > > desired can be deduced...hmmm...can't I just say that whatever the
> > > encoding type says and the sender_tspec says is what the switching type
> > > used (I'm lazy, it takes too long to run through all the combinations)</z>
> > >
> > > >
> > > > And if I removed the switching capability field, then it opens the door
> > > > for the possibility where somewhere within my network I might change the
> > > > switching type in order to satisfy a request (because the switching type
> > > > requested is non-existent or exhausted).</z>
> > > >
> > > >
> > > > JD: Please give an example of where substituting one value of switching
> > > > capability for another in the middle of an LSP makes sense.
> > > >
> > >
> > > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > > and it goes through an all-optical network that can provide OCh1 (2.5G
> > > service). In the SONET network it switches the STS-48c layer, while in
> > > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > > connection, where one part of network may work PDH-based and switching
> > > E1 while another part may be SDH-based and switching VC-12, but the
> > > connection or service is essentially the same. They're not really
> > > client-server layers but similar layers from different technologies...</z>
> > >
> > > > <z>I think it does make sense. I think you have to assume that within
> > > > the switched transport network there will be many kinds of interfaces
> > > > connecting to the transport network. If you can't offer this capability,
> > > > then essentially what you've done is segment the transport network into
> > > > sub-networks based on what interfaces they have and only the like-type
> > > > interfaces can connect to each other. If you look at the IP world, you
> > > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > > together and talking to each other without a problem. This is capability
> > > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > > reason to restrict this). What really matters is that the service is
> > > > delivered. Granted there will be some inefficiencies in this, but that's
> > > > really a policy decision whether users are willing to accept this type
> > > > of connection.</z>
> > > >
> > > >
> > > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > > you were describing in your previous example was an LSP, one end of which
> > > > was
> > > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > > >
> > >
> > > <z>Maybe this is one where we need to ask individuals with operational
> > > experience and have some experience with service provisioning whether
> > > having one end with Ethernet and another end with OC-48 sounds like a
> > > configuration that makes sense?
> > >
> > > Again, the point here is that if this doesn't make sense, then
> > > essentially what you have is multiple switched networks, each serving
> > > one particular type of customer interface, i.e., a switched network for
> > > 1 Gb Ethernet, a switched network for OC-48, etc.
> > >
> > > Is this one of those "violent agreements" where we're concentrating on
> > > two different levels but saying the same thing?</z>

Delivery-date: Thu, 01 Nov 2001 07:33:43 -0800
From: "Ewart Tempest" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Thu, 1 Nov 2001 10:22:21 -0500

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:[email-masked]]
> Sent: Wednesday, October 31, 2001 8:19 PM
> To: Zhi-Wei Lin
> Cc: [email-masked]
> 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 = 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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Moving right along ... Switching Type</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Yakov,</FONT>
</P>

<P><FONT SIZE=3D2>See embedded comment below.</FONT>
</P>

<P><FONT SIZE=3D2>Ewart</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Yakov Rekhter [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, October 31, 2001 8:19 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Zhi-Wei Lin</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Moving right along ... Switching =
Type</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Zhi-Wei,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;z&gt;Maybe this is one where we need =
to ask individuals with </FONT>
<BR><FONT SIZE=3D2>&gt; operational </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; experience and have some experience with =
service </FONT>
<BR><FONT SIZE=3D2>&gt; provisioning whether </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; having one end with Ethernet and another =
end with OC-48 </FONT>
<BR><FONT SIZE=3D2>&gt; sounds like a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; configuration that makes sense?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Let me see if I understand your proposal. =
Consider the following</FONT>
<BR><FONT SIZE=3D2>&gt; example:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; R1---OXC1---OXC2----R2</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; where the TE interface on R1 is a collection of =
GigE ports, and the TE</FONT>
<BR><FONT SIZE=3D2>&gt; interface on R2 is a collection of OC-48 ports. =
Are you saying that</FONT>
<BR><FONT SIZE=3D2>&gt; establishing an LSP between R1 to R2 makes =
sense ?</FONT>
</P>

<P><FONT SIZE=3D2>[EWART]: Correct. OXC1 may be capable of performing =
signal conversion or, more likely, there may be some intermediate =
non-GMPLS device between R1 &amp; OXC1 that performs such a conversion =
(refer to e-mail entitled &quot;Query on Encoding field wrt presence of =
technology conversion devices - OSPF-TE/ISIS-TE extensions&quot;, 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. </FONT></P>

<P><FONT SIZE=3D2>&quot;Within the GMPLS related routing documents =
(draft-ietf-ccamp-ospf-gmpls-extensions &amp; =
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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; =
SONET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SONET (LSP =
Enc. Type =3D SONET,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; G-PID =3D one of POS*)</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; technology&nbsp;&nbsp;&nbsp; =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; client A ------ conversion ------ LSR A ------- LSR B ------ LSR C =
------- client B</FONT></P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; device</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
\-------------------------------/</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ASTN</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FiberChannel</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>(LSP Enc. =
Type =3D FiberChannel,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2> =
G-PID =3D FC-3)</FONT>
</P>

<P><FONT SIZE=3D2>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?&quot;</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yakov.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C162E9.00435800--

Delivery-date: Thu, 01 Nov 2001 07:31:02 -0800
Date: Thu, 01 Nov 2001 09:17:09 -0600
From: Ben Mack-Crane <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
CC: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> >
> > > <z>The section you mentioned, from what I can tell, is an example list
> > > of some possible combinations of different equipment functions. I see
> > > them as examples. But as I said, from routing perspective, it may make
> > > sense but not signaling. What you've pointed out is the routing document...
> > >  From signaling perspective, if I removed the switching capability
> > > field, there is nothing lost...do you agree?
> > >
> > >
> > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > possible combinations of switching capabilities supported on a link, an
> > > intermediate node can deduce, from other fields in the Path message, what
> > > switching capability is desired.
> > >
> >
> > <z>Wow...ok...so I have to list all the different combinations of
> > different switching capabilities on each side and the possible
> > connections and then demonstrate that what switching capability is
> > desired can be deduced...hmmm...can't I just say that whatever the
> > encoding type says and the sender_tspec says is what the switching type
> > used (I'm lazy, it takes too long to run through all the combinations)</z>
> >
> > >
> > > And if I removed the switching capability field, then it opens the door
> > > for the possibility where somewhere within my network I might change the
> > > switching type in order to satisfy a request (because the switching type
> > > requested is non-existent or exhausted).</z>
> > >
> > >
> > > JD: Please give an example of where substituting one value of switching
> > > capability for another in the middle of an LSP makes sense.
> > >
> >
> > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > and it goes through an all-optical network that can provide OCh1 (2.5G
> > service). In the SONET network it switches the STS-48c layer, while in
> > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > connection, where one part of network may work PDH-based and switching
> > E1 while another part may be SDH-based and switching VC-12, but the
> > connection or service is essentially the same. They're not really
> > client-server layers but similar layers from different technologies...</z>
> >
> > > <z>I think it does make sense. I think you have to assume that within
> > > the switched transport network there will be many kinds of interfaces
> > > connecting to the transport network. If you can't offer this capability,
> > > then essentially what you've done is segment the transport network into
> > > sub-networks based on what interfaces they have and only the like-type
> > > interfaces can connect to each other. If you look at the IP world, you
> > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > together and talking to each other without a problem. This is capability
> > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > reason to restrict this). What really matters is that the service is
> > > delivered. Granted there will be some inefficiencies in this, but that's
> > > really a policy decision whether users are willing to accept this type
> > > of connection.</z>
> > >
> > >
> > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > you were describing in your previous example was an LSP, one end of which
> > > was
> > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > >
> >
> > <z>Maybe this is one where we need to ask individuals with operational
> > experience and have some experience with service provisioning whether
> > having one end with Ethernet and another end with OC-48 sounds like a
> > configuration that makes sense?
> >
> > Again, the point here is that if this doesn't make sense, then
> > essentially what you have is multiple switched networks, each serving
> > one particular type of customer interface, i.e., a switched network for
> > 1 Gb Ethernet, a switched network for OC-48, etc.
> >
> > Is this one of those "violent agreements" where we're concentrating on
> > two different levels but saying the same thing?</z>

Delivery-date: Thu, 01 Nov 2001 07:18:07 -0800
Date: Thu, 01 Nov 2001 09:04:32 -0600
From: Ben Mack-Crane <[email-masked]>
To: John Drake <[email-masked]>
CC: [email-masked]
Subject: Re: Moving right along ... Switching Type

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:[email-masked]]
> Sent: Wednesday, October 31, 2001 2:10 PM
> To: John Drake
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Monday, October 29, 2001 9:53 AM
> > To: Kireeti Kompella
> > Cc: [email-masked]
> > 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

Delivery-date: Thu, 01 Nov 2001 07:13:51 -0800
Date: Thu, 01 Nov 2001 16:01:58 +0100
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NA (NSG)
To: George Swallow <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked], Maarten Vissers <[email-masked]>, John Drake <[email-masked]>
Subject: Re: Moving right along ... Switching Type

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:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------54894DBE570AB46316BC090D--

Delivery-date: Thu, 01 Nov 2001 06:11:07 -0800
To: Yangguang Xu <[email-masked]>
cc: [email-masked]
Subject: Re: Moving right along ... Switching Type 
Date: Thu, 01 Nov 2001 06:09:24 -0800
From: Yakov Rekhter <[email-masked]>

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: [email-masked]
Delivery-date: Thu, 01 Nov 2001 06:11:02 -0800
Message-Id: <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: Dimitri Papadimitriou <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Moving right along ... Switching Type 
Date: Thu, 01 Nov 2001 09:07:36 -0500
From: George Swallow <[email-masked]>

> > 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

Delivery-date: Thu, 01 Nov 2001 04:06:43 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 01 Nov 2001 03:44:12 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Moving right along ... Switching Type
Date: Thu, 1 Nov 2001 11:41:14 -0000 

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:[email-masked]]
> Sent: 01 November 2001 11:03
> To: Yakov Rekhter
> Cc: Zhi-Wei Lin; [email-masked]
> 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,
> > 
> > > <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 ?
> > 
> > Yakov.
> 

Delivery-date: Thu, 01 Nov 2001 03:07:54 -0800
Cc: Zhi-Wei Lin <[email-masked]>, [email-masked]
Date: Thu, 01 Nov 2001 12:02:49 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Yakov Rekhter <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> 
> > <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 ?
> 
> 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:[email-masked]
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--

Delivery-date: Thu, 01 Nov 2001 02:33:27 -0800
Cc: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Date: Thu, 01 Nov 2001 11:30:38 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, "'Ben Mack-Crane'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Moving right along ... Switching Type

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,
> >
> > > <z>The section you mentioned, from what I can tell, is an example list
> > > of some possible combinations of different equipment functions. I see
> > > them as examples. But as I said, from routing perspective, it may make
> > > sense but not signaling. What you've pointed out is the routing document...
> > >  From signaling perspective, if I removed the switching capability
> > > field, there is nothing lost...do you agree?
> > >
> > >
> > > JD:  No.  I will try again. What you have to demonstrate is that for all
> > > possible combinations of switching capabilities supported on a link, an
> > > intermediate node can deduce, from other fields in the Path message, what
> > > switching capability is desired.
> > >
> >
> > <z>Wow...ok...so I have to list all the different combinations of
> > different switching capabilities on each side and the possible
> > connections and then demonstrate that what switching capability is
> > desired can be deduced...hmmm...can't I just say that whatever the
> > encoding type says and the sender_tspec says is what the switching type
> > used (I'm lazy, it takes too long to run through all the combinations)</z>
> >
> > >
> > > And if I removed the switching capability field, then it opens the door
> > > for the possibility where somewhere within my network I might change the
> > > switching type in order to satisfy a request (because the switching type
> > > requested is non-existent or exhausted).</z>
> > >
> > >
> > > JD: Please give an example of where substituting one value of switching
> > > capability for another in the middle of an LSP makes sense.
> > >
> >
> > <z>Well, for example, you have a SONET network that can provide STS-48c,
> > and it goes through an all-optical network that can provide OCh1 (2.5G
> > service). In the SONET network it switches the STS-48c layer, while in
> > OTN network it switches the OCh layer. This is very similar to E1/VC-12
> > connection, where one part of network may work PDH-based and switching
> > E1 while another part may be SDH-based and switching VC-12, but the
> > connection or service is essentially the same. They're not really
> > client-server layers but similar layers from different technologies...</z>
> >
> > > <z>I think it does make sense. I think you have to assume that within
> > > the switched transport network there will be many kinds of interfaces
> > > connecting to the transport network. If you can't offer this capability,
> > > then essentially what you've done is segment the transport network into
> > > sub-networks based on what interfaces they have and only the like-type
> > > interfaces can connect to each other. If you look at the IP world, you
> > > might have a switch with 100 Mbps and another with 10 Mbps connected
> > > together and talking to each other without a problem. This is capability
> > > that is also needed, where one end could be 1 Gbps Ethernet and another
> > > end is 10 Gbps Ethernet. But one end can also be an OC-48 SONET (no
> > > reason to restrict this). What really matters is that the service is
> > > delivered. Granted there will be some inefficiencies in this, but that's
> > > really a policy decision whether users are willing to accept this type
> > > of connection.</z>
> > >
> > >
> > > JD:  What you're describing here is PSC LSPs and they work just fine.  What
> > > you were describing in your previous example was an LSP, one end of which
> > > was
> > > PSC and the other end of which was TDM.  And that doesn't make sense.
> > >
> >
> > <z>Maybe this is one where we need to ask individuals with operational
> > experience and have some experience with service provisioning whether
> > having one end with Ethernet and another end with OC-48 sounds like a
> > configuration that makes sense?
> >
> > Again, the point here is that if this doesn't make sense, then
> > essentially what you have is multiple switched networks, each serving
> > one particular type of customer interface, i.e., a switched network for
> > 1 Gb Ethernet, a switched network for OC-48, etc.
> >
> > Is this one of those "violent agreements" where we're concentrating on
> > two different levels but saying the same thing?</z>
--------------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:[email-masked]
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--