Subject: FW: Questions about tunneltrace
From: Ron Bonica <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 01 Mar 2001 00:43:08 -0500

Eric,

Thanks for your comments. See reply below....

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eric Rosen
> Sent: Tuesday, February 27, 2001 12:16 PM
> To: [email-masked]
> Subject: Questions about tunneltrace
>
>
> From draft-bonica-tunneltrace-01:
>
>       9) When the tunneling technology isolates the user-plane from the
>       control-plane, do not rely upon the control plane to discover the
>       path.
>
> From draft-bonica-tunproto-00:
>
>    D2 receives the TraceProbe, exercises access control, and determines
>    that it is the hop's head end device. D2 consults its FIB and
>    determines that an IP-in-IP tunnel supports H1.
>
> I think this is saying that  D2 must consult its control
> structures in order
> to determine whether the "hop" H1  is a tunnel or not.  Doesn't
> this violate
> the requirement above?  In the  event of failures, D2's
> "determination" that
> data packets are supposed to be traveling through a tunnel
> doesn't necessar-
> ily mean that data packets would actually travel through that tunnel.

You have a point! Strictly speaking, I am not tracing through the
user-plane, but bouncing back and forth between the user-plane and the
control-plane. I have no choice but to do so.

In order to remain in the user-plane, I would have to send a series of
datagrams from the head-end of the top-level tunnel to the tail-end of the
top level tunnel, causing the each datagram to self destruct at a different
point along the path. Upon destruction, each datagram would elicit some
feedback that would a) include tunnel details and b) be sent all the way
back to the head-end of the top-level path.

Isn't that the kind of layer violation that we are trying to avoid?

Even if this is an acceptable layer violation, don't I still need to do such
things when tracing through tunnels that don't support TTL decrement?

>
> I am also  puzzled more generally about the phrase "D2  consults
> its FIB and
> determines  that a  ...  tunnel  supports H1."   I don't
> understand  how in
> general  D2  can  make  this  determination from  the
> information  that  is
> available in  the traceprobe packet.  If  we're trying to  trace
> nested MPLS
> tunnels, then it would  seem that we at least need to  know the
> label that a
> data packet would have  when it enters D2, but I don't  see any
> place to put
> that.
> More generally,  there doesn't seem to be  any provision
> for handling
> the case  in which  the routing  of a packet  is not  based
> entirely  on the
> packet's destination address.
>
> Similarly, I don't see  how a hop can be identified by  a
> object" which
> has only the IP addresses of the  hop endpoints.  There can be
> any number of
> tunnels between the same  two endpoints, each with different
> characteristics
> and  even with  different routes.   The  only data  you seem  to
> provide  of
> choosing one of these tunnels over the others is the destination
> IP address,
> and this isn't necessarily sufficient.

Again, you have a point!

When we analyse H1, the following information is available:

	-> top-level information (D1's loopback, D4's loopback, TOS)
	-> H1 information (a head-end address on D2, and a tail-end address on D3)

Now, assume that there are two tunnels between D2 and D3. One supports all
UDP traffic, while the other supports all TCP traffic. As currently
specified, GTTP could not distinguish between them. I need another field in
the traceProbe that contains the begining of the packet that I would trace,
including transport layer headers.

>
> On a  more trivial  matter, the  protocol draft will  need to
> say something
> about timing out remembered traceprobes,  in case the trace
> response doesn't
> come back.

Agreed. I will catch this on the next revision.

>
>
>

Delivery-date: Wed, 28 Feb 2001 08:18:02 -0800
Date: Wed, 28 Feb 2001 11:16:39 -0500
From: Dave Walker <[email-masked]>
Reply-To: [email-masked]
To: CCAMP WG <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-walker-ccamp-req-00.txt]

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

Proposed as requirements for the CCAMP work...
--------------E20E3769BA07636418E67E55
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-walker-ccamp-req-00.txt
Date: Tue, 27 Feb 2001 06:50:48 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Common Control and Measurement Plane Framework and 
                          Requirements
	Author(s)	: D. Walker et al.
	Filename	: draft-walker-ccamp-req-00.txt
	Pages		: 33
	Date		: 26-Feb-01
	
This document describes architectural and protocol requirements for 
the Common Control and Measurement Plane.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-walker-ccamp-req-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-walker-ccamp-req-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-walker-ccamp-req-00.txt

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

--OtherAccess--

--NextPart--

--------------E20E3769BA07636418E67E55--

Delivery-date: Wed, 28 Feb 2001 05:18:34 -0800
Date: Wed, 28 Feb 2001 08:04:00 -0500
From: Ron Bonica <[email-masked]>
Subject: draft-bonica-tunproto-00
To: [email-masked]

FYI

=========================================

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

	Title		: Generic Tunnel Tracing Protocol (GTTP) Specification
	Author(s)	: R. Bonica et al.
	Filename	: draft-bonica-tunproto-00.txt
	Pages		:
	Date		: 22-Feb-01

This document describes the Generic Tunnel Tracing Protocol (GTTP).
GTTP supports enhanced route-tracing applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bonica-tunproto-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-bonica-tunproto-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-bonica-tunproto-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.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Not all who wander are lost."
                -- J.R.R. Tolkien

Delivery-date: Wed, 28 Feb 2001 05:18:34 -0800
Date: Wed, 28 Feb 2001 08:03:59 -0500
From: Ron Bonica <[email-masked]>
Subject: draft-bonica-tunneltrace-01
To: [email-masked]

FYI

============================================================================
=====

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

	Title		: Tracing Requirements for Generic Tunnels
	Author(s)	: R. Bonica, K. Kompella, D. Meyer
	Filename	: draft-bonica-tunneltrace-01.txt
	Pages		: 11
	Date		: 22-Feb-01

This document specifies requirements for a generic route tracing
application.  The application must provide all functionality that
'traceroute' [RFC 2151] currently provides.  It also must provide
enhanced capabilities with regard to tracing through tunnels (e.g.,
IP-in-IP, MPLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bonica-tunneltrace-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-bonica-tunneltrace-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-bonica-tunneltrace-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.

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"Not all who wander are lost."
                -- J.R.R. Tolkien

Envelope-to: [email-masked]
Delivery-date: Mon, 26 Feb 2001 04:07:56 -0800
Date: Mon, 26 Feb 2001 04:04:06 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Achieving Assured Service Levels through Source Routed MPLS

Hi Mark,

Thanks very much for your draft.

> It is intended to pursue this as an informational draft but it has relevance
> to the CCAMP wg directly

Unfortunately, CCAMP is not chartered to do IP QoS.

Fortunately, there are other WGs that would in all likelihood be
more than happy to host your work.

Kireeti.

Delivery-date: Mon, 26 Feb 2001 02:26:33 -0800
From: "Mark Gibson" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: 
Date: Mon, 26 Feb 2001 10:22:15 -0000

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_01C09FDD.FD4D6330
Content-Type: text/plain;
	charset="iso-8859-1"

The following Internet Draft is now available from the online document
store:

http://search.ietf.org/internet-drafts/draft-gibson-mpls-srcroute-00.txt

Abstract 
   This memo sets out an MPLS-based solution to the IP service delivery 
   problems as set out in RFC 2990. The solution is based on source 
   routing of IP flows using MPLS label stacks.  
    
   The solution elements are introduced sequentially and a usage 
   scenario is mapped out that aligns with the work in the ISSLL working 
   group.

It is intended to pursue this as an informational draft but it has relevance
to the CCAMP wg directly and to the other wgs CC'd on this email. (apologies
for the cross-post spamming but I wanted to make sure I didn't miss anyone
out).

Mark

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

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

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">The =
following Internet Draft is now available from the online document =
store:</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-gibson-mpls-srcrout=
e-00.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-gibson-mp=
ls-srcroute-00.txt</A></FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">Abstract </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp; This memo sets out an MPLS-based solution to the IP =
service delivery </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp; problems as set</FONT> <FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial Unicode MS">out in RFC 2990. The solution is =
based on source </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp; routing of IP flows using MPLS label stacks.&nbsp; =
</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp;&nbsp; </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp; The solution elements are introduced sequentially and =
a usage </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial Unicode =
MS">&nbsp;&nbsp; scenario is mapped out that aligns with the work in =
the ISSLL working </FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp; group.</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">It is =
intended to pursue this as an informational draft but it has relevance =
to the CCAMP wg directly and to the other</FONT><FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial"> wg</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">s CC'd on this email.</FONT> <FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial">(apologies for the cross-post spamming but I =
wanted to make sure I didn't miss anyone out).</FONT></P>

<P ALIGN=3DLEFT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Mark</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C09FDD.FD4D6330--

Delivery-date: Fri, 23 Feb 2001 12:41:40 -0800
From: Murali Krishnaswamy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: ID: draft-krishnaswamy-optical-rsvp-extn-00.txt
Date: Fri, 23 Feb 2001 15:31:33 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C09DD7.9C3C30F6
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Please post the attached draft on the IETF internet draft directory.

>From Abstract:
We propose an extension to RSVP-TE that would permit setting up optical
channel connections whose paths form a topology that is independent of the
control layer topology. 

Thank you,
Murali Krishnaswamy
Photuris Inc.
[email-masked]

 <<rsvp.txt>> 

------_=_NextPart_000_01C09DD7.9C3C30F6
Content-Type: text/plain;
	name="rsvp.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="rsvp.txt"

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Internet Draft                               Murali Krishnaswamy=0A=
                                             Leah Zhang=0A=
                                             Antonio Rodriguez-Moral=0A=
                                             Photuris Inc.=0A=
=0A=
Expires August 2001                          22 February 2001=0A=
=0A=
=0A=
=0A=
               Lightpath Route Extensions to RSVP-TE for=0A=
                    optical channel connection setup=0A=
=0A=
             <draft-krishnaswamy-optical-rsvp-extn-00.txt>=0A=
=0A=
Status of this Memo=0A=
=0A=
   This document is an Internet-Draft and is in full conformance =
with=0A=
   all provisions of Section 10 of RFC2026.  Internet-Drafts are =
working=0A=
   documents of the Internet Engineering Task Force (IETF), its =
areas,=0A=
   and its working groups.  Note that other groups may also =
distribute=0A=
   working documents as Internet-Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six =
months=0A=
   and may be updated, replaced, or obsoleted by other documents at =
any=0A=
   time.  It is inappropriate to use Internet-Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
=0A=
1. Abstract=0A=
=0A=
   We propose an extension to RSVP-TE [1][2]that would permit setting =
up=0A=
   OCh (optical channel) connections whose paths form a topology that =
is=0A=
   independent of the control layer topology. This separation of an =
OCh=0A=
   connection path and the associated control layer network may be=0A=
   necessary for many reasons.  First, it may not be possible to =
provide=0A=
   a control channel connection to each one of an optical network=0A=
   element (ONE)'s neighbor - for many reasons explained in Sec. 2. =
(ONE=0A=
   as used in this draft includes optical cross-connect (OXC), =
optical=0A=
   add-drop multiplexer (OADM) or even optical terminal multiplexer=0A=
   (OTM).  Secondly by providing the means to signal OCh connections=0A=
   through different multiple control paths, we achieve network=0A=
   resilience against control channel failure. We propose a new=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
1]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   extension to RSVP-TE called Lightpath Route Object (LRO) which is =
a=0A=
   list of nodes along OCh connection path. This is carried in the =
Path=0A=
   message by RSVP-TE as an Opaque Object for interpretation and use =
by=0A=
   the optical nodes. This facilitates setting up OCh connections=0A=
   between nodes that have no adjacency at the IP layer.=0A=
=0A=
=0A=
2. Introduction=0A=
=0A=
   OCh connections can be setup using a signaling scheme similar to=0A=
   those proposed in the Generalized MPLS signaling drafts [3][4]. =
Due=0A=
   to the multiple influencing parameters, the end-to-end path for =
OCh=0A=
   connections is always predetermined and signaled as ERO using =
RSVP-=0A=
   TE. An implicit (and required) assumption in such cases is that, =
the=0A=
   OCh path aligns with the control path.  This OCh and control path=0A=
   association is necessary as RSVP-TE requires IP adjacency.  =
Further=0A=
   the proposed OSPF extensions to support MPlambdaS [5] and the =
opaque=0A=
   TE extensions in general [6], advertise only those TE parameters=0A=
   (both control and OCh) that are specific to that control channel=0A=
   (link).  (Note: Even if an OCh connection that doesn't belong to =
a=0A=
   particular link is advertised over that link, still there is no =
way=0A=
   of signaling an OCh path that is different from the control path=0A=
   (ERO).=0A=
                                       Control Channel=0A=
              ++++++++++++++ +-------+ ++++++++++++++=0A=
              + -------------|   A   |------------- +=0A=
              + |            |       | OCh-Ring-1 | +=0A=
              + |  --------- |       | ---------  | +=0A=
              + |  |         +-------+ OCh-Ring|  | +=0A=
              + |  |                        -2 |  | +=0A=
            +-------+                         +-------+=0A=
            |   D   |-------------------------|   B   |=0A=
            |       |                         |       |=0A=
            +-------+                         +-------+=0A=
              + |                                 | +=0A=
              + |                                 | +=0A=
              + |            +-------+            | +=0A=
              + |------------|   C   |------------| +=0A=
              +++++++++++++++|       |+++++++++++++++=0A=
                             +-------+=0A=
=0A=
        Fig. 1 - Multiple Rings.=0A=
                  OCh-Ring 1 - A-B-C-D=0A=
                  OCh-Ring 2 - A-B-D (No control channel between =
B-D)=0A=
=0A=
   This dependency makes it impossible to set up OCh connections =
between=0A=
   two nodes if they have no adjacency at the IP layer - ie. if there =
is=0A=
   no control channel between them (B-D in Fig.1).  Hence a network=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
2]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   operator can't configure and offer ring configurations similar to=0A=
   OCh-Ring-2.=0A=
=0A=
   Thus this control/OCh layers topology association puts limitations =
in=0A=
   the deployment and features that can be offered by a network=0A=
   operator.=0A=
=0A=
   Some of the reasons for not providing control channel between=0A=
   adjacent nodes are:=0A=
=0A=
=0A=
    o   Since the control channels are terminated in each node,=0A=
        optics/hardware architecture may limit the total number of =
con-=0A=
        trol channels in an optical node. This may be especially true =
in=0A=
        a low cost access/metro WDM system or in highly meshed =
network.=0A=
=0A=
    o   Where an out-of-fiber separate control channel (eg. ethernet) =
is=0A=
        deployed, it is difficult to colocate the controls channel =
along=0A=
        all of the optical paths.=0A=
=0A=
   A more compelling reason for LRO is the case of optical ring =
networks=0A=
   where a network operator would typically prefer to setup "short =
side"=0A=
   connections even in the event of the control channel failure =
along=0A=
   this path (Fig. 2).  As the control channel uses a separate wave-=0A=
   length, for eg. its transmitter/receiver could fail, while all =
the=0A=
   other wavelengths (that carry user data) remain unaffected.  One =
less=0A=
   obvious disadvantage of a long side connection is that it could=0A=
   increase the blocking probability for future wavelength =
allocations.=0A=
=0A=
=0A=
                             +-------+ Control Channel Failure=0A=
              +++++++++++++++|   A   |+++++++++ X X X=0A=
              +    ----------|       |----------    X=0A=
              +    |         +-------+  OCh    |    X=0A=
              +    |                           |    +=0A=
              +    |                           |    +=0A=
            +-------+                         +-------+=0A=
            |   D   |                         |   B   |=0A=
            |       |                         |       |=0A=
            +-------+                         +-------+=0A=
              +    |                           |    +=0A=
              +    |                           |    +=0A=
              +    |         +-------+         |    +=0A=
              +    ----------|   C   |----------    +=0A=
              +++++++++++++++|       |+++++++++++++++=0A=
                             +-------+=0A=
           Fig. 2 - Control Channel Failure between A-B=0A=
=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
3]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   When the control channel between A and B fails, it is not possible =
to=0A=
   setup short side (A-B) OCh connections between A and B using =
RSVP-TE=0A=
   even though the data channels between them remain unaffected.  =
With=0A=
   LRO extensions we would be able to signal and setup the short side =
A-=0A=
   B OCh connection (by specifying LRO as A-B) while letting the =
control=0A=
   message go through the longer path A-D-C-B (or B-C-D-A).=0A=
=0A=
=0A=
   Note: Link Management Protocol [7] proposes protection control =
chan-=0A=
   nels for maintaining link connectivity.  The protection control =
chan-=0A=
   nel takes over when the primary one fails.  However such =
proposals=0A=
   may not be feasible in many systems for architectural and =
economic=0A=
   reasons.=0A=
=0A=
=0A=
3. Lightpath Route Object (LRO)=0A=
=0A=
   Owing to the above reasons we propose an extension to RSVP-TE =
called=0A=
   Lightpath Route Object and this is a list of the nodes in the OCh=0A=
   connection path.  LRO is carried in the Path message and is =
treated=0A=
   as an Opaque Object by RSVP-TE. It is up to the applications on =
the=0A=
   nodes to use the path information in LRO to set up the OCh =
connec-=0A=
   tions. RSVP-TE (control path) itself follows the ERO path only.=0A=
=0A=
   The lightpath routes are specified by the LIGHTPATH_ROUTE object=0A=
   (LRO).=0A=
=0A=
3.1 Path Message=0A=
=0A=
=0A=
      The format of the Path message is as follows:=0A=
=0A=
         <Path Message> ::=3D       <Common Header> [ <INTEGRITY> ]=0A=
                                  <SESSION> <RSVP_HOP>=0A=
                                  <TIME_VALUES>=0A=
                                  [ <LIGHTPATH_ROUTE> ]=0A=
                                  [ <EXPLICIT_ROUTE> ]=0A=
                                  <LABEL_REQUEST>=0A=
                                  [ <SESSION_ATTRIBUTE> ]=0A=
                                  [ <POLICY_DATA> ... ]=0A=
                                  <sender descriptor>=0A=
=0A=
         <sender descriptor> ::=3D  <SENDER_TEMPLATE> <SENDER_TSPEC>=0A=
                                  [ <ADSPEC> ]=0A=
                                  [ <RECORD_ROUTE> ]=0A=
=0A=
=0A=
   The relative placement of LIGHTPATH_ROUTE object is simply a=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
4]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   recommendation.  The ordering of the objects is not important, so =
an=0A=
   implementation MUST be prepared to accept objects in any order.=0A=
=0A=
   We define a new Lightpath route class =3D 22 (check), c_type =3D =
1.=0A=
=0A=
=0A=
3.2 LIGHTPATH_ROUTE Format=0A=
=0A=
=0A=
   LIGHTPATH_ROUTE has  the  following format:=0A=
=0A=
          0                   1                   2                   =
3=0A=
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         |                                                              =
 |=0A=
         //                        (Subobjects)                         =
 //=0A=
         |                                                              =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
      The contents of an LIGHTPATH_ROUTE object are a  series  of =
variable-=0A=
      length data items called subobjects.  Each subobject has the =
form:=0A=
=0A=
          0                   1=0A=
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+=0A=
         |L|    Type     |     Length    | (Subobject contents)         =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+=0A=
=0A=
=0A=
         L=0A=
            The L bit is reserved.=0A=
=0A=
         Type=0A=
=0A=
            The Type indicates the  type  of  contents  of  the  =
subobject.=0A=
            Currently defined values are:=0A=
=0A=
                0   Reserved=0A=
                1   IPv4 prefix=0A=
                2   IPv6 prefix=0A=
=0A=
         Length=0A=
=0A=
            The Length contains the total length of the subobject in =
bytes,=0A=
            including the L, Type and Length fields.  The Length MUST =
be at=0A=
            least 4, and MUST be a multiple of 4.=0A=
=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
5]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   Two Subobjects are defined - for IPv4 and IPv6.=0A=
=0A=
   Subobject 1:  IPv4=0A=
=0A=
          0                   1                   2                   =
3=0A=
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         |L|    Type     |     Length    | IPv4 address (4 bytes)       =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         | IPv4 address (continued)      |              Resvd           =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
         L=0A=
            The L bit is reserved.=0A=
=0A=
         Type=0A=
            0x01  IPv4 address=0A=
=0A=
         Length=0A=
            The Length contains the total length of the subobject in=0A=
            bytes, including the Type and Length fields.  The Length=0A=
            is always 8.=0A=
=0A=
         IPv4 address=0A=
            An IPv4 address (of the optical node).=0A=
=0A=
         Padding=0A=
         Zero on transmission.  Ignored on receipt.=0A=
=0A=
=0A=
   Subobject 2:  IPv6=0A=
=0A=
          0                   1                   2                   =
3=0A=
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         |L|    Type     |     Length    | IPv6 address (16 bytes)      =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         | IPv6 address (continued)                                     =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         | IPv6 address (continued)                                     =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         | IPv6 address (continued)                                     =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
         | IPv6 address (continued)      |             Resvd            =
 |=0A=
         =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
6]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
         L=0A=
            The L bit is reserved.=0A=
=0A=
         Type=0A=
            0x02  IPv6 address=0A=
=0A=
         Length=0A=
            The Length contains the total length of the subobject in=0A=
            bytes, including the Type and Length fields.  The Length=0A=
            is always 20.=0A=
=0A=
         IPv6 address=0A=
            An IPv6 address (of the optical node).=0A=
=0A=
          Padding=0A=
             Zero on transmission.  Ignored on receipt.=0A=
=0A=
=0A=
4. LRO and ERO=0A=
=0A=
   Though LRO is an Opaque object as far as RSVP-TE is concerned, a =
few=0A=
   guidelines are provided regarding its usage and its co-existence =
with=0A=
   ERO.=0A=
=0A=
=0A=
    o   First of all to help implementation LRO is defined such that =
its=0A=
        format is similar to ERO.=0A=
