Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Feb 2001 21:57:01 -0800 Date: Thu, 01 Mar 2001 00:43:08 -0500 From: Ron Bonica Subject: FW: Questions about tunneltrace To: ccamp@ops.ietf.org Cc: erosen@cisco.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Eric, Thanks for your comments. See reply below.... > -----Original Message----- > From: owner-tun-trace@ops.ietf.org > [mailto:owner-tun-trace@ops.ietf.org]On Behalf Of Eric Rosen > Sent: Tuesday, February 27, 2001 12:16 PM > To: tun-trace@ops.ietf.org > 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. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Feb 2001 08:18:02 -0800 Message-ID: <3A9D2467.A318CFD2@ss8.com> Date: Wed, 28 Feb 2001 11:16:39 -0500 From: Dave Walker Reply-To: drwalker@ss8.com MIME-Version: 1.0 To: CCAMP WG Subject: [Fwd: I-D ACTION:draft-walker-ccamp-req-00.txt] Content-Type: multipart/mixed; boundary="------------E20E3769BA07636418E67E55" 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 Received: from loki.ietf.org ([132.151.1.177]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FWY3KK1K; Tue, 27 Feb 2001 09:08:56 -0500 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA23102 for ietf-123-outbound.05@ietf.org; Tue, 27 Feb 2001 08:35:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA22106 for ; Tue, 27 Feb 2001 06:50:48 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03644 for ; Tue, 27 Feb 2001 06:50:48 -0500 (EST) Message-Id: <200102271150.GAA03644@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-walker-ccamp-req-00.txt Date: Tue, 27 Feb 2001 06:50:48 -0500 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010226143128.I-D@ietf.org> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Feb 2001 05:18:34 -0800 Date: Wed, 28 Feb 2001 08:04:00 -0500 From: Ron Bonica Subject: draft-bonica-tunproto-00 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT 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: mailserv@ietf.org. 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Feb 2001 05:18:34 -0800 Date: Wed, 28 Feb 2001 08:03:59 -0500 From: Ron Bonica Subject: draft-bonica-tunneltrace-01 To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT 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: mailserv@ietf.org. 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: ccamp-data@psg.com Delivery-date: Mon, 26 Feb 2001 04:07:56 -0800 Date: Mon, 26 Feb 2001 04:04:06 -0800 (PST) From: Kireeti Kompella Message-Id: <200102261204.EAA17421@kummer.juniper.net> To: ccamp@ops.ietf.org, mrg@nortelnetworks.com 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Feb 2001 02:26:33 -0800 Message-ID: From: "Mark Gibson" To: "'ccamp@ops.ietf.org'" Cc: mpls@UU.NET, te-wg@UU.NET, nbvpn@bbo.com Subject: Date: Mon, 26 Feb 2001 10:22:15 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09FDD.FD4D6330" 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

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

http://search.ietf.org/internet-drafts/draft-gibson-mp= ls-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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Feb 2001 12:41:40 -0800 Message-ID: From: Murali Krishnaswamy To: "'internet-drafts@ietf.org'" Cc: "'ccamp@ops.ietf.org'" , "'ip-optical@lists.bell-labs.com'" , "'mpls@uu.net'" Subject: ID: draft-krishnaswamy-optical-rsvp-extn-00.txt Date: Fri, 23 Feb 2001 15:31:33 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09DD7.9C3C30F6" 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. murali@photuris.com <> ------_=_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= =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= ::=3D [ ]=0A= =0A= =0A= [ ]=0A= [ ]=0A= =0A= [ ]=0A= [ ... ]=0A= =0A= =0A= ::=3D =0A= [ ]=0A= [ ]=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, arodmor@photuris.com=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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Feb 2001 08:18:29 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6A9D@BBY1EXM01> From: Shahram Davari To: "'internet-drafts@ietf.org'" Cc: "'mpls@uu.net'" , "'ccamp@ops.ietf.org'" Subject: New: draft-harrison-mpls-oam-00.txt Date: Fri, 23 Feb 2001 08:15:33 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C09DB3.D919AFE0" 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. <> Thanks, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 <> ------_=_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: neil.2.Harrison@bt.com=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: peter.j.willis@bt.com=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: Shahram_Davari@pmc-sierra.com=20 =20 Ben Mack-Crane=20 Tellabs=20 4951 Indiana Ave Phone: 1-630-512-7255=20 Lisle, IL, USA Email: ben.mack-crane@tellabs.com=20 =20 Hiroshi Ohta=20 NTT=20 Y-709A, 1-1 Hikarino=92ka phone: 81-468-59-8840 =20 Yokosuka-Shi Email: ohta.hiroshi@nslab.ntt.co.jp=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:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C09DB3.D919AFE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Feb 2001 12:41:50 -0800 Message-ID: From: "Mannie, Eric" To: 'Maarten Vissers' Cc: ip-optical@lists.bell-labs.com, "'ccamp@ops.ietf.org'" Subject: RE: [IP-Optical] GMPLS enhancements Date: Thu, 22 Feb 2001 21:39:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Feb 2001 08:48:08 -0800 Message-Id: <200102221644.JAA26807@tcb.net> To: ccamp@ops.ietf.org From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: PWOT Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 pwot-request@ietf.org o Go to http://www.ietf.org/mailman/listinfo/pwot General posts should be directed to pwot@ietf.org. 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Feb 2001 03:32:44 -0800 Message-ID: From: Heiles Juergen To: "'Mannie, Eric'" , "'Maarten Vissers'" Cc: "'ccamp@ops.ietf.org'" , ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS enhancements Date: Thu, 22 Feb 2001 12:28:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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:Eric.Mannie@ebone.com] > 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; 'ccamp@ops.ietf.org'; ip-optical@lists.bell-labs.com > 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 "". > > > > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Feb 2001 02:36:01 -0800 Message-ID: From: "Mannie, Eric" 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 , "'ccamp@ops.ietf.org'" , ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS enhancements Date: Wed, 21 Feb 2001 11:33:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "". > > > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Feb 2001 16:50:05 -0800 Message-Id: <5.0.0.25.2.20010220194750.08227a88@mailbox> Date: Tue, 20 Feb 2001 19:48:17 -0500 To: "Sambasiva R. Mantha" From: "Andre N. Fredette" Subject: Re: Agenda for the IETF Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Feb 2001 15:06:38 -0800 Message-ID: <3A92F76B.F52326D5@usa.alcatel.com> Date: Tue, 20 Feb 2001 17:02:03 -0600 From: "Sambasiva R. Mantha" Organization: Alcatel USA MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Agenda for the IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anyone have an agenda for the upcoming IETF meeting? When will be the ccamp scheduled? Thanks Sambu Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Feb 2001 11:15:11 -0800 Message-ID: From: "Mannie, Eric" To: "'ccamp@ops.ietf.org'" Subject: FW: [IP-Optical] GMPLS enhancements Date: Mon, 19 Feb 2001 20:12:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 "". > > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Feb 2001 11:50:17 -0800 From: jorge.rodriguez@telefonica-data.com To: mpls@UU.NET, ccamp@ops.ietf.org Message-ID: Date: Fri, 16 Feb 2001 20:47:00 +0100 Subject: Interoperability Juniper-Passport Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 jorge.rodriguez@telefonica-data.com +34 91 514 4082 _________________________________________________________________ Hemos renovado nuestra web. Esperamos su visita en http://www.telefonica-data.com Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Feb 2001 22:34:25 -0800 Date: Tue, 13 Feb 2001 06:32:41 +0000 From: Vijay Gill To: , , cc: , , Subject: CCAMP charter and agenda items request for the Minneapolis IETF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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