Subject: Doubt in LMP
From: Chaya <[email-masked]>
To: <[email-masked]>
Date: Mon, 1 Jul 2002 09:39:48 +0530 (IST)

Hi,

	When is the  evdcDown event generated in data link
	FSM. Is it when the channel status mesg arrive,
	but is it not the channel status message is used
	when the data link is allocated?

thanks,
Chaya

Delivery-date: Fri, 28 Jun 2002 16:08:23 -0700
From: "Manral, Vishwas" <[email-masked]>
To: 'Jeff Parker' <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Control vs Client Links in IS-IS TE
Date: Fri, 28 Jun 2002 14:09:54 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi Jeff,

I guess in Section 4.0 of draft
http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt it is
stated that

   If a link is advertised with the maximum link metric (2^24 - 1), this
   link should not be considered during the normal SPF computation.

So if we want to preclude a link from normal SPF and yet use it for MPLS
LSP's we can set the metric to the value 2^24 - 1.

Thanks,
Vishwas

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Friday, June 28, 2002 10:57 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: Control vs Client Links in IS-IS TE

Consider a service provider who wishes to distinguish his control traffic
from the network he provides subscribers, by distinguishing his control
links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that
only run customer traffic. 

Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP
to router B.  How can IS-IS distinguish the two types of links if it is
using wide metrics?

In OSPF, we can send an Opaque LSA with info about an LSP.  This will not be
used for the IGP's SPF.  
However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus
looks like a normal link from A to B when the router is using Wide Metrics
in the SPF.  If B also has an LSP to A, other routers will have no way to
distinguish an MPLS LSP link intended for CSPF and those to be used in the
IGP's SPF.  I could imagine using a field such as Switch Capability, to
decide if a link should be included in SPF or not, but haven't seen this
suggested anywhere.  

- jeff parker
- axiowave networks

Delivery-date: Fri, 28 Jun 2002 10:36:21 -0700
From: Jeff Parker <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Control vs Client Links in IS-IS TE
Date: Fri, 28 Jun 2002 13:27:08 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Consider a service provider who wishes to distinguish his control traffic
from the network he provides subscribers, by distinguishing his control
links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that
only run customer traffic. 

Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP
to router B.  How can IS-IS distinguish the two types of links if it is
using wide metrics?

In OSPF, we can send an Opaque LSA with info about an LSP.  This will not be
used for the IGP's SPF.  
However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus
looks like a normal link from A to B when the router is using Wide Metrics
in the SPF.  If B also has an LSP to A, other routers will have no way to
distinguish an MPLS LSP link intended for CSPF and those to be used in the
IGP's SPF.  I could imagine using a field such as Switch Capability, to
decide if a link should be included in SPF or not, but haven't seen this
suggested anywhere.  

- jeff parker
- axiowave networks

Delivery-date: Fri, 28 Jun 2002 03:40:35 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-kim-ccamp-gmpls-nsid-00.txt
Date: Fri, 28 Jun 2002 06:35:42 -0400

--NextPart

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

	Title		: A Requirement of the Network State Information 
                          Database for Traffic Engineering Over GMPLS
	Author(s)	: D. Kim
	Filename	: draft-kim-ccamp-gmpls-nsid-00.txt
	Pages		: 17
	Date		: 27-Jun-02
	
This document presents a set of requirements of the Network State 
Information Database (NSID) for Traffic Engineering over Generalized 
Multiprotocol Label Switching (GMPLS). The Network State Information 
Database is required to implement the network architecture for 
network models that introduce the control element of IP and to 
optimize the utilization of network resource. And this document 
includes discussion about the considerations and necessity of the 
several attributes to construct NSID for Traffic Engineering over 
GMPLS that are extended from the requirement for Traffic Engineering 
over MPLS [4]. These attributes can be used to maximize the 
utilization of network resources and to enhance resource oriented 
Traffic Engineering techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-gmpls-nsid-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kim-ccamp-gmpls-nsid-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kim-ccamp-gmpls-nsid-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-kim-ccamp-gmpls-nsid-00.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 28 Jun 2002 02:22:58 -0700
Date: Fri, 28 Jun 2002 11:18:19 +0200
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
Cc: [email-masked], [email-masked], [email-masked]

Hi,

Sorry for the confusion ... I meant:

"Although, this draft fits in MPLS WG, I'm copying CCAMP as some aspects 
are related to the ongoing protection/restoration work done in CCAMP".

And we're still interested by your comments, thanks.

JP.

>Date: Thu, 27 Jun 2002 17:34:22 +0200
>To: [email-masked]
>From: Jean Philippe Vasseur <[email-masked]>
>Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>Cc: [email-masked]
>
>Hi,
>
>This draft proposes a model for the backup tunnel computation to provide 
>bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the 
>capability to provide not only a fast convergence but also bandwidth 
>guaranties while making an efficient backup bandwidth usage.
>
>Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be 
>related to the ongoing protection/restoration work done in CCAMP.
>
>Any comment is of course very welcome.
>
>Thanks.
>
>JP.
>
>>To: IETF-Announce:;
>>CC: [email-masked]
>>From: [email-masked]
>>Reply-to: [email-masked]
>>Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>>Date: Thu, 27 Jun 2002 06:39:03 -0400
>>Sender: [email-masked]
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>
>>         Title           : MPLS Traffic Engineering Fast reroute: backup 
>> tunnel
>>                           path computation for bandwidth protection
>>         Author(s)       : J. Vasseur et al.
>>         Filename        : draft-vasseur-mpls-backup-computation-00.txt
>>         Pages           : 43
>>         Date            : 26-Jun-02
>>
>>This draft proposes an efficient model called ''Facility based
>>computation model'' for computing bypass tunnels paths in the context of
>>the MPLS TE Fast Reroute, while allowing bandwidth sharing between
>>backup tunnel protecting independent resources. Both a centralized and
>>a distributed path computation scenarios are described. The required
>>signaling extensions are also addressed in the draft.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>>
>>To remove yourself from the IETF Announcement list, send a message to
>>ietf-announce-request with the word unsubscribe in the body of the message.
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>         "get draft-vasseur-mpls-backup-computation-00.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>         [email-masked].
>>In the body type:
>>         "FILE 
>> /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt".
>>
>>NOTE:   The mail server at ietf.org can return the document in
>>         MIME-encoded form by using the "mpack" utility.  To use this
>>         feature, insert the command "ENCODING mime" before the "FILE"
>>         command.  To decode the response(s), you will need "munpack" or
>>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>         exhibit different behavior, especially when dealing with
>>         "multipart" MIME messages (i.e. documents which have been split
>>         up into multiple messages), so check your local documentation on
>>         how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>Content-Type: text/plain
>>Content-ID:     <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt>

Delivery-date: Thu, 27 Jun 2002 08:37:54 -0700
Date: Thu, 27 Jun 2002 17:34:22 +0200
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
Cc: [email-masked]

Hi,

This draft proposes a model for the backup tunnel computation to provide 
bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the 
capability to provide not only a fast convergence but also bandwidth 
guaranties while making an efficient backup bandwidth usage.

Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be 
related to the ongoing protection/restoration work done in CCAMP.

Any comment is of course very welcome.

Thanks.

JP.

>To: IETF-Announce:;
>CC: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>Date: Thu, 27 Jun 2002 06:39:03 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : MPLS Traffic Engineering Fast reroute: backup 
> tunnel
>                           path computation for bandwidth protection
>         Author(s)       : J. Vasseur et al.
>         Filename        : draft-vasseur-mpls-backup-computation-00.txt
>         Pages           : 43
>         Date            : 26-Jun-02
>
>This draft proposes an efficient model called ''Facility based
>computation model'' for computing bypass tunnels paths in the context of
>the MPLS TE Fast Reroute, while allowing bandwidth sharing between
>backup tunnel protecting independent resources. Both a centralized and
>a distributed path computation scenarios are described. The required
>signaling extensions are also addressed in the draft.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-vasseur-mpls-backup-computation-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt>

Delivery-date: Thu, 27 Jun 2002 04:19:31 -0700
Date: Thu, 27 Jun 2002 20:15:54 +0900
From: Eiji Oki <[email-masked]>
To: [email-masked]
Subject: Fw: I-D ACTION:draft-oki-ccamp-upstream-labelset-00.txt

--------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

A new draft on Upstream Label Set was posted in the following.
This draft describes an extended version of the bi-directional path setup 
RSVP-TE signaling procedure by using a new Upstream Label Set Object. 
The proposed procedure is useful in limited/non-wavelength-convertible 
optical networks, while it is consistent with the current version of the 
GMPLS RSVP-TE signaling.

Your comments are appreciated.

Thank you.
Eiji

--
Eiji Oki
NTT Network Innovation Laboratories
3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
TEL: +81-422-59-3441  FAX: +81-422-59-6387
E-mail: [email-masked]

----------------------- Original Message -----------------------
From:    [email-masked]
To:      IETF-Announce: ;
Date:    Thu, 27 Jun 2002 06:41:36 -0400
Subject: I-D ACTION:draft-oki-ccamp-upstream-labelset-00.txt
----

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

	Title		: Upstream Label Set Support in RSVP-TE extensions
	Author(s)	: E. Oki
	Filename	: draft-oki-ccamp-upstream-labelset-00.txt
	Pages		: 7
	Date		: 26-Jun-02
	
This document describes extensions to GMPLS RSVP-TE signaling required
to support a upstream label set when a bidirectional path is set up.  In
the existing drafts on GMPLS RSVP-TE signaling, a upstream label for the
upstream path has to be reserved at an intermediate node before Path
message is transmitted to the next-hop node. On the other hand, a label
set that includes one or more labels for the downstream path is carried
by Path message and then Resv message reserves a label at each interme-
diate node on the route or a source node.  This document proposes the
way to support the upstream label set as is the case of the Label Set
for downstream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-oki-ccamp-upstream-labelset-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------------- Original Message Ends --------------------

--------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
Content-Transfer-Encoding: 7bit

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server"; server="[email-masked]"
Content-Transfer-Encoding: 7bit

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

ENCODING mime
FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt

--OtherAccess
Content-Type: Message/External-body; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"; name="draft-oki-ccamp-upstream-labelset-00.txt"
Content-Disposition: attachment;
 filename="draft-oki-ccamp-upstream-labelset-00.txt"
Content-Transfer-Encoding: 7bit

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

--OtherAccess--

--------_3D1AF0C0B4E208FF8FF8_MULTIPART_MIXED_--

Delivery-date: Thu, 27 Jun 2002 03:45:42 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-oki-ccamp-upstream-labelset-00.txt
Date: Thu, 27 Jun 2002 06:41:36 -0400

--NextPart

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

	Title		: Upstream Label Set Support in RSVP-TE extensions
	Author(s)	: E. Oki
	Filename	: draft-oki-ccamp-upstream-labelset-00.txt
	Pages		: 7
	Date		: 26-Jun-02
	
This document describes extensions to GMPLS RSVP-TE signaling required
to support a upstream label set when a bidirectional path is set up.  In
the existing drafts on GMPLS RSVP-TE signaling, a upstream label for the
upstream path has to be reserved at an intermediate node before Path
message is transmitted to the next-hop node. On the other hand, a label
set that includes one or more labels for the downstream path is carried
by Path message and then Resv message reserves a label at each interme-
diate node on the route or a source node.  This document proposes the
way to support the upstream label set as is the case of the Label Set
for downstream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-oki-ccamp-upstream-labelset-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-oki-ccamp-upstream-labelset-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-oki-ccamp-upstream-labelset-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 27 Jun 2002 02:25:26 -0700
Date: Thu, 27 Jun 2002 18:20:02 +0900
To: [email-masked]
From: MATSUURA Nobuaki <[email-masked]>
Subject: Fwd: I-D ACTION:draft-matsuura-reverse-lsp-00.txt

F.Y.I.

Any comments, please.

 >To: IETF-Announce: ;
 >From: [email-masked]
 >Reply-to: [email-masked]
 >Subject: I-D ACTION:draft-matsuura-reverse-lsp-00.txt
 >Date: Mon, 24 Jun 2002 07:48:13 -0400
 >Sender: [email-masked]
 >
 >A New Internet-Draft is available from the on-line Internet-Drafts directories.
 >
 >
 >	Title		: Signaling Reverse-directional LSP in Generalized MPLS
 >	Author(s)	: N. Matsuura, E. Oki
 >	Filename	: draft-matsuura-reverse-lsp-00.txt
 >	Pages		:
 >	Date		: 21-Jun-02
 >
 >Generalized MPLS extends the MPLS control plane to encompass
 >bidirectional LSPs. This document defines related extensions to
 >Generalized MPLS signaling to support the establishment of
 >reverse-directional LSPs. This document presents a functional
 >description of the extensions for signaling reverse-directional
 >LSPs.
 >
 >A URL for this Internet-Draft is:
 >http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt
 >
 >To remove yourself from the IETF Announcement list, send a message to
 >ietf-announce-request with the word unsubscribe in the body of the message.
 >
 >Internet-Drafts are also available by anonymous FTP. Login with the username
 >"anonymous" and a password of your e-mail address. After logging in,
 >type "cd internet-drafts" and then
 >	"get draft-matsuura-reverse-lsp-00.txt".
 >
 >A list of Internet-Drafts directories can be found in
 >http://www.ietf.org/shadow.html
 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >
 >
 >Internet-Drafts can also be obtained by e-mail.
 >
 >Send a message to:
 >	[email-masked].
 >In the body type:
 >	"FILE /internet-drafts/draft-matsuura-reverse-lsp-00.txt".
 >
 >NOTE:	The mail server at ietf.org can return the document in
 >	MIME-encoded form by using the "mpack" utility.  To use this
 >	feature, insert the command "ENCODING mime" before the "FILE"
 >	command.  To decode the response(s), you will need "munpack" or
 >	a MIME-compliant mail reader.  Different MIME-compliant mail readers
 >	exhibit different behavior, especially when dealing with
 >	"multipart" MIME messages (i.e. documents which have been split
 >	up into multiple messages), so check your local documentation on
 >	how to manipulate these messages.
 >
 >
 >Below is the data which will enable a MIME compliant mail reader
 >implementation to automatically retrieve the ASCII version of the
 >Internet-Draft.
 >Content-Type: text/plain
 >Content-ID:	<[email-masked]>
 >
 >ENCODING mime
 >FILE /internet-drafts/draft-matsuura-reverse-lsp-00.txt
 >
 ><ftp://ftp.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-00.txt> 

Delivery-date: Wed, 26 Jun 2002 03:45:46 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-aboulmagd-ccamp-crldp-ason-ext-00.txt
Date: Wed, 26 Jun 2002 06:41:08 -0400

--NextPart

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

	Title		: CR-LDP Extensions for ASON
	Author(s)	: O. Aboul-Magd
	Filename	: draft-aboulmagd-ccamp-crldp-ason-ext-00.txt
	Pages		: 10
	Date		: 25-Jun-02
	
This draft considers CR-LDP extensions for the support of the ITU 
ASON architecture (G.8080) [2] and its signaling requirements 
(G.7713) [3]. 
The CCAMP WG charter includes the statement: 
'Define signalling protocols and measurement protocols such that 
they support multiple physical path and tunnel technologies (e.g. O-
O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, 
GRE) using input from technology-specific working groups such as 
MPLS, IPO, etc.' 
This draft is within the CCAMP charter since it defines extensions 
to a CCAMP-defined signaling protocol, namely CR-LDP, for transport 
network tunnels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-aboulmagd-ccamp-crldp-ason-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-aboulmagd-ccamp-crldp-ason-ext-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 26 Jun 2002 01:48:21 -0700
From: "Sushanthm" <[email-masked]>
To: <[email-masked]>
Subject: ERO doubt
Date: Wed, 26 Jun 2002 14:16:03 +0530

In the section 6.0, draft-ietf-mpls-generalized-signaling-08.txt

The ERO objects or ER-hop ( IP addr ) includes particular node/interface's
for a desired  LSP.
Is it the data interface or the control interface?

In optical domain,especially Lamda interface, is it only Strict routes are
supported?

Regards,
Sushanth

Delivery-date: Tue, 25 Jun 2002 08:57:27 -0700
From: Jonathan Lang <[email-masked]>
To: [email-masked]
Cc: Ron Bonica <[email-masked]>, "Kireeti Kompella (E-mail)" <[email-masked]>
Subject: Protection and Restoration Design Team drafts
Date: Tue, 25 Jun 2002 08:44:40 -0700

In addition to the updates to the Protection and Restoration analysis draft
(draft-papadimitriou-ccamp-gmpls-recovery-analysis-01.txt) and terminology
draft (draft-ietf-gmpls-recovery-terminology-01.txt), the Protection and
Restoration design team has also produced a first version of the functional
spec which can be found at
http://www.cs.odu.edu/~sudheer/draft-bala-gmpls-recovery-functional-00.txt.

We welcome your comments on the drafts.

Thanks,

GMPLS P&R Design team

Delivery-date: Tue, 25 Jun 2002 04:07:26 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ozugur-ccamp-gmpls-label-flag-00.txt
Date: Tue, 25 Jun 2002 07:02:09 -0400

--NextPart

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

	Title		: Label Set Priority and Flagging Operations
	Author(s)	: T. Ozugur, D. Papadimitriou
	Filename	: draft-ozugur-ccamp-gmpls-label-flag-00.txt
	Pages		: 9
	Date		: 24-Jun-02
	
This document presents the GMPLS Signaling mechanisms referred to as
generalized label flagging method, and RSVP-TE/CR-LDP specific
signaling extensions formats needed to ease forward-link label
unavailability when the downstream label selection is restricted by
the upstream node using the Label Set. It also relaxes backward-link
label collision when the downstream label collides with competing
label selection. This method introduces the Flagged Label Set
object/TLV in order to prioritize the reservation of the labels
included in the Label Set enabling to decrease the forward- and
backward-link blocking probability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ozugur-ccamp-gmpls-label-flag-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ozugur-ccamp-gmpls-label-flag-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ozugur-ccamp-gmpls-label-flag-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ozugur-ccamp-gmpls-label-flag-00.txt

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 24 Jun 2002 12:23:02 -0700
Date: Mon, 24 Jun 2002 15:05:15 -0400
To: :
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: draft-ietf-ccamp-gmpls-lsr-mib-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

	Hi,

	FYI, we were unable to post the CCAMP GMPLS LSR MIB
by the deadline, so it is available here until after the next
meeting:

ftp://[email-masked]/tnadeau/draft-ietf-ccamp-gmpls-lsr-mib-00.txt

	Please review the GMPLS-LSR and other GMPLS MIBs
and send feedback to the CCAMP mailing list. The documents
just published reflect the discussion we had during the
last CCAMP WG meeting in Minnesota.

Abstract

    This memo defines a portion of the Management Information
    Base (MIB) for use with network management protocols in
    the Internet community.  In particular, it describes
    managed objects for Generalized Multiprotocol Label
    Switching (GMPLS) Label Switched Routers (LSRs).

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 

Delivery-date: Mon, 24 Jun 2002 04:47:24 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-02.txt
Date: Mon, 24 Jun 2002 07:46:16 -0400

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-signaling-survey-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 24 Jun 2002 04:42:23 -0700
Cc: [email-masked]
Date: Mon, 24 Jun 2002 13:37:30 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: [email-masked], [email-masked], [email-masked]
Original-CC: [email-masked]
Subject: Re: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt

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

Hello Jonathan, John, Dimitri,

I'm surprised about the draft "Control Channel Bootstrap for LMP".
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

It seems somewhat premature to introduce the need to bootstrap a
control channel when the control channel concept is apparently not
clear.

* Does a control network consist of DCC-like control channels ?

* Is a control channel an IP tunnel on top of an existing
  control network (e.g. PPP-over-IP, RFC-2661) ?
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html

* Is a control network an instantiation of a control channel ?
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00835.html

With the help of Greg Bernstein, I've tried to rewrite the LMP
draft (see attached file). This update proposal seems to provide
the intended functionality without the need for a control channel.

Hopefully this update proposal gives more clarification on what
I intended to say with my email of April 9.
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html

Best regards,

Michiel

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Control Channel Bootstrap for LMP
>         Author(s)       : J. Lang, J. Drake
>         Filename        : draft-lang-ccamp-lmp-bootstrap-00.txt
>         Pages           : 7
>         Date            : 10-Jun-02
> 
> The Link Management Protocol (LMP) requires that at least one bi-
> directional control channel is established between the nodes. The
> control channel may be transmitted either in-band with the data
> links or out-of-band over a separate wavelength, fiber, or IP
> network. This draft specifies a simple procedure to dynamically
> bootstrap control channels and exchange interface mappings using a
> new LMP message that is transmitted in-band over the data links.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-lang-ccamp-lmp-bootstrap-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+
--------------1B116D1A6A920265DE0478CD
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-everdingen-ccamp-lmp-update-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="draft-everdingen-ccamp-lmp-update-00.txt"

CCAMP Working Group                              Michiel van Everdingen =

Internet Draft                                    (Lucent Technologies) =

Expiration Date: December 2002       Greg Bernstein (Ciena Corporation) =

                                                                        =

 =

                                                               June 2002 =

                    Link Management Protocol Update =

    =

                draft-everdingen-ccamp-lmp-update-00.txt =

 =

 =

Status of this Memo =

    =

   This document is an Internet-Draft and is in full conformance with =

   all provisions of Section 10 of RFC2026 [RFC2026]. =

    =

   Internet-Drafts are working documents of the Internet Engineering =

   Task Force (IETF), its areas, and its working groups.  Note that =

   other groups may also distribute working documents as Internet-
   Drafts.  =

    =

   Internet-Drafts are draft documents valid for a maximum of six months =

   and may be updated, replaced, or obsoleted by other documents at any =

   time.  It is inappropriate to use Internet- Drafts as reference =

   material or to cite them other than as "work in progress."  =

    =

   The list of current Internet-Drafts can be accessed at =

   http://www.ietf.org/ietf/1id-abstracts.txt  =

    =

   The list of Internet-Draft Shadow Directories can be accessed at =

   http://www.ietf.org/shadow.html. =

    =

    =

Abstract =

    =

   Optical networks are being developed to include photonic switches, =

   optical crossconnects, SONET/SDH crossconnects and routers.  These =

   networks consist of data links and a logically separated control =

   network.  Furthermore, multiple data links may be combined to form a =

   single traffic engineering (TE) link for routing purposes.  This =

   draft proposes an update of the Link Management Protocol LMP. LMP =

   runs between neighboring nodes (regarding data links) and is used to =

   manage TE links.  Specifically, LMP can be used to discover and =

   verify the physical connectivity of the data links, correlate the =

   data link property information, suppress downstream alarms, and =

   localize link failures for protection/restoration purposes in GMPLS =

   switched networks. =

  =

Everdingen et al                                              [Page 1] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

Table of Contents =

   1.  Introduction..................................................3 =

   2.  LMP Overview..................................................6 =

   3.  Neighbor Discovery............................................8 =

   4.  Link Property Correlation....................................12 =

   5.  Verifying Data Link Connectivity.............................14 =

      5.1. Example of Link Connectivity Verification................16 =

   6.  Fault Management.............................................18 =

      6.1. Fault Detection..........................................19 =

      6.2. Fault Localization Procedure.............................19 =

      6.3. Examples of Fault Localization...........................19 =

   7.  Addressing...................................................23 =

   8.  LMP Authentication...........................................23 =

   9.  IANA Considerations..........................................23 =

   10. LMP Finite State Machines....................................24 =

      10.1. TE Link FSM.............................................24 =

      10.2. Data Link FSM...........................................25 =

   11. LMP Message Formats..........................................29 =

      11.1. Common Header...........................................29 =

      11.2. LMP Object Format.......................................30 =

      11.3. Authentication..........................................31 =

      11.4. Link Verification.......................................33 =

      11.5. Link Summary Messages...................................36 =

      11.6. Fault Management Messages...............................37 =

   12. LMP Object Definitions.......................................39 =

      12.1. NODE_ID Classes.........................................39 =

      12.2. LINK _ID Classes........................................40 =

      12.3. INTERFACE_ID Classes....................................41 =

      12.4. MESSAGE_ID Class........................................41 =

      12.5. MESSAGE_ID_ACK Class....................................42 =

      12.6. BEGIN_VERIFY Class......................................42 =

      12.7. BEGIN_VERIFY_ACK Class..................................43 =

      12.8. VERIFY_ID Class.........................................43 =

      12.9. TE_LINK Class...........................................43 =

      12.10. DATA_LINK Class........................................44 =

      12.11. CHANNEL_STATUS Class...................................48 =

      12.12. CHANNEL_STATUS_REQUEST Class...........................49 =

      12.13. ERROR_CODE Class.......................................49 =

   13. Security Considerations......................................51 =

   14. References...................................................51 =

   15. Authors' Addresses...........................................52 =

  =

Everdingen et al                                              [Page 2] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   Changes compared to [LMP] =

    =

   - Removed the concept "control channel". =

   - Removed possibility of (UDP over HDLC encoded) test messages to =

     be directly sent on DCC channels, bypassing the DCN network  =

   - Included optional procedure for neighbor discovery. =

   - Made clear that LMP's fault management procedure implements =

     a tandem connection monitoring function. =

   - Several editorial changes (a.o. in abstract and introduction) =

 =

1. Introduction  =

 =

   Optical network elements can use a common control plane like GMPLS to =

   dynamically allocate resources and to provide network survivability =

   using protection and restoration techniques.  These optical network =

   elements form together an optical network. =

    =

   Optical networks consist of several layer networks.  The main layers =

   are: =

   -   OC-N / STM-N: a layer consisting of OC-N/SMN-N data links =

   -  STS-N / HO-VC: a layer consisting of STS-N/HO-VC data links =

   - VT-1.5 / LO-VC: a layer consisting of VT-1.5/LO-VC data links =

    =

   As seen from a single layer network, three functions are of interest: =

   - Optical Switching (OXC) =

   - Optical Multiplexing (MUX) =

   - Optical Termination (TRM). =

    =

   From an OC-N, STM-n perspective: =

   - Optical Line Systems (OLS) contain the MUX function: these systems =

     multiplex OC-n/STM-n signals into a DWDM signal. =

   - Fully transparent optical cross connects contain the OXC function. =

   - SONET/SDH ADMs and IP Routers contain the TRM function. =

    =

   From an HO-VC, STS-N perspective: =

   - Optical Line Systems (OLS) are not visible. =

   - Fully transparent optical cross connects are not visible. =

   - SONET/SDH ADMs contain the OXC, MUX and TRM functions. =

   - IP Routers contain the TRM function. =

     =

   In the remainder of this document, we will refer to these optical =

   functions (OXC, MUX and TRM) as 'nodes'. =

    =

   LMP can be used for any type of optical network element, regardless =

   if the network combines an OXC and a MUX function or not. =

    =

   A pair of nodes (e.g., two OXCs) may be connected by thousands of =

   fibers.  In this document, these fibers are more generally called =

   data links.  Note that these data links may be multiplexed together =

   in multiplexing systems.  Furthermore, independently of this =

   multiplexing, multiple data links may be combined into a single =

   traffic-engineering (TE) link for routing purposes. =

  =