=0A=
=0A=
    o   When the RSVP-TE message has no LRO, then the optical nodes =
must=0A=
        use the path specified in the ERO for the OCh connection.=0A=
=0A=
=0A=
    o   When the RSVP-TE message carries LRO, then the optical nodes=0A=
        must use the path specified in the LRO for the OCh =
connection.=0A=
=0A=
=0A=
    o   The LRO nodes must be a sub-set of the ERO nodes.=0A=
=0A=
=0A=
    o   The source and destination nodes of the LRO and ERO must be =
the=0A=
        same.=0A=
=0A=
=0A=
    o   On an implementation note a source node must reject a =
connection=0A=
        request if the above two requirements are not satisfied.=0A=
=0A=
5. Label operation in the presence of LRO=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
7]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
   In switched optical networks the labels carried in the Resv =
message=0A=
   are generally encoded to represent the WDM channels or lambdas =
that=0A=
   have been selected by the downstream neighbors. In cases where =
the=0A=
   LRO is not the same as ERO (normally this should be the case as =
oth-=0A=
   erwise no LRO is required), the label allocation and usage is=0A=
   slightly different.=0A=
=0A=
   When LRO is specified, those intermediate nodes which are not a =
part=0A=
   of LRO (non-LRO nodes) must generate "dummy" or some =
"pre-assigned"=0A=
   labels that are recognized by LRO nodes. (A node determines if it =
is=0A=
   a LRO or non-LRO node by looking in to the PSB).  Only the LRO =
nodes=0A=
   generate valid labels useful for setting up OCh connections.  If =
a=0A=
   LRO member node upon receiving the Resv message, finds that the =
top=0A=
   label is a dummy one, it must then ignore that and look down in =
to=0A=
   the stack till it finds a valid label. (This label will obviously=0A=
   correspond to that of its predecessor LRO node). It is this label=0A=
   that a LRO node must use for setting up OCh connections.=0A=
=0A=
   Note: This draft doesn't modify the RSVP-TE behavior.=0A=
=0A=
=0A=
6. Security Considerations=0A=
=0A=
   This draft doesn't raise any security considerations.=0A=
=0A=
=0A=
7. References=0A=
=0A=
=0A=
[1]   Braden, R. et al., "Resource ReSerVation Protocol (RSVP) - =
Version=0A=
      1, Functional Specification", RFC 2205, September 1997.=0A=
=0A=
[2]   Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP =
Tunnels",=0A=
      Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August=0A=
      2000.=0A=
=0A=
[3]   Ashwood-Smith, P. et. al., "Generalised MPLS - Signaling Func-=0A=
      tional Description", Internet Draft, =
draft-ietf-mpls-generalised-=0A=
      signaling -00.txt, October 2000.=0A=
=0A=
[4]   Ashwood-Smith, P. et. al., "Generalised MPLS Signaling - =
RSVP-TE=0A=
      Extensions", Internet Draft, =
draft-ietf-mpls-generalised-rsvp-te=0A=
      -00.txt, November 2000.=0A=
=0A=
[5]   Kompella, K. et. al., "OSPF Extensions in Support of =
MPL(ambda)S",=0A=
      Internet Draft, draft-kompella-ospf-ompls-extensions-00.txt, =
July=0A=
      2000.=0A=
=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
8]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I.D.           draft-krishnaswamy-optical-rsvp-extn-00.txt=0A=
=0A=
=0A=
[6]   Katz, D. et. al., "Traffic Engineering Extensions to OSPF", =
Inter-=0A=
      net Draft, draft-katz-yeung-ospf-traffic-03.txt, September =
2000.=0A=
=0A=
[7]   Lang, J. et. al., "Link Management Protocol [LMP]", Internet=0A=
      Draft, draft-lang-mpls-lmp-02.txt, July 2000.=0A=
=0A=
=0A=
8. Authors' Addresses=0A=
=0A=
   Murali Krishnaswamy, Leah Zhang, Antonio Rodriguez-Moral=0A=
   Photuris Inc.=0A=
   20 Corporate Place South=0A=
   Piscataway NJ 08854=0A=
   Tel: +1 (732) 465 1000 x1220, x1252, x1343=0A=
   Fax: +1 (732) 465 1010=0A=
   E-mail: murali, lzhang, [email-masked]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Krishnaswamy, et al.                                            [Page =
9]=0A=
=0A=
=0A=

------_=_NextPart_000_01C09DD7.9C3C30F6--

Delivery-date: Fri, 23 Feb 2001 08:18:29 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: New: draft-harrison-mpls-oam-00.txt 
Date: Fri, 23 Feb 2001 08:15:33 -0800

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_000_01C09DB3.D919AFE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Please post the attached Internet draft on the IETF Internet draft directory. 

 <<draft-harrison-mpls-oam-00.txt.txt>> 

Thanks,
Shahram Davari
Systems Engineer
Product Research Group
PMC-Sierra, Inc. (Ottawa)
Phone: (613) 271-4018
Fax:    (613) 271-7007
 <<Shahram Davari.vcf>> 

------_=_NextPart_000_01C09DB3.D919AFE0
Content-Type: text/plain;
	name="draft-harrison-mpls-oam-00.txt.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-harrison-mpls-oam-00.txt.txt"

                                                          Neil Harrison =

   Internet Draft                                          Peter Willis =

   Document: draft-harrison-mpls-oam-00.txt             British Telecom =

   Expires: August 2001                                                 =

                                                         Shahram Davari =

                                                             PMC-Sierra =

                                                                        =

                                                         Ben Mack-Crane =

                                                                Tellabs =

                                                                        =

                                                           Hiroshi Ohta =

                                                                    NTT =

                                                                        =

                                                          February 2001 =

   =20
   =20
                    OAM Functionality for MPLS Networks=20
   =20
   =20
Status of this Memo=20
   =20
   This document is an Internet-Draft and is in full conformance=20
   with all provisions of Section 10 of RFC2026.=20
   =20
   =20
   Internet-Drafts are working documents of the Internet Engineering=20
   Task Force (IETF), its areas, and its working groups.  Note that     =
=20
   other groups may also distribute working documents as Internet-
   Drafts.=20
   =20
   Internet-Drafts are draft documents valid for a maximum of six=20
   months and may be updated, replaced, or obsoleted by other documents =

   at any time.  It is inappropriate to use Internet-Drafts as=20
   reference material or to cite them other than as "work in progress." =

   =20
   The list of current Internet-Drafts can be accessed at=20
        http://www.ietf.org/ietf/1id-abstracts.txt=20
   The list of Internet-Draft Shadow Directories can be accessed at=20
        http://www.ietf.org/shadow.html.=20
   =20
   =20
Copyright Notice=20
   =20
   Copyright(C) The Internet Society (2001). All Rights Reserved.=20
   =20
   =20
Abstract=20
   =20
   This Internet draft provides requirements and mechanisms for OAM=20
   (Operation and Maintenance) for the user-plane in MPLS networks. A=20
   connectivity verification "CV" OAM packet is defined, which is=20
   transmitted periodically from LSP source to LSP sink. The CV flow=20
   could be used to detect defects related to misrouting of LSPs as=20
   well as link and nodal failure, and if required to trigger=20
   protection switching to the protection path.=20
    =20
   Harrison et.al        Expires August 2001                   Page 1 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
   A forward defect identifier "FDI" and a backward defect identifier=20
   "BDI" are defined, which carry the defect type and location to the=20
   near end and far end respectively. At every LSP terminating node,=20
   the FDI is mapped from server layer to client layer. By doing so FDI =

   could suppress the alarm storm, and let the appropriate layer take=20
   control of protection switching. BDI is used by LSP source to start=20
   or stop the QoS aggregation, depending on whether the LSP is in=20
   available or unavailable state. The criteria for entry and exit to=20
   the available and unavailable states are also defined in this=20
   document.=20
=20
=20
Table of Contents=20
   =20
   1.    =
Introduction..................................................3=20
   2.    =
Definitions...................................................4=20
   3.    Symbols and =
Abbreviations.....................................5=20
   4.    Requirements for MPLS =
OAM.....................................5=20
   5.    Principles of OAM =
Function....................................6=20
   5.1   Client/Server =
Recursion-Layering..............................6=20
   5.2   OAM Functionality and Layer =
Independence......................7=20
   5.3   =
Defects.......................................................7=20
   5.4   Availability..................................................7=
=20
   5.5   Decoupling of User behavior from Connectivity =
Assessment......8=20
   5.6   Forward and Backward Defect =
Indicators........................8=20
   5.7   Connectivity =
Verification.....................................9=20
   5.8   Customers Should not be Used as Defect =
Detectors.............10=20
   5.9   The Reliability of OAM Functionality Under Fault =
Conditions..10=20
   6.    Mechanisms of MPLS =
OAM.......................................10=20
   6.1   Special MPLS Label =
Values....................................10=20
   6.2   Handling of Errored OAM =
Packets..............................10=20
   6.3   Label Stack Overhead Encoding Rules for OAM =
Packets..........11=20
   6.3.1 For CV OAM =
Packets...........................................11=20
   6.3.2 For P OAM =
Packets............................................12=20
   6.3.3 For FDI and BDI OAM =
Packets..................................12=20
   6.3.4 MPLS OAM Function Types for the OAM Alert =
Label..............13=20
   6.4   MPLS OAM =
Packets.............................................14=20
   6.4.1 Connectivity Verification (CV) =
Packets.......................15=20
   6.4.2 Performance =93P=94 =
Packets......................................16=20
   6.4.3 Forward defect Indicator =93FDI=94 =
packets.......................16=20
   6.4.4 Backward Defect Indicator =
=93BDI=94..............................17=20
   6.5   Defect Types and their Entry/Exit =
Criteria...................18=20
   6.5.1 Defect Type =
Codepoints.......................................18=20
   6.5.2 dLOCV Entry =
Criteria.........................................20=20
   6.5.3 DTTSI Entry =
Criteria.........................................21=20
   6.5.4 dLoop Entry =
Criteria.........................................21=20
   6.5.5 dLOCV, dTTSI and dLoop exit =
criteria.........................22=20
   6.6   Available and unavailable state =
processing...................23=20
    =20
   Harrison et. al.      Expires August 2001                   Page 2 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   6.6.1 Short Break =
definition.......................................23=20
   6.6.2 Available/Unavailable State =
Definition.......................24=20
   6.6.3 Near-end and Far-end Measurements of =
Availability............24=20
   6.6.4 Near-End State Processing =
Flow-chart.........................25=20
   6.6.5 Far-End State Processing =
Flow-chart..........................27=20
   6.6.6 A pictorial view of near-end and far-end state =
processing....28=20
   7.    Security =
Considerations......................................29=20
   8.    =
References...................................................29=20
   9.    Author's =
Addresses...........................................29=20
   =20
   =20
   Conventions used in this document=20
   =20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in=20
   this document are to be interpreted as described in RFC-2119 [1].=20
   =20
   =20
1. Introduction=20
   =20
   This Internet draft provides requirements and mechanisms for OAM=20
   (Operation and Maintenance) for the user-plane in MPLS networks. It=20
   is recognized that OAM functionality is important in public networks =

   for ease of network operation, for verifying network performance and =

   to reduce operational costs. OAM functionality is especially=20
   important for networks, which are required to deliver (and hence be=20
   measurable against) QoS (Quality of Service) and availability=20
   performance parameters/objectives.=20
   =20
   A connectivity verification "CV" OAM packet is defined in this=20
   document, which is transmitted periodically from LSP source to LSP=20
   sink. The CV flow could be used to detect defects related misrouting =

   of LSPs as well as link and nodal failure, and if required to=20
   trigger protection switching to the protection path. A forward=20
   defect identifier "FDI" and a backward defect identifier "BDI" are=20
   defined, which carry the defect type and location to the near end=20
   and far end respectively. At every LSP terminating node, the FDI is=20
   mapped from server layer to client layer. By doing so FDI could=20
   suppress the alarm storm, and let the appropriate layer take control =

   of protection switching. BDI is used by LSP source to start or stop=20
   the QoS aggregation, depending on whether the LSP is in available or =

   unavailable state. The criteria for entry and exit to the available=20
   and unavailable states are also defined in this document.=20
   =20
   The OAM functionality defined herein is limited to point-point LSP=20
   tunnels. OAM functionality for multipoint-point and point-multipoint =

   LSP tunnels is FFS.=20
   =20
    =20
   Harrison et. al.      Expires August 2001                   Page 3 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
2. Definitions=20
   =20
   This document introduces some new terminology, which is required to=20
   discuss the functional network components associated with OAM.=20
   =20
   =20
       Functional Architecture                    Meaning=20
       Term                        =20
       ------------------                   ------------------=20
       =20
       Client/server               A term referring to the transparent=20
       (relationship between       transport of a client (ie higher)=20
       layer networks)             layer link connection by a server=20
                                   (ie lower) layer network trail.=20
                                   =20
       Link connection             A partition of a layer N trail that=20
                                   exists between two logically=20
                                   adjacent switching points within the =

                                   layer N network.=20
                                   =20
       LSP Tunnel                  An LSP Tunnel is an LSP with well-
                                   defined source (ingress point) and=20
                                   sink (egress point)=20
                                   =20
       Subnetwork                  A subnetwork is a contiguous=20
                                   topological region of a network=20
                                   delimited by its set of peripheral=20
                                   access points, and is characterized=20
                                   by the possible routing across the=20
                                   subnetwork between those access=20
                                   points.  A network is the largest=20
                                   subnetwork and a node is the=20
                                   smallest subnetwork (at least in=20
                                   practical physical terms, though=20
                                   there are smaller sub-networks=20
                                   within nodes).=20
                                   =20
       Trail                       A generic transport entity at layer=20
                                   N which is composed of a client=20
                                   payload (which can be a packet from=20
                                   a client at higher layer N-1) with=20
                                   specific overhead added at layer N=20
                                   to ensure the forwarding integrity=20
                                   of the server transport entity at=20
                                   layer N.=20
                                   =20
       Trail termination point     A source or sink point of a trail at =

                                   layer N, at which the trail overhead =

                                   is added or removed respectively.  A =

                                   trail termination point must have a=20
                                   unique means of identification=20
                                   within the layer network.=20
                                   =20
    =20
   Harrison et. al.      Expires August 2001                   Page 4 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
   =20
3. Symbols and Abbreviations=20
   =20
   This list is not exhaustive of all the abbreviations used in this=20
   draft.  In particular, those in common usage within the MPLS=20
   community (like 'MPLS' itself) have been excluded.=20
   =20
   =20
       Abbreviation               Meaning=20
    ---------------    ----------------------------=20
       AIS             Alarm Indication Signal=20
       =20
       BDI             Backward Defect Indication=20
                       =20
       CV Packet       Connectivity Verification Packet=20
                       =20
       FDI             Forward Defect Indication=20
                       =20
       FFS             For Further Study=20
                       =20
       OAM             Operations and Maintenance=20
                       =20
       P Packets       Performance Packets=20
                       =20
       QoS             Quality of Service=20
                       =20
       SLA             Service Level Agreement=20
                       =20
       TTSI            Trail Termination Source Identifier=20
                       =20
   =20
   =20
4. Requirements for MPLS OAM=20
   =20
   MPLS layer OAM functionality is not a substitute for physical or=20
   server layer OAM (e.g., SDH/SONET) or client layer OAM (e.g., IP).=20
   MPLS LSPs create layer networks in their own right, and will have=20
   defects that are only relevant to the MPLS LSP layer networks.  =20
   =20
   OAM functionality is useful because:=20
   =20
   1)   It allows the Operator to verify whether Quality of Service=20
        guarantees given in SLAs (Service Level Agreements) are in fact =

        being met by the connection.=20
   2)   It allows the Operator to reduce network=92s operating costs, =
by=20
        allowing more efficient detection and handling of defects.=20
        Long-term statistics show that the costs of operating a public=20
        network are higher than the initial installation costs.=20
   3)   It gives support for improved accounting/billing procedures.=20
   4)   It helps provide security for customer traffic by the detection =

        of traffic mis-connections (which may otherwise be=20
        undetectable).=20
   =20
    =20
   Harrison et. al.      Expires August 2001                   Page 5 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   The following functions are required:=20
   =20
   1)   Connectivity Verification of LSPs to confirm that defects do=20
        not exist on the target LSPs.=20
   2)   Fast and efficient defect detection, notification and=20
        localization.=20
   3)   Measurement of availability performance.=20
   =20
   The necessity of additional functions are for further study. In=20
   particular, the need for in-service measurement of LSP QoS=20
   performance (measurement of packet losses, spurious packets, errored =

   packets, delay and delay variation) is for further study. Note that=20
   an LSP needs to be in the available state for QoS assessment to be=20
   valid.=20
   =20
   Defects include following cases:=20
   =20
   1)   Simple loss of LSP connectivity (due to a server layer failure=20
        or a failure within the MPLS layer network);=20
   2)   Swapped LSP trails;=20
   3)   Unintended LSP mismerging (of 2 or more LSP trails);=20
   4)   Unintended replication of LSP packets (of the same LSP trail=20
        for example, due to routing loops).=20
   =20
   =20
5. Principles of OAM Function=20
   =20
   The following principles can, for the most part, be applied to any=20
   layer networks, ie not just MPLS. This recommendation defines=20
   specific embodiments of these principles, as functional OAM=20
   entities, for MPLS layer networks. Although it is recommended that=20
   all the OAM functional entities are deployed network-wide, operators =

   are free to choose if they wish to apply all or only some of these=20
   OAM functional entities (ie CV flows but not P flows), and whether=20
   deployment is network-wide or limited in scope to LSPs of certain=20
   types, e.g. apply only to important LSPs such as those supporting=20
   VPNs. In cases of limited OAM functional entity deployment or scope, =

   then operators should be aware that there could be deficiencies in=20
   their ability to detect/handle certain defect cases.=20
   =20
   =20
5.1 Client/Server Recursion-Layering=20
   =20
   A very important functional architecture feature of layer networks=20
   is client/server recursion (also known as layering). That is, a=20
   client layer link connection (ie a partition of a longer client=20
   layer trail between two logically adjacent client layer nodes) is=20
   created by a server layer trail. This is the basis of client layer=20
   topology construction. This recursion principle extends between=20
   various client/server layer relationships and ultimately 'to the=20
   duct'. Note also that client layer link connections can be multiple=20
   in number, ie a single server layer trail entity can support a=20
   multiple number of client layer link connections.=20
   =20
    =20
   Harrison et. al.      Expires August 2001                   Page 6 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   The key points to note here are:=20
   =20
   (1)  The client and server layer trails termination points will=20
        generally not be congruent.  And since the trail termination=20
        points are associated with the addressable access points of a=20
        layer network, it follows that the addressing of the two layers =

        will also generally not be congruent.=20
   (2)  The 'duct' (or more precisely the environment of physical=20
        occupancy and connectivity) is the lowest layer network. The=20
        degree of connectivity in this layer effectively defines the=20
        degree of independent connectivity in all client layers. This=20
        could be put another way, by saying that the availability=20
        performance of any client layer network design is determined=20
        (and inherited from) the physical infrastructure. This means=20
        that if one cannot state which link connections have a common=20
        lower server layer trail, then one cannot say anything with=20
        certainty about the resilience design of a client layer=20
        network.=20
   =20
   =20
5.2 OAM Functionality and Layer Independence=20
    =20
   The OAM functionality of a layer network must not be dependent on=20
   any specific server or client layer technology. This is critical to=20
   ensure that layer networks can evolve (or new/old layer networks be=20
   added/removed) without impacting other layer networks.=20
   =20
   The control-plane of a given layer network must also have its own=20
   OAM.=20
   =20
   [Note - Control-plane OAM is outside the scope of this draft.]=20
   =20
   =20
5.3 Defects=20
   =20
   All the major defect conditions must be identified with in-service=20
   measurable entry and exit criteria, and all consequent actions must=20
   be specified.  The entry and exit criteria of various defects should =

   be temporally harmonized as far as possible to simplify trail=20
   defect-state processing.  Attention should be paid to relating the=20
   defect entry/exit criteria to =91short-breaks=92, which are =
generally=20
   accepted by many operators as 3-9s periods of gross signal=20
   disturbance from which the network may self-recover. If the event=20
   lasts for >=3D10s this is the normally accepted threshold for =
entering=20
   the unavailable state (also see the next item).=20
   =20
   =20
5.4 Availability=20
   =20
   The most important performance metric of a trail (or a subnetwork=20
   partition thereof) is availability.  This means that the entry and=20
   exit criteria for the available state must be defined. It is also=20
   important to understand how unavailable/available state transitions=20
   relate to the stopping/starting of the aggregation of available=20
    =20
   Harrison et. al.      Expires August 2001                   Page 7 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   state QoS metrics; noting that from pragmatic considerations this=20
   may be effectively applied at an earlier point to preserve the=20
   integrity of the available state metrics, e.g. after 3s say, which=20
   marks the onset of (at least) a short-break, and which from=20
   operational experience is a good practical rule-of-thumb for setting =

   a point beyond which a network is unlikely to self-recover.=20
   =20
   =20
5.5 Decoupling of User behavior from Connectivity Assessment=20
   =20
   User traffic behavior must not be a factor in connectivity status=20
   assessment. In practical terms, this means decoupling user traffic=20
   behavior from all defects and (the dependent) available state=20
   entry/exit criteria.=20
   =20
   =20