Everdingen et al                                              [Page 3] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   To enable communication between nodes for routing, signaling, and =

   link management, a control network must be present that connects =

   every pair of nodes that are neighbors regarding data links. =

    =

   This draft specifies an update of the link management protocol [LMP]. =

   LMP runs between neighboring nodes (neighboring regarding the data =

   links) and is used to manage TE links; see Figure 1. =

    =

               +------+       +------+       +------+       +------+  =

               |      | ----- |      | ----- |      | ----- |      |  =

               | TRM1 | ----- | OXC1 | ----- | OXC2 | ----- | TRM2 |  =

               |      | ----- |      | ----- |      | ----- |      |  =

               +------+       +------+       +------+       +------+  =

                     ^          ^  ^           ^  ^           ^ =

                     |          |  |           |  |           | =

                     +----LMP---+  +----LMP----+  +---LMP-----+ =

                            Figure 1: LMP Model =

 =

   Note that LMP runs between nodes that are either =

   - Terminating the data link (TRM1 and TRM2) or =

   - Cross connecting the data link (OXC1 and OXC2). =

    =

   Note furthermore that LMP does not consider multiplexing nodes that =

   multiplex the data link (see Figure 2).  A companying draft [LMP-
   DWDM] specifies the protocol to be used between OXC and MUX. =

    =

               +------+       +------+       +------+       +------+  =

               |      | ----- |      |       |      | ----- |      |  =

               | OXC1 | ----- | MUX1 | =3D=3D=3D=3D=3D | MUX2 | ----- | O=
XC2 |  =

               |      | ----- |      |       |      | ----- |      |  =

               +------+       +------+       +------+       +------+  =

                 ^                                               ^     =

                 |                                               |     =

                 +----------------------LMP----------------------+   =

                   Figure 2: LMP and Multiplexing nodes =

    =

    =

   In GMPLS, the control network between two neighboring nodes is no =

   longer required to use the same physical medium as the data links =

   between those nodes.  For example, a control network could use =

   separate wavelengths, fibers or Ethernet links and may contain IP =

   routers that are not involved in any operation on the data links. =

    =

   A consequence of allowing the control network to be physically =

   diverse from the associated data links is that the health of this =

   control network does not necessarily correlate to the health of the =

   data links, and vice-versa.  Therefore, a clean separation between =

   the fate of the control network and data links must be made. =

    =

  =

Everdingen et al                                              [Page 4] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   Each of the two end-points of a data link will be either a TTP or a =

   CTP, depending on its multiplexing capability.  A TTP, which resides =

   in a TRM node, terminates the data link.  A CTP, which resides in an =

   OXC node, transparently cross connects the signal on the data link. =

    =

   The distinction between TTP and CTP is important since the management =

   of the data-bearing links (including, for example, discovery and =

   verification) is different based on the type of end-points connected. =
 =

   For example, a SONET crossconnect is a TTP for an OC-192 data link.  =

   This implies that, for this data link, the SONET crossconnect will =

   always send out the same access point identifier in the in-band J0 =

   signal.  In contrast, a photonic cross connect, which is a CTP for an =

   OC-192 data link, may use the in-band J0 signal as a kind of "test-
   signal". =

    =

   If data links are grouped together into a single TE link using link =

   bundling [BUNDLE], then the link resources must be identified using =

   two levels: TE link Id, and interface Id (an Id of the data link =

   within the TE link).  Resource allocation happens at the lowest level =

   (the data links). =

    =

   LMP is designed to support aggregation of one or more data-bearing =

   links into a TE link (either ports into TE links, or component links =

   into TE links).  The purpose of forming a TE link is to group/map the =

   information about certain physical resources (and their properties) =

   into the information that is used by Constrained SPF for the purpose =

   of path computation, and by GMPLS signaling. =

     =

  =

Everdingen et al                                              [Page 5] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

2. LMP Overview  =

 =

   The core procedure of LMP is link property correlation.  Link =

   property correlation is used to synchronize the TE link properties =

   and verify configuration. =

    =

   An "LMP adjacency" is present between two nodes that are neighbors =

   regarding a data link.  LMP provides an optional procedure to =

   automatically discover the connectivity of the data links, but this =

   connectivity can also be manually provisioned. =

 =

   The link property correlation function of LMP is designed to =

   aggregate multiple data links into a TE link and to synchronize the =

   properties of the TE link.  As part of the link property correlation =

   function, a LinkSummary message exchange is defined.  The LinkSummary =

   message includes the local and remote TE Link Ids, a list of all data =

   links that comprise the TE link, and various link properties.  A =

   LinkSummaryAck or LinkSummaryNack message MUST be sent in response to =

   the receipt of a LinkSummary message indicating agreement or =

   disagreement on the link properties.  =

    =

   In this draft, two additional LMP procedures are defined: link =

   connectivity verification and fault management.  Link connectivity =

   verification is used to verify the continued physical connectivity of =

   the data links between the nodes.  The link verification procedure =

   uses a test signal that is sent over the data links and TestStatus =

   messages that are transmitted back over the control network. =

    =

   Fault management is used to localize a fault to a specific data link. =

   By means of this procedure, an OXC or TRM node can detect if an =

   incoming signal fault is caused by a fault on the incoming data link =

   or is caused by a fault further in the upstream direction. =

    =

   The LMP fault management procedure is based on a ChannelStatus =

   exchange using the following messages: ChannelStatus, =

   ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.  =

   The ChannelStatus message is sent unsolicitated and is used to notify =

   an LMP neighbor about the status of one or more data links of a TE =

   link.  The ChannelStatusAck message is used to acknowledge the =

   receipt of the ChannelStatus message.  The ChannelStatusRequest =

   message is used to query an LMP neighbor for the status of one or =

   more data channels of a TE Link.  The ChannelStatusResponse message =

   is used to acknowledge receipt of the ChannelStatusRequest message =

   and indicate the states of the queried data links. =

    =

   All LMP messages are UDP encoded.  This implies that the control =

   network must provide a UDP service. =

    =

   LMP messages are transmitted reliably over the control network using =

   Message Ids and retransmissions.  Message Ids are carried in =

   MESSAGE_ID objects.  No more than one MESSAGE_ID object may be =

   included in an LMP message.  The Message Id is always within the =

  =

Everdingen et al                                              [Page 6] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   scope of the LMP adjacency.  The value of the Message Id is =

   monotonically increasing and only decreases when the value wraps. =

    =

   In addition to these UDP based LMP messages, LMP uses the in-band =

   "access point identifier" for neighbor discovery and link =

   verification. =

    =

   The organization of the remainder of this document is as follows.  In =

   Section 3, a method is presented to discover the connectivity of the =

   data links.  In Section 4, the link property correlation function =

   using the LinkSummary message exchange is described.  The link =

   verification procedure is discussed in Section 5.  In Section 6, it =

   is shown how LMP can be used to isolate TE link and data link =

   failures within the optical network.  Sections 7, 8 and 9 describe =

   the usage of message identifiers, graceful restart and addressing =

   respectively.  Several finite state machines (FSMs) are given in =

   Section 12. The message formats and object definitions are defined in =

   Section 13 and 14 respectively. =

 =

  =

Everdingen et al                                              [Page 7] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

3. Neighbor Discovery =

    =

   In this section, an optional LMP procedure is described to =

   automatically detect the identification of the other end of a data =

   link in the upstream direction.  In other words the neighbor =

   discovery procedure automatically detects the association <local =

   Node_Id, local Interface_Id, remote Node_Id, remote Interface_Id>.  =

   The neighboring node in the upstream direction is informed of this =

   association by means of the subsequent link correlation procedure. =

    =

   The optional neighbor discovery as described in this section uses the =

   capability of optical systems to carry an in-band "access point =

   identifier" [G707].  Alternative discovery procedures that do not =

   require the usage of this access point identifier are described in =

   [OIF-UNI] and in [NDP-PPP].  These procedures use the line or section =

   DCC (data communications channel) and are especially useful in case =

   the access point identifier is not available for use, i.e., =

   prohibited by the carrier, or in accessible by the equipment.  These =

   alternative discovery procedures are applicable in case the data link =

   is an STM-N, OC-N and STS-1/3/.../VC-3/4/...; they are not applicable =

   in case the data link is an VT-1.5, VC-11 or VC-12 data link. =

    =

   Basically, automatic neighbor discovery as described in this section =

   is implemented by reading the incoming access point identifier. =

    =

   A Sub-Network Point (TTP or CTP) that implements the automatic =

   neighbor discovery procedure MUST send its identification in the =

   access point identifier in a signal present on the data link. =

    =

   In case the Sub-Network Point is a TTP, the access point identifier =

   is sent continuously.  In case the Sub-Network Point is a CTP, the =

   access point identifier is sent in any test signal, e.g. the =

   supervisory unequipped signal (see [G707] and [G783]). =

    =

   The access point identifier is encoded in a specific byte in the data =

   link according to the table below: =

    =

   Data link type          Access point identifier to be used =

   --------------          ---------------------------------- =

   STM-N, OC-N                            J0 =

   STS-1/3/.../VC-3/4/...                 J1 =

   VT-1.5/VC-11/12                        J2 =

    =

   In case an IPv4 control network is used, the identification SHOULD be =

   formatted into 16 bytes as follows ([OIF 2000.159.01]): =

    =

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ =

   | 1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16| =

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ =

   |CRC|Typ|Dis|       Node Identifier         | I'face Identifier | =

   +---+---+---+-------------------------------+-------------------+ =

  =

Everdingen et al                                              [Page 8] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

          Figure 3: format of the access point identifier to =

                  enable automatic neighbor discovery =

    =

   The format as specified in Figure 3 is in line with the specification =

   in [G707].  This SDH standard places the most stringent constraints =

   on the contents of the access point identifiers. =

    =

   A Sub-Network Point (TTP or CTP) MAY also use an alternative format =

   for the access point identifier, e.g. the one specified in G.831, =

   Appendix I.  In this case, discovery of the address of the sending =

   access point will need involvement of a 'name server'.  In case an =

   IPv6 control network is used, the neighbor discovery scheme MUST =

   follow this approach. =

    =

   According to [G707], all entries in the access point identifier in =

   the are are formatted printable 7 bit encoded ASCII characters =

   (except for the CRC field).  In case the access point identifier is =

   formatted according to Figure 3, the fields have the following =

   interpretation: =

    =

   CRC =

      The CRC-7 code of the previous frame as specified in G.707. =

    =

   Typ =

      The "type indicator" informs the receiver of the sender's role. =

      Values are: =

      "T": Trail Termination Point =

      "C": Connection Termination Point =

    =

   Dis =

      The "distinguishing identifier" avoids the proposed format to be =

      confused with some other optional format, e.g. the format =

      specified in G.831, Appendix I. =

      Value: =

      "@" =

    =

   Node Identifier =

      The "node identifier" is the IPv4 address that identifies the =

      sending Node_Id. The IPv4 address is encoded in 8 hex characters. =

    =

   I'face Identifier =

      The "Interface Identifier" identifies the sender's Interface_Id in =

      hex format. This gives port numbers 0-FFFFF (1,048,575) which =

      should be enough for all types of Network Elements. =

    =

    =

   As an example, a node with IP address 192.168.2.23 would sent out the =

   following access point identifier (excluding the CRC) from a TTP with =

   local interface id 421: =

      T@C0A80217001A5 =

    =

  =

Everdingen et al                                              [Page 9] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   A sending TTP that implements the automatic neighbor discovery scheme =

   will continuously send out its own identification.  This is according =

   to [G831], "the access point identifier should not change while the =

   access point remains in existence". =

    =

   A sending CTP that implements the automatic neighbor discovery scheme =

   MUST send its identification as long as it has not received a =

   linkSummary message indicating that the associated receiver has =

   discovered this sending CTP.  The CTP MAY send its identification =

   continuously, until it is discovered.  The CTP MAY also send its =

   identification in intervals, until it is discovered. =

    =

   Example: Figure 4 shows 4 nodes and a single data link between these =

   nodes.  Two nodes terminate the data link on interfaces marked with =

   'T' (TTP).  Two other nodes are transparent to the data link on =

   interfaces marked with 'C' (CTP). =

    =

   Note that neighbor discovery is defined per datalink, so the actual =

   number of datalinks per NE is not relevant. =

    =

   +------+      +------+      +------+      +------+ =

   |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    | =

   |      |   A  |      |   B  |      |   C  |      | =

   |      |      |      |      |      |      |      | =

   | TRM1 |      | OXC1 |      | OXC2 |      | TRM2 | =

   +------+      +------+      +------+      +------+ =

               Figure 4: automatic discovery example - 1 =

    =

   OXC1 should, when it wants to discover data link B, connect a test-
   set that sends an access point identifier to identify the sending =

   connection point C in OXC1.  This test-signal should be send long =

   enough for OXC2 to detect and read the test-signal.  OXC2 will =

   continuously scan all its not discovered input ports for a discovery =

   signal. =

    =

   At some point, OXC2 will detect the test-signal on data link B.  See =

   Figure 5. =

    =

    =

   +------+      +------+      +------+      +------+ =

   |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    | =

   |      |   A  |   /  |   B  |  \   |   C  |      | =

   |      |      |  T   |      |   T  |      |      | =

   | TRM1 |      | OXC1 |      | OXC2 |      | TRM2 | =

   +------+      +------+      +------+      +------+ =

               Figure 5: automatic discovery example - 2 =

    =

   When OXC2 has read the access point identifier in the test signal, =

   data link B is discovered.  Subsequent link property correlation can =

   then be invoked. =

  =

Everdingen et al                                             [Page 10] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   Discovery of data link A is similar, except that the access point =

   identifier is continuously sent.  Discovery of data link C is also =

   similar, except that the access point identifier is continuously =

   monitored.  In other words, there is no need for a sending =

   respectively monitoring 'test-set' in TRM1 and TRM2. =

    =

    =

  =

Everdingen et al                                             [Page 11] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

4. Link Property Correlation =

    =

   As part of LMP, a link property correlation exchange is defined for =

   TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack =

   messages.  The contents of these messages are built using LMP =

   objects, which can be either negotiable or non-negotiable (identified =

   by the N flag in the Object header).  Negotiable objects can be used =

   to let both sides agree on certain link parameters.  Non-negotiable =

   objects are used for announcement of specific values that do not =

   need, or do not allow, negotiation. =

    =

   Each TE link has an identifier (Link_Id) that is assigned at each end =

   of the link. =

     =

   The TE-link is only considered to be 'up' in case a linkSummaryAck =

   message is received that indicates that the neighboring node agreed =

   on the current TE-link configuration.  See also section 12.1. =

    =

   Next to this usage for the initial agreement on the TE-link =

   configuration, link property correlation MAY be done at any time a =

   link is 'up'. =

    =

   The LinkSummary message is used to verify the consistency of the TE-
   link and containing data links on both sides.  I.e. Link Summary =

   messages are used to =

   - Check bi-directional connectivity of the data links =

   - Exchange and correlate data link parameters =

   - Exchange and correlate TE link parameters =

   - Agree on the aggregation of multiple data links into one TE link =

    =

   The LinkSummary message includes a TE_LINK object followed by one or =

   more DATA_LINK objects.  The TE_LINK object identifies the TE link's =

   local and remote Link Id and indicates support for fault management =

   and link verification procedures for that TE link.  The DATA_LINK =

   objects are used to characterize the data links that comprise the TE =

   link.  These objects include the local and remote Interface Ids, and =

   may include one or more subobjects further describing the properties =

   of the data links. =

    =

   If the LinkSummary message is received from a remote node and the =

   Interface Id mappings match those that are stored locally, then the =

   two nodes have agreement on the verification procedure (see Section =

   5) and the configuration of the data links.  If the verification =

   procedure is not used, the LinkSummary message can be used to verify =

   agreement on manual configuration. =

    =

   The LinkSummaryAck message is used to signal agreement on the =

   Interface Id mappings and link property definitions.  Otherwise, a =

   LinkSummaryNack message MUST be transmitted, indicating which =

   Interface mappings are not correct and/or which link properties are =

   not accepted. =

    =

  =

Everdingen et al                                             [Page 12] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   If a LinkSummaryNack message indicates that the Interface Id mappings =

   are not correct and the link verification procedure is enabled, the =

   link verification process SHOULD be repeated for all mismatched free =

   data links. =

    =

   If a LinkSummaryNack message includes negotiable parameters, then =

   acceptable values for those parameters MUST be included.  If a =

   LinkSummaryNack message is received and includes negotiable =

   parameters, then the initiator of the LinkSummary message SHOULD send =

   a new LinkSummary message.  The new LinkSummary message SHOULD =

   include new values for the negotiable parameters.  These values =

   SHOULD take into account the acceptable values received in the =

   LinkSummaryNack message. =

    =

    =

  =

Everdingen et al                                             [Page 13] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

5. Verifying Data Link Connectivity =

    =

   In this section, an optional procedure is described that may be used =

   to verify the physical connectivity of the data-bearing links.  The =

   procedure SHOULD be done any time there is uncertainty about the =

   continued connectivity of the data-bearing links, e.g. after a data =

   link failure.  The procedure MAY be done on a periodic basis for all =

   unallocated (free) data links of the TE link. =

    =

   Note that verification of the data links is only done after the data =

   links have been discovered and correlated. =

    =

   The discovery procedure as described in this section uses the in-band =

   access point identifier.  Because the discovery procedure uses the =

   access point identifier, it is only applicable for CTP-->--CTP and =

   CTP-->--TTP data links.  The verify procedure is not applicable for =

   TTP-->--CTP and TTP-->--TTP data links: TTPs constantly send out =

   their identification in-band.  In other words, a TRM node does not =

   need to explicitly send a "beginVerify" message to its LMP adjacency =

   as this neighboring node can at any time verify the connectivity of =

   the data link  (by reading the access point identifier). =

    =

   Other verification procedures may be negotiated as part of the link =

   property correlation.  Specific flags in the TE_Link object can be =

   used for this purpose.  At the moment, only a flag value is defined =

   for the verification method as described in this section. =

    =

   If a BeginVerify message is received and link verification is not =

   supported for the TE link, then a BeginVerifyNack message MUST be =

   transmitted with Error Code =3D 1, "Link Verification Procedure not =

   supported for this TE Link". =

    =

   If a BeginVerifyAck message is received, the local (transmitting) =

   node sends the an in-band test signal over the corresponding data =

   link(s).  The only relevant information in this test signal is the =

   access point identifier.  This access point identifier is formatted =

   according to format of the discovery message (see Figure 3). =

    =

   A characteristic of CTPs (points at an OXC node) is that the data =

   links are transparent when allocated to user traffic.  This =

   characteristic poses a challenge for validating the connectivity of =

   the data links.  Therefore, to ensure proper verification of data =

   link connectivity, it is required that a test-set is available to =

   send and receive an in-band test signal at times the data link is not =

   allocated for use traffic.  In other words, the test-set must be able =

   to terminate the test signal. =

    =

   The local (transmitting) node sends the test signal on the =

   corresponding data link until (1) it receives a correlating =

   TestStatusSuccess or TestStatusFailure message on the control network =

   from the remote (receiving) node or (2) a timeout occurs.  The remote =

   node will send a given TestStatus message periodically over the =

  =

Everdingen et al                                             [Page 14] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   control network until it receives either a correlating TestStatusAck =

   message or an EndVerify message is received over the control network. =

    =

   There is no requirement that all data links be terminated =

   simultaneously, but at a minimum, the network element MUST be able to =

   terminate the data links one at a time. =

    =

   For link verification, a TE link MUST include at least one data link. =
 =

   Furthermore, link verification will only succeed if the neighbors =

   regarding the data link have connectivity over the control plane. =

    =

   To initiate the link verification procedure, the local node MUST send =

   a BeginVerify message over the control network.  To limit the scope =

   of Link Verification to a particular TE Link, the LOCAL_LINK_ID MUST =

   be non-zero.  Furthermore, the BeginVerify message contains the =

   number of data links that are to be verified. =

    =

   If the remote node receives a BeginVerify message and it is ready to =

   process Test messages, it MUST send a BeginVerifyAck message back to =

   the local node.  When the local node receives a BeginVerifyAck =

   message from the remote node, it SHOULD begin testing the data links =

   by transmitting a test signal over each data link.  The remote node =

   MUST send either a TestStatusSuccess or a TestStatusFailure message =

   in response for each data link.  A TestStatusAck message MUST be sent =

   to confirm receipt of the TestStatusSuccess and TestStatusFailure =

   messages. =

    =

   It is also permissible for the sender to terminate the Test procedure =

   anytime after sending the BeginVerify message.  An EndVerify message =

   SHOULD be sent for this purpose. =

    =

   Message correlation is done using message identifiers.  This enables =

   verification of data links, belonging to different link bundles or =

   LMP sessions, in parallel. =

    =

   When the test signal is received, the received Interface Id is =

   recorded and mapped to the local Interface Id for that data link, and =

   a TestStatusSuccess message MUST be sent.  The TestStatusSuccess =

   message includes the local Interface Id and the remote Interface Id =

   (received in the Test message).  The receipt of a TestStatusSuccess =

   message indicates that the test signal was detected at the remote =

   node and the connectivity of the data link has been verified.  When =

   the TestStatusSuccess message is received, the local node SHOULD mark =

   the data link as UP and send a TestStatusAck message to the remote =

   node.  If, however, the Test signal is not detected at the remote =

   node within an observation period (specified by the =

   VerifyDeadInterval), the remote node will send a TestStatusFailure =

   message over the control network indicating that the verification of =

   the physical connectivity of the data link has failed.  When the =

   local node receives a TestStatusFailure message, it SHOULD mark the =

   data link as FAILED and send a TestStatusAck message to the remote =

   node.  When all the data links on the list have been tested, the =

  =

Everdingen et al                                             [Page 15] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   local node SHOULD send an EndVerify message to indicate that testing =

   is complete on this link. =

    =

   If the local/remote data link mappings are known, then the link =

   verification procedure can be optimized by testing the data links in =

   a defined order known to both nodes.  The suggested criteria for this =

   ordering is in increasing value of the Remote_Interface_ID. =

    =

   Both the local and remote nodes SHOULD maintain the complete list of =

   Interface Id mappings for correlation purposes. =

    =

    =

5.1.   Example of Link Connectivity Verification =

    =

   Figure 6 shows an example of the link verification scenario that is =

   executed when the connectivity of all data links between OXC A and =

   OXC B is to be verified.  In this example, the TE link consists of =

   three free CTPs.  Furthermore OXC A and OXC B can communicate over a =

   control network (indicated by a "c"). =

    =

   The verification process is as follows: OXC A sends a BeginVerify =

   message over the control network "c" to OXC B indicating it will =

   begin verifying the ports.  OXC B receives the BeginVerify message =

   and returns the BeginVerifyAck message over the control network to =

   OXC A.  When OXC A receives the BeginVerifyAck message, it begins =

   transmitting the test signal over the first CTP (Interface Id=3D1).  =

   When OXC B receives the test signal, it maps the received Interface =

   Id to its own local Interface Id =3D 10 and transmits a =

   TestStatusSuccess message over the control network back to OXC A.  =

   The TestStatusSuccess message includes both the local and received =

   Interface Ids for the port.  OXC A will send a TestStatusAck message =

   over the control network back to OXC B indicating it received the =

   TestStatusSuccess message.  The process is repeated until all of the =

   data links are verified.  At this point, OXC A will send an EndVerify =

   message over the control network to OXC B to indicate that testing is =

   complete; OXC B will respond by sending an EndVerifyAck message over =

   the control network back to OXC A. =

    =

                                     c =

              -----+----------------------------------+------ =

                   |                                  | =

             +-----------+                      +-----------+ =

             |   OXC A   |                      |    OXC B  | =

             |         1-+--------------------->+-10        | =

             |           |                      |           | =

             |         2-+                /---->+-11        | =

             |           |     /---------/      |           | =

             |         3-+----/                 +-12        | =

             |           |                      |           | =

             |         4-+--------------------->+-14        | =

             |           |                      |           | =

             +-----------+                      +-----------+ =

  =

Everdingen et al                                             [Page 16] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

       Figure 6: Example of link verification between OXC A and =

                                OXC B. =

    =

  =

Everdingen et al                                             [Page 17] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

6. Fault Management =

    =

   In this section, an optional LMP procedure is described that is used =

   to manage failures by rapid notification of the status of one or more =

   data links of a TE Link.  The scope of this procedure is within a TE =

   link, and as such, the use of this procedure is negotiated as part of =

   the LinkSummary exchange.  The procedure can be used to rapidly =

   isolate link failures and is designed to work for both unidirectional =

   and bi-directional data links. =

    =

   The fault management procedure for a specific data link is especially =

   useful in two cases: =

   1. The OXC node does not get fault information from the MUX node. =

   2. The OXC node can't use fault information from the MUX node =

    =

   An example for case (1) is when the OXC node and the MUX node are =

   separate network elements and no communication, like e.g. LMP-DWDM, =

   is available between these nodes. =

    =

   An example for case (2) is if the data link is actually a serial =

   compound data link.  In the latter case, LMP's fault management =

   function provides a kind of tandem connection monitoring function. =

    =

   LMP implements this tandem connection monitoring by sending the state =

   of the signal at the egress node of the serial compound data link to =

   the ingress node of the serial compound data link.  The ingress node =

   then compares this information with it's own information regarding =

   the state of the signal.  The difference between the state of the =

   signal at the egress node and the ingress node gives information =

   about the serial compound data link. =

    =

   +------+      +------+      +------+      +------+ =

   |    C-|--->--|-C--C-|--->--|-C--C-|--->--|-C    | =

   |      |   A  |      |   B  |      |   C  |      | =

   |      |      |      |      |      |      |      | =

   | OXC1 |      | OXC2 |      | OXC3 |      | OXC4 | =

   +------+      +------+      +------+      +------+ =

                  Figure 7: serial compound data link =

    =

   Figure 7 shows an example of a serial compound data link.  OXC2 and =

   OXC3 do not implement LMP nor GMPLS.  They are simply fixed through =

   cross-connects for this data link.  In this case, OXC4 can't find out =

   if the data link between OXC1 and OXC4 is failed from MUX nodes that =

   might be present between OXC3 and OXC4.  The only way OXC4 can know =

   that the data link between OXC1 and OXC4 is failed is by comparing =

   the fault state of the signal incoming at OXC4 and the fault state of =

   the signal outgoing from OXC1.  In other words, fault management =

   provides a way to find out if this data link is failed on any of the =

   sections A, B or C. =

    =

    =

  =

Everdingen et al                                             [Page 18] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

6.1.   Fault Detection =

    =

   Fault detection determines that there is a failure in the received =

   signal on a data link.  How fault detection is done is outside the =

   scope of LMP. =

    =

6.2.   Fault Localization Procedure =

    =

   LMP provides a failure notification through the ChannelStatus =

   message.  This message may be used to indicate that a single data =

   link has failed, multiple data links have failed, or an entire TE =

   link has failed.  Failure correlation is done locally at each node =

   upon receipt of the failure notification. =

    =

   To localize a fault to a particular data link between neighboring =

   OXCs, a downstream node (downstream in terms of data flow) that =

   detects data link failures will send a ChannelStatus message to its =

   upstream neighbor indicating that a failure has occurred (bundling =

   together the notification of all of the failed data links).  An =

   upstream node that receives the ChannelStatus message MUST send a =

   ChannelStatusAck message to the downstream node indicating it has =

   received the ChannelStatus message.  The upstream node should =

   correlate the failure to see if the failure is also detected locally =

   for the corresponding data link(s).  If, for example, the failure is =

   clear on the input of the upstream node or internally, then the =

   upstream node will have localized the failure. =

    =

   After this correlation process, the upstream node MUST send a =

   ChannelStatus message to the downstream node indicating that the data =

   link is failed or is ok.  The upstream node MUST repeat this =

   ChannelStatus message until it receives a corresponding =

   ChannelStatusAck message.  Once the failure has been localized, GMPLS =

   signaling protocols can be used to initiate span or path =

   protection/restoration procedures. =

    =

   If all of the data links of a TE link have failed, then the upstream =

   node MAY be notified of the TE link failure without specifying each =

   data link of the failed TE link.  This is done by sending failure =

   notification in a ChannelStatus message identifying the TE Link =

   without including the Interface Ids in the CHANNEL_STATUS object. =

    =

    =

6.3.   Examples of Fault Localization =

    =

   In Figure 8, a sample network is shown where four OXCs are connected =

   in a linear array configuration.  The control network is indicated by =

   a line labeled with a "c".  The data links are bi-directional. =

    =

   Figure 8 shows two types of data link failures (indicated by ## in =

   the figure): =

   (A) a data link corresponding to the downstream direction of a bi-
   directional LSP fails, =

  =