5.6 Forward and Backward Defect Indicators=20
   =20
   The node in the layer network, which first detects a defect (sourced =

   from within that layer), should apply a well-known 'Forward Defect=20
   Indication' (FDI) signal in the downstream direction. In the=20
   majority of current transport network technologies such a signal has =

   been termed AIS (Alarm Indication Signal). At the trail termination=20
   point where the appropriate FDI signal is generated:=20
   =20
   (1)  There should be a complimentary Backward Defect Indication=20
        (BDI) signal (which is removed at the upstream trail=20
        termination point) and=20
   (2)  There must be a mapping of the FDI signal from the server layer =

        to the appropriate FDI signal of the client layer(s) as part of =

        the server->client adaptation process.=20
   =20
   The primary purpose of the FDI signal is to suppress client layer=20
   alarms (which would otherwise create an 'alarm storm' in places=20
   which could be geographically and organizationally far removed from=20
   the originating defect source location).=20
   =20
   Three secondary purposes of FDI (and in some cases BDI) are:=20
   =20
   (1)  To allow correct processing of available state performance=20
        metrics.=20
   (2)  To inform applications that the connection is no longer=20
        functioning correctly and to take appropriate action, e.g.=20
        perhaps invoke a 're-connect' action, or in the case of voice=20
        perhaps mute the speech path.=20
   (3)  To inform client layer trails (e.g. nested LSPs in the case of=20
        MPLS) that a defect has occurred in a lower server layer trail, =

        and hence to provide some indication that protection-switching=20
        in the affected client layer trails could be postponed to give=20
        the server layer trail an opportunity to effect protection=20
        switching.=20
   =20
   FDI/BDI signals should also provide information on the defect=20
   location and type. Such information is very useful to the lead=20
    =20
   Harrison et. al.      Expires August 2001                   Page 8 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   operator in a co-operating domain scenario, and can also=20
   differentiate failures, which are internal or external to public and =

   private domains.=20
   =20
   Note that, if being used, the BDI signal must be generated (in the=20
   backward direction) in response to detecting a defect at a trail=20
   sink termination point (in the forward direction) and not from some=20
   intermediate point, such as where the defect might be actually=20
   located. The reasons for this are that:=20
   =20
   (1)  In the case of bi-directional trails and unidirectional=20
        defects, each trail direction might not be congruently routed.=20
   (2)  In the case of unidirectional trails the BDI signal may be=20
        provided out-of-band, e.g. perhaps via a control-plane or=20
        management-plane mechanism. [Note: The exact means for=20
        providing the BDI functionality in this is FFS]=20
   =20
   The above requirements mean that the FDI/BDI architecture is valid=20
   for all routing cases.=20
   =20
   =20
5.7 Connectivity Verification=20
   =20
   An essential characteristic of the trails in a layer network is that =

   their trail termination points must have a unique identifier (at=20
   least within that layer network). However, on link connections=20
   between nodes within the layer network, relative identifiers are=20
   commonly used for traffic forwarding. These relative identifiers=20
   only have to be unique per interface, e.g. the VPI/VCI of ATM, the=20
   DLCI of FR, the =91label=92 of MPLS.=20
   =20
   When relative identifiers are used for traffic forwarding there is a =

   possibility of trail misconnectivity due to defects.  These cover a=20
   variety of connectivity failure modes, including:=20
   =20
   1)   Simple loss of continuity (due to a server layer failure or a=20
        failure within the layer network considered);=20
   2)   Swapped connections;=20
   3)   Unintended mismerging (of 2 or more trails);=20
   4)   Unintended replication (of the same trail due, for example, to=20
        routing loops).=20
   =20
   Although some of these defects may be rare in practice, unless=20
   detected/corrected their consequences can be very severe for an=20
   operator; ranging from simple availability/QoS SLA violations=20
   through to more serious security, censorship and mis-billing=20
   implications.=20
   =20
   It is therefore required that a unique trail source identifier be=20
   periodically transmitted from the trail source to the trail sink to=20
   detect these types of defect.=20
   =20
   =20
    =20
   Harrison et. al.      Expires August 2001                   Page 9 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
5.8 Customers Should not be Used as Defect Detectors=20
   =20
   The OAM tools provided should ensure (as far as reasonably=20
   practicable) that customers should not have to act as failure=20
   detectors for the operator.=20
   =20
   =20
5.9 The Reliability of OAM Functionality Under Fault Conditions=20
   =20
   Under fault conditions a layer network cannot, by definition, be=20
   expected to behave in a predictable manner. Therefore care should be =

   exercised when specifying and using OAM functions that require a=20
   layer network to function in a reliable and predictable manner for=20
   fault diagnosis.=20
   =20
   =20
6. Mechanisms of MPLS OAM=20
   =20
   =20
6.1 Special MPLS Label Values=20
   =20
   The label structure defined in [1] indicates a single label field of =

   20 bits.  Label field values 0-3 have already been reserved for=20
   special functions. A special label, the 'OAM Alert Label', is=20
   defined as follows:=20
   =20
                        Table 1: OAM Alert Label=20
   =20
        Label value                          =20
         (Decimal)                        Meaning=20
        ------------              -----------------------=20
             4           OAM Alert Label.  This indicates that the=20
                         first octet following the OAM Alert Label=20
    [Note: this value is in the OAM payload (ie octet 5) is an OAM=20
    yet to be officially Function Type field whose value defines=20
    assigned by IANA]    the type of defect handling OAM function=20
                         (ie CV, P, FDI or BDI), which follows in=20
                         the payload area.=20
   =20
   =20
   All OAM packets must have a minimum payload length of 40 octets to=20
   facilitate ease of processing.  This is achieved by padding with all =

   0s when necessary. All padding bits are reserved for future operator =

   defined usage.  =20
   =20
   =20
6.2 Handling of Errored OAM Packets=20
   =20
   Each OAM packet uses a BIP16 (in the last two octets of the OAM=20
   payload area) to detect errors.  The BIP16 is computed over all the=20
   fields of the OAM payload, including the initial octet, which=20
    =20
   Harrison et. al.      Expires August 2001                  Page 10 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   specifies the Function Type and the BIP16 bit positions (which are=20
   all pre-set to zero for initial calculation purposes).=20
   =20
   BIP16 processing must be performed on all OAM packets prior to being =

   able to reliably pass their payload for further processing.  Any OAM =

   packets that show a BIP16 violation upon reception processing should =

   be discarded.=20
   =20
   In the case of the CV packet flow, persistent BIP16 violations will=20
   cause a Loss of Connectivity Verification; this defect is defined=20
   later, but for now we can note that it would occur after nominally=20
   3s.  This behavior is consistent with the nature of the defect.  =20
   However, it is recommended that at a local equipment level some=20
   notification is given to the Network Management System to indicate=20
   that BIP16 discards are occurring.=20
   =20
   In the case of the other OAM packet types, ie the FDI, BDI and P=20
   packets (these are defined later), it is again recommended that at a =

   local equipment level some indication is given to the Network=20
   Management System that BIP16 discards are occurring.  The threshold=20
   to be used for recording/reporting such BIP16 discard activity for=20
   these OAM packets should be programmable, and is outside the scope=20
   of this Recommendation.=20
   =20
   =20
6.3 Label Stack Overhead Encoding Rules for OAM Packets=20
   =20
   =20
6.3.1   For CV OAM Packets=20
   =20
   CV OAM packets are differentiated from normal user-plane traffic by=20
   an increase of one in the label stack depth at a given LSP level at=20
   which they are inserted. Therefore, they maintain this label stack=20
   difference of one (from normal user-plane traffic) as they traverse=20
   any lower layer server LSPs.=20
   =20
   The OAM Alert Labeled header is added before (ie below) the normal=20
   user-plane forwarding labeled header at the LSP trail source point.  =

   The S bit is set only in the OAM Alert Label.=20
   =20
   The CV OAM packet can be used on both E-LSPs and L-LSPs. However,=20
   the coding of the EXP field is different in the two cases.=20
   In the case of L-LSPs, the coding of the EXP field should be set to=20
   all 0s in both the OAM Alert Labeled header and the preceding normal =

   user-plane forwarding header.  This is to ensure the CV OAM packets=20
   have a Per Hop Behavior (PHB), which ensures the lowest drop=20
   probability [2].=20
   =20
   In the case of E-LSPs, the coding of the EXP field should be set to=20
   all 0s in the OAM Alert Labeled header and to whatever is the=20
   'minimum loss-probability PHB' in the preceding normal user-plane=20
   forwarding header for that E-LSP.  This is again to ensure the CV=20
   OAM packets have a PHB, which ensures the lowest drop probability=20
   [2].=20
    =20
   Harrison et. al.      Expires August 2001                  Page 11 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
   The TTL field should be set to 1 in the OAM Alert Labeled header. =20
   The reasons for this are:=20
   =20
   =B7    CV OAM packets should never travel beyond the LSP trail=20
        termination sink point at the LSP level they were originally=20
        generated (noting that they are not examined by intermediate=20
        label-swapping LSRs, and are only observed at LSP sink points), =

        and=20
   =B7    The TTL of the immediately prior normal user-plane forwarding =

        header is used to mitigate against damage from looping packets. =

   =20
   =20
6.3.2   For P OAM Packets=20
   =20
   The label stack overhead encoding rules of performance P OAM packets =

   are FFS.=20
   =20
   =20
6.3.3   For FDI and BDI OAM Packets=20
   =20
   FDI and BDI OAM packets are invoked, on a nominal 1 per second=20
   basis, when defects are detected. The FDI packet traces forward and=20
   upward through any nested LSP stack. The BDI packet is sent=20
   backwards towards its peer-level LSP trail termination sink point in =

   the reverse direction (assuming a bi-directional in-band LSP exists) =

   for each LSP at and above the level of the defect.=20
   =20
   The OAM Alert labeled header is inserted before (ie below) a normal=20
   user-plane forwarding labeled header, and a label stack of 2 is only =

   ever required for either the FDI or BDI packet at their origin. =20
   Note that in the case of FDI, it is assumed that the server->client=20
   LSP adaptation mappings that were in existence prior to the failure=20
   are recursively used to ensure correct FDI forwarding.  It is=20
   therefore important that the LSP sink point remembers any server-
   >client LSP labels mappings that were in existence prior to the=20
   failure.  Although the exact means for achieving this are outside=20
   the scope of this Recommendation, some examples of how these server-
   > client layer label mappings could be configured are as follows:=20
   =20
   =B7    Manually, via the NMS say;=20
   =B7    Automatically on LSP set-up via extensions to LDP/RSVP=20
        signaling;=20
   =B7    By an automatic 'learning process', i.e. if, during the=20
        establishment of the client LSPs, the signaling is tunneled=20
        trough the server layer, then the server trail terminating node =

        could keep the information about the established LSPs in memory =

        as they occur.=20
   =20
   When server->client layer LSP relationships are changed (e.g.=20
   existing client layer LSP removed, or new client LSP added say),=20
   then it is important that the server->client label mappings are also =

   updated to reflect the new relationships.=20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 12 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   The S bit is set only in the OAM Alert Labeled header. The FDI OAM=20
   packet is recursively mapped upwards, through a client/server=20
   adaptation process at LSP trail termination sink points, into any=20
   further affected higher client layer LSPs.  When this arrives at the =

   top LSP it needs to be mapped into an equivalent FDI for whatever=20
   client layer is then being carried.  In the case of IP (or indeed=20
   any other client layer), this is outside the scope of this document. =

   =20
   Note that higher level LSPs will also see failures (as a result of=20
   corruption of their own CV flow) but they will also see an incoming=20
   FDI OAM packet flow from the lowest level LSP where the failure=20
   originates.  This dynamic behavior allows for correct identification =

   of the true source of the defect and is explained in more detail=20
   later.  But for now it is sufficient to note that the incoming FDI=20
   is needed to:=20
   =20
   =B7    Suppress unnecessary alarms in the affected higher layer =
LSPs.=20
   =B7    Give an indication to affected higher-level LSPs that they =
may=20
        need to hold-off protection switching as the defect is at a=20
        lower level LSP.=20
   =B7    To allow the appropriate BDI coding at the affected higher=20
        layer.=20
   =20
   It is assumed that when a BDI OAM packet is returned in-band it=20
   follows a bi-directional LSP and, like the CV and P OAM packets,=20
   that it should never travel beyond the LSP trail termination sink=20
   point (of the return LSP).=20
   =20
   The coding of the EXP field associated with the OAM Alert Labeled=20
   header and the preceding normal user-plane forwarding labeled header =

   at the LSP level at which the FDI or BDI is inserted is the same as=20
   that previously described for the CV OAM packet.=20
   =20
   The TTL field should be set to 1 in the OAM Alert Labeled packet=20
   header. The reasons for this are:=20
   =20
   =B7    The FDI OAM packet is recursively regenerated at each LSP =
trail=20
        termination sink point into all affected client layer LSPs (if=20
        any); so the TTL field is recursively regenerated with a value=20
        of 1;=20
   =B7    The BDI OAM packet should never travel beyond the LSP trail=20
        termination sink point of the return LSP at the LSP level that=20
        it was originally generated;=20
   =B7    The TTL of the immediately prior normal user-plane forwarding =

        header is used to mitigate against damage from looping packets. =

   =20
   =20
6.3.4   MPLS OAM Function Types for the OAM Alert Label=20
   =20
   The first octet of the OAM packet payload specifies the OAM Function =

   Type as follows:=20
   =20
                        Table 2: OAM Function Types=20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 13 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
       OAM Function Type    First octet of OAM packet payload=20
       codepoint (Hex)      Function Type Purpose=20
       -----------------    ----------------------------------=20
              00            Reserved=20
                            =20
              01            CV (Connectivity Verification).  Used=20
                            to detect/diagnose all types of LSP=20
                            connectivity defect (sourced either=20
                            from below or within the MPLS=20
                            network).  This will be the main in-
                            service OAM defect detection tool.=20
                            =20
              02            P (Performance).  Used to measure=20
                            user-plane loss of packets and their=20
                            aggregate octets.=20
                            =20
              03            FDI (Forward Defect Indicator).  This=20
                            is generated by an MPLS node detecting=20
                            any defect (defined later) and=20
                            inserted into affected client layers. =20
                            Its primary purpose is to suppress=20
                            alarms being raised within affected=20
                            higher level client LSPs and (in turn)=20
                            their client layers.  It includes=20
                            fields to indicate the nature of the=20
                            defect and its location.=20
                            =20
              04            BDI (Backward Defect Indicator).  This=20
                            is generated at a return LSP trail=20
                            termination source point in response=20
                            to a defect being detected at a LSP=20
                            trail termination sink point in the=20
                            other direction.  The defect type and=20
                            location codepoints of the=20
                            complimentary FDI are mapped into=20
                            similar fields of the BDI.  The BDI=20
                            may be realized either in the user-
                            plane if bi-directional LSPs are being=20
                            used (the case considered in this=20
                            document) or out-of-band (e.g. via=20
                            management-plane function) in the case=20
                            of uni-directional LSPs.  The latter=20
                            scenario is outside the scope of this=20
                            document.=20
                            =20
   =20
   All other OAM Function Type codepoints are reserved for possible=20
   future standardization.=20
   =20
   =20
6.4 MPLS OAM Packets=20
   =20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 14 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
6.4.1   Connectivity Verification (CV) Packets=20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   | Func Type (1) |                 (must be 0)                   |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                                                               |=20
   +                                                               +=20
   |                       Ingress Router ID                       |=20
   +                                                               +=20
   |                                                               |=20
   +                                                               +=20
   |                                                               |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                           LSP ID                              |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                                                               |=20
   \\                   Reserved (0) 14 bytes                     \\=20
   |                                                               |=20
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                               |         BIP 16                |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
                    Figure 1: CV Payload Structure=20
   =20
   The intention is that the CV OAM packet is transmitted from the LSP=20
   trail termination source point at a nominal rate of 1 CV per second. =
=20
   It is important that the rate of CV OAM packet generation is=20
   constant so that simple and deterministic defect processing can be=20
   carried out at the LSP trail termination sink point.=20
   =20
   CV OAM packets within a given LSP are not synchronous to any other=20
   CV OAM packets in any other LSP (this includes all nested LSPs, and=20
   CV OAM packets from the remote end of an LSP at level N but in the=20
   other direction when bi-directional LSPs at level N are being used). =

   =20
   The structure of the LSP Trail Termination Source Identifier (TTSI)=20
   is defined by using a 16 octet Router ID IPv6 address plus a 4 octet =

   LSP Tunnel ID [3].  Note that the first 2 octets of the LSP Tunnel=20
   ID are currently padded with all 0s to allow for any future increase =

   in the Tunnel ID field.=20
   =20
   For nodes that do not support IPv6 addressing, an IPv4 address can=20
   be used for the Router ID using the format described in RFC1884 [4]. =
 =20
    =20
   Harrison et. al.      Expires August 2001                  Page 15 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   That is:=20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                                                               |=20
   +                                                               +=20
   |                            (0)                                |=20
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                               |               (FF)            |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                       IPv4 Address                            |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
                   Figure 2: IPV6 Compatible IPV4 Address=20
   =20
   On LSP establishment the LSP trail termination sink point should be=20
   configured with the expected TTSI (Ingress router ID + LSP ID). =20
   Ideally this should be done automatically via LSP signaling at LSP=20
   set-up time (e.g. via a CR-LDP or RSVP control-plane mechanism), but =

   it could also be configured manually.  The mechanism for achieving=20
   this configuration is outside the scope of this Recommendation.=20
   =20
   =20
6.4.2   Performance =93P=94 Packets=20
   =20
   The structure of the P OAM packet is FFS.=20
   =20
   =20
6.4.3   Forward defect Indicator =93FDI=94 packets=20
   =20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   | Func Type (3) | (must be 0)   |        Defect Type            |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                      Defect Location                          |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                                                               |=20
   \\                 Reserved (0) 30 bytes                       \\=20
   |                                                               |=20
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                               |         BIP 16                |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
                        Figure 3: FDI Payload Structure=20
   =20
   The FDI is sent downstream from the first node detecting the defect. =
=20
   In the case of MPLS server layer failures (i.e. in a lower layer=20
   technology such as SDH) this would be the first MPLS node downstream =

   of the server layer failure (as a consequence of the appropriate=20
   client/server adaptation of the server FDI signal). In the case of=20
   MPLS layer failures (i.e. failures within the MPLS fabric) this=20
    =20
   Harrison et. al.      Expires August 2001                  Page 16 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   would be the first LSP trail termination sink point at the same LSP=20
   level as the failure.=20
   =20
   The primary function of the FDI is to stop downstream client layer=20
   alarm storms and hence correctly focus the attention of Operational=20
   personnel.  However, FDI can also have an important role in:=20
   =20
   =B7    Facilitating correctly targeted nested LSP protection =
schemes,=20
        i.e. one would want a lower level (server) LSP to protection=20
        switch before a higher level (client) LSP if the fault was=20
        sourced from within the lower level LSP, and=20
   =20
   =B7    Identifying availability/short-break events and hence suspend =

        up-state QoS metric aggregation.=20
   =20
   The format of the Defect Location field and its handing at inter=20
   domain NNI boundaries is FFS.=20
   =20
   The Defect Type field is set at 2 octets here. This is currently=20
   considered sufficient, but it should be confirmed once all the=20
   Defects Types have been identified and fully specified. A candidate=20
   set of Defect Types and their codepoints are given later.=20
   =20
   The handling of the Defect Type field at inter domain NNI boundaries =

   is FFS. However, 2 octets have been reserved for this function.=20
   =20
   When a FDI is to be passed from a server layer LSP to its client=20
   layer LSP(s) (ie at the client/server adaptation function following=20
   the server layer LSP trail termination sink point), the Defect=20
   Location and Defect Type field should be copied from the server=20
   layer LSP FDI into the client layer LSP(s) FDI.=20
   =20
   The mapping of MPLS layer sourced FDI from the highest-level LSP=20
   into its client layer (e.g. IP) is outside the scope of this=20
   document.=20
   =20
   =20
6.4.4   Backward Defect Indicator =93BDI=94=20
   =20
    0                   1                   2                   3=20
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   | Func Type (4) |   (must be 0) |        Defect Type            |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                      Defect Location                          |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                                                               |=20
   \\                  Reserved(0) 30 bytes                       \\=20
   |                                                               |=20
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   |                               |         BIP 16                |=20
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
 
                        Figure 4: BDI Payload Structure=20
    =20
   Harrison et. al.      Expires August 2001                  Page 17 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
   For the case of bi-directional LSPs, the BDI is sent from the LSP=20
   trail source point of the return LSP as a mirror of the appropriate=20
   (see Note) FDI at the LSP trail sink point of the other direction.   =

   =20
   The Defect Location and Defect Type fields are a direct mapping of=20
   those sets in the appropriate (see Note) FDI and have identical=20
   formats as described previously for the FDI OAM packet.=20
   =20
   Note - The word 'appropriate' here signifies that any incoming FDI=20
   (i.e. from a lower layer) takes precedence over any FDI that would=20
   have been generated at the layer being considered due to detecting=20
   defects at this layer (where these defects are only consequential as =

   a result of a lower layer defect).=20
   =20
   The BDI does not propagate beyond its return LSP trail termination=20
   sink point, and it is discarded at that point after any processing=20
   based its observation is carried out, e.g. for single-ended short-
   break and/or availability measurements.=20
   =20
   =20
6.5 Defect Types and their Entry/Exit Criteria=20
   =20
6.5.1   Defect Type Codepoints=20
   =20
   The following coding structure is proposed for the various defect=20
   types so far identified:=20
   =20
                        Table 3: Defect Types=20
   =20
              DT code in FDI/BDI              =20
              OAM packets (Hex)    =20
              Note: first octet    =20
              indicates layer and  =20
    Defect    second octet         =20
     Type     indicates defect                Meaning=20
    -------   --------------------    ------------------------=20
    dServer          01 01         Any server layer defect=20
                                   arising below the MPLS layer=20
                                   network.  It is not suggested=20
                                   that these are individually=20
                                   identified and defined for=20
                                   each type of server layer,=20
                                   since this function is only=20
                                   appropriate to the server=20
                                   layer itself.  Hence, we only=20
                                   need an indication that it is=20
                                   the server layer and not the=20
                                   MPLS layer.=20
                                      =20
    dLOCV            02 01         Simple Loss of Connectivity=20
                                   Verification due to missing=20
                                   CV OAM packets with expected=20
                                   TTSI.  Note that if the cause=20
    =20
   Harrison et. al.      Expires August 2001                  Page 18 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
                                   of dLOCV is the server layer=20
                                   (ie there is also an incoming=20
                                   FDI signal from the server=20
                                   layer) then the DT codepoint=20
                                   01 01_H is used.  The dLOCV=20
                                   codepoint 02 01_H is only=20
                                   used for MPLS layer simple=20
                                   connectivity failures only.=20
                                   =20
    dTTSI            02 02         Trail Termination Source=20
                                   Identifier Mismatch due to an=20
                                   unexpected TTSI observed in=20
                                   the incoming CV OAM packets. =20
                                   This detects swapped=20
                                   connections and unintended=20
                                   mismerging failures, which=20
                                   can be differentiated by=20
                                   noting whether an expected=20
                                   TTSI is also missing or=20
                                   present respectively.  Note=20
                                   that in the case of the=20
                                   former (ie swapped=20
                                   connections), the dTTSI=20
                                   defect condition takes=20
                                   priority over the dLOCV=20
                                   defect condition, which is=20
                                   also present.=20
                                   =20
    dLoop            02 03         This detects an unintended=20
                                   replication Looping defect=20
                                   from observation of an=20
                                   increased rate of expected CV=20
                                   OAM packets above the nominal=20
                                   1/sec. (Note this defect is=20
                                   added for completeness, but=20
                                   it is expected to be rare)=20
                                   =20
    dUnknown         02 FF         Unknown defect detected in=20
                                   the MPLS layer.  This is=20
                                   expected to be used for MPLS=20
                                   nodal failures, which are=20
                                   detected within the node=20
                                   (probably by proprietary=20
                                   means) and affect user-plane=20
                                   traffic.=20
                                      =20
    None             00 00         Reserved=20
                                   =20
    None             FF FF         Reserved=20
   =20
   =20
   There are 3 MPLS layer user-plane defects, ie dLOCV, dTTSI and=20
   dLoop, which we now define in more detail.=20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 19 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
6.5.2   dLOCV Entry Criteria=20
   =20
   Entry to the dLOCV condition, and hence entry to the LSP Trail Sink=20
   Near-End Defect State, occurs when there are no expected CV OAM=20
   packets observed in any period of 3 consecutive seconds.=20
   =20
   In terms of consequent actions:=20
   =20
   =B7    If there is an incoming FDI signal from a server layer below=20
        the MPLS network, then this is mapped to the DT codepoint 01=20
        01_H in the FDI OAM packets sent forwards and the BDI OAM=20
        packets sent backwards.  The local DL codepoint is also=20
        inserted in these FDI and BDI OAM packets. There are no alarms=20
        associated with the MPLS layer itself but only the server=20
        layer, which sourced the FDI signal.=20
   =20
   Else:=20
   =20
   =B7    If there is an incoming FDI signal from a lower level LSP=20
        within the MPLS network, then that FDI signal's DL/DT=20
        codepoints are mapped into the FDI sent to any further client=20
        layers (i.e. suppresses generation of FDI DL/DT codepoints from =

        this point) and the BDI OAM packet sent backwards.  There are=20
        no alarms generated regarding this LSP (the alarm will be=20
        associated with the lowest layer LSP within which the defect=20
        originated).=20
   =20
   Else:=20
   =20
   =B7    If there is no FDI signal incoming from the server layer or a =

        lower level LSP AND there are no CV OAM packets observed with=20
        an unexpected TTSI which give rise to the dTTSI defect, then=20
        the DT codepoint 02 01_H is inserted in the FDI OAM packets=20
        sent downstream and the BDI OAM packets sent upstream.  The=20
        local DL codepoint is also inserted in these FDI and BDI OAM=20
        packets. A local alarm is raised relevant to this defect=20
        condition.=20
   =20
   Note:=20
   =20
        (i)    Since OAM packet flows are not synchronized in LSPs at=20
               different hierarchical levels (ie when LSPs are nested), =

               there is a possibility that a client layer LSP detects a =

               defect before its server layer LSP. This error could be=20
               up to 1s due to CV packet arrival time differences plus=20
               some additional uncertainty due to network delay=20
               effects. This could result in an error of judgment as to =

               the type of defect that is present and hence which=20
               consequent actions are appropriate; especially whether=20
               the raising of a local alarm is appropriate and the=20
               correct setting of the DL and DT codepoints in FDI/BDI=20
               OAM packets.  To mitigate this effect, it is recommended =

               that the raising of an alarm is deferred for at least 2=20
    =20
   Harrison et. al.      Expires August 2001                  Page 20 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
               seconds after a defect state is detected (the exact=20
               value is FFS). This will also allow the network to=20
               settle into a stable state as regards defect detection=20
               behavior.=20
        =20
        (ii)   The starting/stopping of aggregation of any LSP user-
               plane packet/octet loss metrics (e.g. if using the P OAM =

               packet say) is dependent on whether the LSP is in the=20
               available or unavailable state.=20
   =20
   =20
6.5.3   DTTSI Entry Criteria=20
   =20
   Entry to the dTTSI condition, and hence entry to the LSP Trail Sink=20
   Near-End Defect State, occurs when there are >=3D 2 CV OAM packets=20
   observed in any period of 3 consecutive seconds each with an=20
   unexpected TTSI. Any expected CV OAM packets or any incoming FDI=20
   signals (from either the server layer or a lower level LSP) are=20
   ignored, and it should be noted that the dTTSI defect overrides the=20
   dLOCV defect if both are present (as would be the case, for example, =

   with swapped LSPs). The DT codepoint 02 02_H is inserted in the FDI=20
   OAM packets sent forwards and the BDI OAM packets sent backwards. =20
   The local DL codepoint is also inserted in these FDI and BDI OAM=20
   packets. A local alarm is raised relevant to this defect condition=20
   and the unexpected TTSI captured locally (this may also be=20
   optionally sent to the NMS as an exception report say). The=20
   downstream traffic must also be suppressed.=20
   =20
   Note:=20
   =20
   (i)  Since OAM packet flows are not synchronized in LSPs at=20
        different hierarchical levels (ie when LSPs are nested), there=20
        is a possibility that a client layer LSP detects a defect=20
        before its server layer LSP.  This error could be up to 1s due=20
        to CV packet arrival time differences plus some additional=20
        uncertainty due to network delay effects. This could result in=20
        an error of judgment as to the type of defect that is present=20
        and hence which consequent actions are appropriate; especially=20
        whether the raising of a local alarm is appropriate and the=20
        correct setting of the DL and DT codepoints in FDI/BDI OAM=20
        packets.  To mitigate this effect, it is recommended that the=20
        raising of an alarm is deferred for at least 2 seconds after a=20
        defect state is detected (the exact value is FFS).  This will=20
        also allow the network to settle into a stable state as regards =

        defect detection behavior.=20
   =20
   (ii) The starting/stopping of aggregation of any LSP user-plane=20
        packet/octet loss metrics (e.g. if using the P OAM packet say)=20
        is dependent on whether the LSP is in the available or=20
        unavailable state.=20
   =20
   =20
6.5.4   dLoop Entry Criteria=20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 21 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   Entry to the dLoop condition, and hence entry to the LSP Trail Sink=20
   Near-End Defect State, occurs when there are >=3D 5 CV OAM packets=20
   observed in any period of 3 consecutive seconds each with an=20
   expected TTSI.  The DT codepoint 02 03_H is inserted in the FDI OAM=20
   packets sent forwards and the BDI OAM packets sent backwards.  The=20
   local DL codepoint is also inserted in these FDI and BDI OAM=20
   packets. A local alarm is raised relevant to this defect condition.=20
   =20
   Note:=20
   =20
   (i)  Since OAM packet flows are not synchronized in LSPs at=20
        different hierarchical levels (ie when LSPs are nested), there=20
        is a possibility that a client layer LSP detects a defect=20
        before its server layer LSP. This error could be up to 1s due=20
        to CV packet arrival time differences plus some additional=20
        uncertainty due to network delay effects. This could result in=20
        an error of judgment as to the type of defect that is present=20
        and hence which consequent actions are appropriate; especially=20
        whether the raising of a local alarm is appropriate and the=20
        correct setting of the DL and DT codepoints in FDI/BDI OAM=20
        packets.  To mitigate this effect, it is recommended that the=20
        raising of an alarm is deferred for at least 2 seconds after a=20
        defect state is detected (the exact value is FFS). This will=20
        also allow the network to settle into a stable state as regards =

        defect detection behavior.=20
   =20
   (ii) The starting/stopping of aggregation of any LSP user-plane=20
        packet/octet loss metrics (e.g. if using the P OAM packet say)=20
        is dependent on whether the LSP is in the available or=20
        unavailable state.=20
   =20
   =20
6.5.5   dLOCV, dTTSI and dLoop exit criteria=20
   =20
   Exit of the dLOCV, dTTSI or dLoop condition, and hence exit of the=20
   LSP Trail Sink Near-End Defect State, occurs when there are:=20
   =20
   =B7    >=3D 2 but <=3D 4 CV OAM packets observed each with an =
expected=20
        TTSI, AND=20
   =B7    No CV OAM packets observed with an unexpected TTSI in any=20
        period of 3 consecutive seconds.=20
   =20
   Note that the numbers of CV OAM packets observed each with an=20
   expected TTSI are a suggested number. It must be further studied if=20
   these numbers are appropriate.=20
   =20
   All the consequent actions invoked when entering the LSP Trail Sink=20
   Near-End Defect State (i.e. sending of FDI and BDI OAM packets, the=20
   raising of local alarms and the suppression of traffic in the dTTSI=20
   case only) are stopped when we exit the LSP Trail Sink Near-End=20
   Defect State.=20
   =20
   Note =96 The starting/stopping of aggregation of any LSP user-plane=20
   packet/octet loss metrics (e.g. if using the P OAM packet say) is=20
    =20
   Harrison et. al.      Expires August 2001                  Page 22 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   dependent on whether the LSP is in the available or unavailable=20
   state.=20
   =20
   =20
6.6 Available and unavailable state processing=20
   =20
   The main purpose of defining harmonized defect entry/exit criteria=20
   as noted above is in order to significantly simplify:=20
   =20
   =B7    Near-end/far-end LSP Trail Sink Defect State processing;=20
   =B7    Near-end/far-end LSP Available State processing (which will=20
        shortly be discussed);=20
   =B7    The decision point at which any LSP user-plane traffic QoS=20
        metrics (if being collected) are stopped/started with respect=20
        to aggregation into long-term registers.=20
   =20
   In all sections where the evaluation of events is described, the=20
   measurement technique is based on a sliding-window with a 1 second=20
   granularity of advance.  Note that the datum for the commencement of =

   the sliding window is an arbitrary point in time decided by the each =

   node independently and is not synchronized to OAM packet arrival=20
   events on any LSPs.  This is deemed acceptable to allow simpler=20
   nodal processing.=20
   =20
   It should be noted that this Recommendation uses the traditional=20
   functional dependency relationship between QoS and availability. =20
   That is:=20
   =20
   =B7    QoS is a unidirectional metric, ie if QoS metrics are being=20
        measured then each direction is measured independently.=20
   =B7    Availability is a bi-directional metric in the case of bi-
        directional LSPs, in the sense that if any direction enters the =

        unavailable state (defined later) then both directions are=20
        deemed to be unavailable.  In the case of unidirectional LSPs,=20
        then availability can only have unidirectional significance.=20
   =B7    QoS measurements must be suspended (as regards aggregation =
into=20
        long-term available state registers) if an LSP enters the=20
        unavailable state; noting that this means the QoS measurements=20
        of both directions from the definition of the availability=20
        metric above in the case of bi-directional LSPs.=20
   =20
   However, it should also be noted that (for both pragmatic reasons=20
   and to preserve their statistical significance) QoS metric=20
   aggregation is actually suspended after detecting a short-break=20
   event.=20
   =20
   =20
6.6.1   Short Break definition=20
   =20
   We first define a short-break event.  This is defined as a period=20
   where the entry and exit to any of the previously defined defect=20
   conditions both occur within 9s, ie the LSP Trail Sink Near-End=20
   Defect State lasts for <=3D 9s.  The start of the short-break occurs =

   at the beginning of the defect entry criteria and the end of the=20
    =20
   Harrison et. al.      Expires August 2001                  Page 23 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   short-break occurs at the beginning of the defect exit criteria. =20
   Clearly this has a minimum period of 3s.  Short-breaks are only=20
   defined to exist when the LSP is in the Available State.=20
   =20
   Note =96 Short-breaks are more common than many people realize (in =
one=20
   operator's network a study of SES (Severely Errored Second) events=20
   showed that about 50% of these would have been classified as short-
   breaks).  They can cause severe disruption to some applications and=20
   are therefore an important performance metric (perhaps second in=20
   importance after availability).  Since they exist at the physical=20
   layers they will exist (by inheritance) in client layers, such as=20
   MPLS and IP.  An important property of the short-break, which we=20
   will exploit, is that it yields a pragmatic harmonized threshold for =

   defect evaluation (across all defect types as noted previously) and=20
   the stopping/starting of QoS metric aggregation into long-term up-
   state performance registers.=20
   =20
   =20
6.6.2   Available/Unavailable State Definition=20
   =20
   If the LSP Trail Sink Near-End Defect State exceeds 10 consecutive=20
   seconds in duration then the LSP enters the Unavailable State. The=20
   start point of the Unavailable State is deemed to be at the=20
   beginning of these 10 consecutive seconds. We therefore no longer=20
   have a short-break (and the event should not be registered as such). =

   =20
   A LSP re-enters the Available State after first exiting the LSP=20
   Trail Sink Near-End Defect State and there has been an aggregate=20
   period of 10 consecutive seconds in which there have been:=20
   =20
   =B7    >=3D9 and <=3D 11 CV OAM packets each with an expected TTSI, =
AND=20
   =B7    No CV OAM packets with an unexpected TTSI.=20
   =20
   Note that the numbers of CV OAM packets observed each with an=20
   expected TTSI are suggested numbers.  It must be further studied if=20
   these numbers are appropriate.=20
   =20
   The start point of the Available State is deemed to be at the=20
   beginning of these 10 consecutive seconds.=20
   =20
    
6.6.3   Near-end and Far-end Measurements of Availability=20
   =20
   All of the above discussion is strictly only relevant to the near-
   end processing when the LSP trail termination sink point is in the=20
   LSP Trail Sink Near-End Defect State as discussed previously.  We=20
   can also measure the far-end availability behavior (useful when only =

   a single end is accessible for measurement) by using the BDI signal=20
   (when bi-directional LSPs are being used) since this is a reflected=20
   upstream mirror of the duration over which FDI is sent downstream.=20
   =20
   We therefore define the LSP Trail Sink Far-End Defect State to be=20
   the period over which BDI OAM packets are observed subject to the=20
   following entry and exit criteria:=20
    =20
   Harrison et. al.      Expires August 2001                  Page 24 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
   =20
   =B7    Entry of the LSP Trail Sink Far-End Defect State occurs on =
the=20
        first BDI OAM packet observed.=20
   =B7    Exit of the LSP Trail Sink Far-End Defect State occurs after =
a=20
        period of 3 consecutive seconds in which no BDI OAM packets=20
        have been received.=20
   =20
   Note that this 3s processing delay on exit is to cater for cases in=20
   which perhaps a single BDI is lost (say due to congestion or=20
   errors).  Its effect must be catered for in the far-end processing=20
   state machine as discussed later.=20
   =20
   Since we have fixed the temporal duration of the far-end state to be =

   directly related to the near-end state (albeit with a +3s exit=20
   checking period) we can therefore measure both short-breaks and=20
   unavailability of both directions from a single end (on the=20
   assumption that bi-directional LSPs are being used).=20
   =20
   =20
6.6.4   Near-End State Processing Flow-chart=20
   =20
   The following figure summarizes many of the key points regarding the =

   near-end state-processing algorithm for a given LSP.=20
   =20
                Figure 5: LSP Near-End State Processing Flow Chart=20
   =20
   1.   Assume we start in the available state in the box marked=20
        =91Start=92.  All timers (shown later) can conceptually be =
assumed=20
        reset at this point.  If there are any QoS metrics being=20
        collected (e.g. packet/octet loss measurements from the P OAM=20
        packet) then this is assumed to be active at this time.=20
   2.   The first decision box is =91dLOCV, dTTSI or dLoop?=92. These=20
        defects were defined previously.  If none of these defects are=20
        present we keep checking for this condition and stay in the=20
        available state.  However, if one of these defects is present=20
        we enter the Trail Sink Near-End Defect State.=20
   3.   The consequent actions now required depend on the nature of the =

        defect observed, and whether there is any incoming FDI from a=20
        lower layer, and should follow the rules given previously. But=20
        note that any QoS metrics, which are being collected, are=20
        suppressed from aggregation into the long-term registers=20
        against available time.  The registers are effectively=20
        backdated 3s to allow for the defect detection time (at this=20
        stage we cannot judge whether the event will be a Short-Break,=20
        and hence the LSP remains in the Available State, or whether=20
        the LSP will enter the Unavailable State).=20
   4.   We now start timer T1.  This timer is used to determine the=20
        duration of the Trail Sink Near-End Defect State, and if this=20
        persists for a sufficient time (ie a further 10s) then this=20
        timer is used to branch the flow-chart into the Unavailable=20
        State processing region.=20
   5.   Below (timer) T1, we loop round the decision boxes =
=91T1<10s?=92=20
        and =91End dLOCV, dTTSI or dLoop?=92. We can exit this loop if =
the=20
        defect state ends (in accordance with criteria given=20
    =20
   Harrison et. al.      Expires August 2001                  Page 25 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
        previously) before T1 reaches 10s. Since we are still in the=20
        available state, we restart any QoS metric aggregation into the =

        long-term registers (noting the last 3s must be accounted for), =

        we stop FDI/BDI OAM packet generation and capture the short-
        break event in the local registers. Additionally, if the event=20
        was due to a dTTSI, then we should also capture the TTSI of the =

        offending LSP and cease the suppression of traffic.  The=20
        timestamp of the event should be related to the onset of the=20
        defect, which caused it. If however T1 reaches 10s we enter the =

        Unavailable State. Note that it is not possible to enter the=20
        Unavailable State unless the Trail Sink Near-End Defect State=20
        has persisted for at least 10s in the Available State.=20
   6.   We now record a date/time-stamped Unavailable State entry event =

        in the local registers together with information on the nature=20
        of the defect, which caused it.  Note that the date/timestamp=20
        must be backdated 13s.  Optionally, we may also send an=20
        exception report to the NMS with the Unavailable State entry=20
        date/timestamp noted above, together with any other relevant=20
        information about the defect which caused it, e.g. in the case=20
        of dTTSI this should include the TTSI of the offending LSP.  We =

        now stop timer T1 and start timer T2, whose purpose is to=20
        record the duration of the Unavailable State. Note that when we =

        enter the Unavailable State we also remain in the Trail Sink=20
        Near-End Defect State.=20
   7.   We now run round a decision box =91End dLOCV, dTTSI or =
dLoop?=92,=20
        which is just below the point where we started timer T2, which=20
        checks for the end of the defect state.  When the defect ends=20
        (in accordance with the criteria given previously) we stop=20
        FDI/BDI OAM packet generation and exit the Trail Sink Near-End=20
        Defect State. Any QoS metric aggregation is still inhibited.=20
   =20
   8.   We now run round the decision loop comprised of the two boxes=20
        =91>=3D9 but <=3D 11 expected CV OAM packets in last 10s AND no =

        unexpected CV OAM packets' and =91dLOCV, dTTSI or dLoop?=92.  =
If a=20
        further defect occurs before we meet the exit criteria of the=20
        former decision box, we re-enter the Trail Sink Near-End Defect =

        State and hence restart the generation of FDI/BDI OAM packets=20
        (with DL/DT codepoints and other consequent actions relevant to =

        the specific defect observed). Any QoS metric aggregation=20
        continues to be inhibited.  In this case we are back at point 7 =

        above in the state processing and recommence checking for the=20
        end of the defect. Note that timer T2 continues to run.=20
   9.   To get out of the Unavailable State we must first have exited=20
        the Trail Sink Near-End Defect State as noted in 7 above, and=20
        then met the criteria of the decision box =91>=3D9 but <=3D 11=20
        expected CV OAM packets in last 10s AND no unexpected CV OAM=20
        packets?=92 as noted in 8 above. Note that the =91last 10s=92=20
        referred to here includes the 3s interval required to check for =

        the end of the Trail Sink Near-End Defect State as noted above=20
        in item 7.=20
   10.  We now stop timer T2 and record the duration of the=20
        unavailability event in the local registers.  We recommence any =

        QoS metric aggregation into the local registers and cease all=20
        consequent actions associated with the Unavailable State.  Note =

    =20
   Harrison et. al.      Expires August 2001                  Page 26 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
        that T2 will record Unavailable State duration, which is 3s=20
        less than the true unavailability event. Note also that the=20
        last 10s belong to the Available State and so any QoS metric=20
        aggregation will need to take these 10s into account. =20
        Optionally, we may also send an exception report to the NMS=20
        with the Unavailable State exit date/timestamp suitably=20
        corrected as noted above.=20
   11.  This now takes us back to our starting point in the Available=20
        State.=20
   =20
   =20
6.6.5   Far-End State Processing Flow-chart=20
   =20
   The following figure summarizes many of the key points regarding the =

   far-end state-processing algorithm for a given LSP.=20
   =20
                Figure 6: LSP Far-End State Processing Flow Chart=20
   =20
   1.   Assume we start in the available state at the box marked=20
        =91Start=92.  All timers shown later in the flow chart can=20
        conceptually be assumed to be reset at this point.  If there is =

        any backward QoS aggregation activated on the return direction=20
        LSP then this will be via a separate P OAM packet flow on the=20
        return LSP.=20
   2.   The first decision box is =91BDI OAM packet?=92.  If the answer =