Everdingen et al                                             [Page 19] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   (B) two data links corresponding to both directions of a bi-
   directional LSP fail. =

    =

   In the first example [see Figure 8(a)], there is a failure on one =

   direction of the bi-directional LSP.  OXC 4 will detect the failure =

   and will send a ChannelStatus message to OXC3 indicating the failure =

   to the corresponding upstream node.  When OXC3 receives the =

   ChannelStatus message from OXC4, it returns a ChannelStatusAck =

   message back to OXC4 and correlates the failure locally.  OXC3 =

   determines that the signal it sends on the data link to OXC4 is free =

   of failure.  Correlation of this information with the information =

   received from OXC4 learns that the failure is located on the data =

   link between OXC3 and OXC4.  OXC3 will subsequently send a =

   ChannelStatus message to OXC4 to inform OXC4 of the failure on the =

   data link between OXC3 and OXC4. =

    =

   In the second example [see Figure 8(b)], a single failure (e.g., =

   fiber cut) affects both directions of the bi-directional data link.  =

   OXC3 (OXC2) will detect the failure of the downstream direction and =

   send a ChannelStatus message to the upstream node OXC2 (OXC3) =

   indicating the failure.  Upon reception of the ChannelStatus message, =

   OXC2 (OXC3) will send a ChannelStatusAck message to OXC3 (OXC2).  =

   Consequently, both OXC2 and OXC3 have localized the failure in both =

   directions of the data link. =

    =

                                     c =

         --+----------------+----------------+----------------+-- =

           |                |                |                | =

       +-------+        +-------+        +-------+        +-------+ =

       | OXC 1 |        | OXC 2 |        | OXC 3 |        | OXC 4 | =

       |       |        |       |        |       |        |       | =

   ----+---\   |        |       |        |       |        |       | =

   <---+---\\--+--------+-------+---\    |       |        |    /--+---> =

       |    \--+--------+-------+---\\---+-------+---##---+---//--+---- =

       |       |        |       |    \---+-------+--------+---/   | =

       |       |        |       |        |       |  (a)   |       | =

   ----+-------+--------+---\   |        |       |        |       | =

   <---+-------+--------+---\\--+---##---+--\    |        |       | =

       |       |        |    \--+---##---+--\\   |        |       | =

       |       |        |       |  (b)   |   \\--+--------+-------+---> =

       |       |        |       |        |    \--+--------+-------+---- =

       |       |        |       |        |       |        |       | =

       +-------+        +-------+        +-------+        +-------+ =

       =

   Figure 8 Two types of data link failures (indicated with ##) =

    =

    =

   Data link Activation Indication  =

    =

   The ChannelStatus message may also be used to notify an LMP neighbor =

   that the data link should be actively monitored.  This is called Data =

   Link Activation Indication.  This is particularly useful in networks =

   with transparent OXC nodes where the fault monitoring of data links =

  =

Everdingen et al                                             [Page 20] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   may need to be triggered using messages over the control plane.  =

   Active monitoring MAY be used before user traffic is allowed on the =

   data link. =

    =

   The ChannelStatus message is used to indicate that a data link or =

   group of data links are now active.  The ChannelStatusAck message =

   MUST be transmitted upon receipt of a ChannelStatus message.  When a =

   ChannelStatus message is received, the node must send a signal on the =

   corresponding data link(s).  If the downstream node consequently =

   detects a failure, the ChannelStatus message MUST be transmitted as =

   described in Section 6.2. =

    =

   Data Link Deactivation Indication  =

    =

   The ChannelStatus message MAY also be used to notify an LMP neighbor =

   that the data link no longer needs to be actively monitored.  This is =

   the counterpart to the Data Link Active Indication. =

    =

   When a ChannelStatus message is received with Data Link Deactive =

   Indication, the node MAY remove the signal from the corresponding =

   data link(s). =

    =

7. Message_Id Usage =

    =

   The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP =

   messages to support reliable message delivery.  This section =

   describes the usage of these objects. =

    =

   The MESSAGE_ID and MESSAGE_ID_ACK objects contain a Message_Id field. =
 =

   Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP =

   message. =

    =

   The Message_Id field is within the scope of the LMP adjacency. =

    =

   The Message_Id field of the MESSAGE_ID object MUST contain a =

   monotonically increasing value.  The Message_Id field of the =

   MESSAGE_ID_ACK object contains the Message_Id field of the message =

   being acknowledged.  =

    =

   Unacknowledged messages sent with the MESSAGE_ID object SHOULD be =

   retransmitted until the message is acknowledged or until a retry =

   limit is reached. =

    =

   Nodes processing incoming messages SHOULD check to see if a newly =

   received message is out of order and can be ignored.  Out-of-order =

   messages can be identified by examining the value in the Message_Id =

   field.  If the Message_Id value is less than the largest Message_Id =

   value previously received from the sender of the LMP adjacency, then =

   the message SHOULD be treated as being out of order and consequently =

   be ignored. =

    =

    =

8. Graceful Restart =

  =

Everdingen et al                                             [Page 21] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   This section describes the mechanism to resynchronize the LMP state =

   between LMP adjacencies.  Resynchronization is needed in case of an =

   LMP component restart. =

    =

   Note that resynchronization is not needed in case of a failure in the =

   control plane.  Normal retransmission timers for the linkSummary and =

   channelStatus messages take care of resynchronization as soon as the =

   connectivity between LMP adjacencies is restored. =

    =

   If the control plane failure was the result of an LMP component =

   restart, then the "LMP Restart" flag MUST be set in all LMP messages =

   until the LMP adjacency has acknowledged the reception of the =

   linkSummary and the channelStatusRequest message. =

    =

   Upon restart of the LMP component, this component MUST send a =

   LinkSummary message for each TE Link across the adjacency.  All the =

   objects of the LinkSummary message MUST have the N-bit set to 0 =

   indicating that the parameters are non-negotiable.  This provides the =

   local/remote Link Id and Interace Id mappings, the associated TE Link =

   and data link parameters, and indication of which data links are =

   currently allocated to user traffic. =

    =

   When the LMP adjacency receives the LinkSummary message, it checks =

   the consistency with its local configuration as described in Section =

   4 with the exception that the allocated/deallocated flag of the =

   DATA_LINK Object received in the LinkSummary message MUST take =

   precedence over any local value.  If, however, the LMP adjacency was =

   not capable of retaining the LMP Link information across a restart, =

   the node MUST accept the TE link and data link parameters of the =

   received LinkSummary message and respond with a LinkSummaryAck =

   message. =

    =

   Upon completion of the LinkSummary exchange, the restarted LMP =

   component SHOULD send a ChannelStatusRequest message for all TE =

   links.  The restarted LMP component SHOULD also verify the =

   connectivity of all unallocated data links. =

    =

  =

Everdingen et al                                             [Page 22] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

9. Addressing =

    =

   All LMP messages are sent over UDP.  The destination address of the =

   IP packet MUST be either the address learned in a manual =

   configuration procedure or the address learned in the automatic =

   neighbor discovery procedure. =

    =

    =

10. =

   LMP Authentication =

    =

   LMP authentication is optional (included in the Common Header) and, =

   if used, MUST be supported by both nodes that are neighbors regarding =

   the data links.  The method used to authenticate LMP packets is based =

   on the authentication technique used in [OSPF].  This uses =

   cryptographic authentication using MD5. =

    =

   As a part of the LMP authentication mechanism, a flag is included in =

   the LMP common header indicating the presence of authentication =

   information.  Authentication information itself is appended to the =

   LMP packet.  It is not considered to be a part of the LMP packet, but =

   is transferred in the same IP packet. =

    =

   When the Authentication flag is set in the LMP packet header, an =

   authentication data block is attached to the packet.  This block has =

   a standard authentication header and a data portion.  The contents of =

   the data portion depend on the authentication type.  Currently, only =

   MD5 is supported for LMP. =

    =

11. =

   IANA Considerations =

    =

   LMP defines the following name spaces that require management: =

    =

   - Msg Type Name Space. =

   - LMP Object Class name space. =

   - LMP Object Class type (C-Type).  These are unique with Object =

   Class. =

    =

   Following the policies outlined in [IANA], Msg Type, Object Class, =

   and Class type are allocated through an IETF Consensus action. =

    =

  =

Everdingen et al                                             [Page 23] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

12. =

   LMP Finite State Machines =

    =

    =

12.1.  TE Link FSM =

    =

   The TE Link FSM defines the states and logics of operation of an LMP =

   TE Link.  Note that the TE link (in contrast to the data link) offers =

   bi-directional transmission.  The TE link is considered 'up' in case =

   both ends of the TE link have received the linkSummaryAck message. =

    =

12.1.1.  TE Link States =

    =

   An LMP TE link can be in one of the states described below.  Every =

   state corresponds to a certain condition of the TE link. =

    =

   Down:       There are no data links allocated to the TE link. =

    =

   Init:       Data links have been allocated to the TE link, but the =

               configuration has not yet been synchronized with the LMP =

               neighbor. =

    =

   Up:         This is the normal operational state of the TE link. =

    =

       =

12.1.2.  TE Link Events =

    =

   Operation of the LMP TE link is described in terms of FSM states and =

   events.  Every event has its number and a symbolic name.  Description =

   of possible TE link events is given below. =

    =

   1 : evDLUp:     The number of data links in the TE link has been =

                   changed.  The resulting TE link contains at least one =

                   data chennel. =

   2 : evSumAck:   LinkSummary message received and positively =

                   acknowledged. =

   3 : evSumNack:  LinkSummary message received and negatively =

                   acknowledged. =

   4 : evRcvAck:   LinkSummaryAck message received acknowledging =

                   the TE Link Configuration. =

   5 : evRcvNack:  LinkSummaryNack message received. =

   6 : evSumRet:   Retransmission timer has expired and LinkSummary =

                   message is resent. =

   7 : evDLDown:   Last data link of the TE link has been removed. =

       =

       =

12.1.3.  TE Link FSM Description =

       =

   Figure 9 illustrates operation of the LMP TE Link FSM in a form of =

   FSM state transition diagram. =

  =

Everdingen et al                                             [Page 24] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

                                          3 =

                                        +--+ =

                                        |  | =

                                        |  v =

                                     +--------+ =

                                     |        | =

                                     |  Down  |<---------+ =

                                     |        |          | =

                                     +--------+          | =

                                        |  ^             | =

                                       1|  |7            | =

                                        v  |             | =

                                     +--------+          | =

                                     |        |<-+  2,   | =

                                     |  Init  |  |3,5,6  |7 =

                                     |        |--+       | =

                                     +--------+          | =

                                       |   ^             | =

                                      4|   | 1,3,5       | =

                                       v   |             | =

                                     +--------+          | =

                                     |        |----------+ =

                                     |   Up   | =

                                     |        | =

                                     +--------+ =

                                        |  ^ =

                                        |  | =

                                        +--+ =

                                       2,4,6 =

       =

                       Figure 9: LMP TE Link FSM =

    =

12.2.  Data Link FSM =

    =

   The data link FSM defines the states and logics of operation of a =

   data link within an LMP TE link.  Operation of a data link is =

   described in terms of FSM states and events. =

    =

   The end points of data links can either be in the transmitting mode =

   or in the receiving mode.  For clarity, separate FSMs are defined for =

   these modes. =

    =

12.2.1.  Data Link States =

    =

   Any data link can be in one of the states described below.  Every =

   state corresponds to a certain condition of the TE link. =

    =

   Down:          The data link has not been put in the resource pool =

                  (i.e., the data link is not "in service" =

       =

   Test:          A test signal is sent over the data link. =

  =

Everdingen et al                                             [Page 25] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   PasvTest:      The data link is being checked for an incoming test =

                  signal. =

       =

   Up/Free:       The data link has been successfully tested and is =

                  now put in the pool of resources (in-service).   The =

                  link has not yet been allocated to data traffic. =

       =

   Up/Allocated:  The link is UP and has been allocated for data =

                  traffic. =

    =

12.2.2.  Data Link Events =

       =

   Data bearing link events are generated by the FSMs of the associated =

   TE link.  Every event has its number and a symbolic name. =

   Description of possible data link events is given below: =

   3 :evStartTst:   This is an external event that triggers the sending =

                    of the test signal over the data bearing link. =

   4 :evStartPsv:   This is an external event that triggers the =

                    listening for a test signal over the data bearing =

                    link. =

   5 :evTestOK:     Link verification was successful and the link can =

                    be used for path establishment. This event indicates =

                    the Link Verification procedure (see Section 5) was =

                    successful for this data link and a =

                    TestStatusSuccess message was received. =

   6 :evTestRcv:    Test signal was received over the data link and a =

                    TestStatusSuccess message is transmitted over the =

                    control network. =

   7 :evTestFail:   Link verification returned negative results.  This =

                    could be because (a) a TestStatusFailure message =

                    was received, or (b) the Verification procedure has =

                    ended without receiving a TestStatusSuccess or =

                    TestStatusFailure message for the data link. =

   8 :evPsvTestFail:Link verification returned negative results.  This =

                    indicates that a Test message was not detected and =

                    either (a) the VerifyDeadInterval has expired or =

                    (b) the Verification procedure has ended and the =

                    VerifyDeadInterval has not yet expired. =

   9 :evLnkAlloc:   The data link has been allocated. =

   10:evLnkDealloc: The data link has been deallocated. =

   11:evTestRet:    A retransmission timer has expired and the Test =

                    signal is resent. =

   12:evSummaryFail:The LinkSummary did not match for this data port. =

   13:evLocalizeFail:A Failure has been localized to this data link. =

   14:evdlDown:     The data link is no longer available. =

    =

    =

    =

12.2.3.  FSM Description Transmitter =

       =

   Figure 10 illustrates operation of the transmitting side of the data =

   link in the form of FSM state transition diagram. =

  =

Everdingen et al                                             [Page 26] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   Note that the FSM may start in the Up/Free state.  This may be the =

   case when the data link has been discovered via LMP's automatic =

   neighbor discovery procedure. =

    =

                                +------+ =

                                |      |<-------+ =

                     +--------->| Down |        | =

                     |          |      |<-----+ | =

                     |          +------+      | | =

                     |           3|  ^        | | =

                     |            |  |2,7     | | =

                     |            v  |        | | =

                     |          +------+      | | =

                     |          |      |<-+   | | =

                     |          | Test |  |11 | | =

                     |12        |      |--+   | | =

                     |          +------+      | | =

                     |            5| 3^       | | =

                     |             |  |       | | =

                     |             v  |       | | =

                     |         +---------+    | | =

                     |         |         |14  | | =

                     |         | Up/Free |----+ | =

                     +---------|         |      | =

                               +---------+      | =

                                  9| ^          | =

                                   | |          | =

                                   v |10        | =

                               +---------+      | =

                               |         |13    | =

                               |Up/Alloc |------+ =

                               |         | =

                               +---------+ =

       =

        Figure 10: FSM description of transmitting side of Data =

                                 Link =

    =

  =

Everdingen et al                                             [Page 27] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

12.2.4.  FSM Description receiver =

       =

   Figure 11 illustrates operation of the receiving side of the data =

   link in the form of FSM state transition diagram. =

    =

   Note that the FSM may start in the Up/Free state.  This may be the =

   case when the data link has been discovered via LMP's automatic =

   neighbor discovery procedure. =

    =

                                +------+ =

                                |      |<------+ =

                    +---------->| Down |       | =

                    |           |      |<----+ | =

                    |           +------+     | | =

                    |            4|  ^       | | =

                    |             |  |2,8    | | =

                    |             v  |       | | =

                    |          +----------+  | | =

                    |          | PasvTest |  | | =

                    |12        +----------+  | | =

                    |             6|  4^     | | =

                    |              |   |     | |   =

                    |              v   |     | | =

                    |          +---------+   | | =

                    |          | Up/Free |14 | | =

                    |          |         |---+ | =

                    +----------|         |     | =

                               +---------+     | =

                                   9| ^        | =

                                    | |        | =

                                    v |10      | =

                               +---------+     | =

                               |         |13   | =

                               |Up/Alloc |-----+ =

                               |         | =

                               +---------+ =

       =

         Figure 11: FSM description of receiving side of Data =

                                 Link  =

    =

  =

Everdingen et al                                             [Page 28] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

13. =

   LMP Message Formats =

       =

   All LMP messages are UDP encoded with port number xxx - TBA (to be =

   assigned) by IANA. =

    =

13.1.  Common Header =

       =

   In addition to the standard UDP header, all LMP messages have the =

   following common header: =

    =

   0                   1                   2                   3 =

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   | Vers  |      (Reserved)       |    Flags      |    Msg Type   | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   Vers: 4 bits =

    =

       Protocol version number.  This is version 1. =

    =

   Flags: 8 bits.  The following values are defined.  All other values =

          are reserved. =

    =

        0x02: LMP Restart =

    =

               This bit is set to indicate the LMP component has =

               restarted. =

    =

        0x08: Authentication =

    =

               When set, this bit indicates that an authentication =

               block is attached at the end of the LMP message.  See =

               Section 10 for more details. =

    =

   Msg Type: 8 bits.  The following values are defined.  All other =

             values are reserved. =

    =

         5 =3D BeginVerify =

         =

         6 =3D BeginVerifyAck =

         =

         7 =3D BeginVerifyNack =

         =

         8 =3D EndVerify =

         =

         9 =3D EndVerifyAck         =

         =

        11 =3D TestStatusSuccess =

         =

        12 =3D TestStatusFailure =

         =

        13 =3D TestStatusAck =

         =

  =

Everdingen et al                                             [Page 29] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

        14 =3D LinkSummary =

         =

        15 =3D LinkSummaryAck =

         =

        16 =3D LinkSummaryNack =

         =

        17 =3D ChannelStatus =

         =

        18 =3D ChannelStatusAck =

         =

        19 =3D ChannelStatusRequest =

         =

        20 =3D ChannelStatusResponse =

    =

    =

    =

13.2.  LMP Object Format =

    =

   LMP messages are built using objects.  Each object is identified by =

   its Object Class and Class-type.  Each object has a name, which is =

   always capitalized in this document. LMP objects can be either =

   negotiable or non-negotiable (identified by the N bit in the Object =

   header).  Negotiable objects can be used to let the devices agree on =

   certain values.  Non-negotiable Objects are used for announcement of =

   specific values that do not need or do not allow negotiation. =

    =

   The format of the LMP object is as follows: =

    =

   0                   1                   2                   3 =

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |N|   C-Type    |     Class     |            Length             | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   //                       (Object contents)                     // =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   N: 1 bit =

    =

        The N flag indicates if the object is negotiable (N=3D1) or non-
        negotiable (N=3D0). =

    =

   C-Type: 7 bits =

    =

        Class-type, unique within an Object Class.  Values are defined =

        in Section 14. =

    =

   Class: 8 bits =

    =

        The Class indicates the Object type.  Each Object has a name, =

        which is always capitalized in this document. =

    =

  =

Everdingen et al                                             [Page 30] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   Length: 16 bits =

    =

        The Length field indicates the length of the Object in bytes, =

        including the N, C-Type, Class, and Length fields. =

         =

13.3.  Authentication =

       =

   When authentication is used for LMP, the authentication itself is =

   appended to the LMP packet.  It is not considered to be a part of =

   the LMP packet, but is transmitted in the same UDP packet as shown =

   below: =

    =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   //                     LMP Common Header                       // =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   //                        LMP Payload                          // =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   //                    Authentication Block                     // =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   The authentication block consists of an 8 byte header followed by the =

   data portion shown as follows: =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |      0        |   Auth Type   |    Key ID     | Auth Data Len | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                 Cryptographic Sequence Number                 | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   |                       MD5 Signature (16)                      | =

   |                                                               | =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   Auth Type: 8 bits =

              This defines the type of authentication used for LMP =

              messages.  The following authentication types are =

              defined, all other are reserved for future use: =

               =

              0  No authentication =

              1  Cryptographic authentication =

                  =

   Key ID: 8 bits =

  =

Everdingen et al                                             [Page 31] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

              This field is defined only for cryptographic =

              authentication. =

    =

   Auth Data Length: 8 bits =

              This field contains the length of the data portion of the =

              authentication block. =

    =

   The LMP packet authentication procedure is very similar to the one =

   used in OSPF, including multiple key support, key management, etc. =

   The details specific to LMP are defined below. =

    =

   Sending authenticated packets =

   ----------------------------- =

       =

   When a packet needs to be sent over the control network and an =

   authentication method is configured for it, the Authentication flag =

   in the LMP header is set to 1, the LMP Length field is set to the =

   length of the LMP packet only, not including the authentication =

   block. =

    =

   1) The Checksum field in the LMP packet is set to zero (this will =

      make the receiving side drop the packet if authentication is not =

      supported). =

   2) The LMP authentication header is filled out properly. The message =

      digest is calculated over the LMP packet together with the LMP =

      authentication header. The input to the message digest =

      calculation consists of the LMP packet, the LMP authentication =

      header, and the secret key. When using MD5 as the authentication =

      algorithm, the message digest calculation proceeds as follows: =

       =

        (a)  The authentication header is appended to the LMP packet. =

        (b)  The 16 byte MD5 key is appended after the LMP =

             authentication header. =

        (c)  Trailing pad and length fields are added, as specified in =

             [MD5]. =

        (d)  The MD5 authentication algorithm is run over the =

             concatenation of the LMP packet, authentication header, =

             secret key, pad and length fields, producing a 16 byte =

             message digest (see [MD5]). =

        (e)  The MD5 digest is written over the secret key (i.e., =

             appended to the original authentication header). =

       =

   The authentication block is added to the IP packet right after the =

   LMP packet, so IP packet length includes the length of both LMP =

   packet and LMP authentication blocks. =

    =

   Receiving authenticated packets =

   ------------------------------- =

       =

   When an LMP packet, with the Authentication flag set, has been =

   received, it must be authenticated.  The value of the Authentication =

   field MUST match the configured authentication type. =

    =

  =

Everdingen et al                                             [Page 32] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   If an LMP protocol packet is accepted as authentic, processing of the =

   packet continues.  Packets that fail authentication are discarded.  =

   Note that the checksum field in the LMP packet header is not checked =

   when the packet is authenticated. =

    =

   (1)  If the key is not configured, or if the key is not valid for =

        reception (i.e., current time does not fall into the key's =

        active time frame), the LMP packet is discarded. =

   (2)  If the cryptographic sequence number found in the LMP =

        authentication header is less than the cryptographic sequence =

        number recorded in the node, the LMP packet is discarded. =

   (3)  Verify the message digest in the data portion of the =

        authentication block in the following steps: =

        (a)  The received digest is set aside. =

        (b)  A new digest is calculated, as specified in the previous =

             section. =

        (c)  The calculated and received digests are compared.  If they =

             do not match, the LMP packet is discarded.  If they do =

             match, the LMP protocol packet is accepted as authentic, =

             and the "cryptographic sequence number" in the node's data =

             structure is set to the sequence number found in the =

             packet's LMP header. =

       =

    =

13.4.  Link Verification =

       =

13.4.1.  BeginVerify Message (Msg Type =3D 5) =

       =

   The BeginVerify message is sent over the control network and is used =

   to initiate the link verification process.  The format is as follows: =

    =

   <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 and REMOTE_LINK_ID MUST be non-zero. =

    =

   The BeginVerify message MUST be periodically transmitted until (1) =

   the node receives either a BeginVerifyAck or BeginVerifyNack message =

   to accept or reject the verify process or (2) a timeout expires and =

   no BeginVerifyAck or BeginVerifyNack message has been received.  Both =

   the retransmission interval and the timeout period are local =

   configuration parameters. =

    =

13.4.2.  BeginVerifyAck Message (Msg Type =3D 6) =

       =

   When a BeginVerify message is received and test signals are ready to =

   be processed, a BeginVerifyAck message MUST be transmitted. =

    =

   <BeginVerifyAck Message> ::=3D <Common Header> <MESSAGE_ID_ACK> =

  =

Everdingen et al                                             [Page 33] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

                                <BEGIN_VERIFY_ACK> <VERIFY_ID> =

    =

   The above transmission order SHOULD be followed. =

    =

   The contents of the MESSAGE_ID_ACK object MUST be obtained from the =

   BeginVerify message being acknowledged. =

    =

   The VERIFY_ID object contains a node-unique value that is assigned by =

   the generator of the BeginVerifyAck message. This value is used to =

   uniquely identify the Verification process from multiple LMP =

   neighbors and/or parallel test procedures between the same LMP =

   neighbors. =

    =

    =

13.4.3.  BeginVerifyNack Message (Msg Type =3D 7) =

       =

   If a BeginVerify message is received and a node is unwilling or =

   unable to begin the Verification procedure, a BeginVerifyNack message =

   MUST be transmitted. =

    =

   <BeginVerifyNack Message> ::=3D <Common Header> =

                                 <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 the LOCAL_LINK_ID, REMOTE_LINK_ID combination in the BeginBVerify =

   message does not match the node's configuration, the ERROR_CODE MUST =

   indicate "TE Link Id configuration error". =

    =

   The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. =

    =

13.4.4.  EndVerify Message (Msg Type =3D 8) =

       =

   The EndVerify message is sent over the control network and is used to =

   terminate the link verification process.  The EndVerify message may =

  =

Everdingen et al                                             [Page 34] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   be sent at any time the initiating node desires to end the Verify =

   procedure.  The format is as follows: =

    =

   <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.4.5.  EndVerifyAck Message (Msg Type =3D9) =

       =

   The EndVerifyAck message is sent over the control network and is used =

   to acknowledge the termination of the link verification process.  The =

   format is as follows: =

    =

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

   EndVerify message being acknowledged. =

    =

    =

13.4.6.  TestStatusSuccess Message (Msg Type =3D 11) =

       =

   The TestStatusSuccess message is transmitted over the control network =

   and is used to transmit the mapping between the local Interface Id =

   and the Interface Id that was received in the Test message.   =

    =

   <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 signal being positively acknowledged. =

    =

13.4.7.  TestStatusFailure Message (Msg Type =3D 12) =

       =

   The TestStatusFailure message is transmitted over the control network =

   and is used to indicate that the test signal was not received. =

    =

   <TestStatusFailure Message> ::=3D <Common Header> <MESSAGE_ID_ACK> =

                                   <VERIFY_ID> =

    =

    =

   The above transmission order SHOULD be followed. =

    =

  =

Everdingen et al                                             [Page 35] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

13.4.8.  TestStatusAck Message (Msg Type =3D 13) =

       =

   The TestStatusAck message is used to acknowledge receipt of the =

   TestStatusSuccess or TestStatusFailure messages. =

    =

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

   TestStatusSuccess or TestStatusFailure message being acknowledged. =

    =

13.5.  Link Summary Messages =

       =

13.5.1.  LinkSummary Message (Msg Type =3D 14) =

       =

   The LinkSummary message is used to synchronize the Interface Ids and =

   correlate the properties of the TE link.  The format of the =

   LinkSummary message is as follows: =

    =

   <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.5.2.  LinkSummaryAck Message (Msg Type =3D 15) =

       =

   The LinkSummaryAck message is used to indicate agreement on the =

   Interface Id synchronization and acceptance/agreement on all the link =

   parameters. It is on the reception of this message that the local =

   node makes the TE Link Id associations. =

    =

   <LinkSummaryAck Message> ::=3D  <Common Header> <MESSAGE_ID_ACK> =

    =

   The above transmission order SHOULD be followed. =

    =

13.5.3.  LinkSummaryNack Message (Msg Type =3D 16) =

       =

   The LinkSummaryNack message is used to indicate disagreement on non-
   negotiated parameters or propose other values for negotiable =

   parameters.  Parameters where agreement was reached MUST NOT be =

   included in the LinkSummaryNack Object. =

    =

   <LinkSummaryNack Message> ::=3D <Common Header> <MESSAGE_ID_ACK> =

  =