is=20
        'No', then we keep looping this check condition and stay in the =

        Available State.  If the answer is 'Yes', then this implies=20
        that the near-end processing at the other end of the (outgoing) =

        LSP has entered the Trail Sink Near-End Defect State.  Note=20
        that this also implies that the defect has already existed for=20
        3s at the other end of this LSP.=20
   3.   We then enter the Trail Sink Far-End Defect State and inhibit=20
        any backward QoS metric aggregation.  The QoS registers will=20
        need to be corrected for the previous 3s, which should not be,=20
        aggregated into the long-term Available State counts.=20
   4.   We now start timer T3, and run round the loop composed of the=20
        decision boxes =91T3 <13s?=92 and =913s BDI-Free?=92.  T3 is =
used to=20
        check the duration of the Trail Sink Far-End Defect State.  If=20
        T3 does not reach 13s and we get 3s, which are BDI-Free, then=20
        we re-start any backward packet level metric aggregation.  Note =

        that the last 6s must be accounted for in any backward QoS=20
        metric aggregation registers.  This arises since it takes the=20
        near-end processing 3s to declare the end of the defect at the=20
        other send of the (outgoing) LSP, and a further 3s to declare=20
        the end of the Trail Sink Far-End Defect State at this end of=20
        the (return) LSP, and all this time should count towards the=20
        Available State at this end of the LSP to ensure correct QoS=20
        metric aggregation.  A Short-Break date/time-stamped event=20
        should also be recorded in the local registers together the=20
        DL/DT information of the defect as given in the BDI OAM packet. =
=20
        This Short-Break event must be date/time-stamped relative to 3s =

        before the time at which the first BDI OAM packet was observed. =
=20
        This now takes us back to the initial start position.  If=20
        however T3 reaches 13s we enter the far-end Unavailable State.  =

    =20
   Harrison et. al.      Expires August 2001                  Page 27 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
        Note that it is not possible to enter the Unavailable State=20
        unless the Trail Sink Far-End Defect State has effectively=20
        persisted for at least 13s (and which means that at the other=20
        end of the (outgoing) LSP the Trail Sink Near-End Defect State=20
        has persisted for at least 10s) in available time.=20
   5.   Optionally, we may now send a date/time-stamped unavailability=20
        entry exception report to the NMS, which includes the relevant=20
        BDI OAM packet DL/DT information.  Note that the date/timestamp =

        of any such exception report should be backdated by 16s (ie 3s=20
        prior to the first BDI OAM packet being observed for this=20
        event) to align the far-end processing with that of the near-
        end processing at the other end.  We now stop timer T3 and=20
        start a timer T4, whose purpose is to record the duration of=20
        this unavailability event.  Note that when we enter the=20
        Unavailable State we also remain in the Trail Sink Far-End=20
        Defect State.=20
   6.   We now run round a loop that checks for 3s which are BDI-Free.  =

        This is used to take us out of the Trail Sink Far-End Defect=20
        State.  Note that this is not strictly necessary, and this=20
        check condition could have been omitted and we could just have=20
        shown the following one which checks for a continuous (ie=20
        overall) 10s of BDI-Free behavior.  However, it has been shown=20
        like this to harmonize the =91look=92 of the near-end and =
far-end=20
        Trail Sink Defect State processing.=20
   7.   If we get 3s which are BDI-Free then we exit the Trail Sink=20
        Far-End Defect State and run a loop which checks if we have had =

        an overall continuous period of 10s which are BDI-Free.  If any =

        further BDI OAM packets appear within this overall 10s checking =

        period then we re-enter the Trail Sink Far-End Defect State and =

        need to repeat the process from step 6 above.  If, however, no=20
        further BDI OAM packets appear within the 10s checking period=20
        we exit the far-end Unavailable State.=20
   8.   We stop timer T4 and record the duration of the unavailability=20
        event.  T4 will record a time, which is 3s less than the true=20
        unavailability event.  A date/time-stamped unavailability exit=20
        event, backdated 13s, together with the unavailability duration =

        should now be recorded in the local registers.  Optionally,=20
        this information may also be sent to the NMS as an exception=20
        report.=20
   9.   Any backward QoS metric aggregation can now be restarted,=20
        noting that the last 13s belong to available time and so the=20
        aggregate registers should be corrected accordingly=20
   =20
6.6.6   A pictorial view of near-end and far-end state processing =20
   =20
   The following figure is given to help clarify the temporal=20
   relationships between the near-end and far-end state processing=20
   given in the previous flow-charts for short-break event and an=20
   unavailability event.=20
   =20
   Figure 7:  Near-End and Far-End Temporal Processing of a Short-Break =

   and Unavailability event=20
   =20
   =20
    =20
   Harrison et. al.      Expires August 2001                  Page 28 =
=0C
                 OAM Functionality for MPLS Networks    February 2001=20
   =20
7. Security Considerations=20
   =20
   The OAM function described in this document enhances the security of =

   MPLS networks, by detecting mis-connections, and therefore=20
   preventing customers=92 traffic to be exposed to other customers.=20
    =20
   The MPLS OAM functions as defined in this document do not raise any=20
   new security issue, to MPLS networks.=20
   =20
   =20
8. References=20
   =20
   =20
   [1]  Rosen E, et al, RFC 3032, "MPLS label stack encoding".=20
   =20
   [2]  Le Faucheur et al, "MPLS support of Differentiated Services",=20
   draft-ietf-mpls-ext-08.txt, work in progress.=20
   =20
   [3]  Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",=20
   draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, work in progress.=20
   =20
   [4]  Hinden and Deering, RFC 1884, "IP Version 6 Addressing=20
   Architecture".=20
   =20
9. Author's Addresses=20
   =20
   Neil Harrison=20
   British Telecom              Phone: 44-1604-845933=20
   Heath Bank                   Email: [email-masked]=20
   Iugby Road, Harleston=20
   South Hampton, UK=20
   =20
   Peter Willis=20
   British Telecom              Phone: 44-1473-645178=20
   BT, PP RSB10/PP3 B81         Email: [email-masked]=20
   Adastrial Park=20
   Martlesham, Ipswich, UK =20
   =20
   Shahram Davari=20
   PMC-Sierra=20
   411 Legget Drive             Phone: 1-613-271-4018=20
   Kanata, ON, Canada           Email: [email-masked]=20
   =20
   Ben Mack-Crane=20
   Tellabs=20
   4951 Indiana Ave             Phone: 1-630-512-7255=20
   Lisle, IL, USA               Email: [email-masked]=20
   =20
   Hiroshi Ohta=20
   NTT=20
   Y-709A, 1-1 Hikarino=92ka      phone: 81-468-59-8840 =20
   Yokosuka-Shi                 Email: [email-masked]=20
   Kanagawa, Japan=20
    =20
   Harrison et. al.      Expires August 2001                  Page 29 =
=0C
------_=_NextPart_000_01C09DB3.D919AFE0
Content-Type: application/octet-stream;
	name="Shahram Davari.vcf"
Content-Disposition: attachment;
	filename="Shahram Davari.vcf"

BEGIN:VCARD
VERSION:2.1
N:Davari;Shahram
FN:Shahram Davari
ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203
TITLE:Product Research Engineer
TEL;WORK;VOICE:+1 613 271 4018
ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv=
e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada
EMAIL;PREF;INTERNET:[email-masked]
REV:20010112T213717Z
END:VCARD

------_=_NextPart_000_01C09DB3.D919AFE0--

Delivery-date: Thu, 22 Feb 2001 12:41:50 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: [IP-Optical] GMPLS enhancements
Date: Thu, 22 Feb 2001 21:39:46 +0100

Hello Maarten,

>In addition it is stated that for SONET STS numbering only "S" will be
>used and "U=0". May I propose to change this and also use for STSs "SU"
>as numbering scheme. Reason is that with using "S" only, you will
>typically fill the OC-N starting at S=1, then S=2, etc. For the case of
>an OC-12, you will have completely fragmented the bandwidth after the
>4th STS1 is added. Now it is not longer possible to add any STS-3c.
>Similar, an OC-48 is fully fragmented when 12 STS1 signals are added; it
>is not possible to add now any STS-3c or STS-12c. Etc.

I am not sure to understand your example since for Sonet  U is totally
irrelevant, you just ignore it. Note also that the bandwidth is allocated as
you like, the label is just the indication of a timeslot. You don't have to
allocate the bandwidth following any kind of label numbering.

>Concerning the AU/STS numbering scheme I agree with you that for SDH AUs
>the "SU" numbering has less restrictions than the "EDCBA" numbering.

Ok, so let's keep SUKLM.

>What we need to add is a conversion table now between EDCBA and SU
>numbering.

I think that for information we could include a short text explaining the
mapping between the two, if everybody agree of course. Could give us a
formula instead of a table (really too long), it should be much more
convenient. 

Regards,

Eric

Conversion table (E,D,C,B,A) (ITU-T G.707) to SU:

G.707
EDCBA	  S U	Signal Type
=========================================
00000	  1 0	AU-4-256c/STS-768c in STM-256/OC-768

10000	  1 0	AU-4-64c/STS-192c in STM-256/OC-768
20000	 65 0	AU-4-64c/STS-192c in STM-256/OC-768
30000	129 0	AU-4-64c/STS-192c in STM-256/OC-768
40000	193 0	AU-4-64c/STS-192c in STM-256/OC-768

11000	  1 0	AU-4-16c/STS-48c in STM-256/OC-768
12000	 17 0	AU-4-16c/STS-48c in STM-256/OC-768
13000	 33 0	AU-4-16c/STS-48c in STM-256/OC-768
14000	 49 0	AU-4-16c/STS-48c in STM-256/OC-768
21000	 65 0	AU-4-16c/STS-48c in STM-256/OC-768
22000	 81 0	AU-4-16c/STS-48c in STM-256/OC-768
23000	 97 0	AU-4-16c/STS-48c in STM-256/OC-768
24000	113 0	AU-4-16c/STS-48c in STM-256/OC-768
31000	129 0	AU-4-16c/STS-48c in STM-256/OC-768
32000	145 0	AU-4-16c/STS-48c in STM-256/OC-768
33000	161 0	AU-4-16c/STS-48c in STM-256/OC-768
34000	177 0	AU-4-16c/STS-48c in STM-256/OC-768
41000	193 0	AU-4-16c/STS-48c in STM-256/OC-768
42000	209 0	AU-4-16c/STS-48c in STM-256/OC-768
43000	225 0	AU-4-16c/STS-48c in STM-256/OC-768
44000	241 0	AU-4-16c/STS-48c in STM-256/OC-768

11100	  1 0	AU-4-4c/STS-12c in STM-256/OC-768
11200	  5 0	AU-4-4c/STS-12c in STM-256/OC-768
11300	  9 0	AU-4-4c/STS-12c in STM-256/OC-768
11400	 13 0	AU-4-4c/STS-12c in STM-256/OC-768
12100	 17 0	AU-4-4c/STS-12c in STM-256/OC-768
12200	 21 0	AU-4-4c/STS-12c in STM-256/OC-768
12300	 25 0	AU-4-4c/STS-12c in STM-256/OC-768
12400	 29 0	AU-4-4c/STS-12c in STM-256/OC-768
13100	 33 0	AU-4-4c/STS-12c in STM-256/OC-768
13200	 37 0	AU-4-4c/STS-12c in STM-256/OC-768
13300	 41 0	AU-4-4c/STS-12c in STM-256/OC-768
13400	 45 0	AU-4-4c/STS-12c in STM-256/OC-768
14100	 49 0	AU-4-4c/STS-12c in STM-256/OC-768
14200	 53 0	AU-4-4c/STS-12c in STM-256/OC-768
14300	 57 0	AU-4-4c/STS-12c in STM-256/OC-768
14400	 61 0	AU-4-4c/STS-12c in STM-256/OC-768
21100	 65 0	AU-4-4c/STS-12c in STM-256/OC-768
21200	 69 0	AU-4-4c/STS-12c in STM-256/OC-768
21300	 73 0	AU-4-4c/STS-12c in STM-256/OC-768
21400	 77 0	AU-4-4c/STS-12c in STM-256/OC-768
22100	 81 0	AU-4-4c/STS-12c in STM-256/OC-768
22200	 69 0	AU-4-4c/STS-12c in STM-256/OC-768
22300	 73 0	AU-4-4c/STS-12c in STM-256/OC-768
22400	 77 0	AU-4-4c/STS-12c in STM-256/OC-768
23100	 97 0	AU-4-4c/STS-12c in STM-256/OC-768
23200	 69 0	AU-4-4c/STS-12c in STM-256/OC-768
23300	 73 0	AU-4-4c/STS-12c in STM-256/OC-768
23400	 77 0	AU-4-4c/STS-12c in STM-256/OC-768
24100	113 0	AU-4-4c/STS-12c in STM-256/OC-768
24200	117 0	AU-4-4c/STS-12c in STM-256/OC-768
24300	121 0	AU-4-4c/STS-12c in STM-256/OC-768
24400	125 0	AU-4-4c/STS-12c in STM-256/OC-768
31100	129 0	AU-4-4c/STS-12c in STM-256/OC-768
31200	133 0	AU-4-4c/STS-12c in STM-256/OC-768
31300	137 0	AU-4-4c/STS-12c in STM-256/OC-768
31400	141 0	AU-4-4c/STS-12c in STM-256/OC-768
32100	145 0	AU-4-4c/STS-12c in STM-256/OC-768
32200	149 0	AU-4-4c/STS-12c in STM-256/OC-768
32300	153 0	AU-4-4c/STS-12c in STM-256/OC-768
32400	157 0	AU-4-4c/STS-12c in STM-256/OC-768
33100	161 0	AU-4-4c/STS-12c in STM-256/OC-768
33200	165 0	AU-4-4c/STS-12c in STM-256/OC-768
33300	169 0	AU-4-4c/STS-12c in STM-256/OC-768
33400	173 0	AU-4-4c/STS-12c in STM-256/OC-768
34100	177 0	AU-4-4c/STS-12c in STM-256/OC-768
34200	181 0	AU-4-4c/STS-12c in STM-256/OC-768
34300	185 0	AU-4-4c/STS-12c in STM-256/OC-768
34400	189 0	AU-4-4c/STS-12c in STM-256/OC-768
41100	193 0	AU-4-4c/STS-12c in STM-256/OC-768
41200	197 0	AU-4-4c/STS-12c in STM-256/OC-768
41300	201 0	AU-4-4c/STS-12c in STM-256/OC-768
41400	205 0	AU-4-4c/STS-12c in STM-256/OC-768
42100	209 0	AU-4-4c/STS-12c in STM-256/OC-768
42200	213 0	AU-4-4c/STS-12c in STM-256/OC-768
42300	217 0	AU-4-4c/STS-12c in STM-256/OC-768
42400	221 0	AU-4-4c/STS-12c in STM-256/OC-768
43100	225 0	AU-4-4c/STS-12c in STM-256/OC-768
43200	229 0	AU-4-4c/STS-12c in STM-256/OC-768
43300	233 0	AU-4-4c/STS-12c in STM-256/OC-768
43400	237 0	AU-4-4c/STS-12c in STM-256/OC-768
44100	241 0	AU-4-4c/STS-12c in STM-256/OC-768
44200	245 0	AU-4-4c/STS-12c in STM-256/OC-768
44300	249 0	AU-4-4c/STS-12c in STM-256/OC-768
44400	253 0	AU-4-4c/STS-12c in STM-256/OC-768

11110	  1 1	AU-4/STS-3c in STM-256/OC-768
11120	  2 1	AU-4/STS-3c in STM-256/OC-768
11130	  3 1	AU-4/STS-3c in STM-256/OC-768
11140	  4 1	AU-4/STS-3c in STM-256/OC-768
11210	  5 1	AU-4/STS-3c in STM-256/OC-768
11220	  6 1	AU-4/STS-3c in STM-256/OC-768
11220	  7 1	AU-4/STS-3c in STM-256/OC-768
11220	  8 1	AU-4/STS-3c in STM-256/OC-768
11310	  9 1	AU-4/STS-3c in STM-256/OC-768
:
11410	 13 1	AU-4/STS-3c in STM-256/OC-768
:
12110	 17 1	AU-4/STS-3c in STM-256/OC-768
:
12210	 21 1	AU-4/STS-3c in STM-256/OC-768
:
12310	 25 1	AU-4/STS-3c in STM-256/OC-768
:
12410	 29 1	AU-4/STS-3c in STM-256/OC-768
:
13110	 33 1	AU-4/STS-3c in STM-256/OC-768
:
13210	 37 1	AU-4/STS-3c in STM-256/OC-768
:
13310	 41 1	AU-4/STS-3c in STM-256/OC-768
:
13410	 45 1	AU-4/STS-3c in STM-256/OC-768
:
14110	 49 1	AU-4/STS-3c in STM-256/OC-768
:
14210	 53 1	AU-4/STS-3c in STM-256/OC-768
:
14310	 57 1	AU-4/STS-3c in STM-256/OC-768
:
14410	 61 1	AU-4/STS-3c in STM-256/OC-768
:
21110	 65 1	AU-4/STS-3c in STM-256/OC-768
:
21210	 69 1	AU-4/STS-3c in STM-256/OC-768
:
21310	 73 1	AU-4/STS-3c in STM-256/OC-768
:
21410	 77 1	AU-4/STS-3c in STM-256/OC-768
:
22110	 81 1	AU-4/STS-3c in STM-256/OC-768
:
22210	 85 1	AU-4/STS-3c in STM-256/OC-768
:
22310	 89 1	AU-4/STS-3c in STM-256/OC-768
:
22410	 93 1	AU-4/STS-3c in STM-256/OC-768
:
23110	 97 1	AU-4/STS-3c in STM-256/OC-768
:
23210	101 1	AU-4/STS-3c in STM-256/OC-768
:
23310	105 1	AU-4/STS-3c in STM-256/OC-768
:
23410	109 1	AU-4/STS-3c in STM-256/OC-768
:
24110	113 1	AU-4/STS-3c in STM-256/OC-768
:
24210	117 1	AU-4/STS-3c in STM-256/OC-768
:
24310	121 1	AU-4/STS-3c in STM-256/OC-768
:
24410	125 1	AU-4/STS-3c in STM-256/OC-768
:
31110	129 1	AU-4/STS-3c in STM-256/OC-768
:
31210	133 1	AU-4/STS-3c in STM-256/OC-768
:
31310	137 1	AU-4/STS-3c in STM-256/OC-768
:
31410	141 1	AU-4/STS-3c in STM-256/OC-768
:
32110	145 1	AU-4/STS-3c in STM-256/OC-768
:
32210	149 1	AU-4/STS-3c in STM-256/OC-768
:
32310	153 1	AU-4/STS-3c in STM-256/OC-768
:
32410	157 1	AU-4/STS-3c in STM-256/OC-768
:
33110	161 1	AU-4/STS-3c in STM-256/OC-768
:
33210	165 1	AU-4/STS-3c in STM-256/OC-768
:
33310	169 1	AU-4/STS-3c in STM-256/OC-768
:
33410	173 1	AU-4/STS-3c in STM-256/OC-768
:
34110	177 1	AU-4/STS-3c in STM-256/OC-768
:
34210	181 1	AU-4/STS-3c in STM-256/OC-768
:
34310	185 1	AU-4/STS-3c in STM-256/OC-768
:
34410	189 1	AU-4/STS-3c in STM-256/OC-768
:
41110	193 1	AU-4/STS-3c in STM-256/OC-768
:
41210	197 1	AU-4/STS-3c in STM-256/OC-768
:
41310	201 1	AU-4/STS-3c in STM-256/OC-768
:
41410	205 1	AU-4/STS-3c in STM-256/OC-768
:
42110	209 1	AU-4/STS-3c in STM-256/OC-768
:
42210	213 1	AU-4/STS-3c in STM-256/OC-768
:
42310	217 1	AU-4/STS-3c in STM-256/OC-768
:
42410	221 1	AU-4/STS-3c in STM-256/OC-768
:
43110	225 1	AU-4/STS-3c in STM-256/OC-768
:
43210	229 1	AU-4/STS-3c in STM-256/OC-768
:
43310	233 1	AU-4/STS-3c in STM-256/OC-768
:
43410	237 1	AU-4/STS-3c in STM-256/OC-768
:
44110	241 1	AU-4/STS-3c in STM-256/OC-768
:
44210	245 1	AU-4/STS-3c in STM-256/OC-768
:
44310	249 1	AU-4/STS-3c in STM-256/OC-768
:
44410	253 1	AU-4/STS-3c in STM-256/OC-768
44420	254 1	AU-4/STS-3c in STM-256/OC-768
44430	255 1	AU-4/STS-3c in STM-256/OC-768
44440	256 1	AU-4/STS-3c in STM-256/OC-768