Everdingen et al                                             [Page 36] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

                                 <ERROR_CODE> [<DATA_LINK>...] =

    =

   The above transmission order SHOULD be followed. =

    =

   The DATA_LINK Objects MUST include acceptable values for all =

   negotiable parameters.  If the LinkSummaryNack includes DATA_LINK =

   Objects for non-negotiable parameters, they MUST be copied from the =

   DATA_LINK Objects received in the LinkSummary message. =

    =

   If the LinkSummaryNack message is received and only includes =

   negotiable parameters, then a new LinkSummary message SHOULD be sent. =
 =

   The values received in the new LinkSummary message SHOULD take into =

   account the acceptable parameters included in the LinkSummaryNack =

   message. =

    =

   The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2. =

    =

13.6.  Fault Management Messages =

       =

13.6.1.  ChannelStatus Message (Msg Type =3D 17) =

       =

   The ChannelStatus message is sent over the control network and is =

   used to notify an LMP neighbor of the status of a data link.  A node =

   that receives a ChannelStatus message MUST respond with a =

   ChannelStatusAck message.  The format is as follows: =

    =

   <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.6.2.  ChannelStatusAck Message (Msg Type =3D 18) =

       =

   The ChannelStatusAck message is used to acknowledge receipt of the =

   ChannelStatus Message.  The format is as follows: =

    =

   <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.6.3.  ChannelStatusRequest Message (Msg Type =3D 19) =

       =

   The ChannelStatusRequest message is sent over the control network and =

   is used to request the status of one or more data link(s).  A node =

   that receives a ChannelStatusRequest message MUST respond with a =

   ChannelStatusResponse message.  The format is as follows: =

    =

  =

Everdingen et al                                             [Page 37] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   <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.6.4.  ChannelStatusResponse Message (Msg Type =3D 20) =

       =

   The ChannelStatusResponse message is used to acknowledge receipt of =

   the ChannelStatusRequest Message and notify the LMP neighbor of the =

   status of the data link(s).  The format is as follows: =

    =

   <ChannelStatusResponse Message> ::=3D <Common Header> <MESSAGE_ID_ACK>=
  =

                                       <CHANNEL_STATUS> =

    =

   The above transmission order SHOULD be followed. =

    =

   The contents of the MESSAGE_ID_ACK objects MUST be obtained from the =

   ChannelStatusRequest message being acknowledged. =

  =

Everdingen et al                                             [Page 38] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

14. =

   LMP Object Definitions =

       =

14.1.  NODE_ID Classes =

        =

14.1.1.  LOCAL_NODE_ID Class =

    =

   Class =3D 3. =

   IPv4, C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                        Node_Id (4 bytes)                      | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

    =

    =

   IPv6, C-Type =3D 2 =

    =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   +                                                               + =

   |                                                               | =

   +                        Node_Id (16 bytes)                     + =

   |                                                               | =

   +                                                               + =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

    =

   Node_Id: =

    =

        This identifies the address (in the control plane) of the node =

        that originated the LMP packet. =

    =

   This Object is non-negotiable. =

    =

14.1.2.  REMOTE _NODE_ID Class =

       =

   Class =3D 4. =

   IPv4, C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                        Node_Id (4 bytes)                      | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

    =

   IPv6, C-Type =3D 2 =

    =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

  =

Everdingen et al                                             [Page 39] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   +                                                               + =

   |                                                               | =

   +                        Node_Id (16 bytes)                     + =

   |                                                               | =

   +                                                               + =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

            =

   Node_Id: =

    =

        This identities the remote node. =

    =

   This Object is non-negotiable. =

    =

14.2.  LINK _ID Classes =

       =

14.2.1.  LOCAL_LINK_ID Class =

    =

   Class =3D 5 =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                        Link_Id (4 bytes)                      | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

    =

       =

   Link_Id: =

   This identifies the sender's Link associated with the message. =

   This Object is non-negotiable. =

    =

14.2.2.  REMOTE _LINK_ID Class =

       =

   Class =3D 6  =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                         Link_Id (4 bytes)                     | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

            =

       =

   Link_Id: =

    =

        This identifies the remote node's Link Id and MUST be non-zero. =

    =

   This Object is non-negotiable. =

    =

  =

Everdingen et al                                             [Page 40] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

14.3.  INTERFACE_ID Classes =

       =

14.3.1.  LOCAL_INTERFACE_ID Class =

    =

   Class =3D 7 =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface_Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

            =

   Interface_Id: =

    =

        This identifies the data link (either port or component link).  =

        The Interface_Id MUST be node-wide unique and non-zero. The =

        Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit =

        into the in-band discovery and test messages. =

    =

   This Object is non-negotiable. =

    =

14.3.2.  REMOTE_INTERFACE_ID Class =

       =

   Class =3D 8.  =

   C-Type =3D 1 =

       =

   0                   1                   2                   3 =

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface_Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

            =

     =

   Interface_Id: =

    =

        This identifies the remote node's data link (either port or =

        component link).  The Interface Id MUST be non-zero. The =

        Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit =

        into the in-band discovery and test messages. =

    =

   This Object is non-negotiable. =

    =

14.4.  MESSAGE_ID Class =

       =

   Class =3D 9.  =

   MessageId, C-Type =3D 1 =

       =

   0                   1                   2                   3 =

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                          Message_Id                           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

  =

Everdingen et al                                             [Page 41] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

       =

   Message_Id: =

   The Message_Id field is used to identify a message.  This value is =

   incremented and only decreases when the value wraps.  This is used =

   for message acknowledgment. =

   This Object is non-negotiable. =

    =

14.5.  MESSAGE_ID_ACK Class =

       =

   Class =3D 10. =

   MessageIdAck, C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                          Message_Id                           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   Message_Id: =

    =

        The Message_Id field is used to identify the message being =

        acknowledged.  This value is copied from the MESSAGE_ID object =

        of the message being acknowledged. =

    =

   This Object is non-negotiable. =

    =

         =

14.6.  BEGIN_VERIFY Class =

       =

   Class =3D 13. =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Number of Data Links (n)                | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                    local interface id. #1                     | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                :                              | =

   //                               :                             // =

   |                                :                              | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                    local interface id. #n                    | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

       =

   Number of Data Links:  32 bits =

    =

        This is the number of data links that will be verified. =

    =

   Interface_Id: =

    =

  =

Everdingen et al                                             [Page 42] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

        This identifies the local node's data link (either port or =

        component link) that is to be verified. =

         =

    =

14.7.  BEGIN_VERIFY_ACK Class =

       =

   Class =3D 14. =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |      VerifyDeadInterval       |        (Reserved)             | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   VerifyDeadInterval:  16 bits =

    =

        If a Test message is not detected within the =

        VerifyDeadInterval, then a node will send the TestStatusFailure =

        message for that data link. =

 =

   This Object is non-negotiable. =

    =

    =

14.8.  VERIFY_ID Class =

       =

   Class =3D 15. =

   C-Type =3D 1 =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                           VerifyId                            | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   VerifyId:  32 bits =

        This is used to differentiate Test messages from different TE =

        links and/or LMP peers.  This is a node-unique value that is =

        assigned by the recipient of the BeginVerify message. =

    =

   This Object is non-negotiable. =

    =

    =

14.9.  TE_LINK Class =

       =

   Class =3D 16. =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |             Flags             |       (Reserved)              | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                      Local_Link_Id (4 bytes)                  | =

  =

Everdingen et al                                             [Page 43] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                      Remote_Link_Id (4 bytes)                 | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   Flags: 16 bits =

        The following flags are defined.  All other values are =

        reserved. =

    =

   0x01 Fault Management Supported. =

    =

   0x02 Link Verification via access point identifier method supported. =

    =

   Local_Link_Id: =

    =

        This identifies the node's local Link Id and MUST be non-zero. =

    =

   Remote_Link_Id: =

    =

        This identifies the remote node's Link Id and MUST be non-zero. =

    =

14.10. DATA_LINK Class =

       =

   Class =3D 17. =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |     Flags     |                   (Reserved)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                   Local_Interface_Id (4 bytes)                | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                   Remote_Interface_Id (4 bytes)               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                                                               | =

   //                        (Subobjects)                         // =

   |                                                               | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   Flags: 8 bits =

        The following flags are defined.  All other values are =

        reserved. =

        0x02 Allocated Link: If set, the data link is currently =

                             allocated for user traffic.  If a single =

                             Interface_Id is used for both the transmit =

                             and receive data links, then this bit only =

                             applies to the transmit interface. =

        0x04 Failed Link:  If set, the data link is failed and not =

                           suitable for user traffic. =

         =

        Local_Interface_Id: =

         =

  =

Everdingen et al                                             [Page 44] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

              This is the local identifier of the data link.  This MUST =

              be node-wide unique and non-zero. =

         =

        Remote_Interface_Id: =

         =

        This is the remote identifier of the data link.  This MUST be =

        non-zero. =

         =

        Subobjects =

         =

              The contents of the data link object MAY consist of a =

              series of variable-length  data  items called subobjects.  =

              The subobjects are defined in subsequent sub-sections. =

    =

       =

   The contents of the DATA_LINK object include a series of variable-
   length data items called subobjects.  Each subobject has the form: =

    =

    0                   1 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+  =

   |    Type     |    Length     |      (Subobject contents)       | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+  =

       =

   Type: 8 bits =

    =

        The Type indicates the type of contents of the subobject.  =

    =

   Length: 8 bits =

    =

        The Length contains the total length of the subobject in bytes, =

        including the Type and Length fields.  The Length MUST be at =

        least 4, and MUST be a multiple of 4. =

         =

         =

14.10.1. Subobject Type 1: Local Access Identifier (Local AID)  =

    =

   The Local Access Identifier (Local AID) identifies the local =

   interface_id in a human-readable format. =

     =

   The format of the local AID is as follows:  =

        =

    0                   1 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+  =

   |    Type       |    Length     |          local AID            |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ =

        =

          =

   local AID: =

        =

        Any human-readable string. =

         =

  =

Everdingen et al                                             [Page 45] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

14.10.2. Subobject Type 2: Remote Access Identifier (Local AID)  =

    =

   The Remote Access Identifier (Remote AID) identifies the remote =

   interface_id in a human-readable format. =

     =

   The format of the remote AID is as follows:  =

        =

    0                   1 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+  =

   |    Type       |    Length     |         remote AID            |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ =

        =

          =

   remote AID: =

        =

        Any human-readable string. =

         =

14.10.3. Subobject Type 3: Shared Risk Link Group Identifier (SRLG) =

    =

   SRLGs of which the data link is a member.  This information is =

   manually configured per data link may be used for diverse path =

   computation. =

    =

   The format of the SRLG sub-object is as follows:  =

        =

   0                   1                   2                   3  =

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |    Type       |    Length     |           (Reserved)          |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |                       SRLG value #1                           |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |                        ............                           |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |                      SRLG value #N                            | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

    =

   Length: 8 bits  =

    =

        The length is (N+1)*4, where N is the number of SRLG values.  =

          =

   Shared Risk Link Group Value: 32 bits  =

        =

        List as many SRLGs as apply.  =

          =

   Reserved: 16 bits  =

        =

        Must be set to zero on transmit and ignored on receive.  =

        =

14.10.4. Subobject Type 4: multiplex protection =

    =

  =

Everdingen et al                                             [Page 46] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

   The contents of the multiplex protection object determine whether the =

   data link is protected on multiplex level. Examples of protection =

   schemes on multiplex level: MSP/line protection, MS-SPRing/BLSR =

   etcetera. This information can be used as a measure of the quality of =

   the data link.  It may be advertised by routing and used by signaling =

   as a selection criterion as described in [GMPLS].  =

    =

   The format of the Optical Protection subobject is as follows:   =

    =

    0                   1                   2                   3   =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   =

   |    Type       |    Length     | Link Flags|      Reserved     |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

        =

   Length: 8 bits  =

    =

        The length field has value '4'.  =

          =

   Link Flags:  6 bits  =

    =

        Encoding for Link Flags can be found in [GMPLS].  =

    =

    =

14.10.5. Subobject Type 5: Total Span delay =

    =

   The total span delay object determines the delay any bit experiences =

   when travelling over the data link. =

     =

   The format of the span delay sub-object is as follows:  =

        =

    0                   1                   2                   3   =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |    Type       |    Length     |           (Reserved)          |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |                       Span Length                             |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

        =

   Length: 8 bits  =

    =

        The length field has value '8'.  =

          =

   Span Length: 32 bits =

        =

        Total Length of the WDM span in meters expressed as an unsigned =

        integer. =

         =

   Reserved: 16 bits  =

    =

        Must be set to zero on transmit and ignored on receive. =

        =

14.10.6. Subobject Type 6: Administrative Cost =

  =

Everdingen et al                                             [Page 47] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   The administrative cost sub-object gives the cost of the data link =

   for path routing purposes. This information is manually configured =

   per data link. =

    =

   The format of the Administrative Group sub-object is as follows: =

    =

    0                   1                   2                   3   =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |    Type       |    Length     |            (Reserved)         |  =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

   |                    Administrative Cost (cont)                 | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =

        =

    =

   Administrative Cost: 32 bits  =

    =

        A 32 bit value.  =

        =

   Reserved: 16 bits =

    =

        Must be set to zero on transmit and ignored on receive. =

    =

    =

14.11. CHANNEL_STATUS Class =

       =

   Class =3D 18 =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |A|                       Channel Status                        | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                              :                                | =

   //                             :                               // =

   |                              :                                | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |A|                       Channel Status                        | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

       =

   Active bit: 1 bit =

    =

   This indicates that the data link is allocated to user traffic and =

   the data link should be actively monitored. =

    =

   Direction bit: 1 bit =

  =

Everdingen et al                                             [Page 48] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

    =

   This indicates the direction (transmit/receive) of the data link =

   referred to in the Channel_Status object.  If set, this indicates the =

   data channel is in the transmit direction. =

    =

   Channel_Status: 31 bits =

    =

        This indicates the status condition of a data link.  The =

        following values are defined.  All other values are reserved. =

          1. Signal Okay (OK): Data link is operational =

          2. Signal Degrade (SD): A soft failure caused by a BER =

             exceeding a preselected threshold.  The specific BER used =

             to define the threshold is configured. =

          3. Signal Fail (SF): A hard signal failure including (but not =

             limited to) loss of signal (LOS), loss of frame (LOF), or =

             Line AIS. =

       =

   This Object contains one or more Interface Ids followed by a =

   Channel_Status field. =

    =

   To indicate the status of the entire TE Link, there MUST only be one =

   Interface Id and it MUST be zero. =

    =

   This Object is non-negotiable. =

    =

14.12. CHANNEL_STATUS_REQUEST Class =

       =

   Class =3D 19 =

   C-Type =3D 1 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                              :                                | =

   //                             :                               // =

   |                              :                                | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                       Interface Id (4 bytes)                  | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

       =

   This Object contains one or more Interface Ids. =

    =

   The Length of this object is 4N in bytes, where N is the number of =

   Interface Ids. =

    =

   This Object is non-negotiable. =

    =

14.13. ERROR_CODE Class =

       =

   Class =3D 20. =

   BEGIN_VERIFY_ERROR, C-Type =3D 1 =

  =

Everdingen et al                                             [Page 49] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                          ERROR CODE                           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

            =

        The following bit-values are defined: =

         =

        0x01 =3D Link Verification Procedure not supported for this TE =

               Link. =

        0x02 =3D Unwilling to verify at this time =

        0x08 =3D TE Link Id configuration error =

         =

        All other values are Reserved. =

         =

        Multiple bits may be set to indicate multiple errors. =

         =

        This Object is non-negotiable. =

         =

   If a BeginVerifyNack message is received with Error Code 2, the node =

   that originated the BeginVerify SHOULD schedule a BeginVerify =

   retransmission after Rf seconds, where Rf is a locally defined =

   parameter. =

    =

   LINK_SUMMARY_ERROR, C-Type =3D 2 =

       =

    0                   1                   2                   3 =

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

   |                          ERROR CODE                           | =

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

            =

   The following bit-values are defined: =

    =

   0x01 =3D Unacceptable non-negotiable LINK_SUMMARY parameters =

   0x02 =3D Renegotiate LINK_SUMMARY parameters =

   0x04 =3D Bad Received Remote_Link_Id =

   0x08 =3D Bad TE Link Object =

   0x10 =3D Bad Data Link Object =

            =

   All other values are Reserved. =

    =

   Multiple bits may be set to indicate multiple errors. =

    =

   This Object is non-negotiable. =

    =

  =

Everdingen et al                                             [Page 50] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

15. =

   Security Considerations =

       =

   LMP exchanges may be authenticated using the Cryptographic =

   authentication option.  MD5 is currently the only message digest =

   algorithm specified. =

    =

16. =

   References =

    =

   [RFC2026]   Bradner, S., "The Internet Standards Process-Revision =

               3," BCP 9, RFC 2026, October 1996. =

   [LAMBDA]    Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., =

               "Multi-Protocol Lambda Switching: Combining MPLS Traffic =

               Engineering Control with Optical Crossconnects," =

               Internet Draft, draft-awduche-mpls-te-optical-03.txt, =

               (work in progress), April 2001. =

   [BUNDLE]    Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in =

               MPLS Traffic Engineering," Internet Draft, draft- =

               kompella-mpls-bundle-05.txt, (work in progress), February =

               2001. =

   [RSVP-TE]   Awduche, D. O., Berger, L., Gan, D.-H., Li, T., =

               Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP =

               Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- =

               tunnel-08.txt, (work in progress), February 2001. =

   [CR-LDP]    Jamoussi, B., et al, "Constraint-Based LSP Setup using =

               LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, =

               (work in progress), September 1999. =

   [OSPF-TE]   Katz, D., Yeung, D., Kompella, K., "Traffic Engineering =

               Extensions to OSPF," Internet Draft, draft-katz-yeung- =

               ospf-traffic-04.txt, (work in progress), February 2001. =

   [ISIS-TE]   Li, T., Smit, H., "IS-IS extensions for Traffic =

               Engineering," Internet Draft,draft-ietf-isis-traffic- =

               02.txt, (work in progress), September 2000. =

   [OSPF]      Moy, J., "OSPF Version 2," RFC 2328, April 1998. =

   [LMP]       Lang, J.P. et al, "Link Management Protocol", Internet =

               Draft, draft-ietf-ccamp-lmp-03.txt, (work in progress), =

               March 2002. =

   [LMP-DWDM]  Fredette, A., Lang, J. P., editors, "Link Management =

               Protocol (LMP) for WDM Transmission Systems,=F6 Internet =

               Draft, draft-fredette-lmp-wdm-03.txt, (work in =

               progress), November 2001. =

   [MD5]       Rivest, R., "The MD5 Message-Digest Algorithm," RFC =

               1321, April 1992. =

   [GMPLSSIG]  Ashwood-Smith, P., Banerjee, A., et al, "Generalized =

               MPLS - Signaling Functional Description," Internet Draft, =

               draft-ietf-mpls-generalized-signaling-06.txt, (work in =

               progress), October 2001. =

   [G707]      ITU-T G.707, "Network node interface for the synchronous =

               digital hierarchy (SDH)," March 1996. =

   [G783]      ITU-T G.783, "Characteristics of Synchronous Digital =

               Hierarchy (SDH) equipment functional blocks," October =

               2000. =

   [GR253]     GR-253-CORE, "Synchronous Optical Network (SONET) =

               Transport Systems: Common Generic Criteria," Telcordia =

  =

Everdingen et al                                             [Page 51] =

=0C
Internet Draft   draft-everdingen-ccamp-lmp-update-00        June 2002 =

 =

 =

               Technologies, Issue 3, September 2000. =

   [LSP-HIER]  Kompella, K. and Rekhter, Y., "LSP Hierarchy with MPLS =

               TE," Internet Draft, draft-ietf-mpls-lsp-hierarchy- =

               02.txt, (work in progress), February 2001. =

   [OIF-UNI]   The Optical Internetworking Forum, "UNI 1.0 Signaling =

               Specification", October, 2001. =

   [NDP-PPP]   J. Sadler et al, "Neighbor Discovery via PPP", Internet =

               draft draft-sadler-pppext-disc-01.txt, June 2002. =

    =

    =

17. =

   Authors' Addresses =

    =

      Michiel van Everdingen =

      Lucent Technologies =

      P.O. Box 18 =

      1270 AA Huizen =

      The Netherlands =

      Email: [email-masked] =

    =

      Greg Bernstein =

      Ciena Corporation =

      10480 Ridgeview Court =

      Cupertino, CA 94014 =

      Phone: (510) 573-2237 =

      Email: [email-masked] =

    =

  =

Everdingen et al                                             [Page 52] =

=0C
--------------1B116D1A6A920265DE0478CD--

Delivery-date: Wed, 19 Jun 2002 10:15:56 -0700
Date: Wed, 19 Jun 2002 10:06:30 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Ron Bonica <[email-masked]>
CC: [email-masked], GMPLS P&R Design Team <[email-masked]>
Subject: Re: FW: reminder if you have asked for or will ask for an agenda slot  inYokohama

Hi Ron and Kireeti:

Can you allocate the following for the Protection and
restoration design team drafts:

- Update on the terminology draft  - 5 minutes
  <draft-ietf-gmpls-recovery-terminology-00.txt>
  Speaker: Dimitri or Eric

- Update on the recovery analysis document - 5 minutes
  <draft-papadimitriou-ccamp-gmpls-recovery-analysis-01.txt>
  Speaker: Dimitri

- GMPLS recovery framework document - 10 minutes
  <draft-bala-gmpls-recovery-framework-00.txt>
  Speaker: Bala or Jonathan

Thanks

GMPLS P&R Design team

Ron Bonica wrote:

> This applies equally to the CCAMP WG
>
>                          Ron
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Loa
> > Andersson
> > Sent: Monday, June 17, 2002 9:12 AM
> > To: mpls wg; George Swallow; Scott Bradner
> > Subject: reminder if you have asked for or will ask for an agenda slot
> > in Yokohama
> >
> >
> > All,
> >
> > just a short reminder to those who have or are requesting agenda
> > slots at the MPLS WG in Yokohama. Please consider this when you
> > prepare for the meeting.
> >
> >
> >
> >          It is not the purpose of a WG session to have
> >          presentation of the content of a document. It
> >          is assumed that all attendees will have read the
> >          drafts in advance of the meeting.
> >
> >          For documents that are work-in-progress, the
> >          presentation should cover issues resolved since
> >          the last draft followed by open issues and
> >          controversial topics with the intent to reach a
> >          resolution of said issues and topics.
> >
> >          For new work items, the presentation should focus on
> >          what the problem is and why it is necessary for the
> >          work group to address it.  Further it should be either
> >          shown how it falls within the existing charter or why
> >          and how the charter should be extended to encompass it.
> >          The solution should only be sketched.
> >
> >          The appropriate way of bringing new work to the working
> >          group is to send a draft to the mailing list and promoting
> >          discussion on the list. Slots on the agenda should be used
> >          to discuss outstanding topics that has not be solved on the
> >          mailing list.
> >
> >          For new proposals addressing issues where
> >          work-in-progess the presentation should focus
> >          on the (perceived) short-fallings of the existing
> >          work and why those issues need to be addressed
> >          both in terms of why they are required and why they
> >          cannot be addressed in the existing work.
> >          the new work must be related to existing work (i.e.
> >          compatible, mutually exclusive, outright replacement).
> >          Finally, the new solution should be skechted,
> >          explaining how the solution overcomes those issues.
> >          The primary purpose of this last part is to allow commentary
> >          from the floor, it should not be orientented toward selling
> >          the idea.
> >
> >          In all cases only a limited number of slides should be used.
> >          Speakers should budget their at least 25% of their time to
> >          allow for questions.
> >
> > Loa and George
> >
> > --
> > Loa Andersson
> > Chief Architect,
> > Utfors Research, Architecture and Future Lab (URAX)
> > Utfors AB
> > Råsundavägen 12
> > Box 525, 169 29 Solna
> > Office          +46 8 5270 2000
> > Office direct   +46 8 5270 5038
> > Mobile          +46 70 848 5038
> > Email           [email-masked]
> > WWW             www.utfors.se
> >
> >

Delivery-date: Wed, 19 Jun 2002 03:12:46 -0700
Reply-To: "Oleg Allenov" <[email-masked]>
From: "Oleg Allenov" <[email-masked]>
To: "ccamp" <[email-masked]>
Subject: GMPLS LSP encoding 
Date: Wed, 19 Jun 2002 14:11:27 +0400
Organization: AMT Group

in draft-ietf-mpls-generalized-signaling-08.txt
section 3.1.1 
when defining  LSP Encoding Type
why do we differentiate between 1 - Packet and 2 - Ethernet?
Does not generic packet label request cover ethernet and all the other
packet technologies?

Cheers,
oleg

Delivery-date: Tue, 18 Jun 2002 07:41:01 -0700
Date: Tue, 18 Jun 2002 10:36:34 -0400
From: Zhi-Wei Lin <[email-masked]>
To: ccamp <[email-masked]>, [email-masked]
Subject: new draft: GMPLS for ASON

Hi all,

I've uploaded a new draft covering the GMPLS usage and extensions to 
support the ASON requirements. This document proposes appropriate 
extensions towards the resolution of additional requirements identified 
and communicated by the ITU-T in support of ITU's ASON standardization 
effort, and only provides the extensions for RSVP-TE signaling. Among 
the major extensions include support for the concept of "call", as well 
as support for setting up soft permanent connections.

http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt

Thanks
Zhi

Delivery-date: Mon, 17 Jun 2002 14:46:52 -0700
From: "Richard Rabbat" <[email-masked]>
To: "'Yangguang Xu'" <[email-masked]>
Cc: <[email-masked]>, "'Richard Rabbat'" <[email-masked]>
Subject: RE: questions of your draft
Date: Mon, 17 Jun 2002 14:45:03 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C2160D.90D29160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Yangguang,

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

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

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

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

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

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

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

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]] 
Sent: Sunday, June 16, 2002 3:08 PM
To: [email-masked]
Subject: questions of your draft

Richard,

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

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

Thanks,

Yangguang

------=_NextPart_000_000E_01C2160D.90D29160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Hi =
Yangguang,</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The protection path =
is set
up (e.g., path computation and label mapping) together with the working =
path
when the connection request arrives. However, protection paths are =
activated
and put into service after the network fault, assuming shared =
protection.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>With respect to the =
setting
up of the protection path, we do not change the end-to-end signaling =
using
RSVP-TE or CR-LDP. Only the activation process is done through =
flooding.&nbsp;
The rationale behind using end-to-end signaling for the setting up of =
the
protection path is that this is a process that is not bound by a certain =
time &nbsp;constraint.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>At activation time, =
assuming
a WDM network, ingress-initiated end-to-end signaling does not scale =
well and
cannot guarantee time bounds.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The scalability =
issue comes
into the picture because for every wavelength in a fiber, a notification
message would be needed using end-to-end signaling.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The issue with time =
bounds
is the amount of messages that are sent out. Let us assume a fiber cut
disrupted 128 wavelengths.&nbsp; Then, the 128th notification message =
from the
detecting NE will have to wait in the outgoing queue of that NE until =
all other
127 messages have been sent to their respective ingress LSRs.&nbsp; At =
every NE
in the network, again, in a WDM network, each NE may receive again from =
0 up to
128 notification signals to activate the protection path (including =
reconfiguration
of the switching core).&nbsp; Flooding requires less messages in the =
network
and ensures that only one message has to be processed at any NE, solving =
the
issue of buffering at every NE.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>In addition, the =
ability to
do the reconfiguration in parallel (if supported by the hardware) is =
allowed
through flooding, but not allowed by end-to-end signaling, since the =
signal may
only tell of one LSP activation.</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>You are correct in =
your assumption
that each NE has the knowledge of which path it is protecting. This is =
done
during the path setup phase.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Yangguang Xu
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Sunday, June
 16, 2002</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=3D2 face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>3:08 =
PM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> questions of =
your draft</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Richard,</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I was reading your =
&quot;Fault
Notification and Service Recovery Protocol&quot; draft. It's a very nice =
one.</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Several questions for me to =
fully
understand your reasoning for flooding the fault notifications. My
understanding&nbsp;of your proposal is that it&nbsp;doesn't need an =
end-to-end
signaling to set up the protecting path. Rather, the protecting path is =
set up
segment by segment triggered by the flooded notification messages. Am I =
right?
Also&nbsp;are you assume that each NE has the knowledge of which path it =
is
protecting?</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><br>
Thanks,</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Yangguang</span></font></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_000E_01C2160D.90D29160--

Delivery-date: Mon, 17 Jun 2002 09:59:56 -0700
Date: Mon, 17 Jun 2002 12:43:38 -0400
From: Ron Bonica <[email-masked]>
Subject: FW: reminder if you have asked for or will ask for an agenda slot in Yokohama
To: [email-masked]

This applies equally to the CCAMP WG

                         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Loa
> Andersson
> Sent: Monday, June 17, 2002 9:12 AM
> To: mpls wg; George Swallow; Scott Bradner
> Subject: reminder if you have asked for or will ask for an agenda s=
lot
> in Yokohama
>
>
> All,
>
> just a short reminder to those who have or are requesting agenda
> slots at the MPLS WG in Yokohama. Please consider this when you
> prepare for the meeting.
>
>
>
>          It is not the purpose of a WG session to have
>          presentation of the content of a document. It
>          is assumed that all attendees will have read the
>          drafts in advance of the meeting.
>
>          For documents that are work-in-progress, the
>          presentation should cover issues resolved since
>          the last draft followed by open issues and
>          controversial topics with the intent to reach a
>          resolution of said issues and topics.
>
>          For new work items, the presentation should focus on
>          what the problem is and why it is necessary for the
>          work group to address it.  Further it should be either
>          shown how it falls within the existing charter or why
>          and how the charter should be extended to encompass it.
>          The solution should only be sketched.
>
>          The appropriate way of bringing new work to the working
>          group is to send a draft to the mailing list and promoting
>          discussion on the list. Slots on the agenda should be used
>          to discuss outstanding topics that has not be solved on th=
e
>          mailing list.
>
>          For new proposals addressing issues where
>          work-in-progess the presentation should focus
>          on the (perceived) short-fallings of the existing
>          work and why those issues need to be addressed
>          both in terms of why they are required and why they
>          cannot be addressed in the existing work.
>          the new work must be related to existing work (i.e.
>          compatible, mutually exclusive, outright replacement).
>          Finally, the new solution should be skechted,
>          explaining how the solution overcomes those issues.
>          The primary purpose of this last part is to allow commenta=
ry
>          from the floor, it should not be orientented toward sellin=
g
>          the idea.
>
>          In all cases only a limited number of slides should be use=
d.
>          Speakers should budget their at least 25% of their time to
>          allow for questions.
>
> Loa and George
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           [email-masked]
> WWW             www.utfors.se
>
>

Delivery-date: Mon, 17 Jun 2002 09:52:09 -0700
content-class: urn:content-classes:message
Subject: RE: Question on LMP
Date: Mon, 17 Jun 2002 19:49:31 +0300
From: "Liran Siglat" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi,

Reading the following thread: =
http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00217.html
It seems that you have reached the decision that: "The source IP address =
identifies the originator of the LMP message".
Is this decision still standing ?
>From this decision I deduce that the LMP application MUST set the source =
ip-address of the packets it sends,
so the receiver would identify it and map it correctly to the =
control-channel,
(as opposed to letting it be chosen according to the interface through =
which the packet is sent).
This doesn't seem like the right thing to do, since the source =
ip-address in the IP header has its own uses.
If LMP runs over IP it shouldn't identify the originator of a LMP =
message according to fields in the IP header,
instead it should use its own identifiers (CCID) even in messages such =
as LinkSummary messages which are not
sent in the scope of a particular control channel.

Some clarification on the issue, will be great.
Thanks, Liran.

Delivery-date: Mon, 17 Jun 2002 05:57:05 -0700
Date: Mon, 17 Jun 2002 08:55:37 -0400
From: Dave McDysan <[email-masked]>
Subject: Reminder - Call for Presentations for  MPLS 2002: Oct. 27-29, Washington D.C.
To: Ppvpn <[email-masked]>, Ccamp <[email-masked]>, Mpls <[email-masked]>, Pwe3 <[email-masked]>

Dear Colleagues,

The MPLS 2002 Conference will be held in Washington D.C. from October 27
through October 29. See www.mpls2002.com for more information.

A group of industry experts on the Technical Program Committee is soliciting
presentation proposals for this conference. This note is a reminder that if
you wish to suggest a particular topic or a contribution please send a brief
proposal to the attention of the Technical Program Committee at
[email-masked] by June 21, 2002. See above web site for more details.

The program committee is looking for original and unpublished work to
continue the tradition initiated by this conference in 1998 of covering
cutting edge topics. They are solicting presentations from both the vendor
and service provider community on new technologies and operational
experience.

Regards,

David E. McDysan
WorldCom

Delivery-date: Sun, 16 Jun 2002 22:50:27 -0700
Date: Mon, 17 Jun 2002 11:12:25 +0530 (IST)
From: Chaya <[email-masked]>
To: <[email-masked]>
Subject: info about ctype

hi

	Should the C-type be same for the link id and
	interface id.

	or suppose can the link id be unnumbered and interface id
	be IPv4

	or is Ctype configurable for link id and interface id
	for each of  the messages which invloves it

	pls reply

thanks,
Chaya

Delivery-date: Sun, 16 Jun 2002 08:38:12 -0700
content-class: urn:content-classes:message
Subject: Out-of-fiber CCs
Date: Sun, 16 Jun 2002 18:34:12 +0300
From: "Liran Siglat" <[email-masked]>
To: <[email-masked]>

Hi,

Is there any point in having several out-of-fiber CCs?
I didn't find any point in this, since when the CC is out-of-fiber =
messages are sent to the configured Node-ID,
(so if one CC fails this actually means all the CCs have failed too).
Thanks, Liran.

Delivery-date: Sat, 15 Jun 2002 18:05:51 -0700
From: "Naidu, Venkata" <[email-masked]>
To: "'V'" <[email-masked]>, [email-masked]
Subject: RE: OSPF-TE question....
Date: Sat, 15 Jun 2002 21:00:22 -0400

Venkat,

-> Is this possible:
-> 
-> 
->          +------R1--------+
->          ^   Area 0       v
->          ^                v
->         N1                N5
->        /  \             /    \
->      /     \          /       \
->    N2  area N3------N6  area   N7
->      \  2   /         \   3   /
->       \    /            \    /
->         N4                N8
-> 
-> N1-N8 are OXC nodes.
-> R1 is a router providing control plane connectivity.
-> 
-> All Na-Nb links are TDM links and provide control plane 
-> connectivity except
-> N3-N6 where control plane connectivity is provided 
-> out-of-band. All Na-Nb links
-> have TE attributes that need to be advertised.
-> 
-> Links N1-R1-N5 are not TE links.
-> 
-> If the service provider requires that N1-N4 needs to be part 
-> of area 2 and N5-N8
-> be part of area 3:
-> 1. Can N3-N6 be advertised at all?

  A link (reachability or TE) must be in one and only one
  OSPF area. If you configure N3->N6 link in Area 2 and
  N6->N3 link in area 3, then N3 and N6 won't form any
  OSPF adjacency as per RFC2328. But N3 and N6 routers 
  *MAY* (depending on the implementation) advertise their
  respective links to respective areas.

  Finally, you will end up seeing unidirectional links 
  being advertised in Area 2 (N3->N6) and in Area 3 (N6->N3)
  TE topology database.

  Unlike, OSPF SPF, there is no *rule* for bi-directionality
  test in (G)MPLS CSPF. Again, you *MAY* (depending on the
  ingress LER CSPF) successful establish a uni-directional LSP
  to N3/N6 as egress LERs (depending on area 2 or 3 CSPF).

  You may get unpredictable results in case of multi-area TE
  approaches.

-> 2. Can you couple two area (2 and 3 in this example) from a 
-> TE topology point of view but not for the regular topology?

 You may want to look at:
 
http://www.ietf.org/internet-drafts/draft-venkata-ospf-te-only-option-00.txt

-> 3. Based on answers for 2 and 3, would N3 and N6 need to 
-> establish ospf adjacency?

  see answer to question 1.

--
Venkata.

Delivery-date: Fri, 14 Jun 2002 18:37:33 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: SUKLM doubt
Date: Tue, 11 Jun 2002 15:03:46 -0700

Hi All,
        In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when 
a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is 
not applicable and is set to zero. Does this means all the fields viz 
{SUKLM} should be zero ? Why not S value to be non-zero i.e. set to the 
lowest index in Nth multiplex (which will be 1) ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Fri, 14 Jun 2002 16:20:46 -0700
Date: Fri, 14 Jun 2002 15:23:51 -0700
From: V <[email-masked]>
To: [email-masked]
Subject: OSPF-TE question....

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Is this possible:

         +------R1--------+
         ^   Area 0       v
         ^                v
        N1                N5
       /  \             /    \
     /     \          /       \
   N2  area N3------N6  area   N7
     \  2   /         \   3   /
      \    /            \    /
        N4                N8

N1-N8 are OXC nodes.
R1 is a router providing control plane connectivity.

All Na-Nb links are TDM links and provide control plane connectivity except
N3-N6 where control plane connectivity is provided out-of-band. All Na-Nb links
have TE attributes that need to be advertised.

Links N1-R1-N5 are not TE links.

If the service provider requires that N1-N4 needs to be part of area 2 and N5-N8
be part of area 3:
1. Can N3-N6 be advertised at all?
2. Can you couple two area (2 and 3 in this example) from a TE topology point of
view but not for the regular topology?
3. Based on answers for 2 and 3, would N3 and N6 need to establish ospf
adjacency?

Please post your replies to the list.

Thanks
- Venkat.

Delivery-date: Fri, 14 Jun 2002 10:43:27 -0700
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Question Re: Path State Removed in Path Err
Date: Fri, 14 Jun 2002 13:39:19 -0400

In section 7.2.1 of draft-ietf-mpls-generalized-rsvp-te-07.txt it says:

7.2.1. Deletion procedure

   In some circumstances, particularly optical networks, it is useful to
   set the administrative status of an LSP before tearing it down.  In
   such circumstances the procedure SHOULD be followed when deleting an
   LSP from the ingress:

   1.  The ingress node precedes an LSP deletion by inserting an Admin
       Status Object in a Path message and setting the Reflect (R) and
       Delete (D) bits.

   2.  Transit and egress nodes process the Admin Status Object as
       described above.  (Alternatively, the egress MAY respond with
       a PathErr message with the Path_State_Removed flag set, see
       section 4.4.)

   3.  Upon receiving the Admin Status Object with the Delete (D) bit set
       in the Resv message, the ingress node sends a PathTear message
       downstream to remove the LSP and normal RSVP processing takes place.

I presume that a Resv Tear would also be a legal alternative in step 2? If
so, would the same node be required to send a Path Tear downstream, or would
a Path w/D bit and R bit set be ok?

Thanks

Michael Mandelberg
FirstWave ION

Delivery-date: Fri, 14 Jun 2002 09:39:05 -0700
From: "Richard Rabbat" <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "'Richard Rabbat'" <[email-masked]>
Subject: RE: Agenda
Date: Fri, 14 Jun 2002 09:36:08 -0700

Hi Ron, Kireeti,

I would like to request a 5-10 min slot for the following ID:
"Fault Notification and Service Recovery Protocol"
available as of today at:

http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-prot
ocol-00.txt

Abstract  
    
   This draft describes a fault notification and service recovery 
   protocol that can be used in GMPLS-enabled networks to achieve 
   bounded time activation of protection paths in the case of single 
   failures. It presents a complete solution to the problem and 
   justifies choices made for the notification method, extensions 
   required to current algorithms and protocols and any security and 
   deployment issues.

For those interested in some of simulation results using this approach,
please refer to the white paper posted at:
http://perth.mit.edu/~richard/wp-ietf-fault-notification.pdf

Best,
Richard.
--
Richard Rabbat, Ph.D.
Fujitsu Laboratories of America, Inc
595 Lawrence Expressway
Sunnyvale, CA 94085
Phone: 1-408-530-4537
Fax: 1-408-530-4515

Delivery-date: Fri, 14 Jun 2002 04:34:59 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-03.txt
Date: Fri, 14 Jun 2002 07:29:55 -0400

--NextPart

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

	Title		: Crankback Routing Extensions for MPLS Signaling
	Author(s)	: A. Iwata, N. Fujita, G. Ash, 
                          A. Farrel, S. Marshall-Unitt
	Filename	: draft-iwata-mpls-crankback-03.txt
	Pages		: 31
	Date		: 13-Jun-02
	
This draft proposes crankback routing extensions for CR-LDP signaling
and for RSVP-TE signaling. Recently, several routing protocol
extensions for advertising resource information in addition to
topology information have been proposed for use in distributed
constraint-based routing. In such a distributed routing environment,
however, the information used to compute a constraint-based path may
be out of date. This means that LSP setup requests may be blocked by
links or nodes without sufficient resources. This draft specifies
crankback routing extensions for CR-LDP and RSVP-TE so that the label
request can be retried on an alternate path that detours around the
blocked link or node upon a setup failure. Furthermore, the crankback
routing schemes can also be applied to LSP restoration by indicating
the location of the failure link or node. This would significantly
improve the successful recovery ratio for failed LSPs, especially in
situations where a large number of setup requests are triggered at
the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-iwata-mpls-crankback-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-iwata-mpls-crankback-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-iwata-mpls-crankback-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Fri, 14 Jun 2002 04:34:53 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-rabbat-fault-notification-protocol-00.txt
Date: Fri, 14 Jun 2002 07:29:46 -0400

--NextPart

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

	Title		: A Fault Notification and Service Recovery Protocol
	Author(s)	: R. Rabbat et al.
	Filename	: draft-rabbat-fault-notification-protocol-00.txt
	Pages		: 18
	Date		: 13-Jun-02
	
This draft describes a fault notification and service recovery 
protocol that can be used in GMPLS-enabled networks to achieve 
bounded time activation of protection paths in the case of single 
failures. It presents a complete solution to the problem and 
justifies choices made for the notification method, extensions 
required to current algorithms and protocols and any security and 
deployment issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rabbat-fault-notification-protocol-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rabbat-fault-notification-protocol-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-rabbat-fault-notification-protocol-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rabbat-fault-notification-protocol-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 13 Jun 2002 19:48:18 -0700
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Subject: How to choose TBA Class-Nums
Date: Tue, 11 Jun 2002 17:36:51 -0400

For example, the Label_Set object has Class-Num 0bbbbbbb. Are these intended
to be vendor specific?

Thanks

Delivery-date: Thu, 13 Jun 2002 17:03:35 -0700
Date: Thu, 13 Jun 2002 19:52:25 -0400
From: Ron Bonica <[email-masked]>
Subject: WG last call: draft-ietf-ccamp-gmpls-sonet-sdh-05
To: [email-masked]

Folks,

This email is a last call for comments regarding
draft-ietf-ccamp-gmpls-sonet-sdh-05. The WG last call period will end two
weeks from today, on June 27th at 23:59 EDT.

Please restrict comments to the deltas between the previous and current
draft versions.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Entia non sunt multiplicanda sine necessitate."
                -- William of Ockham

Delivery-date: Thu, 13 Jun 2002 16:53:18 -0700
Date: Thu, 13 Jun 2002 19:42:18 -0400
From: Ron Bonica <[email-masked]>
Subject: WG Last Call: draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03
To: [email-masked]

Folks,

This email is a last call for comments regarding
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03. The WG last call period will
end two weeks from today, on June 27th at 23:59 EDT.

Please restrict comments to the deltas between the previous and current
draft versions.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Entia non sunt multiplicanda sine necessitate."
                -- William of Ockham

Delivery-date: Thu, 13 Jun 2002 16:50:39 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-01.txt
Date: Wed, 12 Jun 2002 07:12:45 -0400

--NextPart

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

	Title		: Generalized MPLS Signalling Extensions for G.709 
                          Optical Transport Networks Control
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-g709-01.txt
	Pages		: 20
	Date		: 11-Jun-02
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN
developments.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-g709-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Thu, 13 Jun 2002 16:43:43 -0700
Date: Thu, 13 Jun 2002 19:32:13 -0400
From: Ron Bonica <[email-masked]>
Subject: WG Last Call: draft-ietf-ccamp-gmpls-architecture-02
To: [email-masked]

Folks,

This email is a last call for comments regarding
draft-ietf-ccamp-gmpls-architecture-02. The WG last call period will end two
weeks from today, on June 27th at 23:59 EDT.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Entia non sunt multiplicanda sine necessitate."
                -- William of Ockham

Delivery-date: Thu, 13 Jun 2002 15:46:58 -0700
From: Jonathan Lang <[email-masked]>
To: 'Baktha Muralidharan' <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-ccamp-lmp-04.txt
Date: Thu, 13 Jun 2002 15:37:28 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2132A.E5B65080
Content-Type: text/plain;
	charset="iso-8859-1"

Baktha,
  The lmp-04 draft is an authors-only preview. If you still have questions
after it has been submitted, please feel free to post them.
  
Thanks,
Jonathan

-----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Thursday, June 13, 2002 12:51 PM
To: Jonathan Lang
Cc: [email-masked]
Subject: Comments on draft-ietf-ccamp-lmp-04.txt

Hi Jonathan

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

Regards,
/Baktha

==========================================================================
1.

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

..."

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

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

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

3.

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

4.

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

5.

Baktha> State that the retry limit is a local configuration parameter.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 5.00.3504.2500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D601552922-13062002>Baktha,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D601552922-13062002>&nbsp;=20
The lmp-04 draft is an authors-only preview. If you still have =
questions after=20
it has been submitted, please feel free to post =
them.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D601552922-13062002>&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D601552922-13062002>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D601552922-13062002>Jonathan</SPAN></FONT></DIV></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Baktha =
Muralidharan=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, June 13, 2002 =
12:51=20
  PM<BR><B>To:</B> Jonathan Lang<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Comments on=20
  draft-ietf-ccamp-lmp-04.txt<BR><BR></DIV></FONT><FONT=20
  face=3D"Courier New, Courier">Hi =
Jonathan<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Please see my comments on ccamp-lmp-04 below, prefixed=20
  =
Baktha&gt;<BR><BR>Regards,<BR>/Baktha<BR><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>1.<BR><BR>"...<BR=
>10.2.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp; Retransmission Algorithm =
<BR>&nbsp;&nbsp;&nbsp;=20
  <BR>&nbsp;&nbsp; After a node transmits a message requiring =
acknowledgement,=20
  it <BR>&nbsp;&nbsp; should immediately schedule a retransmission =
after Ri=20
  seconds.&nbsp; If a <BR>&nbsp;&nbsp; corresponding acknowledgement =
message is=20
  received before Ri seconds, <BR>&nbsp;&nbsp; then message =
retransmission=20
  SHOULD be canceled.&nbsp; Otherwise, it will <BR>&nbsp;&nbsp; =
retransmit the=20
  message after (1+Delta)*Ri seconds.&nbsp; =
The<BR><BR>..."<BR><BR>Baktha&gt;=20
  Shouldn't the first retransmission be after Ri seconds, rather than=20
  (1+Delta)*Ri ?<BR><BR></FONT><FONT=20
  face=3D"Arial, =