11111	  1 2	AU-3/STS-1 in STM-256/OC-768
11112	  1 3	AU-3/STS-1 in STM-256/OC-768
11113	  1 4	AU-3/STS-1 in STM-256/OC-768
11121	  2 2	AU-3/STS-1 in STM-256/OC-768
11122	  2 3	AU-3/STS-1 in STM-256/OC-768
11123	  2 4	AU-3/STS-1 in STM-256/OC-768
:
11131	  3 2	AU-3/STS-1 in STM-256/OC-768
:
11141	  4 2	AU-3/STS-1 in STM-256/OC-768
:
11211	  5 2	AU-3/STS-1 in STM-256/OC-768
:
11311	  9 2	AU-3/STS-1 in STM-256/OC-768
:
11411	 13 2	AU-3/STS-1 in STM-256/OC-768
:
12111	 17 2	AU-3/STS-1 in STM-256/OC-768
:
12211	 21 2	AU-3/STS-1 in STM-256/OC-768
:
12311	 25 2	AU-3/STS-1 in STM-256/OC-768
:
12411	 29 2	AU-3/STS-1 in STM-256/OC-768
:
13111	 33 2	AU-3/STS-1 in STM-256/OC-768
:
13211	 37 2	AU-3/STS-1 in STM-256/OC-768
:
13311	 41 2	AU-3/STS-1 in STM-256/OC-768
:
13411	 45 2	AU-3/STS-1 in STM-256/OC-768
:
14111	 49 2	AU-3/STS-1 in STM-256/OC-768
:
14211	 53 2	AU-3/STS-1 in STM-256/OC-768
:
14311	 57 2	AU-3/STS-1 in STM-256/OC-768
:
14411	 61 2	AU-3/STS-1 in STM-256/OC-768
:
21111	 65 2	AU-3/STS-1 in STM-256/OC-768
:
21211	 69 2	AU-3/STS-1 in STM-256/OC-768
:
21311	 73 2	AU-3/STS-1 in STM-256/OC-768
:
21411	 77 2	AU-3/STS-1 in STM-256/OC-768
:
22111	 81 2	AU-3/STS-1 in STM-256/OC-768
:
22211	 85 2	AU-3/STS-1 in STM-256/OC-768
:
22311	 89 2	AU-3/STS-1 in STM-256/OC-768
:
22411	 93 2	AU-3/STS-1 in STM-256/OC-768
:
23111	 97 2	AU-3/STS-1 in STM-256/OC-768
:
23211	101 2	AU-3/STS-1 in STM-256/OC-768
:
23311	105 2	AU-3/STS-1 in STM-256/OC-768
:
23411	109 2	AU-3/STS-1 in STM-256/OC-768
:
24111	113 2	AU-3/STS-1 in STM-256/OC-768
:
24211	117 2	AU-3/STS-1 in STM-256/OC-768
:
24311	121 2	AU-3/STS-1 in STM-256/OC-768
:
24411	125 2	AU-3/STS-1 in STM-256/OC-768
:
31111	129 2	AU-3/STS-1 in STM-256/OC-768
:
31211	133 2	AU-3/STS-1 in STM-256/OC-768
:
31311	137 2	AU-3/STS-1 in STM-256/OC-768
:
31411	141 2	AU-3/STS-1 in STM-256/OC-768
:
32111	145 2	AU-3/STS-1 in STM-256/OC-768
:
32211	149 2	AU-3/STS-1 in STM-256/OC-768
:
32311	153 2	AU-3/STS-1 in STM-256/OC-768
:
32411	157 2	AU-3/STS-1 in STM-256/OC-768
:
33111	161 2	AU-3/STS-1 in STM-256/OC-768
:
33211	165 2	AU-3/STS-1 in STM-256/OC-768
:
33311	169 2	AU-3/STS-1 in STM-256/OC-768
:
33411	173 2	AU-3/STS-1 in STM-256/OC-768
:
34111	177 2	AU-3/STS-1 in STM-256/OC-768
:
34211	181 2	AU-3/STS-1 in STM-256/OC-768
:
34311	185 2	AU-3/STS-1 in STM-256/OC-768
:
34411	189 2	AU-3/STS-1 in STM-256/OC-768
:
41111	193 2	AU-3/STS-1 in STM-256/OC-768
:
41211	197 2	AU-3/STS-1 in STM-256/OC-768
:
41311	211 2	AU-3/STS-1 in STM-256/OC-768
:
41411	215 2	AU-3/STS-1 in STM-256/OC-768
:
42111	219 2	AU-3/STS-1 in STM-256/OC-768
:
42211	213 2	AU-3/STS-1 in STM-256/OC-768
:
42311	217 2	AU-3/STS-1 in STM-256/OC-768
:
42411	221 2	AU-3/STS-1 in STM-256/OC-768
:
43111	225 2	AU-3/STS-1 in STM-256/OC-768
:
43211	229 2	AU-3/STS-1 in STM-256/OC-768
:
43311	233 2	AU-3/STS-1 in STM-256/OC-768
:
43411	237 2	AU-3/STS-1 in STM-256/OC-768
:
44111	241 2	AU-3/STS-1 in STM-256/OC-768
:
44211	245 2	AU-3/STS-1 in STM-256/OC-768
:
44311	249 2	AU-3/STS-1 in STM-256/OC-768
:
44411	253 2	AU-3/STS-1 in STM-256/OC-768
:
44421	254 2	AU-3/STS-1 in STM-256/OC-768
:
44431	255 2	AU-3/STS-1 in STM-256/OC-768
:
44441	256 2	AU-3/STS-1 in STM-256/OC-768
44442	256 3	AU-3/STS-1 in STM-256/OC-768
44443	256 4	AU-3/STS-1 in STM-256/OC-768

G.707
DCBA	  S U	Signal Type
=========================================
0000	  1 0	AU-4-64c/STS-192c in STM-64/OC-192

1000	  1 0	AU-4-16c/STS-48c in STM-64/OC-192
2000	 17 0	AU-4-16c/STS-48c in STM-64/OC-192
3000	 33 0	AU-4-16c/STS-48c in STM-64/OC-192
4000	 49 0	AU-4-16c/STS-48c in STM-64/OC-192

1100	  1 0	AU-4-4c/STS-12c in STM-64/OC-192
1200	  5 0	AU-4-4c/STS-12c in STM-64/OC-192
1300	  9 0	AU-4-4c/STS-12c in STM-64/OC-192
1400	 13 0	AU-4-4c/STS-12c in STM-64/OC-192
2100	 17 0	AU-4-4c/STS-12c in STM-64/OC-192
2200	 21 0	AU-4-4c/STS-12c in STM-64/OC-192
2300	 25 0	AU-4-4c/STS-12c in STM-64/OC-192
2400	 29 0	AU-4-4c/STS-12c in STM-64/OC-192
3100	 33 0	AU-4-4c/STS-12c in STM-64/OC-192
3200	 37 0	AU-4-4c/STS-12c in STM-64/OC-192
3300	 41 0	AU-4-4c/STS-12c in STM-64/OC-192
3400	 45 0	AU-4-4c/STS-12c in STM-64/OC-192
4100	 49 0	AU-4-4c/STS-12c in STM-64/OC-192
4200	 53 0	AU-4-4c/STS-12c in STM-64/OC-192
4300	 57 0	AU-4-4c/STS-12c in STM-64/OC-192
4400	 61 0	AU-4-4c/STS-12c in STM-64/OC-192

1110	  1 1	AU-4/STS-3c in STM-64/OC-192
1120	  2 1	AU-4/STS-3c in STM-64/OC-192
1130	  3 1	AU-4/STS-3c in STM-64/OC-192
1140	  4 1	AU-4/STS-3c in STM-64/OC-192
1210	  5 1	AU-4/STS-3c in STM-64/OC-192
1220	  6 1	AU-4/STS-3c in STM-64/OC-192
1220	  7 1	AU-4/STS-3c in STM-64/OC-192
1220	  8 1	AU-4/STS-3c in STM-64/OC-192
1310	  9 1	AU-4/STS-3c in STM-64/OC-192
:
1410	 13 1	AU-4/STS-3c in STM-64/OC-192
:
2110	 17 1	AU-4/STS-3c in STM-64/OC-192
:
2210	 21 1	AU-4/STS-3c in STM-64/OC-192
:
2310	 25 1	AU-4/STS-3c in STM-64/OC-192
:
2410	 29 1	AU-4/STS-3c in STM-64/OC-192
:
3110	 33 1	AU-4/STS-3c in STM-64/OC-192
:
3210	 37 1	AU-4/STS-3c in STM-64/OC-192
:
3310	 41 1	AU-4/STS-3c in STM-64/OC-192
:
3410	 45 1	AU-4/STS-3c in STM-64/OC-192
:
4110	 49 1	AU-4/STS-3c in STM-64/OC-192
:
4210	 53 1	AU-4/STS-3c in STM-64/OC-192
:
4310	 57 1	AU-4/STS-3c in STM-64/OC-192
:
4410	 61 1	AU-4/STS-3c in STM-64/OC-192
4420	 62 1	AU-4/STS-3c in STM-64/OC-192
4430	 63 1	AU-4/STS-3c in STM-64/OC-192
4440	 64 1	AU-4/STS-3c in STM-64/OC-192

1111	  1 2	AU-3/STS-1 in STM-64/OC-192
1112	  1 3	AU-3/STS-1 in STM-64/OC-192
1113	  1 4	AU-3/STS-1 in STM-64/OC-192
1121	  2 2	AU-3/STS-1 in STM-64/OC-192
1122	  2 3	AU-3/STS-1 in STM-64/OC-192
1123	  2 4	AU-3/STS-1 in STM-64/OC-192
:
1131	  3 2	AU-3/STS-1 in STM-64/OC-192
:
1141	  4 2	AU-3/STS-1 in STM-64/OC-192
:
1211	  5 2	AU-3/STS-1 in STM-64/OC-192
:
1311	  9 2	AU-3/STS-1 in STM-64/OC-192
:
1411	 13 2	AU-3/STS-1 in STM-64/OC-192
:
2111	 17 2	AU-3/STS-1 in STM-64/OC-192
:
2211	 21 2	AU-3/STS-1 in STM-64/OC-192
:
2311	 25 2	AU-3/STS-1 in STM-64/OC-192
:
2411	 29 2	AU-3/STS-1 in STM-64/OC-192
:
3111	 33 2	AU-3/STS-1 in STM-64/OC-192
:
3211	 37 2	AU-3/STS-1 in STM-64/OC-192
:
3311	 41 2	AU-3/STS-1 in STM-64/OC-192
:
3411	 45 2	AU-3/STS-1 in STM-64/OC-192
:
4111	 49 2	AU-3/STS-1 in STM-64/OC-192
:
4211	 53 2	AU-3/STS-1 in STM-64/OC-192
:
4311	 57 2	AU-3/STS-1 in STM-64/OC-192
:
4411	 61 2	AU-3/STS-1 in STM-64/OC-192
:
4441	 63 2	AU-3/STS-1 in STM-64/OC-192
4442	 64 3	AU-3/STS-1 in STM-64/OC-192
4443	 65 4	AU-3/STS-1 in STM-64/OC-192

G.707
CBA	  S U	Signal Type
=========================================
000	  1 0	AU-4-16c/STS-48c in STM-16/OC-48

100	  1 0	AU-4-4c/STS-12c in STM-16/OC-48
200	  5 0	AU-4-4c/STS-12c in STM-16/OC-48
300	  9 0	AU-4-4c/STS-12c in STM-16/OC-48
400	 13 0	AU-4-4c/STS-12c in STM-16/OC-48

110	  1 1	AU-4/STS-3c in STM-16/OC-48
120	  2 1	AU-4/STS-3c in STM-16/OC-48
130	  3 1	AU-4/STS-3c in STM-16/OC-48
140	  4 1	AU-4/STS-3c in STM-16/OC-48
210	  5 1	AU-4/STS-3c in STM-16/OC-48
220	  6 1	AU-4/STS-3c in STM-16/OC-48
220	  7 1	AU-4/STS-3c in STM-16/OC-48
220	  8 1	AU-4/STS-3c in STM-16/OC-48
310	  9 1	AU-4/STS-3c in STM-16/OC-48
320	 10 1	AU-4/STS-3c in STM-16/OC-48
330	 11 1	AU-4/STS-3c in STM-16/OC-48
340	 12 1	AU-4/STS-3c in STM-16/OC-48
410	 13 1	AU-4/STS-3c in STM-16/OC-48
420	 14 1	AU-4/STS-3c in STM-16/OC-48
430	 15 1	AU-4/STS-3c in STM-16/OC-48
440	 16 1	AU-4/STS-3c in STM-16/OC-48

111	  1 2	AU-3/STS-1 in STM-16/OC-48
112	  1 3	AU-3/STS-1 in STM-16/OC-48
113	  1 4	AU-3/STS-1 in STM-16/OC-48
121	  2 2	AU-3/STS-1 in STM-16/OC-48
122	  2 3	AU-3/STS-1 in STM-16/OC-48
123	  2 4	AU-3/STS-1 in STM-16/OC-48
131	  3 2	AU-3/STS-1 in STM-16/OC-48
132	  3 3	AU-3/STS-1 in STM-16/OC-48
133	  3 4	AU-3/STS-1 in STM-16/OC-48
141	  4 2	AU-3/STS-1 in STM-16/OC-48
:
211	  5 2	AU-3/STS-1 in STM-16/OC-48
:
311	  9 2	AU-3/STS-1 in STM-16/OC-48
:
411	 13 2	AU-3/STS-1 in STM-16/OC-48
:
441	 16 2	AU-3/STS-1 in STM-16/OC-48
442	 16 3	AU-3/STS-1 in STM-16/OC-48
443	 16 4	AU-3/STS-1 in STM-16/OC-48

G.707
BA	  S U	Signal Type
=========================================
00	  1 0	AU-4-4c/STS-12c in STM-4/OC-12

10	  1 1	AU-4/STS-3c in STM-4/OC-12
20	  2 1	AU-4/STS-3c in STM-4/OC-12
30	  3 1	AU-4/STS-3c in STM-4/OC-12
40	  4 1	AU-4/STS-3c in STM-4/OC-12

11	  1 2	AU-3/STS-1 in STM-4/OC-12
12	  1 3	AU-3/STS-1 in STM-4/OC-12
13	  1 4	AU-3/STS-1 in STM-4/OC-12
21	  2 2	AU-3/STS-1 in STM-4/OC-12
22	  2 3	AU-3/STS-1 in STM-4/OC-12
23	  2 4	AU-3/STS-1 in STM-4/OC-12
31	  3 2	AU-3/STS-1 in STM-4/OC-12
32	  3 3	AU-3/STS-1 in STM-4/OC-12
33	  3 4	AU-3/STS-1 in STM-4/OC-12
41	  4 2	AU-3/STS-1 in STM-4/OC-12
42	  4 3	AU-3/STS-1 in STM-4/OC-12
43	  4 4	AU-3/STS-1 in STM-4/OC-12

G.707
A	  S U	Signal Type
=========================================
0	  1 1	AU-4/STS-3c in STM-1/OC-3

1	  1 2	AU-3/STS-1 in STM-1/OC-3
2	  1 3	AU-3/STS-1 in STM-1/OC-3
3	  1 4	AU-3/STS-1 in STM-1/OC-3

Delivery-date: Thu, 22 Feb 2001 08:48:08 -0800
To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: PWOT Mailing List
Date: Thu, 22 Feb 2001 09:44:11 -0700

The PWOT mailing list has been created for discussion 
of Pseudo Wires Over Transport.  PWOT is a descendant 
of CEOT (Circulation Emulation Over Transport), and is 
a to-be working group.  

The IESG is working with the chairs to finalize the 
charter now and a BOF slot has been secured for the 
meeting in Minneapolis.  

The charter will be posted once it's been finalized.  

CEOT list subscription will not be transferred, so if
you're interested please subscribe to PWOT.  There are 
two methods of subscribing:

o Submit the standard email request to [email-masked]
o Go to http://www.ietf.org/mailman/listinfo/pwot 

General posts should be directed to [email-masked].  Member 
posting only is enabled.  Archives will be accessible via 
the URL above.

Additional information (i.e., charter, et al.) will be
posted as soon as it's finalized.

Thanks!

Luca & Danny

Delivery-date: Thu, 22 Feb 2001 03:32:44 -0800
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] GMPLS enhancements
Date: Thu, 22 Feb 2001 12:28:26 +0100

Hi Eric and Maarten,

it is not a question of using G.707 or GMPLS. G.707 defines a transport plane technology (SDH) and GMPLS a control plane technology as you stated. The intend of GMPLS is to define a control plane for transport planes, exisitng ones or new ones, but not to define a transport plane of its own I assume. SDH is one transport plane technology. G.707 defines the signal structure for SDH. G.707  compliant equipment has not to support all features of G.707, e.g. it might not supprot contiguous concatenation. In addition vendor proprietary features exists. GMPLS should at least support the G.707 features (VC-11/12/2/3/4/VC-4-Xv/VC-4-Yc y=4,16,64). Vendor proprietary features (or tricks) can also be added or we should allow at least a mechnism to extend GMPLS with such features. However we have to ensure that the different features can be clearly distinguished. For standard and non standard contiguous concatenation that works fine as we define the number of concatenated VCs and the star!
!
ting slot. From these information it can be decided if it is supported or not by the equipment. The concatenation iformation is not orthogonal to the lable it indicates the bandwidth of the label like VC-11, VC-2 or VC-4 does.
You mentioned multiplexing and transport of e.g. four STM-1s each with its own multiplex and regenerator section OH. Yes it is possible and different proprietary solutions exists (not for STM-1, but for STM-16). One problem is , that you need addtional overhead in order to have supervision for the new entity. You have to use different indications for the different proprietary formats as they don't interwork.
As long as you are in your own network you can do what you want (except the regulation forces you to supprot specific features, which will be standard features). As soon as you have to go to antoher networ operator you need mutual agreement or use standard features.

Eric, I have some addtiona lcomments below. Specially with your view on layers I have problems.

Rgards

Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Wednesday, February 21, 2001 11:34 AM
> To:	'Maarten Vissers'
> Cc:	Ben Mack-Crane (E-mail); Greg Bernstein (E-mail); Bala Rajagopalan (E-mail); Debanjan Saha (E-mail); Michael Raftelis (E-mail); Shash Chatterjee (E-mail); Jeff Connell (E-mail); Vishal Sharma; [email-masked]'; [email-masked]
> Subject:	RE: [IP-Optical] GMPLS enhancements
> 
> Hello Maarten,
> 
> >It seems that you try to glue toghether two versions of SDH: the
> >standardised SDH (G.707) and several proprietary extensions of SDH. Not
> >mentioning this explicitly is highly confusing. 
> 
> We try to glue to the industry. There are common practices and new practices
> (e.g. fast restoration) that are not part of G.707 but that are highly
> valuable to control. In addition, we consider SONET as well.
	[Heiles Juergen]  Restoration or protection is not part of G.707, G.707 does not prevent fast restoration.
>  
> GMPLS is a new control plane, it is not proprietary, it is already a
> reference in the industry, it is not being standardized by ITU-T and is not
> part of G.707. GMPLS deliberately allows to change the classical behavior of
> legacy SDH networks.
	[Heiles Juergen]  GMPLS changes the control of SDH networks, should not change the transport plane itself.
>  
> If somebody don't like GMPLS, he/she is not obliged to implement it - you
> may just ignore GMPLS and use the regular G.707.
	[Heiles Juergen]  GMPLS does not out rule G.707 and vice versa as stated above.
>  
> > It also suggests
> >capabilities to be present which will not be supported in many of the
> >SDH networks.
> 
> Not supported in SDH networks but supported in GMPLS-SDH networks.
	[Heiles Juergen]  Proprietary SDH networks might support it and GMPS-SDH networks might not support it, all options exisits.
>  
> There are also plenty of IP capabilities that are not supported in plenty of
> IP networks, etc.
> A profile is always welcome.
> 
> >In my opinion, you should therefore have separate entities in the LSP
> >encoding type for standardised-SDH and proprietary-SDH; and idem for
> >SONET. Standardised-SDH and proprietary-SDH equipment may not be able to
> >interwork; only if proprietary-SDH equipment is configured as
> >standardised-SDH equipment interworking will be possible. 
> 
> About the regular (legacy) SDH interoperability, did you try it already ?
> That's really not simple because there are plenty of differences between the
> implementations. I heard many people saying that legacy SDH interoperability
> doesn't exist. 
	[Heiles Juergen]  SDH/Sonet is used world wide and I assume GTS uses it also. Do you have only islands of single vendor equipment that do not interwork with others? No! Some itnerworking issues exists, but that is the same as in the IP world. One vendor decides to implement RSVP only, the other LDP only. 
> Restricting the work to a super-minimal set of functionalities that must be
> supported by *everybody* doesn't make sense for me. If someone doesn't
> implement the capabilities that you want, you don't buy their box, that's
> all. 
> 
> >For standardised-SDH, the EDCBA number is defined in G.707 (10/00);
> >G.707 (10/00) compliant equipment will support AU-4-Xc (X=4,16,64,256)
> >timeslots as defined by the EDCBA numbering scheme only.
> 
> Our label supports this, and more.
> 
> >When we introduced the EDCBA numbering, there were no objections from
> >any of the companies represented in ITU-T...
> 
> Because this numbering has nothing to do with what can be implemented, it is
> just a numbering.
	[Heiles Juergen]  I have also some favors not to use the EDCBA numbering. It is not requried and might be too restrictive as you said.
>  
> >As there is no intention to make one big label encompassing all
> >transport layer signals, every layer should be taken individually. This
> >includes MSn, HOVC and LOVC layers.
> 
> In the context of GMPLS, I see SDH as being one layer. In that layer we can
> request pipes of different sizes and we can do some nesting of pipes, by
> using the SDH mulitplexing rules. The fact that you have high order pipes
> and low order pipes does not imply that we have two layers for SDH and that
> we need separate label definitions as you said.
	[Heiles Juergen]  Here I have strong objections. SDH is a technology and not a layer. It constis of several layer networks and GMPLS should be aware of this. Otherwise GMPLS is too restrictive. We have these layers VC-12 and V-4 connections ca nbe setuo independtly from each other. A VC-12 can make use of a VC-4 connection betwen two points A and B. It doesn't have to care about which interfaces the VC-4 uses and what the postiion of the VC-4 within a STM-N is. Its no difference between multiplexing a VC-12 -> VC-4 -> STM-16 multipelxing and VC-4 -> STM-16 -> WDM multiplexing. It is multipelxing and the technology doesn't matter (e.g. WDM. TDM, PDH, SDH). It should be handled the same by the control plane. Network management systems handle WDM the same as TDM (SDH).