Helvetica">2.<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
</X-TAB></FONT><FONT=20
  face=3D"Courier New, Courier">"...<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Prior to=20
  initial transmission, initialize Rk =3D Ri and Rn =3D 0.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  while (Rn++ &lt; Rl) { <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
transmit=20
  the message; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; wake up =
after Rk=20
  milliseconds; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rk =3D =
Rk * (1 +=20
  Delta); <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* acknowledged message or no =
reply from=20
  receiver and Rl <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
reached*/<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>..."<BR><BR>Baktha&gt;=20
  It is not clear if the initial transmission happens before entering =
the=20
  [while] loop or<BR>Baktha&gt; inside the loop. If the initial =
transmission=20
  happens happens inside the loop, we want<BR>Baktha&gt; the while =
condition to=20
  be (Rn++ &lt;=3D Rl)<BR><BR></FONT><FONT=20
  face=3D"Arial, Helvetica">3.<BR><BR>Baktha&gt; I assume that the =
backoff=20
  procedure applicable to ALL LMP procedures; might want to state this=20
  explicitly.<BR><BR>4.<BR><BR>Baktha&gt; If the response to an LMP =
message is=20
  received within "rk" milliseconds, it is accepted and the =
retransmission is=20
  cancelled.<BR>Baktha&gt; I believe that this renders the timeout =
period=20
  insignificant.<BR><BR>5.<BR><BR>Baktha&gt; State that the retry limit =
is a=20
  local configuration parameter.<BR></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01C2132A.E5B65080--

Delivery-date: Thu, 13 Jun 2002 13:21:10 -0700
From: "Bhargava, Nidhi" <[email-masked]>
To: 'Baktha Muralidharan' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-ccamp-lmp-04.txt
Date: Thu, 13 Jun 2002 16:14:29 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21316.EC581900
Content-Type: text/plain;
	charset="iso-8859-1"

Baktha,
I couldn't find draft-ietf-ccamp-lmp-04.txt on the IETF site. Can you please
give the link
for the same.
Thanks
Nidhi
------------------------------- 
Nidhi Bhargava 
NetPlane Systems Inc. 
A Mindspeed Technologies Company 
Tel:   + 1.781.329.3200 x5353 
Web:   http://www.netplane.com <http://www.netplane.com/>  

 -----Original Message-----
From: Baktha Muralidharan [mailto:[email-masked]]
Sent: Thursday, June 13, 2002 3:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-ietf-ccamp-lmp-04.txt

Hi Jonathan

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

Regards,
/Baktha

==========================================================================
1.

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

..."

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

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

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

3.

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

4.

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

5.

Baktha> State that the retry limit is a local configuration parameter.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D651081520-13062002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Baktha,</FONT></SPAN></DIV>
<DIV><SPAN class=3D651081520-13062002><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
couldn't find  draft-ietf-ccamp-lmp-04.txt on the IETF site. Can you=20
please&nbsp;give the&nbsp;link</FONT></SPAN></DIV>
<DIV><SPAN class=3D651081520-13062002><FONT face=3DArial =
color=3D#0000ff size=3D2>for=20
the same.</FONT></SPAN></DIV>
<DIV><SPAN class=3D651081520-13062002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D651081520-13062002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Nidhi</FONT></SPAN></DIV>
<DIV><SPAN class=3D651081520-13062002></SPAN><SPAN =
class=3D651081520-13062002><FONT=20
face=3D"Courier New" size=3D2>-------------------------------</FONT> =
<BR><FONT=20
face=3D"Courier New" size=3D2>Nidhi Bhargava</FONT> <BR><FONT =
face=3D"Courier New"=20
size=3D2>NetPlane Systems Inc.</FONT> <BR><FONT face=3D"Courier New" =
size=3D2>A=20
Mindspeed Technologies Company</FONT> <BR><FONT face=3D"Courier New"=20
size=3D2>Tel:&nbsp;&nbsp; + 1.781.329.3200 x5353</FONT> <BR><FONT=20
face=3D"Courier New" size=3D2>Web:&nbsp;&nbsp; <A =
href=3D"http://www.netplane.com/"=20
target=3D_blank>http://www.netplane.com</A></FONT> </DIV></SPAN>
<DIV><SPAN class=3D651081520-13062002>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV></SPAN><FONT face=3DTahoma><BR><FONT size=3D2><SPAN=20
class=3D651081520-13062002><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Baktha Muralidharan [mailto:[email-masked]]<BR><B>Sent:</B> =
Thursday, June=20
13, 2002 3:51 PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B>=20
[email-masked]<BR><B>Subject:</B> Comments on=20
draft-ietf-ccamp-lmp-04.txt<BR><BR></FONT></FONT></DIV></DIV>
<BLOCKQUOTE><FONT face=3D"Courier New, Courier">Hi=20
  Jonathan<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please see my comments =
on=20
  ccamp-lmp-04 below, prefixed=20
  =
Baktha&gt;<BR><BR>Regards,<BR>/Baktha<BR><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>1.<BR><BR>"...<BR=
>10.2.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp; Retransmission Algorithm =
<BR>&nbsp;&nbsp;&nbsp;=20
  <BR>&nbsp;&nbsp; After a node transmits a message requiring =
acknowledgement,=20
  it <BR>&nbsp;&nbsp; should immediately schedule a retransmission =
after Ri=20
  seconds.&nbsp; If a <BR>&nbsp;&nbsp; corresponding acknowledgement =
message is=20
  received before Ri seconds, <BR>&nbsp;&nbsp; then message =
retransmission=20
  SHOULD be canceled.&nbsp; Otherwise, it will <BR>&nbsp;&nbsp; =
retransmit the=20
  message after (1+Delta)*Ri seconds.&nbsp; =
The<BR><BR>..."<BR><BR>Baktha&gt;=20
  Shouldn't the first retransmission be after Ri seconds, rather than=20
  (1+Delta)*Ri ?<BR><BR></FONT><FONT=20
  face=3D"Arial, =
Helvetica">2.<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
</X-TAB></FONT><FONT=20
  face=3D"Courier New, Courier">"...<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Prior to=20
  initial transmission, initialize Rk =3D Ri and Rn =3D 0.=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  while (Rn++ &lt; Rl) { <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
transmit=20
  the message; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; wake up =
after Rk=20
  milliseconds; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rk =3D =
Rk * (1 +=20
  Delta); <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* acknowledged message or no =
reply from=20
  receiver and Rl <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
reached*/<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>..."<BR><BR>Baktha&gt;=20
  It is not clear if the initial transmission happens before entering =
the=20
  [while] loop or<BR>Baktha&gt; inside the loop. If the initial =
transmission=20
  happens happens inside the loop, we want<BR>Baktha&gt; the while =
condition to=20
  be (Rn++ &lt;=3D Rl)<BR><BR></FONT><FONT=20
  face=3D"Arial, Helvetica">3.<BR><BR>Baktha&gt; I assume that the =
backoff=20
  procedure applicable to ALL LMP procedures; might want to state this=20
  explicitly.<BR><BR>4.<BR><BR>Baktha&gt; If the response to an LMP =
message is=20
  received within "rk" milliseconds, it is accepted and the =
retransmission is=20
  cancelled.<BR>Baktha&gt; I believe that this renders the timeout =
period=20
  insignificant.<BR><BR>5.<BR><BR>Baktha&gt; State that the retry limit =
is a=20
  local configuration parameter.<BR></BLOCKQUOTE></FONT></BODY></HTML>

------_=_NextPart_001_01C21316.EC581900--

Delivery-date: Thu, 13 Jun 2002 12:52:21 -0700
Date: Thu, 13 Jun 2002 15:51:20 -0400
To: [email-masked]
From: Baktha Muralidharan <[email-masked]>
Subject: Comments on draft-ietf-ccamp-lmp-04.txt
Cc: [email-masked]

--=====================_23405565==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Jonathan

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

Regards,
/Baktha

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

=93=85
10.2.
      Retransmission Algorithm

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

=85=94

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

2.
         =93=85
       Prior to initial transmission, initialize Rk =3D Ri and Rn =3D 0.

       while (Rn++ < Rl) {
         transmit the message;
         wake up after Rk milliseconds;
         Rk =3D Rk * (1 + Delta);
       }
       /* acknowledged message or no reply from receiver and Rl
       reached*/
         =85=94

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

3.

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

4.

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

5.

Baktha> State that the retry limit is a local configuration parameter.

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

<html>
<font face=3D"Courier New, Courier">Hi Jonathan<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please see my comments on ccamp-lmp-04
below, prefixed Baktha&gt;<br>
<br>
Regards,<br>
/Baktha<br>
<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>
1.<br>
<br>
=93=85<br>
10.2. <br>
&nbsp;&nbsp;&nbsp;&nbsp; Retransmission Algorithm <br>
&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; After a node transmits a message requiring acknowledgement,
it <br>
&nbsp;&nbsp; should immediately schedule a retransmission after Ri
seconds.&nbsp; If a <br>
&nbsp;&nbsp; corresponding acknowledgement message is received before Ri
seconds, <br>
&nbsp;&nbsp; then message retransmission SHOULD be canceled.&nbsp;
Otherwise, it will <br>
&nbsp;&nbsp; retransmit the message after (1+Delta)*Ri seconds.&nbsp;
The<br>
<br>
=85=94<br>
<br>
Baktha&gt; Shouldn=92t the first retransmission be after Ri seconds, rather
than (1+Delta)*Ri ?<br>
<br>
</font><font face=3D"Arial, Helvetica">2.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font=
 face=3D"Courier New, Courier">=93=85<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Prior to initial transmission, initialize
Rk =3D Ri and Rn =3D 0. <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while (Rn++ &lt; Rl) { <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transmit the message; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; wake up after Rk milliseconds;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rk =3D Rk * (1 + Delta); <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* acknowledged message or no reply from
receiver and Rl <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reached*/<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>=85=94<br>
<br>
Baktha&gt; It is not clear if the initial transmission happens before
entering the [while] loop or<br>
Baktha&gt; inside the loop. If the initial transmission happens happens
inside the loop, we want<br>
Baktha&gt; the while condition to be (Rn++ &lt;=3D Rl)<br>
<br>
</font><font face=3D"Arial, Helvetica">3.<br>
<br>
Baktha&gt; I assume that the backoff procedure applicable to ALL LMP
procedures; might want to state this explicitly.<br>
<br>
4.<br>
<br>
Baktha&gt; If the response to an LMP message is received within =93rk=94
milliseconds, it is accepted and the retransmission is cancelled.<br>
Baktha&gt; I believe that this renders the timeout period
insignificant.<br>
<br>
5.<br>
<br>
Baktha&gt; State that the retry limit is a local configuration
parameter.<br>
</font></html>

--=====================_23405565==_.ALT--

Envelope-to: [email-masked]
Delivery-date: Thu, 13 Jun 2002 12:19:51 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: MPLS Management Overview
Date: Thu, 13 Jun 2002 15:14:18 -0400

Hi,
A new version of the MPLS Management Overview has been posted.
Discussion on the MPLS WG mailing list.

Main changes are an increase in detail and a description of the inter-relation
between MIB modules, and between MIB tables.

http://search.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-02.txt

Adrian

Delivery-date: Wed, 12 Jun 2002 14:55:31 -0700
From: Jonathan Lang <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
Date: Wed, 12 Jun 2002 14:44:19 -0700

Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 10:02 AM
> To: Jonathan Lang; [email-masked]'
> Cc: Razdan, Rajender
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi Jonathan, in response to some of your points and questions:
> 
> (a) G.7714.1 is new work on automatic discovery specific to SDH/G.709
> approved to move forward at the meeting in Geneva. It starts with OIF UNI
> discovery as a base and will modify as appropriate.  I expect
contributions
> on this to come into the T1X1 meeting next week in Greensboro NC.  Maybe
you
> can come out and discuss. 
Thanks. I misinterpreted you previous email to indicate that G.7714.1 was
more than a statement of work.

> 
> (b) Protocol mechanisms can be very similar but their use much different.
> For example in-band/in-fiber OIF-UNI discovery only uses the
> CONFIG/CONFIG_ACK with the CCID set to the port number.  Periodic hellos
> aren't needed (we have many ways of telling whether the DCCs are working).
> Link verification isn't needed since it gets included with the
> config/config-ack.  Hence this seems quite different from the intent
within
> the LMP draft.
LMP consists of 4 pieces: control channel management, link property
correlation, link verification, and fault management. The link verification
and fault management procedures are optional. In addition, the fast
keep-alives (i.e. periodic Hellos) of control channel management are also
optional.

Per OIF UNI 1.0 Discovery section (Section 8), LMP Control channel
management and LMP link property correlation are required, link verification
is optional, and fault management isn't used. The periodic Hellos of control
channel management are also optional.

> 
> (c) Concerning J0, section DCC, line DCC: Each of these is a different
> mechanism with different pros and cons.  In addition, J0 and section DCC
> apply at a different layer than line DCC.  This is also true for J1 (path
> trace), J2 (vt path trace).  The transport network is layered and hence
the
> notion of "layer adjacency discovery" in G.7714 or of multi-layer
discovery
> as discussed in OIF2000.159v2.
Exactly, see section 5.3 of draft-lang-ccamp-lmp-bootstrap-00.txt.

> 
> (d) What mechanism to use at which layer (TTP or CTP, i.e., trail or test
> signal) depends somewhat on the layers involved.  There are subtleties
with
> the SONET/SDH overhead and practical implementations.
see above comment.

> For example, I'd
> really like a "line trace", like we have a section trace (J0) and a path
> trace (J1), but its not there.  Hence, why I think these types of
> discussions belong at T1/ITU-T.
How does this relate to LMP?

> 
> (e) I didn't see pre-OTN transparent work such as LMP and LMP-DWDM
including
> previously standardized technologies such as SONET, SDH and G.709.  I
really
> don't see LMP applying to these technologies in its current incarnation. I
> think performance monitoring, fault management, automated discovery,
control
> channel management for these technologies belongs in a different forum.
Are you saying you didn't read the OIF UNI 1.0?

> 
> (f) I thought that the LMP messages were going to go over UDP. The latest
> draft (I've got) still says IP. Was a decision reversed?
No, the decision was not reversed.

-Jonathan

> 
> Greg
> 
> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 4:06 PM
> To: Bernstein, Greg; [email-masked]
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Greg,
> 
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 3:51 PM
> > To: Jonathan Lang; [email-masked]
> > Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> > 
> > 
> > Hi Jonathan,
> > I understand this is addressing the In-band/In-fiber case, 
> like we did at
> > with the OIF UNI, but the mechanism seems different.  
> Particularly in the
> > case of line or section DCC (the case most of us have 
> already implemented
> > and interoperated with).
> The ID we submitted addresses the Out-of-band/out-of-fiber 
> case. The ib/if
> case is already supported in LMP today (the OIF UNI 1.0 is 
> aligned with
> LMP).
> 
> > 
> > For a trail trace mechanism, i.e., you mention using J0.  
> If I recall this
> > doesn't solve George Swallows problem of a "dumb mux" 
> between a router and
> a
> > SONET/SDH switch. I think J1 (path trace) was the solution 
> we discussed
> way
> > back then. I think Michiel's e-mail probably summarized 
> some of this best
> an
> > proposed a more general solution. 
> The ID we submitted supports multiple options. J0 is but one.
> 
> > However, I still think mucking with this
> > part of the SONET/SDH signal needs to be done at ITU-T.  For the
> > transparent/pre-OTN stuff we could leave it with CCAMP 
> along with WDM-LMP.
> SONET/SDH & GigE are included in pre-OTN.
> 
> > 
> > I did a check on OIF2000.089 and found the following:    
> > oif2000.089.00 -
> > OIF OAM&P Working Group - Living List Author: Ren Wu     
> > Company: Lucent
> > Technologies Date created: 04/24/2000     Date updated: 
> > 04/24/2000 Working
> > group(s): OAM&P
> > Abstract: The OIF OAM&P Working Group met on January 21 - 
> > February 1, 2000
> > in New Orleans, LA. The OAM&P WG Living List was updated during this
> > meeting. The updated Living List includes two additional 
> > issues (readline).
> > In addition, it was agreed to expa...
> > 
> > This doesn't seem like the right reference.  I saw Michiel 
> referencing
> > OIF2000.159v2 some of my old work at OIF along these lines...
> 
> Ooops. This should be oif2000.289
> 
> Did you get a chance to post G.7714.1?
> 
> -Jonathan
> 
> > 
> > Greg
> > 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 3:08 PM
> > To: Bernstein, Greg; [email-masked]
> > Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> > ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> > 
> > 
> > Greg,
> > 
> > > -----Original Message-----
> > > From: Bernstein, Greg [mailto:[email-masked]]
> > > Sent: Tuesday, June 11, 2002 8:40 AM
> > > To: [email-masked]
> > > Subject: Comparision to OIF UNI discovery? RE: I-D
> > > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> > > 
> > > 
> > > Hi John, Jonathan and Dimitri.  How does this compare to 
> > the OIF UNI auto
> > > discovery.  I recall that John and Jonathan were 
> co-authors on that
> > > specification.  At first glance this looks like a different 
> > approach. Do
> > we
> > > need another approach?
> > The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
> > channels. As mentioned in this ID, a proposal for bootstraping
> > out-of-fiber/out-of-band control channels was originally 
> > submitted to the
> > OIF as oif2000.089.0, but was defered for a later version 
> of the UNI.
> > 
> > This ID is basically that proposal with more details fleshed 
> > out. We decided
> > to submit it as an ID because of the recent interest on the list.
> > 
> > This proposal is consistent with the if/ib case described in 
> > UNI 1.0 and
> > supported in the base LMP document. (This is mentioned in the 
> > Introduction
> > to this ID - I'm not sure if you read introductions.)
> > 
> > > 
> > > Also this seems fairly focused on SDH/G.709 type signals, 
> > i.e., trail
> > traces
> > > and DCC channels.  ITU-T already has work underway in the form of
> > G.7714.1.
> > > A liason has already been sent to IETF from ITU-T.
> > > 
> > > It seems to me that this work is better done as part of 
> > that effort, at
> > > least the SDH/G.709 aspects of it, since its technology 
> specific and
> > > suggests reusing channels/mechanisms that are defined for 
> > other functions
> > by
> > > the ITU-T.
> > In the liason, it states, "Draft new Recommendation G.7714.1, 
> > which is based
> > on the OIF UNI 1.0 neighbour and service discovery 
> > specification and will be
> > developed to meet the protocol neutral discovery requirements in
> > Recommendation G.7714".
> > 
> > Since the OIF UNI 1.0 neighbor and service discovery spec. is 
> > based on LMP,
> > I think it is quite appropriate to do this work where LMP is 
> > being defined. 
> > 
> > (I couldn't find a version of G.7714.1. If there is a current 
> > version, can
> > you please post it.)
> > 
> > -Jonathan
> > 
> > > 
> > > Greg B.
> > > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, June 11, 2002 4:06 AM
> > > To: IETF-Announce; @[email-masked]
> > > Cc: [email-masked]
> > > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> > > 
> > > 
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > 
> > > 
> > > 	Title		: Control Channel Bootstrap for LMP
> > > 	Author(s)	: J. Lang, J. Drake
> > > 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> > > 	Pages		: 7
> > > 	Date		: 10-Jun-02
> > > 	
> > > The Link Management Protocol (LMP) requires that at least one bi-
> > > directional control channel is established between the nodes. The 
> > > control channel may be transmitted either in-band with the data 
> > > links or out-of-band over a separate wavelength, fiber, or IP 
> > > network. This draft specifies a simple procedure to dynamically 
> > > bootstrap control channels and exchange interface 
> mappings using a 
> > > new LMP message that is transmitted in-band over the data links.
> > > 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> > trap-00.txt
> > 
> > To remove yourself from the IETF Announcement list, send a 
> message to 
> > ietf-announce-request with the word unsubscribe in the body 
> > of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> > with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-lang-ccamp-lmp-bootstrap-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> 

Delivery-date: Wed, 12 Jun 2002 11:12:38 -0700
Date: Wed, 12 Jun 2002 20:10:33 +0200
From: [email-masked]
Organization: Alcatel Bell - Optical NA (Antwerpen)
To: manoj juneja <[email-masked]>
CC: [email-masked]
Subject: Re: SUKLM doubt

manoj,

see in-line...

manoj juneja wrote:
> 
> Hi All,
>         In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when
> a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is
> not applicable and is set to zero. Does this means all the fields viz
> {SUKLM} should be zero ? 

well, this seems at least and as indicated clear that all values are 
set to zero

Why not S value to be non-zero i.e. set to the
> lowest index in Nth multiplex (which will be 1) ?

because in this case internal structure (as pointed by the label) is not
applicable that's why you see "the label is not applicable", in the text
we have already received several comments on this item and the sentence
should be understood as "the {SUKLM} label is not applicable" i will try
to clarify this... 

- dimitri.
 
> Regards,
> manoj.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Wed, 12 Jun 2002 10:22:54 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Razdan, Rajender" <[email-masked]>
Subject: RE: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
Date: Wed, 12 Jun 2002 10:02:26 -0700

Hi Jonathan, in response to some of your points and questions:

(a) G.7714.1 is new work on automatic discovery specific to SDH/G.709
approved to move forward at the meeting in Geneva. It starts with OIF UNI
discovery as a base and will modify as appropriate.  I expect contributions
on this to come into the T1X1 meeting next week in Greensboro NC.  Maybe you
can come out and discuss. 

(b) Protocol mechanisms can be very similar but their use much different.
For example in-band/in-fiber OIF-UNI discovery only uses the
CONFIG/CONFIG_ACK with the CCID set to the port number. Periodic hellos
aren't needed (we have many ways of telling whether the DCCs are working).
Link verification isn't needed since it gets included with the
config/config-ack.  Hence this seems quite different from the intent within
the LMP draft.

(c) Concerning J0, section DCC, line DCC: Each of these is a different
mechanism with different pros and cons.  In addition, J0 and section DCC
apply at a different layer than line DCC.  This is also true for J1 (path
trace), J2 (vt path trace).  The transport network is layered and hence the
notion of "layer adjacency discovery" in G.7714 or of multi-layer discovery
as discussed in OIF2000.159v2.

(d) What mechanism to use at which layer (TTP or CTP, i.e., trail or test
signal) depends somewhat on the layers involved.  There are subtleties with
the SONET/SDH overhead and practical implementations.  For example, I'd
really like a "line trace", like we have a section trace (J0) and a path
trace (J1), but its not there.  Hence, why I think these types of
discussions belong at T1/ITU-T.

(e) I didn't see pre-OTN transparent work such as LMP and LMP-DWDM including
previously standardized technologies such as SONET, SDH and G.709.  I really
don't see LMP applying to these technologies in its current incarnation. I
think performance monitoring, fault management, automated discovery, control
channel management for these technologies belongs in a different forum.

(f) I thought that the LMP messages were going to go over UDP. The latest
draft (I've got) still says IP. Was a decision reversed?

Greg

-----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 4:06 PM
To: Bernstein, Greg; [email-masked]
Subject: RE: Comparision to OIF UNI discovery? RE: I-D
ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt

Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3:51 PM
> To: Jonathan Lang; [email-masked]
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi Jonathan,
> I understand this is addressing the In-band/In-fiber case, like we did at
> with the OIF UNI, but the mechanism seems different.  Particularly in the
> case of line or section DCC (the case most of us have already implemented
> and interoperated with).
The ID we submitted addresses the Out-of-band/out-of-fiber case. The ib/if
case is already supported in LMP today (the OIF UNI 1.0 is aligned with
LMP).

> 
> For a trail trace mechanism, i.e., you mention using J0.  If I recall this
> doesn't solve George Swallows problem of a "dumb mux" between a router and
a
> SONET/SDH switch. I think J1 (path trace) was the solution we discussed
way
> back then. I think Michiel's e-mail probably summarized some of this best
an
> proposed a more general solution. 
The ID we submitted supports multiple options. J0 is but one.

> However, I still think mucking with this
> part of the SONET/SDH signal needs to be done at ITU-T.  For the
> transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP.
SONET/SDH & GigE are included in pre-OTN.

> 
> I did a check on OIF2000.089 and found the following:    
> oif2000.089.00 -
> OIF OAM&P Working Group - Living List Author: Ren Wu     
> Company: Lucent
> Technologies Date created: 04/24/2000     Date updated: 
> 04/24/2000 Working
> group(s): OAM&P
> Abstract: The OIF OAM&P Working Group met on January 21 - 
> February 1, 2000
> in New Orleans, LA. The OAM&P WG Living List was updated during this
> meeting. The updated Living List includes two additional 
> issues (readline).
> In addition, it was agreed to expa...
> 
> This doesn't seem like the right reference.  I saw Michiel referencing
> OIF2000.159v2 some of my old work at OIF along these lines...

Ooops. This should be oif2000.289

Did you get a chance to post G.7714.1?

-Jonathan

> 
> Greg
> 
> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3:08 PM
> To: Bernstein, Greg; [email-masked]
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Greg,
> 
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 8:40 AM
> > To: [email-masked]
> > Subject: Comparision to OIF UNI discovery? RE: I-D
> > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> > 
> > 
> > Hi John, Jonathan and Dimitri.  How does this compare to 
> the OIF UNI auto
> > discovery.  I recall that John and Jonathan were co-authors on that
> > specification.  At first glance this looks like a different 
> approach. Do
> we
> > need another approach?
> The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
> channels. As mentioned in this ID, a proposal for bootstraping
> out-of-fiber/out-of-band control channels was originally 
> submitted to the
> OIF as oif2000.089.0, but was defered for a later version of the UNI.
> 
> This ID is basically that proposal with more details fleshed 
> out. We decided
> to submit it as an ID because of the recent interest on the list.
> 
> This proposal is consistent with the if/ib case described in 
> UNI 1.0 and
> supported in the base LMP document. (This is mentioned in the 
> Introduction
> to this ID - I'm not sure if you read introductions.)
> 
> > 
> > Also this seems fairly focused on SDH/G.709 type signals, 
> i.e., trail
> traces
> > and DCC channels.  ITU-T already has work underway in the form of
> G.7714.1.
> > A liason has already been sent to IETF from ITU-T.
> > 
> > It seems to me that this work is better done as part of 
> that effort, at
> > least the SDH/G.709 aspects of it, since its technology specific and
> > suggests reusing channels/mechanisms that are defined for 
> other functions
> by
> > the ITU-T.
> In the liason, it states, "Draft new Recommendation G.7714.1, 
> which is based
> on the OIF UNI 1.0 neighbour and service discovery 
> specification and will be
> developed to meet the protocol neutral discovery requirements in
> Recommendation G.7714".
> 
> Since the OIF UNI 1.0 neighbor and service discovery spec. is 
> based on LMP,
> I think it is quite appropriate to do this work where LMP is 
> being defined. 
> 
> (I couldn't find a version of G.7714.1. If there is a current 
> version, can
> you please post it.)
> 
> -Jonathan
> 
> > 
> > Greg B.
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 4:06 AM
> > To: IETF-Announce; @[email-masked]
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > 
> > 	Title		: Control Channel Bootstrap for LMP
> > 	Author(s)	: J. Lang, J. Drake
> > 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> > 	Pages		: 7
> > 	Date		: 10-Jun-02
> > 	
> > The Link Management Protocol (LMP) requires that at least one bi-
> > directional control channel is established between the nodes. The 
> > control channel may be transmitted either in-band with the data 
> > links or out-of-band over a separate wavelength, fiber, or IP 
> > network. This draft specifies a simple procedure to dynamically 
> > bootstrap control channels and exchange interface mappings using a 
> > new LMP message that is transmitted in-band over the data links.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-lang-ccamp-lmp-bootstrap-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

Delivery-date: Wed, 12 Jun 2002 04:16:17 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-01.txt
Date: Wed, 12 Jun 2002 07:12:45 -0400

--NextPart

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

	Title		: Generalized MPLS Signalling Extensions for G.709 
                          Optical Transport Networks Control
	Author(s)	: D. Papadimitriou et al.
	Filename	: draft-ietf-ccamp-gmpls-g709-01.txt
	Pages		: 20
	Date		: 11-Jun-02
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN
developments.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-g709-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 11 Jun 2002 16:15:31 -0700
From: Jonathan Lang <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, [email-masked]
Subject: RE: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
Date: Tue, 11 Jun 2002 16:05:34 -0700

Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3:51 PM
> To: Jonathan Lang; [email-masked]
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi Jonathan,
> I understand this is addressing the In-band/In-fiber case, like we did at
> with the OIF UNI, but the mechanism seems different.  Particularly in the
> case of line or section DCC (the case most of us have already implemented
> and interoperated with).
The ID we submitted addresses the Out-of-band/out-of-fiber case. The ib/if
case is already supported in LMP today (the OIF UNI 1.0 is aligned with
LMP).

> 
> For a trail trace mechanism, i.e., you mention using J0.  If I recall this
> doesn't solve George Swallows problem of a "dumb mux" between a router and
a
> SONET/SDH switch. I think J1 (path trace) was the solution we discussed
way
> back then. I think Michiel's e-mail probably summarized some of this best
an
> proposed a more general solution. 
The ID we submitted supports multiple options. J0 is but one.

> However, I still think mucking with this
> part of the SONET/SDH signal needs to be done at ITU-T.  For the
> transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP.
SONET/SDH & GigE are included in pre-OTN.

> 
> I did a check on OIF2000.089 and found the following:    
> oif2000.089.00 -
> OIF OAM&P Working Group - Living List Author: Ren Wu     
> Company: Lucent
> Technologies Date created: 04/24/2000     Date updated: 
> 04/24/2000 Working
> group(s): OAM&P
> Abstract: The OIF OAM&P Working Group met on January 21 - 
> February 1, 2000
> in New Orleans, LA. The OAM&P WG Living List was updated during this
> meeting. The updated Living List includes two additional 
> issues (readline).
> In addition, it was agreed to expa...
> 
> This doesn't seem like the right reference.  I saw Michiel referencing
> OIF2000.159v2 some of my old work at OIF along these lines...

Ooops. This should be oif2000.289

Did you get a chance to post G.7714.1?

-Jonathan

> 
> Greg
> 
> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3:08 PM
> To: Bernstein, Greg; [email-masked]
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> Greg,
> 
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 8:40 AM
> > To: [email-masked]
> > Subject: Comparision to OIF UNI discovery? RE: I-D
> > ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> > 
> > 
> > Hi John, Jonathan and Dimitri.  How does this compare to 
> the OIF UNI auto
> > discovery.  I recall that John and Jonathan were co-authors on that
> > specification.  At first glance this looks like a different 
> approach. Do
> we
> > need another approach?
> The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
> channels. As mentioned in this ID, a proposal for bootstraping
> out-of-fiber/out-of-band control channels was originally 
> submitted to the
> OIF as oif2000.089.0, but was defered for a later version of the UNI.
> 
> This ID is basically that proposal with more details fleshed 
> out. We decided
> to submit it as an ID because of the recent interest on the list.
> 
> This proposal is consistent with the if/ib case described in 
> UNI 1.0 and
> supported in the base LMP document. (This is mentioned in the 
> Introduction
> to this ID - I'm not sure if you read introductions.)
> 
> > 
> > Also this seems fairly focused on SDH/G.709 type signals, 
> i.e., trail
> traces
> > and DCC channels.  ITU-T already has work underway in the form of
> G.7714.1.
> > A liason has already been sent to IETF from ITU-T.
> > 
> > It seems to me that this work is better done as part of 
> that effort, at
> > least the SDH/G.709 aspects of it, since its technology specific and
> > suggests reusing channels/mechanisms that are defined for 
> other functions
> by
> > the ITU-T.
> In the liason, it states, "Draft new Recommendation G.7714.1, 
> which is based
> on the OIF UNI 1.0 neighbour and service discovery 
> specification and will be
> developed to meet the protocol neutral discovery requirements in
> Recommendation G.7714".
> 
> Since the OIF UNI 1.0 neighbor and service discovery spec. is 
> based on LMP,
> I think it is quite appropriate to do this work where LMP is 
> being defined. 
> 
> (I couldn't find a version of G.7714.1. If there is a current 
> version, can
> you please post it.)
> 
> -Jonathan
> 
> > 
> > Greg B.
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, June 11, 2002 4:06 AM
> > To: IETF-Announce; @[email-masked]
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > 
> > 	Title		: Control Channel Bootstrap for LMP
> > 	Author(s)	: J. Lang, J. Drake
> > 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> > 	Pages		: 7
> > 	Date		: 10-Jun-02
> > 	
> > The Link Management Protocol (LMP) requires that at least one bi-
> > directional control channel is established between the nodes. The 
> > control channel may be transmitted either in-band with the data 
> > links or out-of-band over a separate wavelength, fiber, or IP 
> > network. This draft specifies a simple procedure to dynamically 
> > bootstrap control channels and exchange interface mappings using a 
> > new LMP message that is transmitted in-band over the data links.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-lang-ccamp-lmp-bootstrap-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

Delivery-date: Tue, 11 Jun 2002 15:52:59 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, [email-masked]
Subject: RE: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
Date: Tue, 11 Jun 2002 15:50:32 -0700

Hi Jonathan,
I understand this is addressing the In-band/In-fiber case, like we did at
with the OIF UNI, but the mechanism seems different.  Particularly in the
case of line or section DCC (the case most of us have already implemented
and interoperated with).

For a trail trace mechanism, i.e., you mention using J0.  If I recall this
doesn't solve George Swallows problem of a "dumb mux" between a router and a
SONET/SDH switch. I think J1 (path trace) was the solution we discussed way
back then. I think Michiel's e-mail probably summarized some of this best an
proposed a more general solution.  However, I still think mucking with this
part of the SONET/SDH signal needs to be done at ITU-T.  For the
transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP.

I did a check on OIF2000.089 and found the following:    oif2000.089.00 -
OIF OAM&P Working Group - Living List Author: Ren Wu     Company: Lucent
Technologies Date created: 04/24/2000     Date updated: 04/24/2000 Working
group(s): OAM&P
Abstract: The OIF OAM&P Working Group met on January 21 - February 1, 2000
in New Orleans, LA. The OAM&P WG Living List was updated during this
meeting. The updated Living List includes two additional issues (readline).
In addition, it was agreed to expa...

This doesn't seem like the right reference.  I saw Michiel referencing
OIF2000.159v2 some of my old work at OIF along these lines...

Greg

-----Original Message-----
From: Jonathan Lang [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 3:08 PM
To: Bernstein, Greg; [email-masked]
Subject: RE: Comparision to OIF UNI discovery? RE: I-D
ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt

Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 8:40 AM
> To: [email-masked]
> Subject: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi John, Jonathan and Dimitri.  How does this compare to the OIF UNI auto
> discovery.  I recall that John and Jonathan were co-authors on that
> specification.  At first glance this looks like a different approach. Do
we
> need another approach?
The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
channels. As mentioned in this ID, a proposal for bootstraping
out-of-fiber/out-of-band control channels was originally submitted to the
OIF as oif2000.089.0, but was defered for a later version of the UNI.

This ID is basically that proposal with more details fleshed out. We decided
to submit it as an ID because of the recent interest on the list.

This proposal is consistent with the if/ib case described in UNI 1.0 and
supported in the base LMP document. (This is mentioned in the Introduction
to this ID - I'm not sure if you read introductions.)

> 
> Also this seems fairly focused on SDH/G.709 type signals, i.e., trail
traces
> and DCC channels.  ITU-T already has work underway in the form of
G.7714.1.
> A liason has already been sent to IETF from ITU-T.
> 
> It seems to me that this work is better done as part of that effort, at
> least the SDH/G.709 aspects of it, since its technology specific and
> suggests reusing channels/mechanisms that are defined for other functions
by
> the ITU-T.
In the liason, it states, "Draft new Recommendation G.7714.1, which is based
on the OIF UNI 1.0 neighbour and service discovery specification and will be
developed to meet the protocol neutral discovery requirements in
Recommendation G.7714".

Since the OIF UNI 1.0 neighbor and service discovery spec. is based on LMP,
I think it is quite appropriate to do this work where LMP is being defined. 

(I couldn't find a version of G.7714.1. If there is a current version, can
you please post it.)

-Jonathan

> 
> Greg B.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 4:06 AM
> To: IETF-Announce; @[email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Control Channel Bootstrap for LMP
> 	Author(s)	: J. Lang, J. Drake
> 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> 	Pages		: 7
> 	Date		: 10-Jun-02
> 	
> The Link Management Protocol (LMP) requires that at least one bi-
> directional control channel is established between the nodes. The 
> control channel may be transmitted either in-band with the data 
> links or out-of-band over a separate wavelength, fiber, or IP 
> network. This draft specifies a simple procedure to dynamically 
> bootstrap control channels and exchange interface mappings using a 
> new LMP message that is transmitted in-band over the data links.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
trap-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Tue, 11 Jun 2002 15:18:18 -0700
From: Jonathan Lang <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, [email-masked]
Subject: RE: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
Date: Tue, 11 Jun 2002 15:08:22 -0700

Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 8:40 AM
> To: [email-masked]
> Subject: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi John, Jonathan and Dimitri.  How does this compare to the OIF UNI auto
> discovery.  I recall that John and Jonathan were co-authors on that
> specification.  At first glance this looks like a different approach. Do
we
> need another approach?
The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
channels. As mentioned in this ID, a proposal for bootstraping
out-of-fiber/out-of-band control channels was originally submitted to the
OIF as oif2000.089.0, but was defered for a later version of the UNI.

This ID is basically that proposal with more details fleshed out. We decided
to submit it as an ID because of the recent interest on the list.

This proposal is consistent with the if/ib case described in UNI 1.0 and
supported in the base LMP document. (This is mentioned in the Introduction
to this ID - I'm not sure if you read introductions.)

> 
> Also this seems fairly focused on SDH/G.709 type signals, i.e., trail
traces
> and DCC channels.  ITU-T already has work underway in the form of
G.7714.1.
> A liason has already been sent to IETF from ITU-T.
> 
> It seems to me that this work is better done as part of that effort, at
> least the SDH/G.709 aspects of it, since its technology specific and
> suggests reusing channels/mechanisms that are defined for other functions
by
> the ITU-T.
In the liason, it states, "Draft new Recommendation G.7714.1, which is based
on the OIF UNI 1.0 neighbour and service discovery specification and will be
developed to meet the protocol neutral discovery requirements in
Recommendation G.7714".

Since the OIF UNI 1.0 neighbor and service discovery spec. is based on LMP,
I think it is quite appropriate to do this work where LMP is being defined. 

(I couldn't find a version of G.7714.1. If there is a current version, can
you please post it.)

-Jonathan

> 
> Greg B.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 4:06 AM
> To: IETF-Announce; @[email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Control Channel Bootstrap for LMP
> 	Author(s)	: J. Lang, J. Drake
> 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> 	Pages		: 7
> 	Date		: 10-Jun-02
> 	
> The Link Management Protocol (LMP) requires that at least one bi-
> directional control channel is established between the nodes. The 
> control channel may be transmitted either in-band with the data 
> links or out-of-band over a separate wavelength, fiber, or IP 
> network. This draft specifies a simple procedure to dynamically 
> bootstrap control channels and exchange interface mappings using a 
> new LMP message that is transmitted in-band over the data links.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
trap-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Tue, 11 Jun 2002 15:05:32 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: SUKLM doubt
Date: Tue, 11 Jun 2002 15:03:46 -0700

Hi All,
        In draft draft-ietf-ccamp-sonet-sdh-05.txt, it is written that when 
a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is requested, the label is 
not applicable and is set to zero. Does this means all the fields viz 
{SUKLM} should be zero ? Why not S value to be non-zero i.e. set to the 
lowest index in Nth multiplex (which will be 1) ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Delivery-date: Tue, 11 Jun 2002 14:41:38 -0700
From: "Michael I Mandelberg(Isaac)" <[email-masked]>
To: [email-masked]
Subject: How to choose TBA Class-Nums
Date: Tue, 11 Jun 2002 17:36:51 -0400

For example, the Label_Set object has Class-Num 0bbbbbbb. Are these intended
to be vendor specific?

Thanks

Delivery-date: Tue, 11 Jun 2002 10:22:17 -0700
Date: Tue, 11 Jun 2002 19:19:39 +0200
To: Ron Bonica <[email-masked]>, [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Agenda
Cc: [email-masked]

--=====================_13785983==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Ron and Kireeti,

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

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

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

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

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

Would you mind accepting those two drafts within CCAMP ?

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

Many thanks in advance.

Best regards.

JP.

At 11:31 10/06/2002 -0400, Ron Bonica wrote:
>All,
>
>The CCAMP meeting in Yokohama is tentatively planned for Monday afternoon.
>
>If you would like time on the agenda, please send a request to Kireeti and
>me.  Include the name and title of you ID and an estimate of how much time
>you would need.
>
>
>===========================================
>Ronald P. Bonica       Ph: 703 886 1681
>vBNS Engineering       page: 1 888 268 8021
>Ashburn, Va.
>===========================================
>"Entia non sunt multiplicanda sine necessitate."
>                 -- William of Ockham

--=====================_13785983==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Ron and Kireeti,<br>
<br>
May I request a 5mn slot for: <br>
- &quot;RSVP Path computation request and reply messages&quot; -
draft-vasseur-mpls-path-computation-rsvp-te-3.txt - To be posted soon.
<br>
<br>
There are also two drafts related to the announcement of Path Computation
Server capability both for OSPF and ISIS. Here is the abstract for the
OSPF draft:<br>
<font face="Courier New, Courier">Abstract<br>
<br>
This draft proposes an OSPF extension for a router to announce its Path
Computation Server capability used in the context of MPLS Traffic
Engineering. This draft defines a new opaque LSA called PCSD (Path
Computation Server Discovery). The PCSD LSA has a variable length and is
made of a set of TLVs. <br>
<br>
</font>1. Where does this draft fit in the picture of the Sub-IP
work<br>
<br>
<font face="Courier New, Courier">This document specifies OSPF extensions
in support of MPLS Traffic Engineering. It relates to the work on
off-load computation of Traffic Engineering Label Switch Path covered by
CCAMP. <br>
<br>
</font>Would you mind accepting those two drafts within CCAMP ? <br>
<br>
If yes, thanks to allocate two times 5 minutes slots:<br>
OSPF Path Computation Server discovery
:draft-vasseur-mpls-path-computation-rsvp-te-013.txt<br>
IS-IS Path Computation Server discovery TLV:
draft-vasseur-mpls-pcsd-isis-discovery-00.txt<br>
<br>
Many thanks in advance.<br>
<br>
Best regards.<br>
<br>
JP.<br>
<br>
At 11:31 10/06/2002 -0400, Ron Bonica wrote:<br>
<blockquote type=cite cite>All,<br>
<br>
The CCAMP meeting in Yokohama is tentatively planned for Monday
afternoon.<br>
<br>
If you would like time on the agenda, please send a request to Kireeti
and<br>
me.&nbsp; Include the name and title of you ID and an estimate of how
much time<br>
you would need.<br>
<br>
<br>
===========================================<br>
Ronald P. Bonica&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ph: 703 886
1681<br>
vBNS Engineering&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; page: 1 888 268
8021<br>
Ashburn, Va.<br>
===========================================<br>
&quot;Entia non sunt multiplicanda sine necessitate.&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-- William of Ockham</blockquote></html>

--=====================_13785983==_.ALT--

Delivery-date: Tue, 11 Jun 2002 08:47:12 -0700
From: "Bernstein, Greg" <[email-masked]>
To: [email-masked]
Subject: Comparision to OIF UNI discovery?  RE: I-D ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
Date: Tue, 11 Jun 2002 08:39:47 -0700

Hi John, Jonathan and Dimitri.  How does this compare to the OIF UNI auto
discovery.  I recall that John and Jonathan were co-authors on that
specification.  At first glance this looks like a different approach. Do we
need another approach?

Also this seems fairly focused on SDH/G.709 type signals, i.e., trail traces
and DCC channels.  ITU-T already has work underway in the form of G.7714.1.
A liason has already been sent to IETF from ITU-T.

It seems to me that this work is better done as part of that effort, at
least the SDH/G.709 aspects of it, since its technology specific and
suggests reusing channels/mechanisms that are defined for other functions by
the ITU-T.

Greg B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 4:06 AM
To: IETF-Announce; @[email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt

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

	Title		: Control Channel Bootstrap for LMP
	Author(s)	: J. Lang, J. Drake
	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
	Pages		: 7
	Date		: 10-Jun-02
	
The Link Management Protocol (LMP) requires that at least one bi-
directional control channel is established between the nodes. The 
control channel may be transmitted either in-band with the data 
links or out-of-band over a separate wavelength, fiber, or IP 
network. This draft specifies a simple procedure to dynamically 
bootstrap control channels and exchange interface mappings using a 
new LMP message that is transmitted in-band over the data links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Tue, 11 Jun 2002 04:10:34 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
Date: Tue, 11 Jun 2002 07:06:05 -0400

--NextPart

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

	Title		: Control Channel Bootstrap for LMP
	Author(s)	: J. Lang, J. Drake
	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
	Pages		: 7
	Date		: 10-Jun-02
	
The Link Management Protocol (LMP) requires that at least one bi-
directional control channel is established between the nodes. The 
control channel may be transmitted either in-band with the data 
links or out-of-band over a separate wavelength, fiber, or IP 
network. This draft specifies a simple procedure to dynamically 
bootstrap control channels and exchange interface mappings using a 
new LMP message that is transmitted in-band over the data links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-lang-ccamp-lmp-bootstrap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 10 Jun 2002 08:45:29 -0700
Date: Mon, 10 Jun 2002 11:31:57 -0400
From: Ron Bonica <[email-masked]>
Subject: Agenda
To: [email-masked]
Cc: [email-masked], [email-masked]

All,

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

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

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Entia non sunt multiplicanda sine necessitate."
                -- William of Ockham

Delivery-date: Sun, 09 Jun 2002 22:40:05 -0700
Date: Mon, 10 Jun 2002 14:35:04 +0900
From: Eiji Oki <[email-masked]>
To: "#SHEN SHU#" <[email-masked]>, <[email-masked]>
Subject: Re: Can wavelength availability information be carried by OSPF-Ext for GMPLS?

Hi Shu,

Yes, in principle, whenever event of link-state change occurs, optical link information is updated.
How it causes a OSPF convergence problem depends on the frequency of the link-state update and 
network topology. 
I think that the wavelength availability information is needed to perform traffic engineering 
in optical networks. 
I am now describing this issue and the updated version will be posted soon.

Hope this helps. Best regards.
Eiji

On Sun, 9 Jun 2002 23:06:22 +0800
"#SHEN SHU#" <[email-masked]> wrote:

> Hi, Eiji Oki,
> 
> Regarding your ID (draft-oki-ipo-optlink-req-00.txt), I have the following question:
> 
> How is flooding of optical link information originated? Is it triggered by event of link change? 
> --If yes, won't the frequent wavelength availability change impact OSPF convergence?
> --If no, how often will the timer be? Use the OSPF 30min max timer? how could up-to-date information garrentteed or approached?
> 
> I am not quite sure if such details should be included in your ID or stated in another document.
> If it's out of your scope, is there any other doc takeing care of this?
> 
> Your kindly answers/clarifications will be highly appreciated.
> 
> Best regards, 
> Shu SHEN 
> Research student 
> Network Technology Research Center 
> Nanyang Technological University, Singapore 
> Personal Website: http://shenshu.myip.org/
> 
> 
> -----Original Message-----
> From: #SHEN SHU# 
> Sent: Sunday, June 09, 2002 10:56 PM
> To: 'Ravi Ravindran'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS?
> 
> 
> Hi, Ravi,
> 
> I don't quite understand why you say information such as wavelength availability is "strictly binds to data plane".
> Is this because of wavelength availability is specific to LSC? or maybe a LSC from some vendors never use such information to make routing decisions?
> Either reason I would not agree.
> I think support for exchanging such information should be included within control plane, at least as an option.
> Please explain further.
> 
> About the ID you suggested, do you know what's its current status? I found it's not on the IPO WG's ID list.
> May be the authors of this ID can provide more information about it. 
> 
> Thanks a lot!
> 
> Cheers,
> Shu
> 
> -----Original Message-----
> From: Ravi Ravindran [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 4:27 AM
> To: #SHEN SHU#
> Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS?
> 
> 
> OSPF-GMPLS extensions only try to address the common rourting issues relating to all non-packet switched interfaces. Extensions to things like you stated is more vendor specific, since that strictly binds to data plane property. 
> The following ID discusses some ways to deal with LSC nodes. 
> http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt 
> Ravi 
> -----Original Message----- 
> From: #SHEN SHU# [mailto:[email-masked]] 
> Sent: Saturday, June 08, 2002 3:36 AM 
> To: [email-masked] 
> Subject: Can wavelength availability information be carried by OSPF-Ext 
> for GMPLS? 
> 
> 
> Dear All, 
> Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my understanding is that there's no way to exchange wavelength availability information with such extension. Is this right?
> If a LSC router wants to make routing decision based on wavelength availability, how could it collect such information from each link of the network?
> Or does the OSPF extension leaves wavelength assignment to LDP completely? 
> Please comment, thanks! 
> Best regards, 
> Shu SHEN 
> Research student 
> Network Technology Research Center 
> Nanyang Technological University, Singapore 
> Personal Website: http://shenshu.myip.org/ 

--
Eiji Oki
NTT Network Innovation Laboratories
3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
TEL: +81-422-59-3441  FAX: +81-422-59-6387
E-mail: [email-masked]

Delivery-date: Sun, 09 Jun 2002 08:33:42 -0700
content-class: urn:content-classes:message
Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS?
Date: Sun, 9 Jun 2002 23:06:22 +0800
From: "#SHEN SHU#" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi, Eiji Oki,

Regarding your ID (draft-oki-ipo-optlink-req-00.txt), I have the =
following question:

How is flooding of optical link information originated? Is it triggered =
by event of link change?=20
--If yes, won't the frequent wavelength availability change impact OSPF =
convergence?
--If no, how often will the timer be? Use the OSPF 30min max timer? how =
could up-to-date information garrentteed or approached?

I am not quite sure if such details should be included in your ID or =
stated in another document.
If it's out of your scope, is there any other doc takeing care of this?

Your kindly answers/clarifications will be highly appreciated.

Best regards,=20
Shu SHEN=20
Research student=20
Network Technology Research Center=20
Nanyang Technological University, Singapore=20
Personal Website: http://shenshu.myip.org/

-----Original Message-----
From: #SHEN SHU#=20
Sent: Sunday, June 09, 2002 10:56 PM
To: 'Ravi Ravindran'
Cc: [email-masked]'; [email-masked]'
Subject: RE: Can wavelength availability information be carried by =
OSPF-Ext for GMPLS?

Hi, Ravi,

I don't quite understand why you say information such as wavelength =
availability is "strictly binds to data plane".
Is this because of wavelength availability is specific to LSC? or maybe =
a LSC from some vendors never use such information to make routing =
decisions?
Either reason I would not agree.
I think support for exchanging such information should be included =
within control plane, at least as an option.
Please explain further.

About the ID you suggested, do you know what's its current status? I =
found it's not on the IPO WG's ID list.
May be the authors of this ID can provide more information about it.=20

Thanks a lot!

Cheers,
Shu

-----Original Message-----
From: Ravi Ravindran [mailto:[email-masked]]
Sent: Sunday, June 09, 2002 4:27 AM
To: #SHEN SHU#
Subject: RE: Can wavelength availability information be carried by =
OSPF-Ext for GMPLS?

OSPF-GMPLS extensions only try to address the common rourting issues =
relating to all non-packet switched interfaces. Extensions to things =
like you stated is more vendor specific, since that strictly binds to =
data plane property.=20
The following ID discusses some ways to deal with LSC nodes.=20
http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt=20
Ravi=20
-----Original Message-----=20
From: #SHEN SHU# [mailto:[email-masked]]=20
Sent: Saturday, June 08, 2002 3:36 AM=20
To: [email-masked]=20
Subject: Can wavelength availability information be carried by OSPF-Ext=20
for GMPLS?=20

Dear All,=20
Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my =
understanding is that there's no way to exchange wavelength availability =
information with such extension. Is this right?
If a LSC router wants to make routing decision based on wavelength =
availability, how could it collect such information from each link of =
the network?
Or does the OSPF extension leaves wavelength assignment to LDP =
completely?=20
Please comment, thanks!=20
Best regards,=20
Shu SHEN=20
Research student=20
Network Technology Research Center=20
Nanyang Technological University, Singapore=20
Personal Website: http://shenshu.myip.org/=20

Delivery-date: Sun, 09 Jun 2002 08:28:13 -0700
content-class: urn:content-classes:message
Subject: RE: Can wavelength availability information be carried by OSPF-Ext for GMPLS?
Date: Sun, 9 Jun 2002 22:56:11 +0800
From: "#SHEN SHU#" <[email-masked]>
To: "Ravi Ravindran" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi, Ravi,

I don't quite understand why you say information such as wavelength =
availability is "strictly binds to data plane".
Is this because of wavelength availability is specific to LSC? or maybe =
a LSC from some vendors never use such information to make routing =
decisions?
Either reason I would not agree.
I think support for exchanging such information should be included =
within control plane, at least as an option.
Please explain further.

About the ID you suggested, do you know what's its current status? I =
found it's not on the IPO WG's ID list.
May be the authors of this ID can provide more information about it.=20

Thanks a lot!

Cheers,
Shu

-----Original Message-----
From: Ravi Ravindran [mailto:[email-masked]]
Sent: Sunday, June 09, 2002 4:27 AM
To: #SHEN SHU#
Subject: RE: Can wavelength availability information be carried by =
OSPF-Ext for GMPLS?

OSPF-GMPLS extensions only try to address the common rourting issues =
relating to all non-packet switched interfaces. Extensions to things =
like you stated is more vendor specific, since that strictly binds to =
data plane property.=20
The following ID discusses some ways to deal with LSC nodes.=20
http://www.ietf.org/internet-drafts/draft-oki-ipo-optlink-req-00.txt=20
Ravi=20
-----Original Message-----=20
From: #SHEN SHU# [mailto:[email-masked]]=20
Sent: Saturday, June 08, 2002 3:36 AM=20
To: [email-masked]=20
Subject: Can wavelength availability information be carried by OSPF-Ext=20
for GMPLS?=20

Dear All,=20
Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my =
understanding is that there's no way to exchange wavelength availability =
information with such extension. Is this right?
If a LSC router wants to make routing decision based on wavelength =
availability, how could it collect such information from each link of =
the network?
Or does the OSPF extension leaves wavelength assignment to LDP =
completely?=20
Please comment, thanks!=20
Best regards,=20
Shu SHEN=20
Research student=20
Network Technology Research Center=20
Nanyang Technological University, Singapore=20
Personal Website: http://shenshu.myip.org/=20

Delivery-date: Sat, 08 Jun 2002 00:41:31 -0700
content-class: urn:content-classes:message
Subject: Can wavelength availability information be carried by OSPF-Ext for GMPLS?
Date: Sat, 8 Jun 2002 15:36:22 +0800
From: "#SHEN SHU#" <[email-masked]>
To: <[email-masked]>

Dear All,

Regarding draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, my =
understanding is that there's no way to exchange wavelength availability =
information with such extension. Is this right?
If a LSC router wants to make routing decision based on wavelength =
availability, how could it collect such information from each link of =
the network?

Or does the OSPF extension leaves wavelength assignment to LDP =
completely?

Please comment, thanks!

Best regards,=20
Shu SHEN=20
Research student=20
Network Technology Research Center=20
Nanyang Technological University, Singapore=20
Personal Website: http://shenshu.myip.org/

Delivery-date: Thu, 06 Jun 2002 13:04:46 -0700
From: "Robin Qiu" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: OIF-UNI/LMP - service discovery
Date: Thu, 06 Jun 2002 16:03:01 -0400

Hi Bala, all,

I have seen some LMP "Service Discovery" implementations (as specified in 
oif2001.125.7, section 9) that mandate the message exchange sequence as 
illustrated in Figure 9-2 (page 42), i.e.
* one ServiceConfig Msg#1 from UNI-C to UNI-N
   (ServiceConfig Ack/Nack from UNI-N to UNI-C), followed by
* one or more ServiceConfig Msg#2 from UNI-C to UNI-N
   (one or more ServiceConfig Ack/Nack from UNI-N to UNI-C), followed by
* one ServiceConfig Msg#3 from UNI-N to UNI-C
   (ServiceConfig Ack/Nack from UNI-C to UNI-N)

While this is literally compliant with the spec (page 42, section 9.3)
"There can be more than one exchange of ServiceConfig Message #2  and the 
corresponding ServiceConfig Ack/Nack. A ServiceConfig Message #3, is sent by 
the UNI-N to the UNI-C after the latter has received the Client Port-Level 
Service Attributes corresponding to all the links between the TNE it 
represents and the clients represented by the UNI-C.",
I wonder if this is the authors' intention, to enforce this message 
sequence.

My questions are:
1. Why couldn't UNI-N independently send ServiceConfig Msg#3 to UNI-C,
   instead of following ServiceConfig Msg#2?
2. If Msg#3 MUST follow Msg#2, how does UNI-N know when Msg#2 exchange
   is complete, because there could be more than one Msg#2?

Thanks.

Robin

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Delivery-date: Thu, 06 Jun 2002 10:23:38 -0700
content-class: urn:content-classes:message
Subject: RE: Sonet Ring provisioning
Date: Thu, 6 Jun 2002 10:21:41 -0700
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>

I am reading that to mean, RSVP-TE/CR-LDP allow for TRAFFIC-SPEC
objects, but do not specify what the allowable TRAFFIC-SPEC objects are.
Am I offbase here. This is of course based on my assumption that a type
of service translates to a TRAFFIC-SPEC.

Vik

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]=20
Sent: Thursday, June 06, 2002 9:46 AM
To: Vikram Anantha
Cc: [email-masked]
Subject: Re: Sonet Ring provisioning

Good points Vikram. Since we cannot standardize services,
we need to keep them in min while proposing the mechanisms. This is waht
we are trying to do also.

Vikram Anantha wrote:

> Here's my two bits.
>
> It appears to me that there are many ways of representing "restoration

> islands",. By restoration islands, I refer to BLSR or vendor specific=20
> mesh etc. As Zhi and Sudheer have pointed out it could be "protected=20
> nodes" or "protected links". But in any case, the way of representing=20
> an "restoration island" depends to a large extent on what kind of a=20
> service the user desires. Some of the types of services may be:
> - end to end 1+1/1:1
> - end to end dynamic mesh
> - end to end unprotected.
> - dynamic mesh going thro' "restoration islands"

These restoration islands are called risk domains in
draft-many-ccamp-srg-01.txt.

>
>
> For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1)

> and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to=20
> specify a path from A to Z that could be one of the following:
>
> 1. Not routed thro' a BLSR ring
> 2. routed thro' one BLSR ring
> 3. Routed thro' two BLSR rings
>

These can be again achieved through the SRG draft. Please note the
discussion on the inclusive and exclusive constraints.

>
>                         J1-----K1        J11----K11
>                         /        \       /        \
>                        I1         L1--- I11        L11
>                      /  \        /       \        / \
>                     /    N1-----M1        N11----M11 \
>                    /                                  \
>                   /     J------K                       \
>                  /      /        \                      \
>   A------B------H------I          L-------O-------Y------Z
>           \             \        /               /
>            \             N------M        F------G
>             \                           /
>              C---------------D---------E
>
> So the first question we have to answer is what are the kinds of=20
> services we are trying to provide. Is it fully redundant, mesh, mesh +

> partially redundant?
>

Well we cannot standardize services. So the approach we are taking is
what is the scope of this GMPLS P&R work. Until now we are concentrating
on the mesh restoration. We need to consider ring protection and using
server layer protection as near future enhancements, provided we get
more support from the working group discussions.

- sudheer

>
> -----Original Message-----
> From: Sudheer Dharanikota [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 10:32 AM
> To: [email-masked]
> Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;=20
> 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)
> Subject: Re: Sonet Ring provisioning
>
> Hi All:
>
> This is very interesting discussion.
>
> Some of the people on this discussion list already looked
> at some of these issues. Please refer to draft-many-ccamp-srg-01.txt=20
> for more information.
>
> Here is my opinion:
>
> Transport networks provide their own protection mechanisms such as the

> rings under discussion. As others pointed out it makes good sense to=20
> use them for faster restoration times. These rings may be created=20
> through NMS/EMS - this is not a concern to the control plane.
>
> The real problem is how to represent this ring topology in the control

> plane for the path computation. Well one proposal as mentioned by Zhi=20
> was to represent by a logical node with node capability being "highly=20
> protected node" (inheriting the property of the ring). Another way to=20
> see this, as mentioned in the srg draft is to represent by=20
> point-to-multi point links with the exit points to the ring as the=20
> terminating points of the links and define the same "highly protected"

> property on the links (unlike on the node). Now that we have the links

> and link property we can use it in the path computation. Once path is=20
> computed it is the nodes, which are on the ring and participate in the

> control plane, to make a connection between the end points. Please=20
> refer to the above draft or=20
> http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf
>
> - sudheer
>
> Vishal Sharma wrote:
>
> > Zhi and all,
> >
> > Great discussion! I'm glad we're finally discussing some of these=20
> > issues, and highlighting that mix inherent ring protection with the=20
> > control domain mechanisms is non-trivial.
> >
> > Comments in-line.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Zhi-Wei Lin
> > > Sent: Thursday, May 30, 2002 11:54 AM
> > > To: Suresh Katukam
> > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp=20
> > > (E-mail); mpls@UU. NET (E-mail)
> > > Subject: Re: Sonet Ring provisioning
> > >
> > >
> > > Hi Suresh,
> > >
> > > Yes agree this is very complex if you try to create too much=20
> > > dependencies between control plane and transport plane protection=20
> > > interactions. That is why my simplistic approach:
> > >
> > >     * Control plane sees the entire ring as offering "highly
> available"
> > >       connections
> > >     * Control plane sets up a single connection across this ring
> > >       "sub-network" (if you think this about this, the entire ring
> can
> > >       actually be treated by a control plane controller as a=20
> > > single
> node
> > >       where the BLSR ring nodes may be thought of as aggregate=20
> > > ports
> on
> > >       the single node)
> > >     * The ring sub-network, by virtue of providing the protection
> and
> > >       knowing *exactly* how protection is provided can set up the
> > >       protection channel automatically (but control plane need not
> know
> > >       this as it is irrelevant to the control plane -- it only=20
> > > needs
> to
> > >       know that the single connection is protected)
> >
> > What mechanism will the ring use to setup the internal protection=20
> > channel?
> >
> > Will it require EMS/NMS intervention, as proposed on this thread=20
> > earlier, or will there be another sequence of control plane messages

> > (initiated internal to the ring) to set this path up. The latter=20
> > would
>
> > be prefereable if the objective is to have fully-automated path=20
> > setup (otherwise, we have EMS/NMS intervention for the ring), but it

> > does complicate the control plane protocols (since a new sequence of

> > setup steps may have to be initiated internal to each ring on the=20
> > path of the end-to-end circuit/trail that is being setup.
> >
> > -Vishal
> >
> > >

Delivery-date: Thu, 06 Jun 2002 09:52:03 -0700
Date: Thu, 06 Jun 2002 09:46:04 -0700
From: Sudheer Dharanikota <[email-masked]>
To: Vikram Anantha <[email-masked]>
CC: [email-masked]
Subject: Re: Sonet Ring provisioning

Good points Vikram. Since we cannot standardize services,
we need to keep them in min while proposing the mechanisms.
This is waht we are trying to do also.

Vikram Anantha wrote:

> Here's my two bits.
>
> It appears to me that there are many ways of representing "restoration
> islands",. By restoration islands, I refer to BLSR or vendor specific
> mesh etc. As Zhi and Sudheer have pointed out it could be "protected
> nodes" or "protected links". But in any case, the way of representing an
> "restoration island" depends to a large extent on what kind of a service
> the user desires.
> Some of the types of services may be:
> - end to end 1+1/1:1
> - end to end dynamic mesh
> - end to end unprotected.
> - dynamic mesh going thro' "restoration islands"

These restoration islands are called risk domains in
draft-many-ccamp-srg-01.txt.

>
>
> For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1)
> and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to
> specify a path from A to Z that could be one of the following:
>
> 1. Not routed thro' a BLSR ring
> 2. routed thro' one BLSR ring
> 3. Routed thro' two BLSR rings
>

These can be again achieved through the SRG draft. Please note the
discussion on the inclusive and exclusive constraints.

>
>                         J1-----K1        J11----K11
>                         /        \       /        \
>                        I1         L1--- I11        L11
>                      /  \        /       \        / \
>                     /    N1-----M1        N11----M11 \
>                    /                                  \
>                   /     J------K                       \
>                  /      /        \                      \
>   A------B------H------I          L-------O-------Y------Z
>           \             \        /               /
>            \             N------M        F------G
>             \                           /
>              C---------------D---------E
>
> So the first question we have to answer is what are the kinds of
> services we are trying to provide. Is it fully redundant, mesh, mesh +
> partially redundant?
>

Well we cannot standardize services. So the approach we are taking is
what is the scope of this GMPLS P&R work. Until now we are concentrating
on the mesh restoration. We need to consider ring protection and
using server layer protection as near future enhancements, provided
we get more support from the working group discussions.

- sudheer

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

Delivery-date: Thu, 06 Jun 2002 02:14:16 -0700
Cc: [email-masked]
Date: Thu, 06 Jun 2002 11:09:59 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Alex Zinin <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Alex,

> I believe that neighbor discovery, being a rather new topic for
> the WG, would take some time to reach consensus on. This would
> delay the main LMP spec.

Are you sure that neighbor discovery is rather new ?

- I agree with Martin Dubuc that the current LMP spec can be used for
  neighbor discovery in point-to-point configurations. My understanding
  is that he is even using LMP for a.o. this purpose.

- Jonathan already explained how the current LMP draft "can be used to
  discover the connectivity of the data ports". Note that "discovering
  the connectivity of data ports" is alternative terminology to what I
  have called "neighbor discovery".
  Please refer to
    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html

> > If neighbor discovery is not to be included in LMP, I think there
> > are at least some clarifications needed in the LMP draft on what
> > is and what is not supported. Furthermore, some clarifications on
> > 'control channel management' are needed.
> 
> Sounds reasonable to me. Please work off-line with Jonathan on this
> (feel free to CC me).

I've tried to be as cooperative as possible by specifying the exact
locations in LMP that can be improved regarding "control channel":
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html

My feeling is still that this control channel concept is tied into
the current means of LMP to do neighbor discovery. I've expressed
that feeling several times on this list; no reactions. If this is
true, I would like to see the more general description of neighbor
discovery in
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
as an alternative to "control channel management".

If it would help to progress LMP, I can propose an update of the
full LMP draft. Just let me know.

Thanks,

Michiel

Alex Zinin wrote:
> 
> Michiel,
> 
> >>  While I agree that neighbor
> >>  discovery is useful, I do not believe we should stop the LMP spec
> >>  from progressing.
> 
> > I don't understand this remark.
> [...]
> > If there is anything more I can do to help the LMP spec to progress,
> > please let me know !
> 
> I believe that neighbor discovery, being a rather new topic for
> the WG, would take some time to reach consensus on. This would
> delay the main LMP spec.
> 
> > If neighbor discovery is not to be included in LMP, I think there
> > are at least some clarifications needed in the LMP draft on what
> > is and what is not supported. Furthermore, some clarifications on
> > 'control channel management' are needed.
> 
> Sounds reasonable to me. Please work off-line with Jonathan on this
> (feel free to CC me).
> 
> Alex

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Thu, 06 Jun 2002 01:36:10 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Doubts in GMPLS-LSR-MIB
Date: Thu, 06 Jun 2002 01:32:01 -0700

Hi All,

a)       The gmplsInSegmentEntry in gmpls-lsr-mib contains
gmplsInSegmentIfIndex. In case if the data channel interface and
control channel interfaces are different (i.e. out of band signaling)
then should gmplsInSegmentIfIndex in gmplsInSegmentEntry represent the
ifIndex of control channel interface or the data channel interface ?
As per my understanding it should be of data channel interface.

b) What should gmplsInterfaceLabelMinIn represent in gmplsInterfaceConfEntry 
if the ifIndex corresponds to the control channel interface (as the labels 
are bound to the data channel interface instead the control channel 
interface in GMPLS) ?

Regards,
manoj.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Delivery-date: Wed, 05 Jun 2002 16:39:42 -0700
content-class: urn:content-classes:message
Subject: RE: Sonet Ring provisioning
Date: Wed, 5 Jun 2002 16:36:16 -0700
From: "Vikram Anantha" <[email-masked]>
To: <[email-masked]>

Here's my two bits.

It appears to me that there are many ways of representing "restoration
islands",. By restoration islands, I refer to BLSR or vendor specific
mesh etc. As Zhi and Sudheer have pointed out it could be "protected
nodes" or "protected links". But in any case, the way of representing an
"restoration island" depends to a large extent on what kind of a service
the user desires.
Some of the types of services may be:
- end to end 1+1/1:1
- end to end dynamic mesh
- end to end unprotected.
- dynamic mesh going thro' "restoration islands"

For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1)
and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to
specify a path from A to Z that could be one of the following:

1. Not routed thro' a BLSR ring
2. routed thro' one BLSR ring
3. Routed thro' two BLSR rings

                        J1-----K1        J11----K11 =20
                        /        \       /        \ =20
                       I1         L1--- I11        L11
                     /  \        /       \        / \          =20
                    /    N1-----M1        N11----M11 \
                   /                                  \
                  /     J------K                       \
                 /      /        \                      \
  A------B------H------I          L-------O-------Y------Z
          \             \        /               /
           \             N------M        F------G
            \                           /
             C---------------D---------E

So the first question we have to answer is what are the kinds of
services we are trying to provide. Is it fully redundant, mesh, mesh +
partially redundant?

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]=20
Sent: Friday, May 31, 2002 10:32 AM
To: [email-masked]
Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;
'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)
Subject: Re: Sonet Ring provisioning

Hi All:

This is very interesting discussion.

Some of the people on this discussion list already looked
at some of these issues. Please refer to draft-many-ccamp-srg-01.txt for
more information.

Here is my opinion:

Transport networks provide their own protection mechanisms such as the
rings under discussion. As others pointed out it makes good sense to use
them for faster restoration times. These rings may be created through
NMS/EMS - this is not a concern to the control plane.

The real problem is how to represent this ring topology in the control
plane for the path computation. Well one proposal as mentioned by Zhi
was to represent by a logical node with node capability being "highly
protected node" (inheriting the property of the ring). Another way to
see this, as mentioned in the srg draft is to represent by
point-to-multi point links with the exit points to the ring as the
terminating points of the links and define the same "highly protected"
property on the links (unlike on the node). Now that we have the links
and link property we can use it in the path computation. Once path is
computed it is the nodes, which are on the ring and participate in the
control plane, to make a connection between the end points. Please refer
to the above draft or
http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf

- sudheer

Vishal Sharma wrote:

> Zhi and all,
>
> Great discussion! I'm glad we're finally discussing some of these=20
> issues, and highlighting that mix inherent ring protection with the=20
> control domain mechanisms is non-trivial.
>
> Comments in-line.
>
> -Vishal
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Zhi-Wei Lin
> > Sent: Thursday, May 30, 2002 11:54 AM
> > To: Suresh Katukam
> > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp=20
> > (E-mail); mpls@UU. NET (E-mail)
> > Subject: Re: Sonet Ring provisioning
> >
> >
> > Hi Suresh,
> >
> > Yes agree this is very complex if you try to create too much=20
> > dependencies between control plane and transport plane protection=20
> > interactions. That is why my simplistic approach:
> >
> >     * Control plane sees the entire ring as offering "highly
available"
> >       connections
> >     * Control plane sets up a single connection across this ring
> >       "sub-network" (if you think this about this, the entire ring
can
> >       actually be treated by a control plane controller as a single
node
> >       where the BLSR ring nodes may be thought of as aggregate ports
on
> >       the single node)
> >     * The ring sub-network, by virtue of providing the protection
and
> >       knowing *exactly* how protection is provided can set up the
> >       protection channel automatically (but control plane need not
know
> >       this as it is irrelevant to the control plane -- it only needs
to
> >       know that the single connection is protected)
>
> What mechanism will the ring use to setup the internal protection=20
> channel?
>
> Will it require EMS/NMS intervention, as proposed on this thread=20
> earlier, or will there be another sequence of control plane messages=20
> (initiated internal to the ring) to set this path up. The latter would

> be prefereable if the objective is to have fully-automated path setup=20
> (otherwise, we have EMS/NMS intervention for the ring), but it does=20
> complicate the control plane protocols (since a new sequence of setup=20
> steps may have to be initiated internal to each ring on the path of=20
> the end-to-end circuit/trail that is being setup.
>
> -Vishal
>
> >

Delivery-date: Wed, 05 Jun 2002 11:31:59 -0700
Date: Wed, 5 Jun 2002 14:27:59 -0500
From: "Tao Li" <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: Liberal label retention vs. Conservative label retention
Organization: Polytechnic University

Dear All,

I get confused about the label retention mode used in GMPLS. It reads
'Liberal label retention is normally used, but conservative label 
retention mode could also be used' in <GMPLS-architecture-02, Page8>.
Since GMPLS mandates downstream-on-demand label allocation with ingress
initiated ordered control, how could liberal label retention being
typically used? RFC3036 describes liberal label retention as 'When 
operating in Downstream on Demand mode with liberal label retention, 
an LSR might choose to request label mappings for all known prefixes 
from all peer LSRs.' For SONET or WDM-switch based LSRs, the above
situation will never happen.
I am a student and just begin to learn GMPLS. Your help is highly
appreciated.

Regards,

Tao Li
ECE Department
Polytechnic University
Brooklyn, NY 11201

Delivery-date: Wed, 05 Jun 2002 10:29:45 -0700
Date: Wed, 5 Jun 2002 10:26:49 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Michiel van Everdingen <[email-masked]>
CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Michiel,

>>  While I agree that neighbor
>>  discovery is useful, I do not believe we should stop the LMP spec
>>  from progressing.

> I don't understand this remark.
[...]
> If there is anything more I can do to help the LMP spec to progress,
> please let me know !

I believe that neighbor discovery, being a rather new topic for
the WG, would take some time to reach consensus on. This would
delay the main LMP spec.

> If neighbor discovery is not to be included in LMP, I think there
> are at least some clarifications needed in the LMP draft on what
> is and what is not supported. Furthermore, some clarifications on
> 'control channel management' are needed.

Sounds reasonable to me. Please work off-line with Jonathan on this
(feel free to CC me).

Alex

Delivery-date: Wed, 05 Jun 2002 06:58:12 -0700
Date: Wed, 05 Jun 2002 15:56:16 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: LMP & neighbor discovery

All,

I've received several private questions on how the neighbor
discovery function in
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
would work for the special case of SONET cross connects.

The problem would be that 
- SONET HO path switches (STS-1, STS-Nc) would not have
  J1 termination capabilities.
- SONET LO path switches (VT-1.5) would not have J2 termination
  capabilities.

The solution is to use test signal generators that are able to
create and monitor the 'supervisory unequipped' signal
(see ITU G.707 and ITU G.783).

By virtue of this signal,
- SONET HO path switches (STS-1, STS-Nc) *do* have J1 termination
  capabilities.
- SONET LO path switches (VT-1.5) *do* have J2 termination
  capabilities.

Alternatively, SONET HO path switches can use J0 to discover the
OC trail and infer the STS connectivity from this discovered OC
trail. Likewise, SONET LO path switches can use J1 to discover
the STS trail and infer the VT-1.5 connectivity from this
discovered STS trail.

This alternative approach however has some limitations:
- Not applicable for serial compound linkConnections
  See also http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00621.html
- Not applicable for STS connectivity discovery in case regenerators
  terminate the J0 in-between STS cross connects.

Same concept applies in SDH and OTN (supervisory unequipped is called
'NULL client' in OTN).

Hope this helps !

Best regards,

Michiel

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Wed, 05 Jun 2002 06:13:34 -0700
Cc: [email-masked]
Date: Wed, 05 Jun 2002 15:09:05 +0200
From: Michiel van Everdingen <[email-masked]>
Organization: Lucent Technologies
To: Alex Zinin <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Alex,

>  The main point of contention is whether the LMP spec should
>  include neighbor discovery or not.

Agreed.

>  While I agree that neighbor
>  discovery is useful, I do not believe we should stop the LMP spec
>  from progressing.

I don't understand this remark.

I've given very explicit text that can - in my mind - extremely
simple be added as *optional* procedure in the current LMP draft.
As far as I know, I did not receive a single question or single
problem with adding this text into the current LMP draft.

For the text, please refer to
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html

As this type of neighbor discovery is *optional*, I think it covers
Martin's worry that it has a big impact on vendors that have
implementations according to the current LMP draft.

If there is anything more I can do to help the LMP spec to progress,
please let me know !

>  I suggest that the WG follows the recommendation made by
>  its co-chair (see Kireeti's message on May 29th), i.e., work on
>  the LMP spec is completed without neighbor discovery and folks
>  interested in defining this functionality work together in a
>  _constructive_ manner and come up with a separate draft.

If neighbor discovery is not to be included in LMP, I think there
are at least some clarifications needed in the LMP draft on what
is and what is not supported. Furthermore, some clarifications on
'control channel management' are needed.

Please see also my reaction on Kireeti's message, posted on May 30th.
I would be interested in your reply also !

Thanks,

Michiel

Alex Zinin wrote:
> 
> Folks,
> 
>  This discussion has been going on for a while and I think it
>  is past the point where it could help the progress of the WG.
> 
>  The main point of contention is whether the LMP spec should
>  include neighbor discovery or not. While I agree that neighbor
>  discovery is useful, I do not believe we should stop the LMP spec
>  from progressing.
> 
>  I suggest that the WG follows the recommendation made by
>  its co-chair (see Kireeti's message on May 29th), i.e., work on
>  the LMP spec is completed without neighbor discovery and folks
>  interested in defining this functionality work together in a
>  _constructive_ manner and come up with a separate draft.
> 
>  Regards,
> 
> Alex Zinin

-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:[email-masked]  |
+------------------------------------------------------------------+

Delivery-date: Tue, 04 Jun 2002 18:19:39 -0700
Date: Tue, 4 Jun 2002 18:15:18 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Re: LMP & neighbor discovery

Folks,

 This discussion has been going on for a while and I think it
 is past the point where it could help the progress of the WG.

 The main point of contention is whether the LMP spec should
 include neighbor discovery or not. While I agree that neighbor
 discovery is useful, I do not believe we should stop the LMP spec
 from progressing.

 I suggest that the WG follows the recommendation made by
 its co-chair (see Kireeti's message on May 29th), i.e., work on
 the LMP spec is completed without neighbor discovery and folks
 interested in defining this functionality work together in a
 _constructive_ manner and come up with a separate draft.

 Regards,
 
Alex Zinin

Delivery-date: Tue, 04 Jun 2002 13:45:11 -0700
Date: Tue, 04 Jun 2002 16:41:55 -0400
From: Carmine Daloia <[email-masked]>
To: Martin Dubuc <[email-masked]>
CC: Michiel van Everdingen <[email-masked]>, [email-masked]
Subject: Re: LMP & neighbor discovery

--------------010804020600010909070600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Martin,

See below.

Carmine

Martin Dubuc wrote:

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

>
>
>I am not convinced that it is not possible to perform TTP->CTP or TTP->TTP link verification with the current spec. I am pretty positive that one can perform TTP->TTP link verification when one models the TTP as a component link.
>
The reason why Michiel stated that LMP is not applicable for TTP->CTP or 
TTP->TTP is because the current LMP specification requires the TTP 
generating the test signal to change its Access Point Identifier over 
time which is not in line with G.831. G.831 requires that the TTP API be 
constant over time. Michiel's proposal satisfies the G.831 requirement 
(see Michiel's email 
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html) .

> 
> 
>Regarding the automatic discovery aspects of LMP, you are right that there is a deficiency with regards to non point-to-point configuration. Current framework of LMP works very well for point-to-point configurations.
>
So you agree that LMP does cover discovery when a point-to-point control 
channel exists across each data link. So this seems to imply that 
Discovery is within the scope of LMP. From reading the emails on this 
topic the past few weeks it is obvious that this was not clear to many 
on the ccamp list and even not clear to folks that are listed on the LMP 
specification itself.

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

> I do not know if we should extend the current spec to also allow auto-discovery of non point-to-point configuration. LMP is most useful in my mind in a point-to-point configuration, so I don't have much problems with the current limitation, which is that control channels for non point-to-point neighbors need to be manually provisioned.
>
>Finally, I am not sure why you bring the 7200 OADX in the discussion. Is this a lame argument to discredit my interventions? I hope that we could have discussions at another level.
>
>Regards,
>
>Martin
>
>-----Original Message-----
>From: Michiel van Everdingen [mailto:[email-masked]]
>Sent: Friday, May 31, 2002 5:59 AM
>To: Martin Dubuc
>Cc: [email-masked]
>Subject: Re: LMP & neighbor discovery
>
>
>Hello Martin,
>
>You seem to only be able to make bold statements without following
>up on them:
>
>- On your statement that we don't need TTP and CTP terminology
>  because you find these concepts complex:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
>  Please follow up on my question for alternative terminology:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html
>
>- On your statement that my proposal for neighbor discovery is
>  tailored specifically for Sonet/SDH:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html
>  Please follow up on my reply that it is more general
>  applicable:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html
>
>- On your statement that we don't need to enhance the 
>  discovery aspects of LMP:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html
>  Please follow up on Carmine's question in:
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html
>
>
>Would the background of your annoyance be that for your specific
>product, 7200 OADX, you are only interested in LMP-WDM (i.e.
>not LMP) ? I can understand that in a product that integrates
>OADM and OXC, it is no problem to have a fixed (not operator
>provisioned) control channel between the OADM and the OXC.
>However, your specific product is not the only product on this
>earth...
>
>
>Best regards,
>
>Michiel
>
>
>Martin Dubuc wrote:
>
>>Michiel,
>>
>>Neighbor discovery, through use of appropriate control channel management
>>(see Section 3 and 9), is supported with the current LMP draft. There is
>>no need for any extension to the draft for this purpose.
>>
>>Regards,
>>
>>Martin
>>[...snip...]
>>
>
>
>

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

<html>
<head>
</head>
<body>
Martin,<br>
<br>
See below.<br>
<br>
Carmine<br>
<br>
<br>
Martin Dubuc wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <pre wrap="">Michiel,<br><br>Just because it is easy to specify the address of an endpoint in a 15 character field doesn't mean that this is the way to go. Why not put a 30 byte field in every message in order for vendors to add any extensions they'd like? In my mind, any extensions we add to LMP has to make sense in the framework of LMP. As I said before, there is absolutely no mention of CTPs and TTPs in the current LMP spec. Introducing anything that makes reference to CTPs/TTPs would require major rework to LMP spec and might have big impact on any vendor (on this earth) implementing LMP. I am not sure it makes sense at this point in the game.</pre>
  </blockquote>
  <font face="Courier New, Courier, monospace">I don't think anyone really
cares about the exact terminology so long as it is clear and understandable.
What is more important is making sure that LMP actually provides what is
needed. &nbsp;Until LMP does provide what is needed, I don't think its too late
to change a LMP specification. Isn't this still a work in progress?</font><br>
  <blockquote type="cite" cite="mid:[email-masked]">
    <pre wrap=""><br><br>I am not convinced that it is not possible to perform TTP-&gt;CTP or TTP-&gt;TTP link verification with the current spec. I am pretty positive that one can perform TTP-&gt;TTP link verification when one models the TTP as a component link.</pre>
    </blockquote>
    <pre wrap=""></pre>
    <font face="Courier New, Courier, monospace">The reason why Michiel stated
that LMP is not applicable for TTP-&gt;CTP or TTP-&gt;TTP is because the
current LMP specification requires the TTP generating the test signal to
change its Access Point Identifier over time which is not in line with G.831.
G.831 requires that the TTP API be constant over time. Michiel's proposal
satisfies the G.831 requirement (see Michiel's email </font><a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html</a>)<font face="Courier New, Courier, monospace">
.</font> <br>
    <blockquote type="cite" cite="mid:[email-masked]">
      <pre wrap=""> <br> <br>Regarding the automatic discovery aspects of LMP, you are right that there is a deficiency with regards to non point-to-point configuration. Current framework of LMP works very well for point-to-point configurations.</pre>
      </blockquote>
      <font face="Courier New, Courier, monospace">So you agree that LMP
does cover discovery when a point-to-point control channel exists across
each data link. So this seems to imply that Discovery is within the scope
of LMP. From reading the emails on this topic the past few weeks it is obvious
that this was not clear to many on the ccamp list and even not clear to folks
that are listed on the LMP specification itself.<br>
      <br>
Given that Discovery is within the scope of LMP, what is being proposed is
that we meed to make it applicable/useful to network configurations that
do not support a point-to-point control channel across each data link. A
big portion of the LMP specification introduction describes Photonic Cross-connects,
yet Photonic Cross-connects will not be capable of supporting a point-to-point
control channel in each of its data links. So given that PXCs are within
the Framework of LMP and Discovery is as well, it would make sense to me
that Discovery would apply to PXCs. Its also going to be important for the
new "intelligent-switched" network to interwork with the embedded switches
that are controlled by the management plane. This leads to the need to support
discovery across serial-compound link connections, which LMP does not. Shouldn't
the ability to interwork with the embedded base be considered in LMP or is
LMP only applicable for new start-up companies building entirely new networks?
      </font><br>
      <blockquote type="cite" cite="mid:[email-masked]">
        <pre wrap=""> I do not know if we should extend the current spec to also allow auto-discovery of non point-to-point configuration. LMP is most useful in my mind in a point-to-point configuration, so I don't have much problems with the current limitation, which is that control channels for non point-to-point neighbors need to be manually provisioned.<br><br>Finally, I am not sure why you bring the 7200 OADX in the discussion. Is this a lame argument to discredit my interventions? I hope that we could have discussions at another level.<br><br>Regards,<br><br>Martin<br><br>-----Original Message-----<br>From: Michiel van Everdingen [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]<br>Sent: Friday, May 31, 2002 5:59 AM<br>To: Martin Dubuc<br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>Subject: Re: LMP &amp; neighbor discovery<br><br><br>Hello Martin,<br><br
>You seem to only be able to make bold statements without following<br>up on them:<br><br>- On your statement that we don't need TTP and CTP terminology<br>  because you find these concepts complex:<br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html</a><br>  Please follow up on my question for alternative terminology:<br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html</a><br><br>- On your statement that my proposal for neighbor discovery is<br>  tailored specifically for Sonet/SDH:<br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html</a><br>  Please follow up on my reply that it is more general<br>  applicable:<br>    <a class="moz-txt-link-freetext" hre
f="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html</a><br><br>- On your statement that we don't need to enhance the <br>  discovery aspects of LMP:<br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html</a><br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html</a><br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html</a><br>  Please follow up on Carmine's question in:<br>    <a class="moz-txt-link-freetext" href="http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html">http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html</a><br><br><br>Would the background of your annoyance be that for your 
specific<br>product, 7200 OADX, you are only interested in LMP-WDM (i.e.<br>not LMP) ? I can understand that in a product that integrates<br>OADM and OXC, it is no problem to have a fixed (not operator<br>provisioned) control channel between the OADM and the OXC.<br>However, your specific product is not the only product on this<br>earth...<br><br><br>Best regards,<br><br>Michiel<br><br><br>Martin Dubuc wrote:<br></pre>
        <blockquote type="cite">
          <pre wrap="">Michiel,<br><br>Neighbor discovery, through use of appropriate control channel management<br>(see Section 3 and 9), is supported with the current LMP draft. There is<br>no need for any extension to the draft for this purpose.<br><br>Regards,<br><br>Martin<br>[...snip...]<br></pre>
          </blockquote>
          <pre wrap=""><!----><br><br><br></pre>
          </blockquote>
          <br>
          </body>
          </html>

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

Delivery-date: Tue, 04 Jun 2002 09:44:15 -0700
content-class: urn:content-classes:message
Subject: RE: LMP & neighbor discovery
Date: Tue, 4 Jun 2002 12:40:12 -0400
From: "Martin Dubuc" <[email-masked]>
To: "Michiel van Everdingen" <[email-masked]>
Cc: <[email-masked]>

Michiel,

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

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

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

Regards,

Martin

-----Original Message-----
From: Michiel van Everdingen [mailto:[email-masked]]
Sent: Friday, May 31, 2002 5:59 AM
To: Martin Dubuc
Cc: [email-masked]
Subject: Re: LMP & neighbor discovery

Hello Martin,

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

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

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

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

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

Best regards,

Michiel

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

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

Delivery-date: Tue, 04 Jun 2002 04:46:57 -0700
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-yagyu-gmpls-shared-restoration-routing-00.txt
Date: Tue, 04 Jun 2002 07:43:22 -0400

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-yagyu-gmpls-shared-restoration-routing-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-yagyu-gmpls-shared-restoration-routing-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 03 Jun 2002 05:30:46 -0700
Date: Mon, 03 Jun 2002 08:29:27 -0400
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-01.txt

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

Lou

At 07:37 AM 6/3/2002, [email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Common Control and Measurement Plane 
>Working Group of the IETF.
>
>         Title           : Generalized MPLS Signaling - Implementation Survey
>         Author(s)       : L. Berger, Y. Rekhter
>         Filename        : draft-ietf-ccamp-gmpls-signaling-survey-01.txt
>         Pages           : 81
>         Date            : 31-May-02
>
>This document provides a survey of GMPLS signaling implementations.
>The primary focus of this survey are the signaling protocol
>mechanisms specified in the Generalized MPLS signaling documents.
>Other specifications and documents are listed if included in the
>submitted form.  The survey form and latest version of this document
>are available from 
><http://www.labn.net/gmpls-survey>http://www.labn.net/gmpls-survey.
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt 
>
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-ccamp-gmpls-signaling-survey-01.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>or 
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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-signaling-survey-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>

Delivery-date: Mon, 03 Jun 2002 04:39:34 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
Date: Mon, 03 Jun 2002 07:37:36 -0400

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 03 Jun 2002 04:39:25 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-signaling-survey-01.txt
Date: Mon, 03 Jun 2002 07:37:23 -0400

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-signaling-survey-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 03 Jun 2002 04:39:19 -0700
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
Date: Mon, 03 Jun 2002 07:37:29 -0400

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Delivery-date: Mon, 03 Jun 2002 02:16:42 -0700
Cc: Sudheer Dharanikota <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Suresh Katukam <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Date: Mon, 03 Jun 2002 11:14:23 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: Sudheer Dharanikota <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Suresh Katukam <[email-masked]>, "R. Muralidharan" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Manoj Agiwal'" <[email-masked]>, "'Ccamp (E-mail)" <[email-masked]>, "mpls@UU. NET (E-mail)" <[email-masked]>
Subject: Re: Sonet Ring provisioning

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

Vishal,

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

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

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

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

Regards,

Maarten

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

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

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

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

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

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[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

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