>  
> The proof is that one could decide to allocate a VC-11 and to specify
> exactly where it is at each level of the SDH multiplex, i.e. by specifying a
> full SUKLM label. In your proposal of having SDH high order labels and low
> order labels, we will need to allocate and to return two labels at the same
> time, it is in conflict with the principles of GMPLS.
	[Heiles Juergen]  That is not true. Assume that you have a SDH network with 4/4 (VC-4) and 4/1 (VC-12, VC-2, VC-3, VC4) switches. When you setup a VC-12 link connection from A to B you use a VC-4 taht goes fro mA to B and put the VC-12 into this VC-4. This VC-4 goes via intermediate VC-4 switches K and L. A and B have VC-4 and VC-12 switching functionality. The VC-4 is conected to STM-14 IF 1 at A and B. See figure below.
	 -----------------       ---     ---       ---------------
	|       A        -|1----| K |---| L |----1|-      B       |     
	|              /  |      ---     ---      | \             |
	| VC-11->VC-4-    |                       |  -VC-4->VC-11 |
	|                 |      ---     ---      |               |
	|                -|2----| M |---| N |----2|-              |
	 -----------------       ---     ---       ---------------

	 -----------------       ---     ---       ---------------
	|       A        -|1----| K |---| L |----1|-      B       |     
	|                 |      ---     ---      |               |
	| VC-11->VC-4-    |                       |  -VC-4->VC-11 |
	|              \  |      ---     ---      | /             |
	|                -|2----| M |---| N |----2|-              |
	 -----------------       ---     ---       ---------------

	Now because of VC-4 path protection or restoration or rearrangments of the VC-4 for traffic engineering purposes the VC-4 is switched to a new path going via M and N using STM-16 IF 2 at A and B. For the VC-11 it is still the same VC-4. For VC-11 it doesn't matter if it goes via IF 1 or 2. It is only important that is uses the VC-4 which goes from A to B. It doesn't matter which interfaces the VC-4 uses. Note that the VC-4 connection could be contorlled via GMPLS or in the tradional way.
>  
> Regards,
> 
> Eric
> 
> "Mannie, Eric" wrote:
> > 
> > Hi Maarten,
> > 
> > I think that you misunderstood some important things about the label,
> I'll
> > try to clarify in the following.
> > 
> > First, as you know,
> > 
> > - All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy,
> > "flat" stuff !
> > - The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some
> specific
> > rules: "tree-like" hierarchy.
> > - A label identifies the first time-slot (or component) of a particular
> > signal, not the full aggregate.
> > 
> > Consequently, you need separate values to identify the nesting (UKLM) and
> > only one value to identify any component in the interleaving (S = index).
> > 
> > We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S
> > field is a simple index, it is flat and there is no reason to represent
> > something flat as a hierarchy.
> > 
> > So there is no reason to use E, D, C, B !
> > 
> > And yes, one STM-1 can be seen as a time-slot if all STM-1s are
> (logically)
> > time-division multiplexed. For instance, if you want to transport four
> > STM-1s "transparently" you will have four STM-1s, each one with an
> > independent overhead. This can be achieved by interleaving the four
> > overheads, or by tunneling the overheads. How this transparency is
> achieved
> > is proprietary in the data plane, different vendors have different
> > solutions. At least we would like to have a standardized solution to
> request
> > and use it in the control plane. I understand your confusion since we
> don't
> > use a regular SDH/SONET, but their are common tricks that vendors are
> > implementing and that are useful to control in a generic way via the GMPLS
> > control plane.
> > 
> > So, we are not 100% glued to G.707. The same apply for
> > protection/restoration since we are not tied anymore to only the
> > protection/restoration schemes standardized by ITU-T, the fast meshed
> > restoration is an example.
> > 
> > In addition, you want to indicate some fixed concatenation levels
> (AU-4-4c,
> > AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate
> > since there are plenty of other different levels of concatenation, indeed
> > all levels are possible, e.g. AU-4-7c. The concatenation is anyway better
> > indicated separately, it is orthogonal with a label.
> > 
> > Think also about contiguous concatenation for example, I could want to
> > concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to
> > indicate where begins my concatenation. Arbitrary concatenation is> 
> commonly
> > used.
	[Heiles Juergen]  I don't think so. Most IP routers support only non-channelized SDH/Sonet interface.

> > 
> > Moreover, we want to be able to manipulate circuits of any size,
> > concatenated or not (e.g. an STM-7 or STM-255). 
	[Heiles Juergen]  Do you want to manipulate STM-7 or VC-4-7c? A STM-7 doesn't exists. You can manipulate a STM-16 or STM-4 as a whole signal, but introducing additonal sub multipelx strucutures like a group of 7 VC-4 within a STM-16  should be avoided. SUpervision and maintenance flows for such new strucutres are not existing, which would screw up your whole network operations and management.

> With you proposal it would
> > be impossible to do so since we can only encode the index of a few
> > time-slots. We really need to encode the index of each possible STM-1/AUG.
> > We go further than a pure G.707.
> > 
> > Concerning your comment about  SDH ADM and cross connect equipment that
> may
> > have separate Higher Order and Lower Order fabrics, please refer to our
> > discussion that occurred two months ago when I explained the nesting of
> LSPs
> > and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to
> > allow different classes of equipments, those that can switch higher orders
> > in the core and those that can switches lower orders in the metro/access.
> > Indeed, you can design any kind of equipment. Circuits are just nested in
> > circuits. That's why the higher part or lower part of a label
> (respectively)
> > can be zeroed to indicate irrelevant (see editorial bug that we discussed,
> > should be corrected in the next version of GMPLS, S=0 is valid).
> > 
> > Kind regards,
> > 
> > Eric
> > 
> > > Note that the latest version of G.707 (10/00) has defined a naming
> > > structure for the AU's, similar to that for the TU's. AUs are now named
> > > according the EDCBA structure (TUs are named according the KLM
> > > structure). It is thus possible to replace the S,U number by the
> > > standardised number E,D,C,B,A. The specification could be:
> > >
> > >       0                   1                   2                   3
> > >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >      |         |  E  |  D  |  C  |  B  |  A  |   K   |   L   |   M   |
> > >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >    For SDH, this is an extension of the numbering scheme defined in
> > >    G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For
> > >    SONET the K field is not significant and must be set to zero.
> > >
> > >    Each letter indicates a possible branch number starting at the parent
> > >    node in the multiplex structure. Branches are considered as numbered
> > >    in increasing order, starting from the top of the multiplexing
> > >    structure. The numbering starts at 1, zero is used to indicate a non-
> > >    significant field.
> > >
> > >    When a field is not significant in a particular context it MUST be
> > >    set to zero when transmitted, and MUST be ignored when received.
> > >
> > >    1. E indicates possible branches of a STM-256/OC786. It is not
> > >       meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12,
> > >       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> > >       E=1 indicates that the STM-256/OC768 is not further sub-divided
> > >       and contains an AU-4-256c/STS768c.
> > >       E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768.
> > >
> > >    2. D indicates possible branches of either an AUG-64 or a
> > > STM-64/OC192.
> > >       It is not meaningful for the cases of STM-16/OC48, STM-4/OC12,
> > >       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> > >       D=1 indicates that the AUG-64 or STM-64/OC192 is not further
> > >       sub-divided and contains an AU-4-64c/STS192c.
> > >       D=2->5 indicates a specific AUG-16 inside the given AUG-64 or> 
> > >       STM-64/OC192.
> > >
> > >    3. C indicates possible bra> nches of either an AUG-16 or a
> > > STM-16/OC48.
> > >       It is not meaningful for the cases of STM-4/OC12, STM-1/OC3,
> > >       STM-0/OC1 multiplexing and must be 0 in that case.
> > >       C=1 indicates that the AUG-16 or STM-16/OC48 is not further
> > >       sub-divided and contains an AU-4-16c/STS48c.
> > >       C=2->5 indicates a specific AUG-4 inside the given AUG-16 or
> > >       STM-16/OC48.
> > >
> > >    4. B indicates possible branches of either an AUG-4 or a STM-4/OC12.
> > >       It is not meaningful for the cases of STM-1/OC3, STM-0/OC1
> > >       multiplexing and must be 0 in that case.
> > >       B=1 indicates that the AUG-4 or STM-4/OC12 is not further
> > >       sub-divided and contains an AU-4-4c/STS12c.
> > >       B=2->5 indicates a specific AUG-1 inside the given AUG-4 or
> > >       STM-4/OC12.
> > >
> > >    5. A indicates possible branches of either an AUG-1 or a STM-1/OC3.
> > >       It is not meaningful for the case of STM-0/OC1 multiplexing
> > >       and must be 0 in that case. A=1 indicates that the AUG-1 or
> > >       STM-1/OC3 is not further sub-divided and contains an
> > >       AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given
> > >       AUG-1 or STM-1/OC3.
> > >
> > >    6. K is only significant for SDH and must be ignored for SONET. It
> > >       indicates a specific branch of a VC-4. K=1 indicates that the
> > >       VC-4 is not further sub-divided and contains a C-4. K=2->4
> > >       indicates a specific TUG-3 inside the VC-4. K is not
> > >       significant when the STM-1 is divided into VC-3s (easy to read
> > >       and test).
> > >
> > >    7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
> > >       is not significant for an unstructured VC-4. L=1 indicates that
> > >       the TUG-3/VC-3/STS-1 SPE is not further sub-divided and
> > >       contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8
> > >       indicates a specific TUG-2/VT Group inside the corresponding
> > >       higher order signal.
> > >
> > >    8. M indicates a specific branch of a TUG-2/VT Group. It is not
> > >       significant for an unstructured VC-4, TUG-3, VC-3 or STS-1
> > >       SPE. M=1 indicates that the TUG-2/VT Group is not further
> > >       sub-divided and contains a VC-2/VT-6. M=2->3 indicates a
> > >       specific VT-3 inside the corresponding VT Group, these values
> > >       MUST NOT be used for SDH since there is no equivalent of VT-3
> > >       with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the
> > >       corresponding TUG-2/VT Group. M=7->10 indicates a specific
> > >       VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried
> > >       within a TU-11. M=11->13 indicates a specific VC-11 inside the
> > >       corresponding TUG-2 carried within a TU-12. Note that M=0 denotes
> > >       an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> > >
> > > Some examples:
> > >   EDCBAKLM
> > > - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0)
> > >            in a STM-16/OC48
> > > - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768
> > > - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0)
> > >            in a STM-256/OC768
> > > - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192
> > > - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal.
> > >
> > > The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3)
> > > structure in a STM-16 could then consist of the following set of labels:
> > >
> > >   EDCBAKLM
> > > - 00210000 AU-4-4c (1,0,0)
> > > - 00321000 AU-4 (2,1,0)
> > > - 00331000 AU-4 (2,2,0)
> > > - 00341000 AU-4 (2,3,0)
> > > - 00351000 AU-4 (2,4,0)
> > > - 00410000 AU-4-4c (3,0,0)
> > > - 00521000 AU-4 (4,1,0)
> > > - 00532000 AU-3 (4,2,1)
> > > - 00533000 AU-3 (4,2,2)
> > > - 00534000 AU-3 (4,2,3)
> > > - 00541000 AU-4 (4,3,0)
> > > - 00551000 AU-4 (4,4,0)> 
> > >
> > > For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering
> > > scheme has the bandwidth implied. There is no need to code this
> > > bandwidth seperately anylonger.
> > >
> > > Question related to the definition of "M":
> > > ------------------------------------------
> > > "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to
> > > transport a VC-11 via a TU-12, I believe that the M range should be
> > > extended with values 11 to 13 as follows:
> > >
> > >    The M encoding is summarized in the following table:
> > >
> > >        M           SDH                             SONET
> > >       ----------------------------------------------------------
> > >        0           unstructured VC-4/VC-3  unstructured STS-1 SPE
> > >        1           VC-2                            VT-6
> > >        2           -                               1st VT-3
> > >        3           -                               2nd VT-3
> > >        4           1st VC-12                       1st VT-2
> > >        5           2nd VC-12                       2nd VT-2
> > >        6           3rd VC-12                       3rd VT-2
> > >        7           1st VC-11 in TU-11              1st VT-1.5
> > >        8           2nd VC-11 in TU-11              2nd VT-1.5
> > >        9           3rd VC-11 in TU-11              3rd VT-1.5
> > >        10          4th VC-11 in TU-11              4th VT-1.5
> > >        11          1st VC-11 in TU-12              -
> > >        12          2nd VC-11 in TU-12              -
> > >        13          3rd VC-11 in TU-12              -
> > >
> > > At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive
> > > monitors) as a VC-12. At the path endpoints however, the VC-11 is
> > > treated as a VC-11.
> > >
> > > Coding the lower order VC (LOVC)/VT signals:
> > > --------------------------------------------
> > > SDH ADM and cross connect equipment may have separate Higher Order and
> > > Lower Order fabrics. This decouples the TU identification from the AU
> > > timeslot and associated physical port. I.e. EDCBAKLM label should be
> > > split into separate EDCBA and KLM labels.
> > >
> > > Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M"
> > > VC4 termination points connected to the LO Fabric.
> > >
> > > The TU timeslots are defined with reference to a VC4 termination point.
> > > The VC4 signal geenrated by a VC4 termination point can be transported
> > > over any of the STM-N signals; there is no predefined relationship,
> > > neither is there a permanent relationship (i.e. it is possible to
> > > re-route the VC-4 without tearing it down, or tearing down the LOVC
> > > connection over it).
> > >
> > > As such, the TU timeslots should be numbered with respect to its VC4
> > > termination point, not with respect to the AU4 timeslot in an STM-N; The
> > > AU4/STM-N part of the label may change over time, whereas the TU link
> > > connection and TU connection point stay the same.
> > > Resulting label should be "<VC4 TP number><K><L><M>".
> > >
> > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > > FABRIC
> > > signal    PORT    timeslots     |  |        Term.      timeslots
> > >                                 |  |        Points     per VC4 TP
> > >                                 |  |
> > > STM-N --- PHY --- "N" AU -------|  |
> > >                   timeslots        |
> > > STM-N --- PHY --- "N" AU ----------|
> > >                   timeslots
> > >
> > >                 Figure 1 - SDH ADM with separate HO and LO Fabrics
> > >
> > > The HO Fabric contains the relation between AU number and VC4 TP number,
> > > as well as between between two AU numbers (case of STM-N - AU - STM-N
> > > connection).
> > >
> > >       <-- phys. <--- EDCBA               <--- VC4       <--- KLM
> > >           port       AU                       TP             TU
> > >           number     number                   number         number> 
> > >
> > > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > > FABRIC
> > > > signal    PORT    timeslots     |  |        Term.      timeslots
> > >                                 |  |        Points     per VC4 TP
> > >
> > >                         Figure 2 - numbering
> > >
> > > Regards,
> > >
> > > Maarten

Delivery-date: Wed, 21 Feb 2001 02:36:01 -0800
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: "Ben Mack-Crane (E-mail)" <[email-masked]>,  "Greg Bernstein (E-mail)" <[email-masked]>, "Bala Rajagopalan (E-mail)" <[email-masked]>, "Debanjan Saha (E-mail)" <[email-masked]>,  "Michael Raftelis (E-mail)" <[email-masked]>,  "Shash Chatterjee (E-mail)" <[email-masked]>,  "Jeff Connell (E-mail)" <[email-masked]>, Vishal Sharma <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] GMPLS enhancements
Date: Wed, 21 Feb 2001 11:33:33 +0100

Hello Maarten,

>It seems that you try to glue toghether two versions of SDH: the
>standardised SDH (G.707) and several proprietary extensions of SDH. Not
>mentioning this explicitly is highly confusing. 

We try to glue to the industry. There are common practices and new practices
(e.g. fast restoration) that are not part of G.707 but that are highly
valuable to control. In addition, we consider SONET as well.

GMPLS is a new control plane, it is not proprietary, it is already a
reference in the industry, it is not being standardized by ITU-T and is not
part of G.707. GMPLS deliberately allows to change the classical behavior of
legacy SDH networks.

If somebody don't like GMPLS, he/she is not obliged to implement it - you
may just ignore GMPLS and use the regular G.707.

> It also suggests
>capabilities to be present which will not be supported in many of the
>SDH networks.

Not supported in SDH networks but supported in GMPLS-SDH networks.

There are also plenty of IP capabilities that are not supported in plenty of
IP networks, etc.
A profile is always welcome.

>In my opinion, you should therefore have separate entities in the LSP
>encoding type for standardised-SDH and proprietary-SDH; and idem for
>SONET. Standardised-SDH and proprietary-SDH equipment may not be able to
>interwork; only if proprietary-SDH equipment is configured as
>standardised-SDH equipment interworking will be possible. 

About the regular (legacy) SDH interoperability, did you try it already ?
That's really not simple because there are plenty of differences between the
implementations. I heard many people saying that legacy SDH interoperability
doesn't exist. 

Restricting the work to a super-minimal set of functionalities that must be
supported by *everybody* doesn't make sense for me. If someone doesn't
implement the capabilities that you want, you don't buy their box, that's
all. 

>For standardised-SDH, the EDCBA number is defined in G.707 (10/00);
>G.707 (10/00) compliant equipment will support AU-4-Xc (X=4,16,64,256)
>timeslots as defined by the EDCBA numbering scheme only.

Our label supports this, and more.

>When we introduced the EDCBA numbering, there were no objections from
>any of the companies represented in ITU-T...

Because this numbering has nothing to do with what can be implemented, it is
just a numbering.

>As there is no intention to make one big label encompassing all
>transport layer signals, every layer should be taken individually. This
>includes MSn, HOVC and LOVC layers.

In the context of GMPLS, I see SDH as being one layer. In that layer we can
request pipes of different sizes and we can do some nesting of pipes, by
using the SDH mulitplexing rules. The fact that you have high order pipes
and low order pipes does not imply that we have two layers for SDH and that
we need separate label definitions as you said.

The proof is that one could decide to allocate a VC-11 and to specify
exactly where it is at each level of the SDH multiplex, i.e. by specifying a
full SUKLM label. In your proposal of having SDH high order labels and low
order labels, we will need to allocate and to return two labels at the same
time, it is in conflict with the principles of GMPLS.

Regards,

Eric

"Mannie, Eric" wrote:
> 
> Hi Maarten,
> 
> I think that you misunderstood some important things about the label,
I'll
> try to clarify in the following.
> 
> First, as you know,
> 
> - All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy,
> "flat" stuff !
> - The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some
specific
> rules: "tree-like" hierarchy.
> - A label identifies the first time-slot (or component) of a particular
> signal, not the full aggregate.
> 
> Consequently, you need separate values to identify the nesting (UKLM) and
> only one value to identify any component in the interleaving (S = index).
> 
> We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S
> field is a simple index, it is flat and there is no reason to represent
> something flat as a hierarchy.
> 
> So there is no reason to use E, D, C, B !
> 
> And yes, one STM-1 can be seen as a time-slot if all STM-1s are
(logically)
> time-division multiplexed. For instance, if you want to transport four
> STM-1s "transparently" you will have four STM-1s, each one with an
> independent overhead. This can be achieved by interleaving the four
> overheads, or by tunneling the overheads. How this transparency is
achieved
> is proprietary in the data plane, different vendors have different
> solutions. At least we would like to have a standardized solution to
request
> and use it in the control plane. I understand your confusion since we
don't
> use a regular SDH/SONET, but their are common tricks that vendors are
> implementing and that are useful to control in a generic way via the GMPLS
> control plane.
> 
> So, we are not 100% glued to G.707. The same apply for
> protection/restoration since we are not tied anymore to only the
> protection/restoration schemes standardized by ITU-T, the fast meshed
> restoration is an example.
> 
> In addition, you want to indicate some fixed concatenation levels
(AU-4-4c,
> AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate
> since there are plenty of other different levels of concatenation, indeed
> all levels are possible, e.g. AU-4-7c. The concatenation is anyway better
> indicated separately, it is orthogonal with a label.
> 
> Think also about contiguous concatenation for example, I could want to
> concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to
> indicate where begins my concatenation. Arbitrary concatenation is
commonly
> used.
> 
> Moreover, we want to be able to manipulate circuits of any size,
> concatenated or not (e.g. an STM-7 or STM-255). With you proposal it would
> be impossible to do so since we can only encode the index of a few
> time-slots. We really need to encode the index of each possible STM-1/AUG.
> We go further than a pure G.707.
> 
> Concerning your comment about  SDH ADM and cross connect equipment that
may
> have separate Higher Order and Lower Order fabrics, please refer to our
> discussion that occurred two months ago when I explained the nesting of
LSPs
> and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to
> allow different classes of equipments, those that can switch higher orders
> in the core and those that can switches lower orders in the metro/access.
> Indeed, you can design any kind of equipment. Circuits are just nested in
> circuits. That's why the higher part or lower part of a label
(respectively)
> can be zeroed to indicate irrelevant (see editorial bug that we discussed,
> should be corrected in the next version of GMPLS, S=0 is valid).
> 
> Kind regards,
> 
> Eric
> 
> > Note that the latest version of G.707 (10/00) has defined a naming
> > structure for the AU's, similar to that for the TU's. AUs are now named
> > according the EDCBA structure (TUs are named according the KLM
> > structure). It is thus possible to replace the S,U number by the
> > standardised number E,D,C,B,A. The specification could be:
> >
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |         |  E  |  D  |  C  |  B  |  A  |   K   |   L   |   M   |
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    For SDH, this is an extension of the numbering scheme defined in
> >    G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For
> >    SONET the K field is not significant and must be set to zero.
> >
> >    Each letter indicates a possible branch number starting at the parent
> >    node in the multiplex structure. Branches are considered as numbered
> >    in increasing order, starting from the top of the multiplexing
> >    structure. The numbering starts at 1, zero is used to indicate a non-
> >    significant field.
> >
> >    When a field is not significant in a particular context it MUST be
> >    set to zero when transmitted, and MUST be ignored when received.
> >
> >    1. E indicates possible branches of a STM-256/OC786. It is not
> >       meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12,
> >       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> >       E=1 indicates that the STM-256/OC768 is not further sub-divided
> >       and contains an AU-4-256c/STS768c.
> >       E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768.
> >
> >    2. D indicates possible branches of either an AUG-64 or a
> > STM-64/OC192.
> >       It is not meaningful for the cases of STM-16/OC48, STM-4/OC12,
> >       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
> >       D=1 indicates that the AUG-64 or STM-64/OC192 is not further
> >       sub-divided and contains an AU-4-64c/STS192c.
> >       D=2->5 indicates a specific AUG-16 inside the given AUG-64 or
> >       STM-64/OC192.
> >
> >    3. C indicates possible branches of either an AUG-16 or a
> > STM-16/OC48.
> >       It is not meaningful for the cases of STM-4/OC12, STM-1/OC3,
> >       STM-0/OC1 multiplexing and must be 0 in that case.
> >       C=1 indicates that the AUG-16 or STM-16/OC48 is not further
> >       sub-divided and contains an AU-4-16c/STS48c.
> >       C=2->5 indicates a specific AUG-4 inside the given AUG-16 or
> >       STM-16/OC48.
> >
> >    4. B indicates possible branches of either an AUG-4 or a STM-4/OC12.
> >       It is not meaningful for the cases of STM-1/OC3, STM-0/OC1
> >       multiplexing and must be 0 in that case.
> >       B=1 indicates that the AUG-4 or STM-4/OC12 is not further
> >       sub-divided and contains an AU-4-4c/STS12c.
> >       B=2->5 indicates a specific AUG-1 inside the given AUG-4 or
> >       STM-4/OC12.
> >
> >    5. A indicates possible branches of either an AUG-1 or a STM-1/OC3.
> >       It is not meaningful for the case of STM-0/OC1 multiplexing
> >       and must be 0 in that case. A=1 indicates that the AUG-1 or
> >       STM-1/OC3 is not further sub-divided and contains an
> >       AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given
> >       AUG-1 or STM-1/OC3.
> >
> >    6. K is only significant for SDH and must be ignored for SONET. It
> >       indicates a specific branch of a VC-4. K=1 indicates that the
> >       VC-4 is not further sub-divided and contains a C-4. K=2->4
> >       indicates a specific TUG-3 inside the VC-4. K is not
> >       significant when the STM-1 is divided into VC-3s (easy to read
> >       and test).
> >
> >    7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
> >       is not significant for an unstructured VC-4. L=1 indicates that
> >       the TUG-3/VC-3/STS-1 SPE is not further sub-divided and
> >       contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8
> >       indicates a specific TUG-2/VT Group inside the corresponding
> >       higher order signal.
> >
> >    8. M indicates a specific branch of a TUG-2/VT Group. It is not
> >       significant for an unstructured VC-4, TUG-3, VC-3 or STS-1
> >       SPE. M=1 indicates that the TUG-2/VT Group is not further
> >       sub-divided and contains a VC-2/VT-6. M=2->3 indicates a
> >       specific VT-3 inside the corresponding VT Group, these values
> >       MUST NOT be used for SDH since there is no equivalent of VT-3
> >       with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the
> >       corresponding TUG-2/VT Group. M=7->10 indicates a specific
> >       VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried
> >       within a TU-11. M=11->13 indicates a specific VC-11 inside the
> >       corresponding TUG-2 carried within a TU-12. Note that M=0 denotes
> >       an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> >
> > Some examples:
> >   EDCBAKLM
> > - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0)
> >            in a STM-16/OC48
> > - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768
> > - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0)
> >            in a STM-256/OC768
> > - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192
> > - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal.
> >
> > The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3)
> > structure in a STM-16 could then consist of the following set of labels:
> >
> >   EDCBAKLM
> > - 00210000 AU-4-4c (1,0,0)
> > - 00321000 AU-4 (2,1,0)
> > - 00331000 AU-4 (2,2,0)
> > - 00341000 AU-4 (2,3,0)
> > - 00351000 AU-4 (2,4,0)
> > - 00410000 AU-4-4c (3,0,0)
> > - 00521000 AU-4 (4,1,0)
> > - 00532000 AU-3 (4,2,1)
> > - 00533000 AU-3 (4,2,2)
> > - 00534000 AU-3 (4,2,3)
> > - 00541000 AU-4 (4,3,0)
> > - 00551000 AU-4 (4,4,0)
> >
> > For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering
> > scheme has the bandwidth implied. There is no need to code this
> > bandwidth seperately anylonger.
> >
> > Question related to the definition of "M":
> > ------------------------------------------
> > "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to
> > transport a VC-11 via a TU-12, I believe that the M range should be
> > extended with values 11 to 13 as follows:
> >
> >    The M encoding is summarized in the following table:
> >
> >        M           SDH                             SONET
> >       ----------------------------------------------------------
> >        0           unstructured VC-4/VC-3  unstructured STS-1 SPE
> >        1           VC-2                            VT-6
> >        2           -                               1st VT-3
> >        3           -                               2nd VT-3
> >        4           1st VC-12                       1st VT-2
> >        5           2nd VC-12                       2nd VT-2
> >        6           3rd VC-12                       3rd VT-2
> >        7           1st VC-11 in TU-11              1st VT-1.5
> >        8           2nd VC-11 in TU-11              2nd VT-1.5
> >        9           3rd VC-11 in TU-11              3rd VT-1.5
> >        10          4th VC-11 in TU-11              4th VT-1.5
> >        11          1st VC-11 in TU-12              -
> >        12          2nd VC-11 in TU-12              -
> >        13          3rd VC-11 in TU-12              -
> >
> > At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive
> > monitors) as a VC-12. At the path endpoints however, the VC-11 is
> > treated as a VC-11.
> >
> > Coding the lower order VC (LOVC)/VT signals:
> > --------------------------------------------
> > SDH ADM and cross connect equipment may have separate Higher Order and
> > Lower Order fabrics. This decouples the TU identification from the AU
> > timeslot and associated physical port. I.e. EDCBAKLM label should be
> > split into separate EDCBA and KLM labels.
> >
> > Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M"
> > VC4 termination points connected to the LO Fabric.
> >
> > The TU timeslots are defined with reference to a VC4 termination point.
> > The VC4 signal geenrated by a VC4 termination point can be transported
> > over any of the STM-N signals; there is no predefined relationship,
> > neither is there a permanent relationship (i.e. it is possible to
> > re-route the VC-4 without tearing it down, or tearing down the LOVC
> > connection over it).
> >
> > As such, the TU timeslots should be numbered with respect to its VC4
> > termination point, not with respect to the AU4 timeslot in an STM-N; The
> > AU4/STM-N part of the label may change over time, whereas the TU link
> > connection and TU connection point stay the same.
> > Resulting label should be "<VC4 TP number><K><L><M>".
> >
> > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > FABRIC
> > signal    PORT    timeslots     |  |        Term.      timeslots
> >                                 |  |        Points     per VC4 TP
> >                                 |  |
> > STM-N --- PHY --- "N" AU -------|  |
> >                   timeslots        |
> > STM-N --- PHY --- "N" AU ----------|
> >                   timeslots
> >
> >                 Figure 1 - SDH ADM with separate HO and LO Fabrics
> >
> > The HO Fabric contains the relation between AU number and VC4 TP number,
> > as well as between between two AU numbers (case of STM-N - AU - STM-N
> > connection).
> >
> >       <-- phys. <--- EDCBA               <--- VC4       <--- KLM
> >           port       AU                       TP             TU
> >           number     number                   number         number
> >
> > STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> > FABRIC
> > signal    PORT    timeslots     |  |        Term.      timeslots
> >                                 |  |        Points     per VC4 TP
> >
> >                         Figure 2 - numbering
> >
> > Regards,
> >
> > Maarten

Delivery-date: Tue, 20 Feb 2001 16:50:05 -0800
Date: Tue, 20 Feb 2001 19:48:17 -0500
To: "Sambasiva R. Mantha" <[email-masked]>
From: "Andre N. Fredette" <[email-masked]>
Subject: Re: Agenda for the IETF
Cc: [email-masked]

http://www.ietf.org/meetings/agenda_50.txt

At 05:02 PM 2/20/2001 -0600, Sambasiva R. Mantha wrote:
>Does anyone have an agenda for the upcoming IETF meeting?
>When will be the ccamp scheduled?
>
>Thanks
>
>Sambu

Delivery-date: Tue, 20 Feb 2001 15:06:38 -0800
Date: Tue, 20 Feb 2001 17:02:03 -0600
From: "Sambasiva R. Mantha" <[email-masked]>
Organization: Alcatel USA 
To: [email-masked]
Subject: Agenda for the IETF

Does anyone have an agenda for the upcoming IETF meeting?
When will be the ccamp scheduled?

Thanks

Sambu

Delivery-date: Mon, 19 Feb 2001 11:15:11 -0800
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: [IP-Optical] GMPLS enhancements
Date: Mon, 19 Feb 2001 20:12:48 +0100

Hi Maarten,

I think that you misunderstood some important things about the label,  I'll
try to clarify in the following.

First, as you know,

- All AUGs ("STM-1s" ) in an STM-N are byte interleaved : no hierarchy,
"flat" stuff !
- The AUs, TUGs, TUs in an AUG ("STM-1") are nested following some specific
rules: "tree-like" hierarchy.
- A label identifies the first time-slot (or component) of a particular
signal, not the full aggregate.

Consequently, you need separate values to identify the nesting (UKLM) and
only one value to identify any component in the interleaving (S = index).

We just need to identify ONE STM-1/AUG in a group of N STM-1s/AUGs. The S
field is a simple index, it is flat and there is no reason to represent
something flat as a hierarchy.

So there is no reason to use E, D, C, B !

And yes, one STM-1 can be seen as a time-slot if all STM-1s are (logically)
time-division multiplexed. For instance, if you want to transport four
STM-1s "transparently" you will have four STM-1s, each one with an
independent overhead. This can be achieved by interleaving the four
overheads, or by tunneling the overheads. How this transparency is achieved
is proprietary in the data plane, different vendors have different
solutions. At least we would like to have a standardized solution to request
and use it in the control plane. I understand your confusion since we don't
use a regular SDH/SONET, but their are common tricks that vendors are
implementing and that are useful to control in a generic way via the GMPLS
control plane.

So, we are not 100% glued to G.707. The same apply for
protection/restoration since we are not tied anymore to only the
protection/restoration schemes standardized by ITU-T, the fast meshed
restoration is an example.

In addition, you want to indicate some fixed concatenation levels (AU-4-4c,
AU-4-16c, AU-4-64c and AU-4-256c) in the label. This is not appropriate
since there are plenty of other different levels of concatenation, indeed
all levels are possible, e.g. AU-4-7c. The concatenation is anyway better
indicated separately, it is orthogonal with a label.

Think also about contiguous concatenation for example, I could want to
concatenate the 3rd, 4th and 5th STM-1/AUG, so I just need to say S=3 to
indicate where begins my concatenation. Arbitrary concatenation is commonly
used.

Moreover, we want to be able to manipulate circuits of any size,
concatenated or not (e.g. an STM-7 or STM-255). With you proposal it would
be impossible to do so since we can only encode the index of a few
time-slots. We really need to encode the index of each possible STM-1/AUG.
We go further than a pure G.707.

Concerning your comment about  SDH ADM and cross connect equipment that may
have separate Higher Order and Lower Order fabrics, please refer to our
discussion that occurred two months ago when I explained the nesting of LSPs
and how it can be applied to SDH/SONET. One of the benefits of GMPLS is to
allow different classes of equipments, those that can switch higher orders
in the core and those that can switches lower orders in the metro/access.
Indeed, you can design any kind of equipment. Circuits are just nested in
circuits. That's why the higher part or lower part of a label (respectively)
can be zeroed to indicate irrelevant (see editorial bug that we discussed,
should be corrected in the next version of GMPLS, S=0 is valid).

Kind regards,

Eric

> Note that the latest version of G.707 (10/00) has defined a naming
> structure for the AU's, similar to that for the TU's. AUs are now named
> according the EDCBA structure (TUs are named according the KLM
> structure). It is thus possible to replace the S,U number by the
> standardised number E,D,C,B,A. The specification could be:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         |  E  |  D  |  C  |  B  |  A  |   K   |   L   |   M   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    For SDH, this is an extension of the numbering scheme defined in
>    G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For
>    SONET the K field is not significant and must be set to zero.
> 
>    Each letter indicates a possible branch number starting at the parent
>    node in the multiplex structure. Branches are considered as numbered
>    in increasing order, starting from the top of the multiplexing
>    structure. The numbering starts at 1, zero is used to indicate a non-
>    significant field.
> 
>    When a field is not significant in a particular context it MUST be
>    set to zero when transmitted, and MUST be ignored when received.
> 
>    1. E indicates possible branches of a STM-256/OC786. It is not
>       meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12,
>       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
>       E=1 indicates that the STM-256/OC768 is not further sub-divided
>       and contains an AU-4-256c/STS768c.
>       E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768.
> 
>    2. D indicates possible branches of either an AUG-64 or a
> STM-64/OC192.
>       It is not meaningful for the cases of STM-16/OC48, STM-4/OC12,
>       STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
>       D=1 indicates that the AUG-64 or STM-64/OC192 is not further
>       sub-divided and contains an AU-4-64c/STS192c.
>       D=2->5 indicates a specific AUG-16 inside the given AUG-64 or
>       STM-64/OC192.
> 
>    3. C indicates possible branches of either an AUG-16 or a
> STM-16/OC48.
>       It is not meaningful for the cases of STM-4/OC12, STM-1/OC3,
>       STM-0/OC1 multiplexing and must be 0 in that case.
>       C=1 indicates that the AUG-16 or STM-16/OC48 is not further
>       sub-divided and contains an AU-4-16c/STS48c.
>       C=2->5 indicates a specific AUG-4 inside the given AUG-16 or
>       STM-16/OC48.
> 
>    4. B indicates possible branches of either an AUG-4 or a STM-4/OC12.
>       It is not meaningful for the cases of STM-1/OC3, STM-0/OC1
>       multiplexing and must be 0 in that case.
>       B=1 indicates that the AUG-4 or STM-4/OC12 is not further
>       sub-divided and contains an AU-4-4c/STS12c.
>       B=2->5 indicates a specific AUG-1 inside the given AUG-4 or
>       STM-4/OC12.
> 
>    5. A indicates possible branches of either an AUG-1 or a STM-1/OC3.
>       It is not meaningful for the case of STM-0/OC1 multiplexing
>       and must be 0 in that case. A=1 indicates that the AUG-1 or
>       STM-1/OC3 is not further sub-divided and contains an
>       AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given
>       AUG-1 or STM-1/OC3.
> 
>    6. K is only significant for SDH and must be ignored for SONET. It
>       indicates a specific branch of a VC-4. K=1 indicates that the
>       VC-4 is not further sub-divided and contains a C-4. K=2->4
>       indicates a specific TUG-3 inside the VC-4. K is not
>       significant when the STM-1 is divided into VC-3s (easy to read
>       and test).
> 
>    7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
>       is not significant for an unstructured VC-4. L=1 indicates that
>       the TUG-3/VC-3/STS-1 SPE is not further sub-divided and
>       contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8
>       indicates a specific TUG-2/VT Group inside the corresponding
>       higher order signal.
> 
>    8. M indicates a specific branch of a TUG-2/VT Group. It is not
>       significant for an unstructured VC-4, TUG-3, VC-3 or STS-1
>       SPE. M=1 indicates that the TUG-2/VT Group is not further
>       sub-divided and contains a VC-2/VT-6. M=2->3 indicates a
>       specific VT-3 inside the corresponding VT Group, these values
>       MUST NOT be used for SDH since there is no equivalent of VT-3
>       with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the
>       corresponding TUG-2/VT Group. M=7->10 indicates a specific
>       VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried
>       within a TU-11. M=11->13 indicates a specific VC-11 inside the
>       corresponding TUG-2 carried within a TU-12. Note that M=0 denotes
>       an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).
> 
> Some examples:
>   EDCBAKLM
> - 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0)
>            in a STM-16/OC48
> - 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768
> - 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0)
>            in a STM-256/OC768
> - 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192
> - 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal.
> 
> The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3)
> structure in a STM-16 could then consist of the following set of labels:
> 
>   EDCBAKLM
> - 00210000 AU-4-4c (1,0,0)
> - 00321000 AU-4 (2,1,0)
> - 00331000 AU-4 (2,2,0)
> - 00341000 AU-4 (2,3,0)
> - 00351000 AU-4 (2,4,0)
> - 00410000 AU-4-4c (3,0,0)
> - 00521000 AU-4 (4,1,0)
> - 00532000 AU-3 (4,2,1)
> - 00533000 AU-3 (4,2,2)
> - 00534000 AU-3 (4,2,3)
> - 00541000 AU-4 (4,3,0)
> - 00551000 AU-4 (4,4,0)
> 
> For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering
> scheme has the bandwidth implied. There is no need to code this
> bandwidth seperately anylonger.
> 
> Question related to the definition of "M":
> ------------------------------------------
> "M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to
> transport a VC-11 via a TU-12, I believe that the M range should be
> extended with values 11 to 13 as follows:
> 
>    The M encoding is summarized in the following table:
> 
>        M           SDH                             SONET
>       ----------------------------------------------------------
>        0           unstructured VC-4/VC-3  unstructured STS-1 SPE
>        1           VC-2                            VT-6
>        2           -                               1st VT-3
>        3           -                               2nd VT-3
>        4           1st VC-12                       1st VT-2
>        5           2nd VC-12                       2nd VT-2
>        6           3rd VC-12                       3rd VT-2
>        7           1st VC-11 in TU-11              1st VT-1.5
>        8           2nd VC-11 in TU-11              2nd VT-1.5
>        9           3rd VC-11 in TU-11              3rd VT-1.5
>        10          4th VC-11 in TU-11              4th VT-1.5
>        11          1st VC-11 in TU-12              -
>        12          2nd VC-11 in TU-12              -
>        13          3rd VC-11 in TU-12              -
> 
> At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive
> monitors) as a VC-12. At the path endpoints however, the VC-11 is
> treated as a VC-11.
> 
> Coding the lower order VC (LOVC)/VT signals:
> --------------------------------------------
> SDH ADM and cross connect equipment may have separate Higher Order and
> Lower Order fabrics. This decouples the TU identification from the AU
> timeslot and associated physical port. I.e. EDCBAKLM label should be
> split into separate EDCBA and KLM labels.
> 
> Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M"
> VC4 termination points connected to the LO Fabric.
> 
> The TU timeslots are defined with reference to a VC4 termination point.
> The VC4 signal geenrated by a VC4 termination point can be transported
> over any of the STM-N signals; there is no predefined relationship,
> neither is there a permanent relationship (i.e. it is possible to
> re-route the VC-4 without tearing it down, or tearing down the LOVC
> connection over it).
> 
> As such, the TU timeslots should be numbered with respect to its VC4
> termination point, not with respect to the AU4 timeslot in an STM-N; The
> AU4/STM-N part of the label may change over time, whereas the TU link
> connection and TU connection point stay the same.
> Resulting label should be "<VC4 TP number><K><L><M>".
> 
> STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> FABRIC
> signal    PORT    timeslots     |  |        Term.      timeslots
>                                 |  |        Points     per VC4 TP
>                                 |  |
> STM-N --- PHY --- "N" AU -------|  |
>                   timeslots        |
> STM-N --- PHY --- "N" AU ----------|
>                   timeslots
> 
>                 Figure 1 - SDH ADM with separate HO and LO Fabrics
> 
> The HO Fabric contains the relation between AU number and VC4 TP number,
> as well as between between two AU numbers (case of STM-N - AU - STM-N
> connection).
> 
>       <-- phys. <--- EDCBA               <--- VC4       <--- KLM
>           port       AU                       TP             TU
>           number     number                   number         number
> 
> STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
> FABRIC
> signal    PORT    timeslots     |  |        Term.      timeslots
>                                 |  |        Points     per VC4 TP
> 
>                         Figure 2 - numbering
> 
> Regards,
> 
> Maarten

Delivery-date: Fri, 16 Feb 2001 11:50:17 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Date: Fri, 16 Feb 2001 20:47:00 +0100
Subject: Interoperability Juniper-Passport

Anybody has done interoperability tests between Juniper and Passport 7000
(Nortel)? Success? What sw releases?
I'm about to do tests in both MPLS level and with Juniper's CCC.

If this lists weren't the right place, where could I get this kind of
information?

I appreciate any input.
Thanks & regards,
Jorge

____________________________________
Jorge Rodriguez-Gabilondo
Telefonica Data
Network Planning and Design
[email-masked]
+34 91 514 4082

_________________________________________________________________
Hemos renovado nuestra web. Esperamos su visita en
http://www.telefonica-data.com

Delivery-date: Mon, 12 Feb 2001 22:34:25 -0800
Date: Tue, 13 Feb 2001 06:32:41 +0000
From: Vijay Gill <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: CCAMP charter and agenda items request for the Minneapolis IETF 

The CCAMP charter and mailing list information are at:

http://www.ietf.org/html.charters/ccamp-charter.html

We've requested a 2.5 hour slot at the Minn. IETF.

Once we get the allocation, the information will be sent to the ccamp
mailing list. Subscription information is in the charter at the URL above.

Please send requests for agenda items to us. Priority will be given to new
individual submissions, and works in progress that are being moved under
CCAMP.

thanks

kireeti and vijay