Subject: RE: Tunnel trace
From: Ron Bonica <[email-masked]>
To: Philip Matthews <[email-masked]>, [email-masked]
Cc: Kireeti Kompella <[email-masked]>
Date: Sun, 01 Apr 2001 00:47:16 -0500

Philip,

Thanks for your comments. Response inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Philip Matthews
> Sent: Tuesday, March 27, 2001 11:34 PM
> To: [email-masked]
> Cc: Kireeti Kompella; Ron Bonica
> Subject: Re: Tunnel trace
>
>
> I gave Ron the feedback privately after the CCAMP meeting
> that it bothered me that the protocol spec required the
> router at the head of the path to store a copy of the packet.
> To me, this opens up lots of possibilities for denial-of-service attacks.
>
> Here is the situation. There is a network with routers A, B, C ...
> and a host H. According to the current draft, the message exchange is
> - H sends a request message to A
> - A saves a copy of the request message, then sends it along the
> tunnel to B
> - B sends a reply to A
> - A forwards the reply to H
>
> If I understood what Ron told me, the reason the message exchange
> is worked this way is because
> B may not be able to reach H directly (think of the VPN case, or
> the case where
> one is using LDP as a BGP replacement in the core). But the Label
> Encap document
> has already told us how to solve that problem: just send the
> reply along the
> original tunnel until it reaches a router that can forward it to H.
>
> According to Ron, the IESG had some objections to this solution.
> I would like to know more about those objections, because this
> seems to be a
> good solution to me.

This was the strategy of the MPLS-ICMP draft. Speaking for myself (and not
necessarily echoing the sentiments of the IESG), I can see the following
problem with this stragegy:

You might be tracing the tunnel because there is a break or loop somewhere
downstream of the point where the traceProbe timed out. In that case, there
is no hope of getting the traceResponse to the tail end of the tunnel.

                                            Ron

>
> - Philip
>
>
> Kireeti Kompella wrote:
> >
> > Is the requirements draft on target?  Is the protocol spec on target?
> > Is either of interest?
> >
> > Kireeti.
>
>
>

Delivery-date: Fri, 30 Mar 2001 17:15:58 -0800
Date: Fri, 30 Mar 2001 17:08:03 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels 
Cc: [email-masked], Kireeti Kompella <[email-masked]>, [email-masked]
To: George Swallow <[email-masked]>

George

The point that I was trying to make is that there is **other** reroute 
work going on within the CCAMP WG and I am not sure about the 
interaction between that work and the draft that is in question. Hence I 
asked **a** question below.

If it turns out that the WG consensus is to do a last call and send the 
draft forward, fine by me. However, the draft may get obsoleted quickly 
once the CCAMP WG concludes the fast reroute work.

Bora

On Friday, March 30, 2001, at 01:04 PM, George Swallow wrote:

>> As far as I understand this draft outlines a mechanism for fast reroute
>> in MPLS networks. With this in mind, shouldn't we delay the last call 
>> on
>> this draft until ther **other** fast reroute related drafts in CCAMP 
>> run
>> to completion?
>>
>> Regards
>>
>> Bora
>
> Bora -
>
> I don't get your point.  Would you suggest that Sonet not specify BLSR
> or closer to home IPoPTR not work on rerouting schemes?  This is a
> technology specific mechanism which has immediate application.  How or
> even if it fits into a larger picture is irrelavant.
>
> ...George
>
>
> ==================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>

Envelope-to: [email-masked]
Delivery-date: Fri, 30 Mar 2001 13:12:19 -0800
Message-Id: <[email-masked]>
To: Bora Akyol <[email-masked]>
cc: George Swallow <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels 
Date: Fri, 30 Mar 2001 16:04:23 -0500
From: George Swallow <[email-masked]>

> As far as I understand this draft outlines a mechanism for fast reroute 
> in MPLS networks. With this in mind, shouldn't we delay the last call on 
> this draft until ther **other** fast reroute related drafts in CCAMP run 
> to completion?
> 
> Regards
> 
> Bora

Bora -

I don't get your point.  Would you suggest that Sonet not specify BLSR
or closer to home IPoPTR not work on rerouting schemes?  This is a
technology specific mechanism which has immediate application.  How or
even if it fits into a larger picture is irrelavant.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Fri, 30 Mar 2001 13:03:06 -0800
Date: Fri, 30 Mar 2001 12:53:48 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels      
Cc: [email-masked], Kireeti Kompella <[email-masked]>, [email-masked]
To: George Swallow <[email-masked]>

As far as I understand this draft outlines a mechanism for fast reroute 
in MPLS networks. With this in mind, shouldn't we delay the last call on 
this draft until ther **other** fast reroute related drafts in CCAMP run 
to completion?

Regards

Bora

On Wednesday, March 28, 2001, at 03:03 PM, George Swallow wrote:

> This message commences a workgroup last call on "RSVP Label Allocation
> for Backup Tunnels" <draft-swallow-rsvp-bypass-label-01.txt>.  This
> draft is informational.  The last call closes April 11, 12 PM GMT.
>
> ...George
>
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>
>

Delivery-date: Fri, 30 Mar 2001 10:00:20 -0800
From: [email-masked]
To: [email-masked], [email-masked],  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 30 Mar 2001 18:56:29 +0100

Frank Hujber [mailto:[email-masked]] asked 30 March 2001 14:43

> Neil,
> 
> Is it your opinion, then, the the equipment providers that 
> predominate the
> IETF are missing the boat vis a vis OA&M?
NH=> The trite answer is 'yes'....but this really need qualifying.  And note
that Shahram Davari, one of the co-authors, works for PMC Sierra who supply
chips to many equipment manufacturers....and he wants to sort this besides
the carriers I mentioned.  We tried (in the principles section of our ID) to
explain what the requirements were....but if I can summarise some of the key
ones it would be as follows:
-	detect/handle all defects in consistent and simple manner;
-	defect detection must not be a function of user-traffic activity;
-	be able to measure avialbility....ideally both directions from a
single-end....and this requires a very clear up-front vision of defect
handling if the result is to be simple/consistent;
-	stop nested stack alarm storms;
-	give simple diagnostic tools to my Ops people
-	give simple perf metrics (esp avail) to my products people so they
can define services and SLAs which my Ops people can then measure;
-	protect customers from any security concerns wrt traffic leaking
in/out of (for example) a VPN and, protect ourselves from any misbilling
assertions (ie when an SLA is broken)....
-	....which I could put more generally as....don't use customers as
the 'detector' mechansism, ie we want to know before the complaint arrives
if possible;

Now if these requirements can be satisfied some other way (than what we have
described) then I am receptive to look at any such proposals.

neil

Delivery-date: Fri, 30 Mar 2001 07:12:16 -0800
Date: Fri, 30 Mar 2001 17:08:49 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: introduction into G.709

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

FYI,

If you would like to have an introduction into the Optical Transport
Network's signal definition (i.e. ITU-T Rec. G.709), you may consider
attending the tutorial session of the Beyond SONET/SDH conference on
April 10 in Paris. For more information, see
http://www.upperside.fr/beyondsdh/beyondsdhpro.htm

Regards,

Maarten

http://www.upperside.fr/beyondsdh/beyondsdhpro.htm
--------------DEB1A8448CE7DC8E5A5F2922
Content-Type: text/html; charset=iso-8859-1;
 name="beyondsdhpro.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="beyondsdhpro.htm"
Content-Base: "http://www.upperside.fr/beyondsdh/beyo
	ndsdhpro.htm"
Content-Location: "http://www.upperside.fr/beyondsdh/beyo
	ndsdhpro.htm"

<HTML> =

<HEAD><TITLE>Beyond Sonet/SDH</TITLE>
<style>
<!--
A:link {  text-decoration: none}
A:visited {  text-decoration: none}
A:hover {  text-decoration: underline}
A:active {  text-decoration: underline}
-->
</style>
</HEAD> =

<BODY BGCOLOR=3D"#FFFFFF" LINK=3D"#000099" VLINK=3D"#000000" ALINK=3D"#33=
33FF" leftmargin=3D"0" topmargin=3D"0">
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" width=3D"589">
  <!-- fwtable fwsrc=3D"Sans titre" fwbase=3D"beyond.jpg" --> =

  <tr valign=3D"top"><!-- row 1 --> =

    <td><img name=3D"beyond_a" src=3D"beyond_a.jpg" width=3D"590" height=3D=
"117" border=3D"0"></td>
  </tr>
  <tr valign=3D"top"><!-- row 2 --> =

    <td><img name=3D"beyond_b" src=3D"beyond_b.jpg" width=3D"590" height=3D=
"125" border=3D"0" usemap=3D"#MapMap"><map name=3D"MapMap"><area shape=3D=
"rect" coords=3D"-14,80,125,122" href=3D"http://www.dynarc.com" target=3D=
"_top"></map></td>
  </tr>
  <tr valign=3D"top"><!-- row 3 --> =

    <td><img name=3D"beyond_c" src=3D"beyond_c.jpg" width=3D"590" height=3D=
"81" border=3D"0" usemap=3D"#MapMap2"><map name=3D"MapMap2"><area shape=3D=
"rect" coords=3D"2,10,120,68" href=3D"http://www.lightscapenet.com" targe=
t=3D"_top"></map></td>
  </tr>
  <!--   This HTML was automatically created with Macromedia Fireworks 3.=
0   --> =

  <!--   http://www.macromedia.com   --> =

</table>
<table width=3D"743" border=3D"0" cellpadding=3D"0" cellspacing=3D"0" hei=
ght=3D"10069">
  <tr>
    <td width=3D"130" valign=3D"top" height=3D"1348"><img src=3D"../fonds=
/filet.gif" width=3D"128" height=3D"45"><br>
      <img src=3D"beyondspon.jpg" width=3D"128" height=3D"439" border=3D"=
0" usemap=3D"#beyond_cMapMap"><map name=3D"beyond_cMapMap"><area shape=3D=
"rect" coords=3D"451,41,584,90" href=3D"http://www.nortelnetworks.com" ta=
rget=3D"_top"><area shape=3D"rect" coords=3D"3,35,123,80" href=3D"http://=
www.nortelnetworks.com" target=3D"_top"></map> =

      <img src=3D"../fonds/filet1k.gif" width=3D"128" height=3D"1569"> <i=
mg src=3D"../fonds/filet1k.gif" width=3D"128" height=3D"1815"><br>
      <img src=3D"../fonds/filet1k.gif" width=3D"128" height=3D"1569"><im=
g src=3D"../fonds/filet1k.gif" width=3D"128" height=3D"2129"><img src=3D"=
=2E./fonds/filet1k.gif" width=3D"128" height=3D"1639"><img src=3D"../fond=
s/filet1k.gif" width=3D"128" height=3D"1072"> =

    </td>
    <td width=3D"613" valign=3D"top" height=3D"1348"> =

      <center>
        <font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D"#9=
93399"><font color=3D"#000000"> =

        <div align=3D"left"> <br>
          <table width=3D"460" border=3D"0">
            <tr valign=3D"top"> =

              <td height=3D"12"> =

                <div align=3D"center"><a href=3D"beyondsdhspon.htm"><img =
src=3D"sponexhi.gif" width=3D"150" height=3D"40" border=3D"0"></a></div>
              </td>
            </tr>
          </table>
          <p><font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b><f=
ont color=3D"#993399">PROGRAM =

            ON LINE</font></b></font><font face=3D"ARIAL" size=3D"1" colo=
r=3D"black"><br>
            <a name=3D"tut"></a> </font> </p>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhreg.htm"> <font s=
ize=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Registr=
ation =

                  on line</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhregf.htm"> <font =
size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Inscri=
ption =

                  (French)</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"../hotels/hotelinfo.htm"><=
font size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">H=
otel =

                  Reservation</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" bgcolor=3D"#FFFFFF" align=3D"center"> =

                <p align=3D"CENTER"><a href=3D"programme.pdf"><font size=3D=
"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Program =

                  in PDF</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"> =

              </td>
            </tr>
          </table>
          <table width=3D"612" border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0">
            <tr> =

              <td width=3D"2">&nbsp;</td>
              <td width=3D"603" bgcolor=3D"#993399" height=3D"20"> =

                <div align=3D"left"><font face=3D"Arial, Helvetica, sans-=
serif" size=3D"2"><b><font color=3D"#FFFFFF">TECHNICAL =

                  TUTORIAL APRIL 10, 2001</font></b></font></div>
              </td>
            </tr>
          </table>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" align=3D=
"left">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER">&nbsp;</td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#tut"><font size=3D"1" fac=
e=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Technical =

                  Tutorial</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#day1"> <font size=3D"1" f=
ace=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 1</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day2"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 2</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day3"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 3</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
            </tr>
          </table>
          <p><br>
            <font color=3D"#993399"><br>
            <b><font size=3D"2">MORNING SESSION</font></b></font><b><font=
 size=3D"2"><br>
            <br>
            <font color=3D"#993399">Optical Networks: new network technol=
ogies in =

            the access and in the metro area</font><br>
            </font></b></p>
          <table width=3D"450" border=3D"0">
            <tr> =

              <td width=3D"76"> =

                <div align=3D"center"><img src=3D"mauriceg.jpg" width=3D"=
60" height=3D"80"></div>
              </td>
              <td width=3D"364"><font face=3D"ARIAL" size=3D3><font face=3D=
"ARIAL" size=3D"1" color=3D"black"><font color=3D"#993399"><font color=3D=
"#000000"><font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> =

                By <b>Maurice GAGNAIRE,</b> <br>
                Associate Professor, <br>
                <i>Ecole Nationale Sup=E9rieure des T=E9l=E9communication=
s, Paris, France</i></font></font></font></font><i><font face=3D"ARIAL" s=
ize=3D3> =

                </font></i></font></td>
            </tr>
          </table>
          <p><font size=3D"2">During these last ten years, fundamental ad=
vances =

            have been obtained in the field of new opto-electronic device=
s. Such =

            advances added to the benefits of the WDM (Wavelength Divisio=
n Multiplexing =

            ) makes the concept of all-optical networking a reality. If t=
oday =

            there is no doubt about the commercial future of all-optical =
technologies =

            in core networks, the suitability of these techniques in the =
access =

            and in the metro remains very discussed. This tutorial aims a=
t presenting =

            a state of the art of these evolutions. <br>
            <br>
            09.00 <u>Welcome and registration<br>
            <br>
            </u>09.30 <b><br>
            1. Introduction</b><br>
            <br>
            - What are the limits and drawbacks of actual IP and ATM over=
 SDH =

            networks.<br>
            - The concept of all-optical networking: definition, objectiv=
es, challenges.<br>
            - From the overlay approach to the peer-to-peer approach: a c=
hallenge =

            for the next ten years. </font></p>
          <p><font size=3D"2"><b>2. Optical Access Networks</b><br>
            <br>
            An overview of the various technologies: xDSL, HFC, PON, WITL=
 etc..<br>
            The limits of xDSL technologies.<br>
            The FSAN initiative for fiber-in-the-loop (FITL).<br>
            The PON technology. <br>
            The physical layer.<br>
            Which MAC protocol for PON systems ?<br>
            The ITU-T G.983 frame.<br>
            The SuperPON technology.<br>
            The physical layer.<br>
            Why WDM is mandatory for SuperPON MAC protocols.<br>
            Which application for SuperPON systems ? <br>
            <br>
            </font><font face=3D"ARIAL" size=3D"1" color=3D"black"><font =
color=3D"#993399"><font color=3D"#000000"><font size=3D"2">10.30 =

            <u>Coffee break </u><br>
            <br>
            11.00 <b><br>
            3. Optical Metropolitan Area Networks </b><br>
            <br>
            Ring-based topologies. <br>
            Star-based topologies. <br>
            The OMFT proposal. <br>
            A MAC protocol for IP DiffServ oriented optical star. <br>
            <br>
            4. Optical Core Network<br>
            <br>
            All-optical switch/routers : the promises of the MEMS technol=
ogy. =

            <br>
            The Optical Transport Network. <br>
            The Digital Wrapper. <br>
            The Routing and Wavelength Allocation problem. <br>
            <br>
            Conclusion <br>
            <br>
            12.00 <u>Lunch </u><br>
            <br>
            <font color=3D"#993399"><b>Digital Wrapper Presentation</b></=
font> <br>
            </font></font></font></font></p>
          <table width=3D"450" border=3D"0">
            <tr> =

              <td width=3D"76"> =

                <div align=3D"center"><img src=3D"maarten.jpg" width=3D"6=
0" height=3D"79"></div>
              </td>
              <td width=3D"364"><font face=3D"ARIAL" size=3D3><font face=3D=
"ARIAL" size=3D"1" color=3D"black"><font color=3D"#993399"><font color=3D=
"#000000"><font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D"=
#993399"><font color=3D"#000000"><font face=3D"ARIAL" size=3D"1" color=3D=
"black"><font color=3D"#993399"><font color=3D"#000000"><font size=3D"2">=
By =

                <b>Maarten VISSERS, </b><br>
                consulting member of technical staff within the optical n=
etworking =

                group,<br>
                <i>Lucent Technologies </i></font></font></font></font></=
font></font></font></font></font></font></font></td>
            </tr>
          </table>
          <br>
          <font size=3D"2">In 1996, the International Telecommunication U=
nion (ITU-T) =

          identified the Optical Transport Network (OTN) as the next gene=
ration =

          transmission hierarchy beyond SDH/SONET to support the growing =
needs =

          for bandwidth. The Gigabit line signals and associated Megabit =
path =

          signals had to be extended into Terabit line capacity and assoc=
iated =

          Gigabit path signals. Wavelength Division Multiplexing (WDM) ha=
s been =

          the enabler to make this step. <br>
          <br>
          14.00<b> Introduction <br>
          <br>

          </b>Initially started as SDH/SONET over WDM line systems, the a=
ddition =

          of cross connects will show the limitations of this initial con=
figuration. =

          STM-N/OC-N signals are designed as section level signals, not a=
s path =

          level signals required in the optical transport network. A new =
path =

          level signal was needed, which would provide overhead/OAM signa=
ls independent =

          of its client signals. <br>
          <br>
          <b>Optical Channel (OCh) Signal Definition </b></font> =

          <p><font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D=
"#993399"><font color=3D"#000000"><font size=3D"2"> =

            A path level signal transported via a new section level signa=
l: the =

            Optical Transport Module (OTM). This multi-wavelength OTM sig=
nal can =

            transport an optical channel signal per wavelength. Optical c=
hannel =

            signals can have bit rates of about 2.5, 10 and 40 Gbit/s at =
the moment.<br>
            <br>
            <b>Digital Wrapper Concept Introduction <br>
            <br>
            </b>A breakthrough in the specification of the optical channe=
l signal. =

            The OCh signal consists of two parts: the Optical channel Dat=
a Unit =

            of level k (ODUk, k=3D1,2,3) and the Optical channel Transpor=
t Unit =

            of level k (OTUk). The ODUk is a digital framed signal consis=
ting =

            of 4 rows by 3824 columns, with the first 16 columns dedicate=
d to =

            ODUk overhead. The ODUk is a network wide transport entity, w=
hich =

            is able to transport client signals, for example STM-N, IP, E=
thernet =

            and ATM, in its payload. <br>
            <br>
            15.00 <u>Coffee break <br>
            <b><br>
            </b></u><b>OTUk & ODUk Role Description </b><br>
            <br>
            The OTUk adapts the ODUk for transport over a specific line s=
ystem. =

            Some OTUk signals will be standardised to support the interco=
nnection =

            of two networks of different operators and/or subnetworks of =
different =

            vendors. Other OTUk signals are proprietary and will be deplo=
yed in =

            vendor specific subnetworks only. The OTN will therefore cons=
ist of =

            vendor and/or operator specific OTN subnetworks, interconnect=
ed via =

            standard Optical Transport Module (OTM-0, OTM-nr) Inter Domai=
n Interfaces =

            (IrDI). The ODUk and OTUk signals provide monitoring capabili=
ties =

            for every stakeholder in the transport domain: customer, serv=
ice provider =

            and network operators. It is as such the first transmission t=
echnology =

            designed for the competitive marketplace, in which the custom=
ers can =

            own the OCh endpoints (and their monitoring capabilities), wh=
ile there =

            are still dedicated monitoring capabilities available for ser=
vice =

            providers and the group of network operators providing the OC=
h connections. =

            <br>
            <br>
            <b>Electrical Processing </b><br>
            <br>
            The electrical processing associated with the transport of OD=
Uk and =

            OTUk signals will not add additional O/E/O points to the netw=
ork. =

            Instead, electrical processing of these signals will be perfo=
rmed =

            at those locations where already O/E/O conversion is required=
: e.g. =

            at network borders and regeneration points defined by the eng=
ineering =

            rules. <br>
            <b><br>
            New ITU-T Recommendations </b><br>
            <br>
            A new set of ITU-T recommendations is emerging, specifying al=
l aspects =

            of this Optical Transport Network: network architecture, stru=
ctures =

            and mappings, equipment, network management, protection switc=
hing, =

            physical layer optical parameters, jitter and wander, error p=
erformance, =

            data communication network and switching. <br>
            <br>
            17.00 <u>End of the session <br>
            <br>
            <br>
            <a name=3D"day1"></a> </u></font></font></font></font></p>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhreg.htm"> <font s=
ize=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Registr=
ation =

                  on line</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhregf.htm"> <font =
size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Inscri=
ption =

                  (French)</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"../hotels/hotelinfo.htm"><=
font size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">H=
otel =

                  Reservation</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" bgcolor=3D"#FFFFFF" align=3D"center"> =

                <p align=3D"CENTER"><a href=3D"programme.pdf"><font size=3D=
"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Program =

                  in PDF</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"> =

              </td>
            </tr>
          </table>
          <table width=3D"612" border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0">
            <tr> =

              <td width=3D"2">&nbsp;</td>
              <td width=3D"603" bgcolor=3D"#993399" height=3D"20"> =

                <div align=3D"left"><font face=3D"Arial, Helvetica, sans-=
serif" size=3D"2"><b><font color=3D"#FFFFFF">CONFERENCE =

                  DAY ONE APRIL 11, 2001</font></b></font></div>
              </td>
            </tr>
          </table>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" align=3D=
"left">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER">&nbsp;</td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#tut"><font size=3D"1" fac=
e=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Technical =

                  Tutorial</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#day1"> <font size=3D"1" f=
ace=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 1</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day2"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 2</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day3"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 3</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
            </tr>
          </table>
          <p><font color=3D"black" face=3D"ARIAL" size=3D"1"><br>
            </font></p>
          <p><font size=3D"2"><br>
            09.00 <u>Welcome and Registration</u><font face=3D"ARIAL" col=
or=3D"black"><font color=3D"#993399"><font color=3D"#000000"><u> =

            <br>
            <br>
            </u>09.30<b><font color=3D"#993399"> Keynote address </font><=
/b><br>
            <br>
            By<b> Arun K.Somani,</b> Nicholas Professor of ECpE <br>
            <br>
            Although SONET has played an important role thus far in the d=
esign =

            and operation of a number of networks around the globe, it is=
 fast =

            approaching its limits. SONET was originally built for transp=
orting =

            64-kbps voice channel traffic. However, it is not exactly sui=
ted for =

            the efficient transport of Internet related data traffic. In =
addition, =

            bandwidth scaling difficulties, quick provisioning and the ne=
ed for =

            service differentiation necessitates the need to leverage tra=
ditional =

            SONET/SDH to newer technologies.<br>
            <br>
            Examining some of the issues that need to considered in the e=
volution =

            of SONET/SDH to newer network technologies:<br>
            <br>
            Technologies that enable dynamic delivery of bandwidth servic=
es.<br>
            </font></font></font></font><font size=3D"2"><font face=3D"AR=
IAL" color=3D"black"><font color=3D"#993399"><font color=3D"#000000"> =

            Technologies that can support data services at multiple data =
rates. =

            <br>
            The ability to satisfy demands for different Quality of Servi=
ce (QoS) =

            <br>
            Technologies that enable IP packets to be injected directly i=
nto the =

            optical ether - IP over WDM. <br>
            WDM: photonic switching and coming of the optical Networks. <=
br>
            WDM: developments in service provider networks. <br>
            <br>
            <b><font color=3D"#993399">EVOLUTION OF THE SDH/SONET TRANSPO=
RT NETWORK =

            </font></b></font></font></font></font></p>
          <p><font size=3D"2">10.00<b> The Optical Transport Network (OTN=
): <br>
            From Pure Transmission Issues to Management Services </b><br>=

            <br>
            The Optical Network is evolving from the point-to-point trans=
mission =

            system to an effective transport layer including networking c=
apabilities. =

            This evolution is mainly driven by the request of flexibility=
 due =

            to very high amount of traffic combined with the high traffic=
 variations =

            in the transport network and permit by the Optical Cross-Conn=
ect. =

            Presenting we will present the different perspectives to intr=
oduce =

            Optical Networking functions and which network architectures =
could =

            be proposed. Discussing the management issues and possible ma=
nagement =

            services. This point is illustrated and argued regarding to t=
he current =

            standardization work in this area (functions related to the O=
ptical =

            Channel within G.709 Recommendation in the ITU-T). <br>
            <br>
            <b>Mathieu Garnot, </b>Optical Network Specification Team Lea=
der,<i> =

            Alcatel Optics Group <br>
            <br>
            </i>10.30 <u>Coffee break <br>
            <br>
            </u>11.00 <b>High bit Rate Sonet/SDH Frames</b><br>
            <br>
            How will 40 Gbit/s SONET/SDH transport systems be deployed in=
 future =

            networks? <br>
            <br>
            - What are the benefits of using a 40 Gbit/s framed transport=
 system?<br>
            - </font><font size=3D"2">How does this technology position i=
tself with =

            DWDM =96 is it too much, too late? <br>
            - What are the technical and operational limits for 40 Gbit/s=
 transmission? =

            <br>
            - What network topologies and architectures can be supported =
by these =

            products? <br>
            - What new functionality will we expect to see on 40 Gbit/s e=
quipment?<br>
            <br>
            </font><font size=3D"2"> How will this help network operators=
 transport =

            different payloads =96 for example between large routers? <br=
>
            <br>
            <b>Jim Everett, </b>SDH Strategist, <i>Marconi</i> <br>
            <br>
            11.30 <b>Beyond Sonet/SDH - a Challenge for Operators </b><br=
>
            <br>
            Efficient transport of IP over optics - a theoretical compari=
son of =

            the different proposed concepts. Experiments with Packet over=
 SDH, =

            Gigabit Ethernet and DPT. <br>
            An agile server layer supporting multiple clients (ASON). <br=
>
            Using MPlambdaS - an integrated approach to transport IP. <br=
>
            Gigabit Ethernet in the access - LAN technology invades the W=
AN.<br>
            <br>
            <b>Adam Kapovits,</b> <i>EURESCOM </i><br>
            <br>
            12.00<b> Evolution of SONET/SDH Networks to METRO Optical Net=
works =

            <br>
            </b><br>
            Describing all current METRO solutions by using valid custome=
r examples =

            from service providers such as British Telecom, COLT Telecom =
and VerizonTelecommunications. =

            <br>
            METRO optical solutions focusing Storage Networking and IP ac=
cess. =

            New Access Networks, xDSL and Wireless local loop currently i=
nstalled =

            and challenging Sonet/SDH networks. <br>
            PON and other optical solutions including WDM offering future=
 proof =

            requirements. Speaker:<br>
            <br>
            <b>Ulrich Mohr, </b>ADVA AG Optical Networking, <i>Strategy D=
irector</i></font><br>
            <br>
            <font size=3D"2">12.30 Lunch<br>
            <br>
            </font><font face=3D"ARIAL" size=3D"1" color=3D"black"><font =
color=3D"#993399"><font color=3D"#993399" size=3D"2"><b>METROPOLITAN =

            NETWORKS: USING SONET/SDH OR NOT</b></font></font></font></p>=

          <div align=3D"left"> =

            <p><font size=3D"2" color=3D"black" face=3D"ARIAL">14.00 <b>D=
escribing the =

              Resilient Packet Ring (RPR) Initiative<br>
              <br>
              </b>Presenting the new initiative to create a new MAC layer=
 standard =

              for resilient packet rings: RPR.<br>
              <br>
              Why are current networking technologies such as SONET/SDH n=
ot optimized =

              to carry IP traffic over Metro MAN? <br>
              Can we change the traditional and expensive layered network=
ing model? =

              <br>
              Why do we have to compile the benefits of several technolog=
ies like =

              Ethernet, SONET/SDH and IP into one new technology? <br>
              What advantages a new MAC will bring to the services provid=
ers? =

              <br>
              How will RPR change the economics of networking services in=
 the =

              MAN? <br>
              The "All Dynamic, All Packet" approach will revolution the =
role =

              of service providers in the MAN. <br>
              Can IP applications take easily advantage of RPR features? =
<br>
              How RPR relates to other technologies such as IP, MPLS, DWD=
M, and =

              10GE? The "reduced complexity" strategy <br>
              Status of IEEE 802.17 standardization and other related bod=
ies <br>
              <br>
              <b>Frederic Thepot,</b> Director EMEA, <i>Dynarc <br>
              <br>
              </i></font><font face=3D"ARIAL" size=3D"1" color=3D"black">=
<font color=3D"#993399"><font color=3D"#000000"><font size=3D"2" color=3D=
"black" face=3D"ARIAL"> =

              14.30 <b>An Introduction to Spatial Reuse Protocol</b></fon=
t></font></font></font><b><font size=3D"2" color=3D"black" face=3D"ARIAL"=
><i> =

              <br>
              <br>
              </i></font></b><font size=3D"2" color=3D"black" face=3D"ARI=
AL">Spatial =

              Reuse Protocol (SRP) is a layer 2 MAC ring technology with =
uses =

              SONET/SDH framing. This technology is used in Metro Area Ne=
twork =

              Architecture for the purpose of extending IP services out t=
o the =

              edge of the network with all the benefits of ring recovery =
and reliability. =

              This Resilient Packet Ring technology is described in the I=
nformational =

              RFC 2892 and is being studied at the IEEE 802.17 Working Gr=
oup. =

              <br>
              <b><br>
              Ritch Dusome, </b>Manager Product Marketing, <i>Cisco Syste=
ms <br>
              <br>
              </i><b><font color=3D"#993399">MPLS/MPLAMBDAS <br>
              <br>
              </font></b><font color=3D"#993399"> <font color=3D"#000000"=
>15.00 <b>Issues =

              in MPLS-based Control of SONET/SDH Optical Networks <br>
              <br>
              </b>Examining the issues involved in enabling MPLS control =
of SONET/SDH =

              networks. Focusing on properties of SONET/SDH networks, the=
ir multiplexing =

              structure, and their protection options, to highlight the t=
ype of =

              information that needs to be propagated within MPLS routing=
 protocols =

              so that it may be used in path computation prior to circuit=
 provisioning. =

              <br>
              Examining the extensions required in the signaling protocol=
s to =

              enable circuit provisioning in these networks, highlighting=
 some =

              new attributes and signal types recently defined in the IET=
F. Finally, =

              discussing some future capabilities, such as new protection=
 capabilities =

              and multilayer circuit setup, that would enable interoperat=
ion with =

              underlying optical networks. <br>
              <br>
              Authors: <br>
              <br>
              <b>Greg Bernstein,</b><i> Ciena </i><br>
              <b>Vishal Sharma,</b> <i>Jasmine Networks </i><br>
              <b>Eric Mannie,<i> </i></b><i>GTS </i><br>
              <b>Ben Mack-Crane,</b> <i>Tellabs </i><br>
              <br>
              Speaker: <br>
              <br>
              <b>Vishal Sharma,</b> </font><font face=3D"ARIAL" size=3D"1=
" color=3D"black"><font color=3D"#993399"><font color=3D"#000000"><font s=
ize=3D"2" color=3D"black" face=3D"ARIAL"><font color=3D"#993399"><font co=
lor=3D"#000000"><i>Jasmine =

              Networks </i></font></font></font></font></font></font><fon=
t color=3D"#000000"> =

              <br>
              <br>
              15.30 <b>Exploring IP Intelligence over an Optical Plane fo=
r the =

              Next Generation Internet </b><br>
              <br>
              WDM Network Management: the MPLS control plane requires up =
to date =

              status info on the physical plant of the network. Automatic=
 provisioning =

              of light paths.<br>
              Dynamic wavelength assignment: For associating MPLS labels =
with =

              lambdas, carriers need dynamic assignment capability. <br>
              Protection and restoration. <br>
              End system identification and network service recovery: In =
order =

              to associate IP labels with lambdas, a discovery procedure =
must =

              be deployed for the MPLS-capable end systems. <br>
              MPLS control channels and signaling protocols: How to distr=
ibute =

              topology state information, monitor physical layer status, =
allocate/de-allocate =

              bandwidth between IP layer and Optical layer. Security: Pro=
tocols =

              and procedures must be established to maintain a secure lin=
k for =

              the control channel, in addition to data channels. <br>
              It is relatively simple for a potential attacker to gain ph=
ysical =

              access to fiber links and carry out service disruption or t=
apping =

              attacks. <br>
              <br>
              Authors: <br>
              <b><br>
              Ashis Khan, </b>VP, Marketing, <i>Maple Optical Systems </i=
><br>
              and <b>Bill Joll,</b> President & CEO, <i>Maple Optical Sys=
tems =

              </i><br>
              <br>
              Speaker: <br>
              <br>
              <b>Ashis Khan,</b> VP, Marketing, <i>Maple Optical Systems =
<br>
              </i><br>
              16.00 <u>Coffee break</u> </font></font></font></p>
          </div>
          <p><font size=3D"2" color=3D"#993399"><b>MANAGEMENT ISSUES</b><=
/font><font size=3D"2"><i><br>
            <br>
            </i>16.30 <b>Service Level Management in Optical Networks </b=
><br>
            <br>
            With the tremendous growth of traffic over the Internet and i=
ncreased =

            diversity of traffic types, optical networking has become the=
 choice =

            for most service providers to handle the volume and meet the =
diverse =

            service requirements of the carried traffic. As the diversity=
 of traffic =

            increases and underlying infrastructure becomes more IP centr=
ic, customers =

            are demanding guaranteed service quality and an accounting fr=
om service =

            providers in form of Service Level Agreements (SLAs) reports.=
 Studying =

            the Service Level (SLA) requirements of the different types o=
f traffic =

            being carried over the optical Internet. Proposing strategies=
 to translate =

            SLA requirements and metrics into network and optical Quality=
 of Service =

            (QoS) parameters.<br>
            <br>
            <b>Mehmet Toy,</b> <i>Axiowave Networks <br>
            <br>
            </i>17.00 <b>Automatic Switched Optical Networks (ASON) - Fun=
ctionality =

            and Architectural Components</b> <br>
            <br>
            Describing the Automatic Switched Optical Network (ASON), an =
optical =

            network solutions that provides client-independent OCh level =
switching, =

            currently being standardised in ITU-T. Focusing on the major =
architectural =

            components such as the control plane of the user network inte=
rface =

            and network node interface, the network topology discovery, t=
raffic =

            engineering and the resilience mechanisms. Clarifying which f=
unctionality =

            can be performed in the automatic switched OTN and which of t=
hem remain =

            in the OTN-client layers. <br>
            <br>
            <b>Roberto Clemente, </b>Project Leader of EURESCOM project F=
ASHION, =

            <i>CSELT <br>
            <br>
            </i>17.30 <u>End of Day One</u><i><br>
            <br>
            <a name=3D"day2"></a> </i></font></p>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhreg.htm"> <font s=
ize=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Registr=
ation =

                  on line</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhregf.htm"> <font =
size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Inscri=
ption =

                  (French)</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"../hotels/hotelinfo.htm"><=
font size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">H=
otel =

                  Reservation</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" bgcolor=3D"#FFFFFF" align=3D"center"> =

                <p align=3D"CENTER"><a href=3D"programme.pdf"><font size=3D=
"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Program =

                  in PDF</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"> =

              </td>
            </tr>
          </table>
          <table width=3D"612" border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0">
            <tr> =

              <td width=3D"2">&nbsp;</td>
              <td width=3D"603" bgcolor=3D"#993399" height=3D"20"> =

                <div align=3D"left"><font face=3D"Arial, Helvetica, sans-=
serif" size=3D"2"><b><font color=3D"#FFFFFF">CONFERENCE =

                  DAY TWO APRIL 12, 2001</font></b></font></div>
              </td>
            </tr>
          </table>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" align=3D=
"left">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER">&nbsp;</td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#tut"><font size=3D"1" fac=
e=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Technical =

                  Tutorial</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#day1"> <font size=3D"1" f=
ace=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 1</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day2"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 2</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day3"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 3</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
            </tr>
          </table>
          <p>&nbsp;</p>
          <p><font size=3D"2">Chairman: <br>
            <br>
            <b>Juan-Manuel Ramos-Gurrion,</b> Director of Broadband Techn=
ology, =

            <i>Bell Canada<br>
            <br>
            </i>09.00 <u>Welcome and coffee</u> <i><br>
            <br>
            </i><font color=3D"#993399"><b>TECHNICAL FOCUS </b></font><i>=
<br>
            <br>
            </i> 09.30<b> Ethernet Metro Networks </b><i><br>
            </i></font></p>
          <table width=3D"450" border=3D"0">
            <tr> =

              <td width=3D"76"> =

                <div align=3D"center"><img src=3D"amirlahat.jpg" width=3D=
"60" height=3D"82"></div>
              </td>
              <td width=3D"364"><font face=3D"ARIAL" size=3D3><font face=3D=
"ARIAL" size=3D"1" color=3D"black"><font color=3D"#993399"><font color=3D=
"#000000"><font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D"=
#993399"><font color=3D"#000000"><font face=3D"ARIAL" size=3D"1" color=3D=
"black"><font color=3D"#993399"><font color=3D"#000000"><font size=3D"2">=
By =

                <b>Amir Lahat,</b> <br>
                Co-founder & Director of Product Management,<br>
                <i>Atrica Inc. </i></font></font></font></font></font></f=
ont></font></font></font></font></font></td>
            </tr>
          </table>
          <p><font size=3D"2"><b>1. Introduction </b><br>
            <br>
            Metro market trends<br>
            The service providers' dilemma <br>
            <br>
            <b>2. Ethernet Technology </b><br>
            <br>
            Current enterprise Ethernet technologies <br>
            New Ethernet developments <br>
            Ethernet technology benefits for service providers <br>
            <br>
            <b>3. Metro Networks Challenges for Ethernet Technology</b><b=
r>
            <br>
            Scalability <br>
            SLA delivery <br>
            Availability <br>
            Maintenance <br>
            Provisioning <br>
            Management <br>
            <br>
            10.30 <u>Coffee break </u><br>
            <br>
            11.00 <br>
            <b>4. Architecture Alternatives for Ethernet Metro Networks</=
b><br>
            <br>
            Ethernet over Sonet <br>
            Ethernet over lambda <br>
            Optical Ethernet <br>
            <br>
            <b>5. Ethernet MANs </b><br>
            <br>
            Q1/2001 Industry Snapshot <br>
            Service providers <br>
            Equipment vendors<br>
            <br>
            <b>6. Summary</b><br>
            <br>
            12.00 <u>Lunch</u> <br>
            <br>
            <font color=3D"#993399"><b>GIGABIT ETHERNET SESSIONS<br>
            <br>
            </b> <font color=3D"#000000">14.00</font><b> Keynote address<=
br>
            <br>
            <font color=3D"#000000">The New Frontiers of Gigabit Ethernet=
 </font><br>
            <br>
            </b><font color=3D"#000000">Identifying the drivers for Gigab=
it Ethernet =

            implementation over the last mile. Emphasising on the additio=
nal services =

            GbE will enable and the corresponding revenue streams those n=
ew services =

            will generate. Examining traditional access methods and deliv=
ery technologies, =

            highlighting their inability to provide the services that wil=
l proliferate =

            on the Next Generation Network. Demonstrating how GbE will pr=
ovide =

            the reliability, security and restoration needed to deliver t=
hese =

            new services. Illustrating how GbE delivered to commercial an=
d residential =

            subscribers alike will impact education, medicine, business, =
entertainment =

            and daily life. How Fiber-to-the-Subscriber and Gigabit Ether=
net provide =

            the revolutionary solutions to help broadband access provider=
s capture =

            significant market share in the exploding global broadband ma=
rketplace. =

            Gigabit Ethernet over fiber will be positioned as the definin=
g solution =

            that will satisfy the vast demand in bandwidth, scalability a=
nd longevity, =

            particularly in the last mile. Summarizing findings from a nu=
mber =

            of industry analyst firms providing market projections for re=
sidential =

            GbE gateway access hardware over the next several years. <br>=

            <br>
            <b>Bernard Daines, </b>President & CEO, <i>World Wide Packets=
 </i><br>
            </font><b><font color=3D"#000000"><br>
            <font color=3D"#993399">SONET/SDH GbE<br>
            CONVERGENCE CONDITIONS<br>
            <br>
            </font></font></b><font color=3D"#000000">14.30 <b>The intere=
st of Ethernet =

            Interfaces in SDH/SONET Equipment </b><br>
            <br>
            With the exploding demand of data traffic, carriers are looki=
ng for =

            new solution to integrate IP services in the transmission net=
work. =

            In fact some of the specific features of routers, such as map=
ping =

            and bridging could be handled in a more efficient way by tran=
smission =

            equipment. <br>
            Describing the features that the operator are looking for in =
order =

            to deliver IP / Ethernet services. <br>
            Demonstrating how depending of the rate (10 to 1000 Mbs), the=
 quality =

            of service, the security, the distance or the protection mech=
anism, =

            SONET / SDH equipment can offer rich & various solutions. =B7=
<br>
            <b><br>
            Olivier de Nomazy,</b> Marketing Broadband , <i>Nortel Networ=
ks </i></font><b><font color=3D"#000000"><font color=3D"#993399"><br>
            <br>
            </font></font></b><font color=3D"#000000"><font color=3D"#993=
399"> <font color=3D"#000000">15.00 =

            </font></font></font><b><font color=3D"#000000">Determining h=
ow SDH =

            and GbE are Likely to Converge in Next Generation Metro and A=
ccess =

            Networks</font></b><font color=3D"#000000"><br>
            <br>
            Analysing the evolution of network architectures and services=
 to determine =

            the future role of transmission technologies. Extending the Q=
uality =

            of Service benefits of SDH into Ethernet packet networks. Exa=
mining =

            the practicalities of deploying GbE over SDH and determining =
its suitability =

            for managing the delivery of circuit switch traffic in the MA=
N Examining =

            the potential convergence of GbE and SDH in both the access a=
nd metropolitan =

            area network. Will SDH continue to be a viable option after 1=
0Gigabit =

            Ethernet is mature. <br>
            <b><br>
            Edward Hopkins,</b> European Product Marketing, <i>Extreme Ne=
tworks</i> =

            </font><b><font color=3D"#000000"><br>
            <br>
            </font></b><font color=3D"#000000">15.30</font><b><font color=
=3D"#000000"> =

            Gigabit Ethernet Network and Applications <br>
            <br>
            </font></b><font color=3D"#000000">Benefits of embedding carr=
ier-class =

            Ethernet within the SDH/WDM infrastructure. <br>
            Discussing the difference between enterprise based Ethernet i=
nfrastructure =

            and carrier-class Ethernet infrastructure. <br>
            Bringing carrier-class reliability to the Ethernet <br>
            Offering carrier-class security for the IP traffic <br>
            Seamless integration between the Ethernet management and the =
SDH/WDM =

            management <br>
            Generating additional revenue source from the Ethernet/SDH/WD=
M infrastructure =

            <br>
            <br>
            <b>Mr. Yoav Valadarsky,</b> Associate VP, <i>Lightscape Netwo=
rks</i> =

            </font><b><font color=3D"#000000"><br>
            </font></b></font> <font color=3D"#000000"><br>
            </font>16.00 <b>Implementing Ethernet over Sonet (EOS) for th=
e Delivery =

            of Carrier Class <br>
            Transparent LAN Services</b><br>
            <br>
            Describing a study conducted in 1998 for the City of Toronto.=
 Based =

            on the demand for Ethernet based services, Bell Nexxia looked=
 for =

            alternate solutions for delivering TLS services at 10Mbps, 10=
0Mbps =

            and 1000Mbps data rates. This study demonstrates the cost eff=
ectiveness =

            and scalability of Ethernet over Sonet when compared to alter=
nate =

            architectures based on ATM. Describing the access and core al=
ternatives =

            to collect and carry large amounts of Ethernet traffic from c=
ustomer =

            premises. <br>
            <br>
            The challenge is to maintain security levels by means of segm=
entation =

            of broadcasts domains using VLAN trunking mechanisms over the=
 high =

            capacity Ethernet over SONET (EOS) rings. Customers will be a=
llowed =

            to tag frames using 802.1p bits for CoS identification before=
 entering =

            into the network. The access and the core networks will be ab=
le to =

            interpret and forward these frames without changing their int=
rinsic =

            characteristics. A set of CoS translations will be required t=
o meet =

            the levels of service across different layer 2 infrastructure=
s in =

            the access and the core. Detailing an end-to-end architecture=
 model =

            to build the EOS infrastructure. An example of the first comm=
ercial =

            implementation of EOS in Canada will be provided along with t=
he service =

            levels agreements and management infrastructure. <br>
            <br>
            Juan Manuel Ramos, Associate Director of Broadband Technology=
, Bell =

            Nexxia. <br>
            <br>
            16.30 <u>Coffee break </u><i><br>
            <br>
            </i>17.00<font color=3D"#993399"><b> DEBATE</b></font> <br>
            <br>
            Gigabit Ethernet versus SONET/SDH: </font><font face=3D"ARIAL=
" size=3D"1" color=3D"black"><font color=3D"#993399"><font color=3D"#0000=
00"><font size=3D"2">a</font></font></font></font><font size=3D"2">dvanta=
ges =

            and drawbacks <br>
            GbE in the WAN <br>
            The impact of 10 GE <br>
            Technical issues <br>
            <br>
            Chairman: <br>
            <br>
            <b>Juan-Manuel Ramos-Gurrion,</b> Director of Broadband Techn=
ology, =

            <i>Bell Canada</i><br>
            <br>
            Participants:<br>
            <br>
            <b>Bernard Daines, </b>President & CEO, <i>World Wide Packets=
 </i><br>
            <b>Dr. Gilad Goren,</b> Founder, Chief Executive Officer, <i>=
Native =

            Networks Technologies</i><br>
            <b>Anand Parikh,</b> Founder and Vice President of Product Ma=
rketing =

            and Business Development, <i>Appian Communications</i> <br>
            </font><font face=3D"ARIAL" size=3D"1" color=3D"black"><font =
color=3D"#993399"><font color=3D"#000000"><font size=3D"2"><b>Fran&ccedil=
;ois =

            Tournesac, </b>Director of Business Development, <i>Atrica, I=
nc. </i></font></font></font></font><font size=3D"2"><br>
            <b>Edward Hopkins,</b> European Product Marketing, <i>Extreme=
 Networks</i><br>
            <b>Nan Chen,</b> Director of Product Managent & Product Marke=
ting, =

            <i>Force 10 Networks</i><br>
            <b>Mr. Yoav Valadarsky,</b> Associate VP, <i>Lightscape Netwo=
rks <br>
            <br>
            </i>18.00 <u>End of Day Two </u><i><br>
            <br>
            <a name=3D"day3"></a> </i></font></p>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhreg.htm"> <font s=
ize=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Registr=
ation =

                  on line</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"beyondsdhregf.htm"> <font =
size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Inscri=
ption =

                  (French)</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"../hotels/hotelinfo.htm"><=
font size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">H=
otel =

                  Reservation</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" bgcolor=3D"#FFFFFF" align=3D"center"> =

                <p align=3D"CENTER"><a href=3D"programme%20intersip.pdf">=
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" color=3D"#993399">=
Program =

                  in PDF</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"> =

              </td>
            </tr>
          </table>
          <table width=3D"612" border=3D"0" cellpadding=3D"0" cellspacing=
=3D"0">
            <tr> =

              <td width=3D"2">&nbsp;</td>
              <td width=3D"603" bgcolor=3D"#993399" height=3D"20"> =

                <div align=3D"left"><font face=3D"Arial, Helvetica, sans-=
serif" size=3D"2"><b><font color=3D"#FFFFFF">CONFERENCE =

                  DAY THREE APRIL 13, 2001</font></b></font></div>
              </td>
            </tr>
          </table>
          <table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" align=3D=
"left">
            <tr background=3D"/congress/transparent.gif"> =

              <td width=3D"100" align=3D"CENTER">&nbsp;</td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#tut"><font size=3D"1" fac=
e=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Technical =

                  Tutorial</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"center"><a href=3D"#day1"> <font size=3D"1" f=
ace=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 1</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day2"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 2</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
              <td width=3D"100" align=3D"CENTER"> =

                <p align=3D"CENTER"><a href=3D"#day3"><font size=3D"1" fa=
ce=3D"Arial, Helvetica, sans-serif" color=3D"#993399">Conference =

                  Day 3</font></a> =

              </td>
              <td width=3D"1" bgcolor=3D"#993399"><img src=3D"transparent=
=2Egif" width=3D"1" height=3D"1" align=3D"BOTTOM" border=3D"0"></td>
            </tr>
          </table>
          <p>&nbsp;</p>
          <p><font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D=
"#993399"><font color=3D"#000000"><font size=3D"2">Chairman: =

            <br>
            <br>
            <b>Juan-Manuel Ramos-Gurrion,</b> Director of Broadband Techn=
ology, =

            <i>Bell Canada</i></font></font></font></font><font size=3D"2=
"><br>
            <br>
            09.00<i> </i><u>Welcome and Coffee</u><i><br>
            </i><br>
            <b><font color=3D"#993399">ETHERNET OPTICAL ACCESS</font></b>=
 <br>
            <br>
            09.30 <b>Evolving Optical Access Networks </b><br>
            <br>
            Describing new "last mile" intelligent optical edge alternati=
ves to =

            existing TDM-based equipment that provide a migration path to=
 packet-based =

            optical networking, service-aware and highly tunable new acce=
ss technologies =

            that can scale as businesses add users and applications.<br>
            <br>
            <b>Anand Parikh, </b>Founder and Vice President of Product Ma=
rketing =

            and Business Development, <br>
            <i>Appian Communications<br>
            <br>
            </i>10.00 <b>Spanning Enterprise LAN over the Public WAN</b><=
br>
            <br>
            Although SONET has limitations in addressing the new data-cen=
tric =

            world, it still possesses formidable features - protection, t=
raffic =

            engineering concepts, OAM and more - that were not duplicated=
 in the =

            enterprise networks. A new way of delivering services to larg=
e customer =

            base must intelligently include these features coupled with t=
he simplicity =

            of Ethernet, and a robust network wide management. Describing=
 APT, =

            a novel net-wise statistical multiplexing technology, that pr=
ovides =

            flow isolation and guaranteed QoS per customer on the public =
network. =

            These multiplexing algorithms are implemented in Silicon and =
are capable =

            of managing thousands of queues providing QoS for thousands o=
f aggregated =

            flows.<br>
            <br>
            <b>Dr. Gilad Goren, </b>Founder, Chief Executive Officer, <i>=
Native =

            Networks Technologies <br>
            <br>
            </i>10.30 <b>Integrated Network Management for Optical Ethern=
et </b><br>
            <br>
            Discussing how optical Ethernet technology can now incorporat=
e a cost-effective, =

            integrated network management system when used for Metropolit=
an Area =

            Networking. Showing how advancements in optical Ethernet tech=
nology =

            now allow for end-to-end provisioning to ensure the quality o=
f service =

            customers pay for with Service Level Agreements (SLA) and how=
 this =

            technology can provide a reliable network management infrastr=
ucture =

            that rivals that of SONET/SDH.<br>
            <br>
            <b>Fran&ccedil;ois Tournesac, </b>Director of Business Develo=
pment, =

            <i>Atrica, Inc.</i><b> </b><i><br>
            <br>
            </i>11.00 <u>Coffee break </u><br>
            <br>
            11.30 </font><font face=3D"ARIAL" size=3D"1" color=3D"black">=
<font color=3D"#993399"><font color=3D"#000000"><font size=3D"2"><b>Servi=
ce =

            Provisioning Capability </b><br>
            <br>
            Outlining new and more promising optical access solutions tha=
t allow =

            optical capacity now being deployed to be software provisione=
d across =

            multiple services, each with distinct service levels, and wit=
h the =

            ability for both guaranteed rates and burstable rates to be r=
emotely =

            adjusted by software command. How these soft-tunable services=
 could =

            be provisioned in minutes instead of weeks, with no need for =
high-cost =

            truck rolls or on-site upgrades. In addition, such services w=
ould =

            provide the ability to immediately deliver exactly the amount=
 of bandwidth =

            where it is needed. <br>
            <br>
            <b>Anand Parikh, </b>Founder and Vice President of Product Ma=
rketing =

            and Business Development, <i><br>
            Appian Communications </i></font></font></font></font><font s=
ize=3D"2"><i><br>
            <b><font color=3D"#993399"><br>
            </font></b></i><font color=3D"#993399"><b>TECHNICAL ISSUES</b=
></font> =

            <br>
            <br>
            12.00 <b>Robustness and Scalability Issues</b> <br>
            <br>
            Focusing on the recent developments in technology that have m=
ade Ethernet =

            a powerful and cost-effective solution for the wide area netw=
ork and =

            the steps which are being taken to infuse it with the robustn=
ess, =

            scalability and manageability required for large-scale deploy=
ment =

            in carrier networks.<br>
            <br>
            </font><font face=3D"ARIAL" size=3D"1" color=3D"black"><font =
color=3D"#993399"><font color=3D"#000000"><font size=3D"2"><b>Fran&ccedil=
;ois =

            Tournesac, </b>Director of Business Development, <i>Atrica, I=
nc.</i><b> =

            </b><i></i></font></font></font></font><font size=3D"2"><br>
            <br>
            12.30 <u>Lunch <br>
            <br>
            </u>14.00 <b>Voice and VoIP in LAN/MAN Gigabit Networks</b><b=
r>
            <br>
            Explaining why voice is different than data, the challenge of=
 implementing =

            voice on high performance MAN/LAN networks and why VoIP is th=
e right =

            technology to do so. Detailing the different parts of a VoIP =
infrastructure, =

            how they compare with the existing PABX system and what type =
of migration =

            strategies are available for VoIP implementation. <br>
            <br>
            <b>Peter Derks, </b><i>VP Sales & Marketing of QuesCom S.A. <=
br>
            <br>
            </i><b><font color=3D"#993399">10 GIGABIT ETHERNET FUTURE <br=
>
            <br>
            </font></b>14.30 <b>10 Gigabit Ethernet Standard Description<=
/b><br>
            <br>
            Discussing the new 10 Gigabit Ethernet standard. Detailing ho=
w 10GbE =

            will penetrate the MAN and WAN,and hence facilitate new busin=
ess models =

            to continue the drive for higher bandwidth and higher revenue=
 opportunities =

            at the edge of the net.<br>
            <br>
            <b>Bernard Daines, </b>President & CEO, <i>World Wide Packets=
 </i><br>
            <br>
            15.00 <u>Coffee break <br>
            <br>
            </u>15.30 Examining the Business Case for Deploying Gigabit E=
thernet =

            and the Significance of 10 Gigabit Ethernet in Metropolitan A=
reas<br>
            <br>
            Identifying the need to migrate towards new metropolitan netw=
ork technology, =

            such as Gigabit Ethernet and 10 Gigabit Ethernet.<br>
            Examining the appropriateness of deploying Ethernet as a tran=
smission =

            technology in metropolitan areas in terms of: <br>
            <br>
            Scalability <br>
            Cost effectiveness<br>
            Provisioning services<br>
            Transporting broadband traffic<br>
            Resilience and reliability<br>
            <b><br>
            Edward Hopkins, </b>European Product Marketing, <i>Extreme Ne=
tworks<br>
            <br>
            </i>16.00 <b>Carrier and Service Provider Applications </b><b=
r>
            <br>
            Dark fiber interconnect. <br>
            DWDM connectivity. <br>
            Ethernet aggregation. <br>
            IEE.3ae 10 GE task force. <br>
            10 GE Alliance objectivs.<br>
            Main PMD proposals.<br>
            WIS layer SONET framing. <br>
            WAN rate adaptation.<br>
            <br>
            <b>Nan Chen,</b> Director of Product Managent & Product Marke=
ting, =

            <i>Force 10 Networks </i><br>
            <br>
            16.30 <u>End of the conference</u> </font> </p>
        </div>
        </font></font></font> =

      </center>
      <div align=3D"center"><a href=3D"beyondsdhspon.htm"><br>
        <br>
        <img src=3D"sponexhi.gif" width=3D"150" height=3D"40" border=3D"0=
"></a><font face=3D"ARIAL" size=3D"1" color=3D"black"><font color=3D"#993=
399"><font color=3D"#000000"><font face=3D"ARIAL" size=3D"1"><br>
        <a href=3D"/index.html" target=3D"_top"><font color=3D"#0000FF"><=
br>
        <br>
        <br>
        HOME PAGE</font></a> <br>
        </font></font></font></font><br>
      </div>
      <center>
        <font size=3D"1" face=3D"ARIAL"><b>Upper Side</b><br>
        54 rue du Fbg St Antoine<br>
        75012 Paris - France<br>
        Telephone: 33 1 53 46 63 80<br>
        Fax: 33 1 53 46 63 85<br>
        <a href=3D"http://www.upperside.fr"><font color=3D"#0000FF">www.u=
pperside.fr</font></a><br>
        <a href=3D"mailto:[email-masked]"><font color=3D"#0000FF">info=
@upperside.fr<br>
        </font></a></font> <font face=3D"ARIAL" size=3D"1"><br>
        <br>
        &copy; Upper Side. January 2001</font><font face=3D"ARIAL" size=3D=
2 color=3D"black"><font size=3D"3"><font color=3D"#993399" size=3D"2"><fo=
nt color=3D"#000000"> =

        </font></font><b><font color=3D"#993399"> </font></b></font> </fo=
nt><font face=3D"ARIAL" size=3D1></font> =

      </center>
    </td>
  </tr>
</table>
<br>
<BR>
</BODY> =

</HTML> =

--------------DEB1A8448CE7DC8E5A5F2922
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DEB1A8448CE7DC8E5A5F2922--

Delivery-date: Fri, 30 Mar 2001 05:41:11 -0800
From: "Frank Hujber" <[email-masked]>
To: <[email-masked]>,	<[email-masked]>,	<[email-masked]>
Cc: <[email-masked]>,	<[email-masked]>,	<[email-masked]>,	<[email-masked]>
Subject: Re: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 30 Mar 2001 08:42:38 -0500

Neil,

Is it your opinion, then, the the equipment providers that predominate the
IETF are missing the boat vis a vis OA&M?

Frank Hujber
[email-masked]
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, March 30, 2001 1:09 AM
Subject: RE: Please Clarify Doubts regarding RGT & RNC

> Ben....see below neil
>
> > Jeurgen,
> >
> > A few more comments below,
> > and a question for carriers, if any are listening.
> >
> > Regards,
> > Ben
> >
> > Heiles Juergen wrote:
> > >
> > > Ben,
> > >
> > > see my comments below.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > > > -----Original Message-----
> > > > From: Ben Mack-Crane [SMTP:[email-masked]]
> > > > Sent: Wednesday, March 28, 2001 5:36 PM
> > > > To:   Heiles Juergen
> > > > Cc:   sambasiva mantha; Vishal Sharma; 'manoj juneja';
> > [email-masked]
> > > > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > > Hello Jeurgen,
> > > >
> > > > I think we are in general agreement.  A few
> > clarifications are included below.
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > Heiles Juergen wrote:
> > > > >
> > > > > Ben,
> > > > >
> > > > > the characteristic information and the trail
> > termination function are directly related as the
> > > > > characteristic infromation is generated/terminated by
> > the trail termination function. So I don't
> > > > > see a need for additional trail termination information.
> > > >
> > > > Some trail termination information is not currently
> > included in the signaling,
> > > > and probably should
> > > > be.  For example, the Trail Trace Identifier should be
> > configured the same way
> > > > at source and sink,
> > > > but is not currently in the signaling spec (but certainly
> > not as part of Signal
> > > > Type).
> > >         [Juergen Heiles]  Configuration of the trail trace
> > is an open issue I agree.
> > > Draft-harrison-mpls-oam-00.txt proposes a trail trace
> > (Connectivity verification CV OAM packets)
> > > for MPLS and suggest that the configuration of the trace is
> > done via LSP signaling at LSP set-up.
> >
> > In the MPLS (packet) case we have proposed that a standard
> > convention be used to
> > create the TTSI (trail trace ID) from the Router ID of the
> > ingress LSR and the local
> > ID for the LSP on that LSR.  We think this information is
> > already in the signaling
> > messages (although the local ID should be 4 octets and only 2
> > are allocated in the
> > current signaling drafts).  If this is also acceptable for
> > SONET/SDH trails, that
> > would solve the problem, but I don't know if that is true.
> > Carriers may have other
> > conventions already in use for assigning trail trace IDs and
> > may not want to change.
> >
> > Do you have any insight into this?
> >
> > Would any carriers like to comment?
> NH=>Carriers usually pay attention to differentiating the OAM required for
> the user and control planes......since in CO networks they are usually
> disjoint in both function and routing (and hence the failure modes are
> different).  This is normal practice.  Hence, you will find in
technologies
> like SDH/Sonet, where carriers have had a large hand in the specification,
> that these issues are attended to from the outset.  So there are trail
trace
> functions to ensure correct connectivity in SDH/Sonet.  There are not
trail
> trail functions in plain MPLS which, ironically, has a richer set of
> potential failure modes.  The ID that you/I/others put together addresses
> this and, perhaps just as importantly, goes on the demonstrate how we can
> simply measure availability......which is perhaps *the* most important
perf
> metric for any carrier to measure.  This latter point is not trivial, and
I
> suspect many have not grasped the importance of what we put in this ID.
We
> also look at consequent actions.....again something that is normally 2nd
> nature for carriers in order to protect customers, stop alarm storms and
> give Ops people useful diagnostic tools.  So, in summary, we don't need
our
> CV flow for SDH/Sonet but we do for plain MPLS.
> >
> > >
> > > > Also Payload
> > > > ID should be set properly, but this can be inferred
> > (translated) from the GPID
> > > > that is signalled.
> > >         [Juergen Heiles]  The payload ID/Signal lable is
> > not configurable as such, it is fixed
> > > defined by the adaptation function. What is configurable is
> > the type of adaptation function itself
> > > if the network element provides this flexibility. As you
> > noted the GPID is equivalent to the payload
> > > ID/signal label.
> > >         It should be noted that the LSP isn't necessarily
> > used to setup a network connection between
> > > two trail terminations. I can also be used to setup
> > sub-network connections. In the later case you
> > > don't know the payload ID and specific GPID.
> >
> > Good point.  In fact, it may be that for many SNC cases the
> > GPID will be set to 0 (unknown)
> > since the client layer may not be known (and is not relevant).
> >
> > >
> > > >  I don't know if there is other trail termination info
> > that should be signalled
> > > > between the endpoints.
> > > > Do you have any thoughts on this?
> > >         [Juergen Heiles]  Tandem Connection Monitoring and
> > setup of the TCM level might need some
> > > thoughts. Do we want to setup TCM automatically via LSP
> > signaling at all?
> >
> > It would be reasonable to support signaled setup of TCM,
> > particularly in the case of SNCs.
> > For example, if the service is an SNC across a carrier's
> > network, TCM may be required
> > to monitor the SLA for that SNC (the extent of the service
> > provided by the carrier).
> NH=> TCM is very useful and should be considered as necessary *when* the
> layered technology has a fixed hierarchy, eg ATM, SDH/Sonet.  This is not
> true for plain MPLS (and this is one of its strengths).  If a carrier
wants
> to measure a 'SNC' that carrier can simply set up a new lower server LSP
for
> the SNC partition considered......however, unless it has proper OAM (and
can
> differentiate up/down-states to correctly assign availability and QoS
metric
> measurements) then its real value is diluted.  This ability (to set up
> arbitrary levels of LSP trails) is also a very useful feature for prot-sw
> for carriers....but again requires decent OAM.
> <snipped to end NH>
>
>

Delivery-date: Fri, 30 Mar 2001 05:00:13 -0800
From: Heiles Juergen <[email-masked]>
To: "'Ben Mack-Crane'" <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: sambasiva mantha <[email-masked]>, Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 30 Mar 2001 14:53:48 +0200

Ben,

this is the second part of my response on RGT&RNC coding.

regards

Juergen

> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:[email-masked]]
> Sent:	Thursday, March 29, 2001 6:26 PM
> To:	Heiles Juergen
> Cc:	sambasiva mantha; Vishal Sharma; 'manoj juneja'; [email-masked]
> Subject:	Re: Please Clarify Doubts regarding RGT & RNC
> 
	<snip>
>  > > > I agree with you that the RTG field combines different types of information. Contiguous concateantion
> > > > is a characteristic information and should be coded into the signal type. As I mentioned before a
> > > > STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> > > > STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
> > >
> > > We have gone back and forth on this topic.  Originally STS-3c was a concatenated
> > > signal, then we
> > > changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
> > > and now it is
> > > coded as a concatenated signal once more.  The current view is that it is
> > > cleaner to code it
> > > as a concatenated signal.  In either case I think we will have some way to code
> > > the same signal
> > > in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
> > > concatenated type
> > > as well.)
> >         [Juergen Heiles]  You might use a dedicated field for contiguous concatenation,
> > but mixing it with bundling and virtual cocnatenation in one field has strange results. For example
> > you cannot setup a virtual concatenation of N STS-3c with a common route, while you can setup virtual
> > concatenation of N VC-4. I assume that virtual concatenation of STS-3c as it is equivalent to virtual
> > concatenation of VC-4s.
> 
> We had some discussion of this among authors of GMPLS SONET/SDH signaling last week
> and one possibility considered was that STS-3c groups could be identified by applying
> the following convention:  If the signal type is OC-3 with no transparency (that is, no
> line or section overhead included) AND some grouping type selected (e.g., virtual concatenation)
> THEN one would assume the path structure was STS-3c.  This would also apply to other
> standard contiguous concatenated rates (STS-12c, VC4-4c, etc.).  What do you think?
	[Juergen Heiles]  It looks strange to me to introduce into the first version of a specification that is still in draft state already a work around. As we still have the opportunity we should fix it properly. Is there any reason no to do it?????
	In the current definitin OC-N path group means all STS-1/Xc-SPE in the OC-N. How would you address a virtual concatenation of 2 STS-3c-SPE  in a OC-192 signal or virtual concatenation of arbitary contiguous concatenation?
	Another concern is interworking between the US (SONET) and Europe (SDH). If we have a common coding for STS-3c and VC-4 virtual concatenation at least for the RTG&RNC field it makes live easier. If we introduce signal types for contiguous cocnatenation we could even use the same code for STS-3c and VC-4, STS-12c and VC-4-4c and so on. Only the LSP encoding would be different.
	Virtual and contiguous concatenation are different. As Neil mentioned contiguous cocnatenation is a layer network of its own and as such needs its own signal type or a n additional contiguous concatenation field to the signal type.
	Virtual cocnatenation is not a network layer of its own. Only the end notes have to care about it. You are limitng yourself from the beginning by combining the two.
	So why not do it straight forward. Add signal types for STS-1-Nc-SPE and VC-4-Nc or add a number field to the STS-1-3c-SPE and VC-4 signal type which defines the number of contiguous concatenated signals. As discussed before you don't need a special indication for arbitary concatenation.
	Bundling for virtual concatenation and othe pruposes has its own field.

>  > 
> There is also a proposal to add another level of grouping by adding a multiplier field.
> This would indicate that some number of grouped signal types is requested (e.g., a number
> of arbitrary contiguous concatenated signals -- say 10xSTS-7c).  This is essentiually
> a second level of grouping, with no type or routing constraint differentiation.
	[Juergen Heiles]  What does this mean that the second level of grouping doesn't require common routing?

> <snip>

Delivery-date: Fri, 30 Mar 2001 04:27:52 -0800
From: Heiles Juergen <[email-masked]>
To: "'Ben Mack-Crane'" <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: sambasiva mantha <[email-masked]>, Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: trail trace (was: Please Clarify Doubts regarding RGT & RNC)
Date: Fri, 30 Mar 2001 14:21:01 +0200

Ben,

I have split my response into e-mails with different subjects.
This one is on trail trace.

Regards

Juergen

> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:[email-masked]]
> Sent:	Thursday, March 29, 2001 6:26 PM
> To:	Heiles Juergen
> Cc:	sambasiva mantha; Vishal Sharma; 'manoj juneja'; [email-masked]
> Subject:	Re: Please Clarify Doubts regarding RGT & RNC
> 
	<snip>>
> > > > the characteristic information and the trail termination function are directly related as the
> > > > characteristic infromation is generated/terminated by the trail termination function. So I don't
> > > > see a need for additional trail termination information.
> > >
> > > Some trail termination information is not currently included in the signaling,
> > > and probably should
> > > be.  For example, the Trail Trace Identifier should be configured the same way
> > > at source and sink,
> > > but is not currently in the signaling spec (but certainly not as part of Signal
> > > Type).
> >         [Juergen Heiles]  Configuration of the trail trace is an open issue I agree.
> > Draft-harrison-mpls-oam-00.txt proposes a trail trace (Connectivity verification CV OAM packets)
> > for MPLS and suggest that the configuration of the trace is done via LSP signaling at LSP set-up.
> 
> In the MPLS (packet) case we have proposed that a standard convention be used to
> create the TTSI (trail trace ID) from the Router ID of the ingress LSR and the local
> ID for the LSP on that LSR.  We think this information is already in the signaling
> messages (although the local ID should be 4 octets and only 2 are allocated in the
> current signaling drafts).  If this is also acceptable for SONET/SDH trails, that
> would solve the problem, but I don't know if that is true.  Carriers may have other
> conventions already in use for assigning trail trace IDs and may not want to change.
> 
> Do you have any insight into this?  
	[Juergen Heiles]  In SDH we have a 16 or optinal 64 byte trace. The 16 byte trace is the soruce address which normally cnsits of country code, operator code and a unique number within the operator domain. For the OTN we use a 64 byte trace.  It consist of a 16 byte source and 16 byte destination address (country code + operator code + unique number). The remianing 32 bytes are availablefor operator specific purposes. 

> Would any carriers like to comment?
> 
> 
	<snip> 

Delivery-date: Fri, 30 Mar 2001 00:20:53 -0800
From: Jonathan Lang <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Andre Fredette <[email-masked]>
Cc: [email-masked]
Subject: RE: LMP vs. NTIP vs. "funiculus"
Date: Fri, 30 Mar 2001 00:12:55 -0800

Maarten,
  I agree that reproduction of capabilities already present is a bad idea.
LMP was initially designed to address issues between GMPLS peers (OXC-OXC,
router-OXC, etc.) that were not addressed with current mechanisms.  There
was a joint proposal in the OIF (oif2000.254; I can send it if you don't
have access to the OIF website) identifying the need for an OXC-WDM
interface (we called it an OLI for Optical Layer Interface) and proposing
that LMP be extended for this purpose.  The lmp-wdm draft that was submitted
to the IETF last December began outlining some simple extensions to LMP for
the OXC-WDM interface.  So, looking again at your diagram (slightly modified
to remove the single channel limitation in case of wavebands), this is how
LMP-WDM fits in.

      parallel      DWDM        parallel    parallel       DWDM
     interfaces     line       interfaces  interfaces      line
  OXC ======= DWDM ------- DWDM ======= OXC ======== DWDM------- DWDM ==
   \ \_______/    \_______/    \_______// \ \________/    \_______/
    \ lmp-wdm       OSC        lmp-wdm /   \ lmp-wdm        OSC
     \________________________________/     \_______________________
                    LMP                                 LMP

>From our prospective, it seems easy to make a few extensions to an existing
protocol (LMP) to meet these requirements.

Thanks,
Jonathan

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 10:49 PM
> To: Andre Fredette
> Cc: [email-masked]
> Subject: Re: LMP vs. NTIP vs. "funiculus"
> 
> 
> Andre,
> 
> I have in general problems with reproduction of capabilities already
> present in e.g. a transport plane. Seems a waste of time to me.
> But when the transport plane doesn't have the capabilites an action
> is required. Either extend the transport plane or rebuild the 
> mechanism
> in the management or control plane.
> 
> I prefer to extend the transport plane when this is a simple extension
> of a common practice which is already present in other parts of it; it
> maintains amongst others the performance. For the OTN this is 
> definitely
> the case, and therefore there would be no need for an LMP in the OTN.
> 
> Other technologies like Ethernet and also SONET/SDH are not 
> designed to
> support PXCs (optical fabric equipment). That's why we are 
> building the
> OTN. I assume that is why LMP is being defined. But as we 
> will "extend"
> the transport plane for OTN, it may be well possible to use the same
> extension for SONET/SDH and Ethernet...
> 
> For OTN (and also SONET/SDH/Ethernet) signal transport through a DWDM
> line we already defined a supervisory channel (the OSC) as an extra
> wavelenght in the DWDM line. The extension proposal for the OTN (and
> perhaps also to be used for SDH/SONET/Ethernet) is to add another
> supervisory channel between the DWDM terminal and the PXC 
> (also referred
> to as OXC). I have called this the "funiculus" (which is another word
> for umbilical cord). In a WDM network, you will have the OSC and the
> funiculus located as follows: 
> 
>      parallel      DWDM        parallel    parallel       DWDM
>       single       line         single      single        line
>      channel                   channel     channel
>     interfaces                interfaces  interfaces
>  OXC ======= DWDM ------- DWDM ======= OXC ======== DWDM 
> ------- DWDM ==
>     \_______/    \_______/    \_______/   \________/    \_______/
>     funiculus       OSC       funiculus   funiculus        OSC
> 
> OSC is between two DWDM line terminals, whereas the funiculus 
> is between
> optical fabric (OXC) and DWDM line terminal (tributary side).
> 
> OSC is on a wavelenght within the fiber, whereas the funiculus is on a
> dedicated fiber or copper wire/coax cable.
> 
> The funiculus is part of the new (multi-fiber) OTM-LF interface I am
> proposing (see Q.11/15 correspondence document cd-otmlf01 
> (attached) or
> at http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.doc
> http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.pdf ).
> 
> Regards,
> 
> Maarten
> 
> 
> Andre Fredette wrote:
> > 
> > Maarten,
> > 
> > You make some good points.  I believe that one of the 
> objectives of LMP is
> > to reproduce the capabilities currently present in the 
> transport plane.  As
> > you point out, with the advent of PXCs, some of the functionality
> > traditionally handled with in-band SONET signalling needs 
> to be exchanged
> > in another way.  We will also be dealing with other 
> technologies, such as
> > Ethernet, that does not have built-in overhead.
> > 
> > Also, as we move towards distributed control of multi-vendor optical
> > networks via GMPLS, open protocols are needed between the 
> different nodes
> > for exchanging the necessary information.  In addition to the fault
> > handling capabilities you describe, I think we need 
> discovery capabilities
> > that will reduce the required manual configuration.
> > 
> > I believe there are two questions at hand:
> > (1)  Which protocol should be used to exchange the information in
> > GMPLS-controlled networks?, and
> > (2)  What information needs to be exchanged?
> > 
> > The mpls, and now ccamp, working groups in the IETF have 
> been working on
> > LMP to solve question (1) for the past year.  Unless there is an
> > overwhelming need to create a new protocol, I think we 
> should stick with
> > LMP (and I haven't even seen an underwhelming reason to switch :-).
> > 
> > Question (2) could use some additional discussion as it pertains to
> > transport systems.  We have a proposal in 
> draft-fredette-lmp-wdm-01.  Some
> > good ideas exist in draft-sahay-ccamp-ntip-00, and you've 
> made some good
> > points in your note.
> > 
> > Andre
> > 
> > At 01:05 PM 3/26/2001 +0200, Maarten Vissers wrote:
> > >When looking at the LMP work I am have the impression at 
> the moment that
> > >it is partly duplicating capabilities already present in 
> the transport
> > >plane.
> 

Delivery-date: Thu, 29 Mar 2001 22:58:58 -0800
Cc: [email-masked]
Date: Fri, 30 Mar 2001 08:49:18 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Andre Fredette <[email-masked]>
Original-CC: [email-masked]
Subject: Re: LMP vs. NTIP vs. "funiculus"

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

Andre,

I have in general problems with reproduction of capabilities already
present in e.g. a transport plane. Seems a waste of time to me.
But when the transport plane doesn't have the capabilites an action
is required. Either extend the transport plane or rebuild the mechanism
in the management or control plane.

I prefer to extend the transport plane when this is a simple extension
of a common practice which is already present in other parts of it; it
maintains amongst others the performance. For the OTN this is definitely
the case, and therefore there would be no need for an LMP in the OTN.

Other technologies like Ethernet and also SONET/SDH are not designed to
support PXCs (optical fabric equipment). That's why we are building the
OTN. I assume that is why LMP is being defined. But as we will "extend"
the transport plane for OTN, it may be well possible to use the same
extension for SONET/SDH and Ethernet...

For OTN (and also SONET/SDH/Ethernet) signal transport through a DWDM
line we already defined a supervisory channel (the OSC) as an extra
wavelenght in the DWDM line. The extension proposal for the OTN (and
perhaps also to be used for SDH/SONET/Ethernet) is to add another
supervisory channel between the DWDM terminal and the PXC (also referred
to as OXC). I have called this the "funiculus" (which is another word
for umbilical cord). In a WDM network, you will have the OSC and the
funiculus located as follows: 

     parallel      DWDM        parallel    parallel       DWDM
      single       line         single      single        line
     channel                   channel     channel
    interfaces                interfaces  interfaces
 OXC ======= DWDM ------- DWDM ======= OXC ======== DWDM ------- DWDM ==
    \_______/    \_______/    \_______/   \________/    \_______/
    funiculus       OSC       funiculus   funiculus        OSC

OSC is between two DWDM line terminals, whereas the funiculus is between
optical fabric (OXC) and DWDM line terminal (tributary side).

OSC is on a wavelenght within the fiber, whereas the funiculus is on a
dedicated fiber or copper wire/coax cable.

The funiculus is part of the new (multi-fiber) OTM-LF interface I am
proposing (see Q.11/15 correspondence document cd-otmlf01 (attached) or
at http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q11/0102/cd/cd-otmlf01.pdf ).

Regards,

Maarten

Andre Fredette wrote:
> 
> Maarten,
> 
> You make some good points.  I believe that one of the objectives of LMP is
> to reproduce the capabilities currently present in the transport plane.  As
> you point out, with the advent of PXCs, some of the functionality
> traditionally handled with in-band SONET signalling needs to be exchanged
> in another way.  We will also be dealing with other technologies, such as
> Ethernet, that does not have built-in overhead.
> 
> Also, as we move towards distributed control of multi-vendor optical
> networks via GMPLS, open protocols are needed between the different nodes
> for exchanging the necessary information.  In addition to the fault
> handling capabilities you describe, I think we need discovery capabilities
> that will reduce the required manual configuration.
> 
> I believe there are two questions at hand:
> (1)  Which protocol should be used to exchange the information in
> GMPLS-controlled networks?, and
> (2)  What information needs to be exchanged?
> 
> The mpls, and now ccamp, working groups in the IETF have been working on
> LMP to solve question (1) for the past year.  Unless there is an
> overwhelming need to create a new protocol, I think we should stick with
> LMP (and I haven't even seen an underwhelming reason to switch :-).
> 
> Question (2) could use some additional discussion as it pertains to
> transport systems.  We have a proposal in draft-fredette-lmp-wdm-01.  Some
> good ideas exist in draft-sahay-ccamp-ntip-00, and you've made some good
> points in your note.
> 
> Andre
> 
> At 01:05 PM 3/26/2001 +0200, Maarten Vissers wrote:
> >When looking at the LMP work I am have the impression at the moment that
> >it is partly duplicating capabilities already present in the transport
> >plane.
--------------F9B1A2F86CF530BD38B6F266
Content-Type: application/msword;
 name="cd-otmlf01.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="cd-otmlf01.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGAAAAAAA
AAAAEAAAGgAAAAEAAAD+////AAAAABcAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////

--------------F9B1A2F86CF530BD38B6F266
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------F9B1A2F86CF530BD38B6F266--

Delivery-date: Thu, 29 Mar 2001 22:24:58 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 30 Mar 2001 07:09:47 +0100

Ben....see below neil

> Jeurgen,
> 
> A few more comments below, 
> and a question for carriers, if any are listening.
> 
> Regards,
> Ben
> 
> Heiles Juergen wrote:
> > 
> > Ben,
> > 
> > see my comments below.
> > 
> > Regards
> > 
> > Juergen
> > 
> > > -----Original Message-----
> > > From: Ben Mack-Crane [SMTP:[email-masked]]
> > > Sent: Wednesday, March 28, 2001 5:36 PM
> > > To:   Heiles Juergen
> > > Cc:   sambasiva mantha; Vishal Sharma; 'manoj juneja'; 
> [email-masked]
> > > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Hello Jeurgen,
> > >
> > > I think we are in general agreement.  A few 
> clarifications are included below.
> > >
> > > Regards,
> > > Ben
> > >
> > > Heiles Juergen wrote:
> > > >
> > > > Ben,
> > > >
> > > > the characteristic information and the trail 
> termination function are directly related as the
> > > > characteristic infromation is generated/terminated by 
> the trail termination function. So I don't
> > > > see a need for additional trail termination information.
> > >
> > > Some trail termination information is not currently 
> included in the signaling,
> > > and probably should
> > > be.  For example, the Trail Trace Identifier should be 
> configured the same way
> > > at source and sink,
> > > but is not currently in the signaling spec (but certainly 
> not as part of Signal
> > > Type).
> >         [Juergen Heiles]  Configuration of the trail trace 
> is an open issue I agree.
> > Draft-harrison-mpls-oam-00.txt proposes a trail trace 
> (Connectivity verification CV OAM packets)
> > for MPLS and suggest that the configuration of the trace is 
> done via LSP signaling at LSP set-up.
> 
> In the MPLS (packet) case we have proposed that a standard 
> convention be used to
> create the TTSI (trail trace ID) from the Router ID of the 
> ingress LSR and the local
> ID for the LSP on that LSR.  We think this information is 
> already in the signaling
> messages (although the local ID should be 4 octets and only 2 
> are allocated in the
> current signaling drafts).  If this is also acceptable for 
> SONET/SDH trails, that
> would solve the problem, but I don't know if that is true.  
> Carriers may have other
> conventions already in use for assigning trail trace IDs and 
> may not want to change.
> 
> Do you have any insight into this?  
> 
> Would any carriers like to comment?
NH=>Carriers usually pay attention to differentiating the OAM required for
the user and control planes......since in CO networks they are usually
disjoint in both function and routing (and hence the failure modes are
different).  This is normal practice.  Hence, you will find in technologies
like SDH/Sonet, where carriers have had a large hand in the specification,
that these issues are attended to from the outset.  So there are trail trace
functions to ensure correct connectivity in SDH/Sonet.  There are not trail
trail functions in plain MPLS which, ironically, has a richer set of
potential failure modes.  The ID that you/I/others put together addresses
this and, perhaps just as importantly, goes on the demonstrate how we can
simply measure availability......which is perhaps *the* most important perf
metric for any carrier to measure.  This latter point is not trivial, and I
suspect many have not grasped the importance of what we put in this ID.  We
also look at consequent actions.....again something that is normally 2nd
nature for carriers in order to protect customers, stop alarm storms and
give Ops people useful diagnostic tools.  So, in summary, we don't need our
CV flow for SDH/Sonet but we do for plain MPLS.
> 
> > 
> > > Also Payload
> > > ID should be set properly, but this can be inferred 
> (translated) from the GPID
> > > that is signalled.
> >         [Juergen Heiles]  The payload ID/Signal lable is 
> not configurable as such, it is fixed
> > defined by the adaptation function. What is configurable is 
> the type of adaptation function itself
> > if the network element provides this flexibility. As you 
> noted the GPID is equivalent to the payload
> > ID/signal label.
> >         It should be noted that the LSP isn't necessarily 
> used to setup a network connection between
> > two trail terminations. I can also be used to setup 
> sub-network connections. In the later case you
> > don't know the payload ID and specific GPID.
> 
> Good point.  In fact, it may be that for many SNC cases the 
> GPID will be set to 0 (unknown)
> since the client layer may not be known (and is not relevant).
> 
> > 
> > >  I don't know if there is other trail termination info 
> that should be signalled
> > > between the endpoints.
> > > Do you have any thoughts on this?
> >         [Juergen Heiles]  Tandem Connection Monitoring and 
> setup of the TCM level might need some
> > thoughts. Do we want to setup TCM automatically via LSP 
> signaling at all?
> 
> It would be reasonable to support signaled setup of TCM, 
> particularly in the case of SNCs.
> For example, if the service is an SNC across a carrier's 
> network, TCM may be required
> to monitor the SLA for that SNC (the extent of the service 
> provided by the carrier).
NH=> TCM is very useful and should be considered as necessary *when* the
layered technology has a fixed hierarchy, eg ATM, SDH/Sonet.  This is not
true for plain MPLS (and this is one of its strengths).  If a carrier wants
to measure a 'SNC' that carrier can simply set up a new lower server LSP for
the SNC partition considered......however, unless it has proper OAM (and can
differentiate up/down-states to correctly assign availability and QoS metric
measurements) then its real value is diluted.  This ability (to set up
arbitrary levels of LSP trails) is also a very useful feature for prot-sw
for carriers....but again requires decent OAM.
<snipped to end NH> 

Delivery-date: Thu, 29 Mar 2001 08:52:08 -0800
Date: Thu, 29 Mar 2001 10:25:32 -0600
From: Ben Mack-Crane <[email-masked]>
To: Heiles Juergen <[email-masked]>
CC: sambasiva mantha <[email-masked]>, Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Jeurgen,

A few more comments below, 
and a question for carriers, if any are listening.

Regards,
Ben

Heiles Juergen wrote:
> 
> Ben,
> 
> see my comments below.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [SMTP:[email-masked]]
> > Sent: Wednesday, March 28, 2001 5:36 PM
> > To:   Heiles Juergen
> > Cc:   sambasiva mantha; Vishal Sharma; 'manoj juneja'; [email-masked]
> > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> >
> > Hello Jeurgen,
> >
> > I think we are in general agreement.  A few clarifications are included below.
> >
> > Regards,
> > Ben
> >
> > Heiles Juergen wrote:
> > >
> > > Ben,
> > >
> > > the characteristic information and the trail termination function are directly related as the
> > > characteristic infromation is generated/terminated by the trail termination function. So I don't
> > > see a need for additional trail termination information.
> >
> > Some trail termination information is not currently included in the signaling,
> > and probably should
> > be.  For example, the Trail Trace Identifier should be configured the same way
> > at source and sink,
> > but is not currently in the signaling spec (but certainly not as part of Signal
> > Type).
>         [Juergen Heiles]  Configuration of the trail trace is an open issue I agree.
> Draft-harrison-mpls-oam-00.txt proposes a trail trace (Connectivity verification CV OAM packets)
> for MPLS and suggest that the configuration of the trace is done via LSP signaling at LSP set-up.

In the MPLS (packet) case we have proposed that a standard convention be used to
create the TTSI (trail trace ID) from the Router ID of the ingress LSR and the local
ID for the LSP on that LSR.  We think this information is already in the signaling
messages (although the local ID should be 4 octets and only 2 are allocated in the
current signaling drafts).  If this is also acceptable for SONET/SDH trails, that
would solve the problem, but I don't know if that is true.  Carriers may have other
conventions already in use for assigning trail trace IDs and may not want to change.

Do you have any insight into this?  

Would any carriers like to comment?

> 
> > Also Payload
> > ID should be set properly, but this can be inferred (translated) from the GPID
> > that is signalled.
>         [Juergen Heiles]  The payload ID/Signal lable is not configurable as such, it is fixed
> defined by the adaptation function. What is configurable is the type of adaptation function itself
> if the network element provides this flexibility. As you noted the GPID is equivalent to the payload
> ID/signal label.
>         It should be noted that the LSP isn't necessarily used to setup a network connection between
> two trail terminations. I can also be used to setup sub-network connections. In the later case you
> don't know the payload ID and specific GPID.

Good point.  In fact, it may be that for many SNC cases the GPID will be set to 0 (unknown)
since the client layer may not be known (and is not relevant).

> 
> >  I don't know if there is other trail termination info that should be signalled
> > between the endpoints.
> > Do you have any thoughts on this?
>         [Juergen Heiles]  Tandem Connection Monitoring and setup of the TCM level might need some
> thoughts. Do we want to setup TCM automatically via LSP signaling at all?

It would be reasonable to support signaled setup of TCM, particularly in the case of SNCs.
For example, if the service is an SNC across a carrier's network, TCM may be required
to monitor the SLA for that SNC (the extent of the service provided by the carrier).

> 
> > >
> > > I agree with you that the RTG field combines different types of information. Contiguous concateantion
> > > is a characteristic information and should be coded into the signal type. As I mentioned before a
> > > STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> > > STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
> >
> > We have gone back and forth on this topic.  Originally STS-3c was a concatenated
> > signal, then we
> > changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
> > and now it is
> > coded as a concatenated signal once more.  The current view is that it is
> > cleaner to code it
> > as a concatenated signal.  In either case I think we will have some way to code
> > the same signal
> > in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
> > concatenated type
> > as well.)
>         [Juergen Heiles]  You might use a dedicated field for contiguous concatenation,
> but mixing it with bundling and virtual cocnatenation in one field has strange results. For example
> you cannot setup a virtual concatenation of N STS-3c with a common route, while you can setup virtual
> concatenation of N VC-4. I assume that virtual concatenation of STS-3c as it is equivalent to virtual
> concatenation of VC-4s.

We had some discussion of this among authors of GMPLS SONET/SDH signaling last week
and one possibility considered was that STS-3c groups could be identified by applying
the following convention:  If the signal type is OC-3 with no transparency (that is, no
line or section overhead included) AND some grouping type selected (e.g., virtual concatenation)
THEN one would assume the path structure was STS-3c.  This would also apply to other
standard contiguous concatenated rates (STS-12c, VC4-4c, etc.).  What do you think?

There is also a proposal to add another level of grouping by adding a multiplier field.
This would indicate that some number of grouped signal types is requested (e.g., a number
of arbitrary contiguous concatenated signals -- say 10xSTS-7c).  This is essentiually
a second level of grouping, with no type or routing constraint differentiation.

<snip>

Delivery-date: Thu, 29 Mar 2001 05:23:21 -0800
Date: Thu, 29 Mar 2001 15:19:45 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

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

All,

I would like to add a few notes to two items in the ongoing
correspondence:

>...
>         It should be noted that the LSP isn't necessarily used 
> to setup a network connection between two trail terminations. It
> can also be used to setup sub-network connections. In the later
> case you don't know the payload ID and specific GPID.

I am trying to generalise the layer network description from the control
plane's viewpoint (CP_LN). So far, I have come up with the following
udnerstanding:
  * CP_LN consists of a Fabric, a set of Ports and a set of Links
  * The set of Ports can be divided into 4 subsets:
    - towards a client LN (vertical relationship - top),
    - towards a server LN (vertical relationship - bottom), 
    - towards a user network (horizontal relationship - bottom) 
      providing native layer network service 
    - towards a user network (horizontal relationship - top)
      providing a circuit service.

	Example - native service is e.g. a VC-4 switched connection
	in a VC-4 layer network (VC-4 subnetwork connection is set-up);
	circuit service is e.g. a 140 Mbit/s (E4) switched circuit via
	a VC-4 layer network (VC-4 trail is set-up).

			to/from client CP_LN
			     ||||||||
     ------------	     --------
   --| UN_LN_CS |	     |      |
     --------|  |	     | C_LN |
             |  |	     |      |	
             ----	     --------
	       |		|
         -------------------------------------------
         |                  Fabric                 |
         -------------------------------------------
	     ||||	     ||||||||
             ----	     --------
   	     |  |	     |      |
     --------|  |	     | S_LN |
   --| UN_LN_NS |	     |      |
     ------------	     --------
				 |

		Figure 1 - 4 port types and fabric in CP_LN

The C_LN port provides a link to a client layer network.
The S_LN port provides a link to this layer network.
The UN_LN_CS port provides access to a circuit of a client layer
network.
The UN_LN_NS port provides access to a connection in this layer network.

			     ||||||||
  (A)-------------	     --------
   --| TTP       |	     |      |
     --------|   |	     | TTP  |
             |TTP|	     |      |	
             -----	     --------
	   (A')|	     (C)|                        |   |   |
         -------------------------------            -------------------
         |           Fabric            |            |     Fabric      |
         -------------------------------            -------------------
	 (B')||||	  (D)||||||||   <-- Link -->   ||||||||    |||
             ----	     --------    Connection    --------    ---
   	     |  |	     |      |    End Points    |      |    | |
  (B)--------|  |	     |      |                  |      |    | |
   --| USER LINK|	     |      |                  |      |
     ------------	     |      --------------------      |
			     |     (Topological) LINK         |
                             ----------------------------------

			Figure 2

Looking at figure 2, there are 4 interfaces to the Fabric: A (via A'), B
(via B'), C and D. Connections in a switched (sub)network can be made
between many combination of these 4 interface types in the ingress node
and egress node of the switched network:

* A - A ==> this includes a trail
* B - B ==> this is a subnetwork connection between UNIs (CTP - CTP)
* C - C ==> this is a trail (TTP - TTP)
* D - D ==> this is a subnetwork connection between NNIs (CTP - CTP); 
	    this is also an LSP as far as I understand

[hybrid connections:]
* A - B ==> trail termination (TTP) at one end and CTP at other end
* A - D ==> TTP - CTP
* B - A ==> CTP - TTP
* B - C ==> CTP - TTP
* B - D ==> CTP - CTP
* C - B ==> TTP - CTP
* C - D ==> TTP - CTP
* D - A ==> CTP - TTP
* D - B ==> CTP - CTP
* D - C ==> CTP - TTP

CTPs may have additional functionality to support:
- non-intrusive monitoring
- tandem connection monitoring; this may be a single instance or
  multiple instances of tandem connection monitoring. E.g. at a UNI
  there might be a Service Provider TCM and a Network Operator TCM
  endpoint active. At a NNI there might be a Network Operator TCM 
  endpoint active. Other cases may also exist.

> 
> >  I don't know if there is other trail termination info that
> > should be signalled between the endpoints.
> > Do you have any thoughts on this?
>         [Juergen Heiles]  Tandem Connection Monitoring and setup of
> the TCM level might need some thoughts. Do we want to setup TCM
> automatically via LSP signaling at all?

TCM endpoints may be required for SLA verification (holding time of
transport connections is rather long compared to voice connection), or
for detecting the trigger condition(s) (SF, SD) for restoration.

TCM endpoints for SLA verification may already be activated during
installation of the interface port unit and/or fiber connection. If not,
then the control plane must do it.

TCM endpoints for restoration may reuse the TCM endpoints for SLA
verification. If not, then the control plane must activate those.

Besides the possible activation of TCM endpoints, a trail or tandem
connection monitored connection set-up will have to perform the
following actions:

- read the MI_TxTI (transmitted trace id) value from the TT_So function
at the "A" end, send this TTI value to the "Z" end and assign it to the
MI_ExTI (expected trace id) signal in the TT_Sk function. MI_TIMdis is
then set to "false" and MI_TIMAISdis is also set to "false".
- read the MI_AcTI signal once the connection is set-up to confirm the
correct connection is created. If AcTI is ExTI then inform the other
end. If this end also has AcTI is ExTI the connection is setup
completely and now the reporting modes at each end can be set: either
set the MI_TPmode to the value "MON", or set the ARCmode for the TT_Sk
to the value "ALARMED".
- if the connection being setup is a trail, a check of the adaptation
function types at each end should also be included.
- if the connection is half of a trail/tandem connection then
  * if "A" end there is a TT_So, the TTI value must be handed-off at "Z"
    to the next switched network
  * if "Z" end is a TT_Sk, the TTI value must be incoming at the "A" end
    and if not available (i.e. "void"), then the MI_TIMdis signal is set
    to "true" (to disable trace id mismatch detection).

As such, the TTI read from MI_TxTI must be signalled, and detection of
MI_AcTI = MI_ExTI is to be signalled.

Some similar actions are necessary when there is a non-intrusive monitor
connected to the connection.

Regards,

Maarten
--------------9F003EB08DE043F2609AB37A
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------9F003EB08DE043F2609AB37A--

Delivery-date: Thu, 29 Mar 2001 00:12:17 -0800
From: Heiles Juergen <[email-masked]>
To: "'Ben Mack-Crane'" <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: sambasiva mantha <[email-masked]>, Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 29 Mar 2001 10:10:07 +0200

Ben,

see my comments below.

Regards

Juergen

> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:[email-masked]]
> Sent:	Wednesday, March 28, 2001 5:36 PM
> To:	Heiles Juergen
> Cc:	sambasiva mantha; Vishal Sharma; 'manoj juneja'; [email-masked]
> Subject:	Re: Please Clarify Doubts regarding RGT & RNC
> 
> Hello Jeurgen,
> 
> I think we are in general agreement.  A few clarifications are included below.
> 
> Regards,
> Ben
> 
> Heiles Juergen wrote:
> > 
> > Ben,
> > 
> > the characteristic information and the trail termination function are directly related as the
> > characteristic infromation is generated/terminated by the trail termination function. So I don't
> > see a need for additional trail termination information.
> 
> Some trail termination information is not currently included in the signaling,
> and probably should
> be.  For example, the Trail Trace Identifier should be configured the same way
> at source and sink,
> but is not currently in the signaling spec (but certainly not as part of Signal
> Type). 
	[Juergen Heiles]  Configuration of the trail trace is an open issue I agree. Draft-harrison-mpls-oam-00.txt proposes a trail trace (Connectivity verification CV OAM packets) for MPLS and suggest that the configuration of the trace is done via LSP signaling at LSP set-up.

> Also Payload 
> ID should be set properly, but this can be inferred (translated) from the GPID
> that is signalled.  
	[Juergen Heiles]  The payload ID/Signal lable is not configurable as such, it is fixed defined by the adaptation function. What is configurable is the type of adaptation function itself if the network element provides this flexibility. As you noted the GPID is equivalent to the payload ID/signal label. 
	It should be noted that the LSP isn't necessarily used to setup a network connection between two trail terminations. I can also be used to setup sub-network connections. In the later case you don't know the payload ID and specific GPID.  

>  I don't know if there is other trail termination info that should be signalled
> between the endpoints.  
> Do you have any thoughts on this?
	[Juergen Heiles]  Tandem Connection Monitoring and setup of the TCM level might need some thoughts. Do we want to setup TCM automatically via LSP signaling at all?

> > 
> > I agree with you that the RTG field combines different types of information. Contiguous concateantion
> > is a characteristic information and should be coded into the signal type. As I mentioned before a
> > STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> > STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
> 
> We have gone back and forth on this topic.  Originally STS-3c was a concatenated
> signal, then we
> changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
> and now it is
> coded as a concatenated signal once more.  The current view is that it is
> cleaner to code it
> as a concatenated signal.  In either case I think we will have some way to code
> the same signal
> in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
> concatenated type
> as well.)
	[Juergen Heiles]  You might use a dedicated filed for contiguous concatenation, but mixing it with bundling and virtual cocnatenation in one field has strange results. For example you cannot setup a virtual concatenation of N STS-3c with a common route, while you can setup virtual concatenation of N VC-4. I assume that virtual concatenation of STS-3c as it is equivalent to virtual concatenation of VC-4s.
>  
> > I also agree with you on arbitary concatenation. It is contiguous concatenation. The signal type can
> > clearly identify the type of contiguous concatenation (e.g. STS-12c-SPE or STS-15c-SPE). The time slot> 
> > allocation is  a local matter for the link between two nodes and we might have other restrictions in> 
> > time slot allocation or wavelength allocation in WDM systems.
> >
> > The RGT is then only needed for bundles with common routing. Common routing should be a general concept
> > independent of the technology (SDH/SONET, OTN, ...). As you mentionedcommon routing could mean the same
> > server layer connection, the same physical signal, the same fiber, the same duct, the same network
> > elements. One has similar options as for diverse routing.
> > 
> > Regards
> > 
> > Juergen
> > 
> > > -----Original Message-----
> > > From: Ben Mack-Crane [SMTP:[email-masked]]
> > > Sent: Friday, March 23, 2001 5:14 PM
> > > To:   sambasiva mantha
> > > Cc:   Vishal Sharma; 'manoj juneja'; [email-masked]
> > > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Vishal & Sambu,
> > >
> > > I would like to add a bit to this discussion.
> > >
> > > First some background:
> > > For those familiar with functional modeling (and I recommend
> > > it to all as an excellent tool for understanding communication
> > > networks) there are three (or maybe four) functional considerations
> > > that must be addressed in setting up a trail.
> > > 1) the type of characteristic information (which is necessary to
> > >    determine which link connections can support the connection)
> > > 2) the type of trail termination function (which must be matched
> > >    at the trail endpoints)
> > > 3) the client characteristic information and type of adaptation
> > >    (which may be separate considerations or bound together, and
> > >    also must be matched at the endpoints)
> > >
> > > Generally, intermediate nodes need only know 1), and possibly parts
> > > of 2) if they support non-intrusive monitoring.  The endpoints
> > > need to be able to exchange info about 2) and 3).
> > >
> > > The current signaling structure, however, does not provide separate
> > > fields for each of these areas.  There are only Signal Type and GPID
> > > fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).
> > >
> > > A similar encoding is being used with RGT (that is, combining
> > > information needed in transit nodes and end nodes into one field).
> > > Thus (as has been explained) the difference between virtual
> > > concatenation and bundling is relevant to the endpoints and not
> > > the transit nodes.
> > >
> > > Now to my point:
> > > The RGT field is also required to distinguish between differing
> > > connection requirements in transit nodes, and this has not been
> > > precisely explained yet.
> > >
> > > Both virtual concatenation and bundling share the constraint that
> > > the set of link connections used must all be within the same higher
> > > order container.  This guarantees some degree of shared fate and
> > > limits delay difference.
> > >
> > > I have stated this as a definition, but this is only one possible
> > > constraint.  Other possibilities include:
> > >
> > > a) the set of link connections must be within one bit stream, but
> > >    may be in different higher order containers,
> > > b) the set of link connections must go to the same neighbor (the
> > >    loosest possible constraint within the signaling model), but
> > >    they may be in different bit streams (even different fibers).>
> > >
> > > Eventually we must be precise about what the constraint is for
> > > each RGT, and we may need to define additional RGT codepoints if
> > > we need to encode different constraints.  Note: there may be a
> > > label signaling problem if constraint b) is required.
> > >
> > > Contiguous concatenation types have the specific constraint that
> > > the set of components be treated as a single byte stream in transit
> > > nodes (relative to pointer adjustment, etc.) and this implies the
> > > components must all be within the same higher order container.
> > >
> > > I think the difference between standard and arbitrary contiguous
> > > concatenation should only be in the number of components allowed.> 
> > > Timeslot flexibility is a local constraint between neighbors, and
> > > both standard and arbitrary concatenated signals can make use of
> > > flexible timeslot allocation, if supported.  Given this, we may
> > > need to have a way to negotiate support for timeslot flexibility
> > > between neighbors (via LMP?) independently of the signaling of a
> > > specific LSP.
> > >
> > > Regards,
> > > Ben
> > >
> > > sambasiva mantha wrote:
> > > >
> > > > Vishal,
> > > >
> > > > I understand what is "bundling" group is for. What I was questioning was your
> > > > statement that no special handling is required for the bundling. They are
> > > > treated the same at the end nodes and at the intermediate nodes. What I was
> > > > pointing out was that when they are tagged as "bundling" group, then the
> > > > intermediate nodes also have to treat it specially.
> > > >
> > > > Sambu
> > > >
> > > > Vishal Sharma wrote:
> > > >
> > > > > Sambu,
> > > > >
> > > > > The "bundling" group type is defined to allow for the setup of multiple
> > > > > channels in parallel, such as three STS-1s in parallel, instead of setting
> > > > > up each individually. (Note that the draft currently allows for
> > > > > the bundling of only those channels that are in the same higher-order
> > > > > container.) This also allows the operator to control the fate of these
> > > > > bundled channels.
> > > > >
> > > > > -Vishal
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: sambasiva mantha [mailto:[email-masked]]
> > > > > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > > > > To: Vishal Sharma
> > > > > > Cc: 'manoj juneja'; [email-masked]
> > > > > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > > > >
> > > > > >
> > > > > > Vishal,
> > > > > >
> > > > > > As  you pointed at the end of the email, if a speciality
> > > > > > funcitionality is not
> > > > > > required for "bundling" group type, then why there is a need for
> > > > > > distinguishing the group as such. In case of a SONET DCS the
> > > > > > bundling has a
> > > > > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > > > > which must be
> > > > > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > > > > operator to separate these STS-1s out in the sense they have
> > > > > > to come in on one
> > > > > > input port (OC-n say) and all the STS-1s in the bundle have
> > > > > > to cross connected
> > > > > > to the same outgoing output port (OC-m).
> > > > > >
> > > > > > Sambu
> > > > > >
> > > > > >
> > > > > > Vishal Sharma wrote:
> > > > > >
> > > > > > > Manoj,
> > > > > > >
> > > > > > > Some clarifications follow...
> > > > > > >
> > > > > > > -Vishal
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >         The GMPLS draft
> > > > > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > > > > Contiguous
> > > > > > > > arbitrary concatenation, Bundle.
> > > > > > > > How does the implementation of a control plane differ if
> > > > > > it receives
> > > > > > > > different RGT values ?
> > > > > > >
> > > > > > > The implementation of the control plane should not differ based on>
> > > > > > > different RGT values, the implementation of the data plane is what
> > > > > > > differs in all of these cases, because each RGT value controls how
> > > > > > > the data bearing channels are  treated by the end nodes and the> 
> > > > > > > intermediate nodes.
> > > > > > >> 
> > > > > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > > > > the virtually
> > > > > > > concatenated channels as they would treat independent channels. The
> > > > > > > end points, however, treat these channels as "bonded"
> > > > > > together, and must
> > > > > > > have hardware and software support to "glue" the data
> > > > > > arriving on these
> > > > > > > channels together appropriately. (For instance, the hardware must
> > > > > > > support compensation for the differential delay that the component
> > > > > > > channels of the virtually concatenated stream may suffer.)
> > > > > > >
> > > > > > > > Another field RNC (Reuested Number of
> > > > > > > > Components) defines the number of such components requested.
> > > > > > > > My understanding is that if RNC is 2 and signal type is
> > > > > > STM-1. Then it
> > > > > > > > means that 2 STM-1 signals are requested and these are
> > > > > > concatenated
> > > > > > > > according to the RGT specified.
> > > > > > >
> > > > > > > Your understanding is correct.
> > > > > > >
> > > > > > > > Does this mean, the number of labels
> > > > > > > > requested depend on the RNC field ?  This means that is
> > > > > > RNC is "X",
> > > > > > > > then "X" number of labels are to be returned in Label
> > > > > > Mapping message
> > > > > > > > and the labels returned should be in accrodance with the requested
> > > > > > > > signal type.
> > > > > > >
> > > > > > > Not quite. The number of labels will be determined by a
> > > > > > combination of
> > > > > > > the RNC and RGT.
> > > > > > >
> > > > > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > > > > channel (which is transparent
> > > > > > > only at the path level, so that line and section overheads
> > > > > > are not to be
> > > > > > > preserved across SONET equipment), and see what happens in
> > > > > > the various
> > > > > > > cases.
> > > > > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > > > >
> > > > > > > If RGT = contiguous standard or contiguous arbitrary
> > > > > > concatenation, then
> > > > > > > only a _single_ label is returned (that one that denotes
> > > > > > the time slot at
> > > > > > > which the first of the concatenated channels begins).
> > > > > > >
> > > > > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > > > > labels (or
> > > > > > > # of labels = RNC in the general case) will
> > > > > > > need to be returned in the label mapping message (namely,
> > > > > > the times slots
> > > > > > > that denote where _each_ of the component STS-1s of the
> > > > > > STS-3 signal is to
> > > > > > > be placed, since in these cases the component STS-1s need
> > > > > > not occur in
> > > > > > > contiguous time slots).
> > > > > > >
> > > > > > > > Please clarify these doubts.
> > > > > > >
> > > > > > > Hope the above helps.
> > > > > > >
> > > > > > > > Can somebody please brief me on grouping type Bundle ?
> > > > > > >
> > > > > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > > > > setting up multiple, independent
> > > > > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > > > > three channels of STS-1 granularity, where each would be totally
> > > > > > > independent of the others, both at the intermediate nodes and at
> > > > > > > the end nodes.
> > > > > > >
> > > > > > > If, however, RGT=virtual concatenation, then what would really be
> > > > > > > setup in the SONET network would again be 3 channels of STS-1
> > > > > > > granularity, which to the intermediate nodes would be no different
> > > > > > > from the case above. To the end nodes, however, it would mean that
> > > > > > > they need to have the capability to handle virtually concatenated
> > > > > > > SONET channels (which means they need to be capable of appropriately>> 
> > > > > > > dividing traffic a> cross them [at the in> put], and "glueing" them back
> > > > > > > together [at the output]).
> > > > > > >
> > > > > > > > Is there any additional capability required in the network for
> > > > > > > > supporting different types of grouping types (RGTs) ?
> > > > > > >
> > > > > > > Not sure what you mean by "additional" capability? In "addition"
> > > > > > > to what?
> > > > > > >
> > > > > > > For contiguous standard concatenation, the network nodes need to
> > > > > > > be able to support standard SDH/SONET concatenation.
> > > > > > > For continuous arbitrary concatenation, the network nodes involved
> > > > > > > in the establishment of such a channel, need to be able to support
> > > > > > > arbitrary concatenation.
> > > > > > > For virtual concatenation, the intermediate nodes through which
> > > > > > > the channle passes need no additional functionality, but the
> > > > > > > end nodes must be able to support the processing of virtually
> > > > > > > concatenated channels.
> > > > > > > For bundling, absolutely no special functionality is required
> > > > > > > in either the intermediate nodes or the end nodes.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > >
> > >

Delivery-date: Wed, 28 Mar 2001 07:45:21 -0800
Date: Wed, 28 Mar 2001 09:35:49 -0600
From: Ben Mack-Crane <[email-masked]>
To: Heiles Juergen <[email-masked]>
CC: sambasiva mantha <[email-masked]>, Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Hello Jeurgen,

I think we are in general agreement.  A few clarifications are included below.

Regards,
Ben

Heiles Juergen wrote:
> 
> Ben,
> 
> the characteristic information and the trail termination function are directly related as the
> characteristic infromation is generated/terminated by the trail termination function. So I don't
> see a need for additional trail termination information.

Some trail termination information is not currently included in the signaling,
and probably should
be.  For example, the Trail Trace Identifier should be configured the same way
at source and sink,
but is not currently in the signaling spec (but certainly not as part of Signal
Type). Also Payload 
ID should be set properly, but this can be inferred (translated) from the GPID
that is signalled.  
I don't know if there is other trail termination info that should be signalled
between the endpoints.  
Do you have any thoughts on this?

> 
> I agree with you that the RTG field combines different types of information. Contiguous concateantion
> is a characteristic information and should be coded into the signal type. As I mentioned before a
> STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> STS-3c-SPE into the signal type and RTG. A different coding for identical signals.

We have gone back and forth on this topic.  Originally STS-3c was a concatenated
signal, then we
changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
and now it is
coded as a concatenated signal once more.  The current view is that it is
cleaner to code it
as a concatenated signal.  In either case I think we will have some way to code
the same signal
in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
concatenated type
as well.)

> I also agree with you on arbitary concatenation. It is contiguous concatenation. The signal type can
> clearly identify the type of contiguous concatenation (e.g. STS-12c-SPE or STS-15c-SPE). The time slot
> allocation is  a local matter for the link between two nodes and we might have other restrictions in
> time slot allocation or wavelength allocation in WDM systems.
>
> The RGT is then only needed for bundles with common routing. Common routing should be a general concept
> independent of the technology (SDH/SONET, OTN, ...). As you mentionedcommon routing could mean the same
> server layer connection, the same physical signal, the same fiber, the same duct, the same network
> elements. One has similar options as for diverse routing.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [SMTP:[email-masked]]
> > Sent: Friday, March 23, 2001 5:14 PM
> > To:   sambasiva mantha
> > Cc:   Vishal Sharma; 'manoj juneja'; [email-masked]
> > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> >
> > Vishal & Sambu,
> >
> > I would like to add a bit to this discussion.
> >
> > First some background:
> > For those familiar with functional modeling (and I recommend
> > it to all as an excellent tool for understanding communication
> > networks) there are three (or maybe four) functional considerations
> > that must be addressed in setting up a trail.
> > 1) the type of characteristic information (which is necessary to
> >    determine which link connections can support the connection)
> > 2) the type of trail termination function (which must be matched
> >    at the trail endpoints)
> > 3) the client characteristic information and type of adaptation
> >    (which may be separate considerations or bound together, and
> >    also must be matched at the endpoints)
> >
> > Generally, intermediate nodes need only know 1), and possibly parts
> > of 2) if they support non-intrusive monitoring.  The endpoints
> > need to be able to exchange info about 2) and 3).
> >
> > The current signaling structure, however, does not provide separate
> > fields for each of these areas.  There are only Signal Type and GPID
> > fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).
> >
> > A similar encoding is being used with RGT (that is, combining
> > information needed in transit nodes and end nodes into one field).
> > Thus (as has been explained) the difference between virtual
> > concatenation and bundling is relevant to the endpoints and not
> > the transit nodes.
> >
> > Now to my point:
> > The RGT field is also required to distinguish between differing
> > connection requirements in transit nodes, and this has not been
> > precisely explained yet.
> >
> > Both virtual concatenation and bundling share the constraint that
> > the set of link connections used must all be within the same higher
> > order container.  This guarantees some degree of shared fate and
> > limits delay difference.
> >
> > I have stated this as a definition, but this is only one possible
> > constraint.  Other possibilities include:
> >
> > a) the set of link connections must be within one bit stream, but
> >    may be in different higher order containers,
> > b) the set of link connections must go to the same neighbor (the
> >    loosest possible constraint within the signaling model), but
> >    they may be in different bit streams (even different fibers).>
> >
> > Eventually we must be precise about what the constraint is for
> > each RGT, and we may need to define additional RGT codepoints if
> > we need to encode different constraints.  Note: there may be a
> > label signaling problem if constraint b) is required.
> >
> > Contiguous concatenation types have the specific constraint that
> > the set of components be treated as a single byte stream in transit
> > nodes (relative to pointer adjustment, etc.) and this implies the
> > components must all be within the same higher order container.
> >
> > I think the difference between standard and arbitrary contiguous
> > concatenation should only be in the number of components allowed.
> > Timeslot flexibility is a local constraint between neighbors, and
> > both standard and arbitrary concatenated signals can make use of
> > flexible timeslot allocation, if supported.  Given this, we may
> > need to have a way to negotiate support for timeslot flexibility
> > between neighbors (via LMP?) independently of the signaling of a
> > specific LSP.
> >
> > Regards,
> > Ben
> >
> > sambasiva mantha wrote:
> > >
> > > Vishal,
> > >
> > > I understand what is "bundling" group is for. What I was questioning was your
> > > statement that no special handling is required for the bundling. They are
> > > treated the same at the end nodes and at the intermediate nodes. What I was
> > > pointing out was that when they are tagged as "bundling" group, then the
> > > intermediate nodes also have to treat it specially.
> > >
> > > Sambu
> > >
> > > Vishal Sharma wrote:
> > >
> > > > Sambu,
> > > >
> > > > The "bundling" group type is defined to allow for the setup of multiple
> > > > channels in parallel, such as three STS-1s in parallel, instead of setting
> > > > up each individually. (Note that the draft currently allows for
> > > > the bundling of only those channels that are in the same higher-order
> > > > container.) This also allows the operator to control the fate of these
> > > > bundled channels.
> > > >
> > > > -Vishal
> > > >
> > > > > -----Original Message-----
> > > > > From: sambasiva mantha [mailto:[email-masked]]
> > > > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > > > To: Vishal Sharma
> > > > > Cc: 'manoj juneja'; [email-masked]
> > > > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > > >
> > > > >
> > > > > Vishal,
> > > > >
> > > > > As  you pointed at the end of the email, if a speciality
> > > > > funcitionality is not
> > > > > required for "bundling" group type, then why there is a need for
> > > > > distinguishing the group as such. In case of a SONET DCS the
> > > > > bundling has a
> > > > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > > > which must be
> > > > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > > > operator to separate these STS-1s out in the sense they have
> > > > > to come in on one
> > > > > input port (OC-n say) and all the STS-1s in the bundle have
> > > > > to cross connected
> > > > > to the same outgoing output port (OC-m).
> > > > >
> > > > > Sambu
> > > > >
> > > > >
> > > > > Vishal Sharma wrote:
> > > > >
> > > > > > Manoj,
> > > > > >
> > > > > > Some clarifications follow...
> > > > > >
> > > > > > -Vishal
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > > > >
> > > > > > >
> > > > > > > Hi All,
> > > > > > >         The GMPLS draft
> > > > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > > > Contiguous
> > > > > > > arbitrary concatenation, Bundle.
> > > > > > > How does the implementation of a control plane differ if
> > > > > it receives
> > > > > > > different RGT values ?
> > > > > >
> > > > > > The implementation of the control plane should not differ based on>
> > > > > > different RGT values, the implementation of the data plane is what
> > > > > > differs in all of these cases, because each RGT value controls how
> > > > > > the data bearing channels are  treated by the end nodes and the
> > > > > > intermediate nodes.
> > > > > >
> > > > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > > > the virtually
> > > > > > concatenated channels as they would treat independent channels. The
> > > > > > end points, however, treat these channels as "bonded"
> > > > > together, and must
> > > > > > have hardware and software support to "glue" the data
> > > > > arriving on these
> > > > > > channels together appropriately. (For instance, the hardware must
> > > > > > support compensation for the differential delay that the component
> > > > > > channels of the virtually concatenated stream may suffer.)
> > > > > >
> > > > > > > Another field RNC (Reuested Number of
> > > > > > > Components) defines the number of such components requested.
> > > > > > > My understanding is that if RNC is 2 and signal type is
> > > > > STM-1. Then it
> > > > > > > means that 2 STM-1 signals are requested and these are
> > > > > concatenated
> > > > > > > according to the RGT specified.
> > > > > >
> > > > > > Your understanding is correct.
> > > > > >
> > > > > > > Does this mean, the number of labels
> > > > > > > requested depend on the RNC field ?  This means that is
> > > > > RNC is "X",
> > > > > > > then "X" number of labels are to be returned in Label
> > > > > Mapping message
> > > > > > > and the labels returned should be in accrodance with the requested
> > > > > > > signal type.
> > > > > >
> > > > > > Not quite. The number of labels will be determined by a
> > > > > combination of
> > > > > > the RNC and RGT.
> > > > > >
> > > > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > > > channel (which is transparent
> > > > > > only at the path level, so that line and section overheads
> > > > > are not to be
> > > > > > preserved across SONET equipment), and see what happens in
> > > > > the various
> > > > > > cases.
> > > > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > > >
> > > > > > If RGT = contiguous standard or contiguous arbitrary
> > > > > concatenation, then
> > > > > > only a _single_ label is returned (that one that denotes
> > > > > the time slot at
> > > > > > which the first of the concatenated channels begins).
> > > > > >
> > > > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > > > labels (or
> > > > > > # of labels = RNC in the general case) will
> > > > > > need to be returned in the label mapping message (namely,
> > > > > the times slots
> > > > > > that denote where _each_ of the component STS-1s of the
> > > > > STS-3 signal is to
> > > > > > be placed, since in these cases the component STS-1s need
> > > > > not occur in
> > > > > > contiguous time slots).
> > > > > >
> > > > > > > Please clarify these doubts.
> > > > > >
> > > > > > Hope the above helps.
> > > > > >
> > > > > > > Can somebody please brief me on grouping type Bundle ?
> > > > > >
> > > > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > > > setting up multiple, independent
> > > > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > > > three channels of STS-1 granularity, where each would be totally
> > > > > > independent of the others, both at the intermediate nodes and at
> > > > > > the end nodes.
> > > > > >
> > > > > > If, however, RGT=virtual concatenation, then what would really be
> > > > > > setup in the SONET network would again be 3 channels of STS-1
> > > > > > granularity, which to the intermediate nodes would be no different
> > > > > > from the case above. To the end nodes, however, it would mean that
> > > > > > they need to have the capability to handle virtually concatenated
> > > > > > SONET channels (which means they need to be capable of appropriately>
> > > > > > dividing traffic across them [at the in> put], and "glueing" them back
> > > > > > together [at the output]).
> > > > > >
> > > > > > > Is there any additional capability required in the network for
> > > > > > > supporting different types of grouping types (RGTs) ?
> > > > > >
> > > > > > Not sure what you mean by "additional" capability? In "addition"
> > > > > > to what?
> > > > > >
> > > > > > For contiguous standard concatenation, the network nodes need to
> > > > > > be able to support standard SDH/SONET concatenation.
> > > > > > For continuous arbitrary concatenation, the network nodes involved
> > > > > > in the establishment of such a channel, need to be able to support
> > > > > > arbitrary concatenation.
> > > > > > For virtual concatenation, the intermediate nodes through which
> > > > > > the channle passes need no additional functionality, but the
> > > > > > end nodes must be able to support the processing of virtually
> > > > > > concatenated channels.
> > > > > > For bundling, absolutely no special functionality is required
> > > > > > in either the intermediate nodes or the end nodes.
> > > > > >
> > > > > >
> > > > > > >
> > > > >
> >

Delivery-date: Wed, 28 Mar 2001 06:19:20 -0800
Date: Tue, 27 Mar 2001 23:34:26 -0500
From: "Philip Matthews" <[email-masked]>
Organization: Nortel Networks
To: [email-masked]
CC: Kireeti Kompella <[email-masked]>, Ron Bonica <[email-masked]>
Subject: Re: Tunnel trace

I gave Ron the feedback privately after the CCAMP meeting
that it bothered me that the protocol spec required the
router at the head of the path to store a copy of the packet.
To me, this opens up lots of possibilities for denial-of-service attacks.

Here is the situation. There is a network with routers A, B, C ...
and a host H. According to the current draft, the message exchange is
- H sends a request message to A
- A saves a copy of the request message, then sends it along the tunnel to B
- B sends a reply to A
- A forwards the reply to H

If I understood what Ron told me, the reason the message exchange is worked this way is because
B may not be able to reach H directly (think of the VPN case, or the case where
one is using LDP as a BGP replacement in the core). But the Label Encap document
has already told us how to solve that problem: just send the reply along the
original tunnel until it reaches a router that can forward it to H.

According to Ron, the IESG had some objections to this solution.
I would like to know more about those objections, because this seems to be a
good solution to me.

- Philip

Kireeti Kompella wrote:
> 
> Is the requirements draft on target?  Is the protocol spec on target?
> Is either of interest?
> 
> Kireeti.

Delivery-date: Tue, 27 Mar 2001 23:38:43 -0800
From: Heiles Juergen <[email-masked]>
To: "'Ben Mack-Crane'" <[email-masked]>, sambasiva mantha <[email-masked]>
Cc: Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Wed, 28 Mar 2001 09:35:54 +0200

Ben,

the characteristic information and the trail termination function are directly related as the characteristic infromation is generated/terminated by the trail termination function. So I don'tsee a need for additional trail termination information.

I agree with you that the RTG field combines different types of information. Contiguous concateantion is a characteristic information and should be coded into the signal type. As I mentioned before a STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
I also agree with you on arbitary concatenation. It is contiguous concatenation. The signal type can clearly identify the type of contiguous concatenation (e.g. STS-12c-SPE or STS-15c-SPE). The time slot allocation is  a local matter for the link between two nodes and we might have other restrictions in time slot allocation or wavelength allocation in WDM systems.
The RGT is then only needed for bundles with common routing. Common routing should be a general concept independent of the technology (SDH/SONET, OTN, ...). As you mentionedcommon routing could mean the same server layer connection, the same physical signal, the same fiber, the same duct, the same network elements. One has similar options as for diverse routing.

Regards

Juergen

> -----Original Message-----
> From:	Ben Mack-Crane [SMTP:[email-masked]]
> Sent:	Friday, March 23, 2001 5:14 PM
> To:	sambasiva mantha
> Cc:	Vishal Sharma; 'manoj juneja'; [email-masked]
> Subject:	Re: Please Clarify Doubts regarding RGT & RNC
> 
> Vishal & Sambu,
> 
> I would like to add a bit to this discussion.
> 
> First some background:
> For those familiar with functional modeling (and I recommend
> it to all as an excellent tool for understanding communication
> networks) there are three (or maybe four) functional considerations
> that must be addressed in setting up a trail.
> 1) the type of characteristic information (which is necessary to 
>    determine which link connections can support the connection)
> 2) the type of trail termination function (which must be matched 
>    at the trail endpoints)
> 3) the client characteristic information and type of adaptation 
>    (which may be separate considerations or bound together, and
>    also must be matched at the endpoints)
> 
> Generally, intermediate nodes need only know 1), and possibly parts
> of 2) if they support non-intrusive monitoring.  The endpoints
> need to be able to exchange info about 2) and 3).
> 
> The current signaling structure, however, does not provide separate
> fields for each of these areas.  There are only Signal Type and GPID
> fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).
> 
> A similar encoding is being used with RGT (that is, combining
> information needed in transit nodes and end nodes into one field).
> Thus (as has been explained) the difference between virtual
> concatenation and bundling is relevant to the endpoints and not
> the transit nodes.
> 
> Now to my point:
> The RGT field is also required to distinguish between differing
> connection requirements in transit nodes, and this has not been
> precisely explained yet.
> 
> Both virtual concatenation and bundling share the constraint that
> the set of link connections used must all be within the same higher
> order container.  This guarantees some degree of shared fate and 
> limits delay difference.
> 
> I have stated this as a definition, but this is only one possible
> constraint.  Other possibilities include:
> 
> a) the set of link connections must be within one bit stream, but 
>    may be in different higher order containers,
> b) the set of link connections must go to the same neighbor (the
>    loosest possible constraint within the signaling model), but
>    they may be in different bit streams (even different fibers).> 
> 
> Eventually we must be precise about what the constraint is for
> each RGT, and we may need to define additional RGT codepoints if
> we need to encode different constraints.  Note: there may be a
> label signaling problem if constraint b) is required.
> 
> Contiguous concatenation types have the specific constraint that
> the set of components be treated as a single byte stream in transit
> nodes (relative to pointer adjustment, etc.) and this implies the
> components must all be within the same higher order container.
> 
> I think the difference between standard and arbitrary contiguous
> concatenation should only be in the number of components allowed.
> Timeslot flexibility is a local constraint between neighbors, and
> both standard and arbitrary concatenated signals can make use of
> flexible timeslot allocation, if supported.  Given this, we may
> need to have a way to negotiate support for timeslot flexibility 
> between neighbors (via LMP?) independently of the signaling of a
> specific LSP.
> 
> Regards,
> Ben
> 
> sambasiva mantha wrote:
> > 
> > Vishal,
> > 
> > I understand what is "bundling" group is for. What I was questioning was your
> > statement that no special handling is required for the bundling. They are
> > treated the same at the end nodes and at the intermediate nodes. What I was
> > pointing out was that when they are tagged as "bundling" group, then the
> > intermediate nodes also have to treat it specially.
> > 
> > Sambu
> > 
> > Vishal Sharma wrote:
> > 
> > > Sambu,
> > >
> > > The "bundling" group type is defined to allow for the setup of multiple
> > > channels in parallel, such as three STS-1s in parallel, instead of setting
> > > up each individually. (Note that the draft currently allows for
> > > the bundling of only those channels that are in the same higher-order
> > > container.) This also allows the operator to control the fate of these
> > > bundled channels.
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: sambasiva mantha [mailto:[email-masked]]
> > > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > > To: Vishal Sharma
> > > > Cc: 'manoj juneja'; [email-masked]
> > > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Vishal,
> > > >
> > > > As  you pointed at the end of the email, if a speciality
> > > > funcitionality is not
> > > > required for "bundling" group type, then why there is a need for
> > > > distinguishing the group as such. In case of a SONET DCS the
> > > > bundling has a
> > > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > > which must be
> > > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > > operator to separate these STS-1s out in the sense they have
> > > > to come in on one
> > > > input port (OC-n say) and all the STS-1s in the bundle have
> > > > to cross connected
> > > > to the same outgoing output port (OC-m).
> > > >
> > > > Sambu
> > > >
> > > >
> > > > Vishal Sharma wrote:
> > > >
> > > > > Manoj,
> > > > >
> > > > > Some clarifications follow...
> > > > >
> > > > > -Vishal
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >         The GMPLS draft
> > > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > > Contiguous
> > > > > > arbitrary concatenation, Bundle.
> > > > > > How does the implementation of a control plane differ if
> > > > it receives
> > > > > > different RGT values ?
> > > > >
> > > > > The implementation of the control plane should not differ based on> 
> > > > > different RGT values, the implementation of the data plane is what
> > > > > differs in all of these cases, because each RGT value controls how
> > > > > the data bearing channels are  treated by the end nodes and the
> > > > > intermediate nodes.
> > > > >
> > > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > > the virtually
> > > > > concatenated channels as they would treat independent channels. The
> > > > > end points, however, treat these channels as "bonded"
> > > > together, and must
> > > > > have hardware and software support to "glue" the data
> > > > arriving on these
> > > > > channels together appropriately. (For instance, the hardware must
> > > > > support compensation for the differential delay that the component
> > > > > channels of the virtually concatenated stream may suffer.)
> > > > >
> > > > > > Another field RNC (Reuested Number of
> > > > > > Components) defines the number of such components requested.
> > > > > > My understanding is that if RNC is 2 and signal type is
> > > > STM-1. Then it
> > > > > > means that 2 STM-1 signals are requested and these are
> > > > concatenated
> > > > > > according to the RGT specified.
> > > > >
> > > > > Your understanding is correct.
> > > > >
> > > > > > Does this mean, the number of labels
> > > > > > requested depend on the RNC field ?  This means that is
> > > > RNC is "X",
> > > > > > then "X" number of labels are to be returned in Label
> > > > Mapping message
> > > > > > and the labels returned should be in accrodance with the requested
> > > > > > signal type.
> > > > >
> > > > > Not quite. The number of labels will be determined by a
> > > > combination of
> > > > > the RNC and RGT.
> > > > >
> > > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > > channel (which is transparent
> > > > > only at the path level, so that line and section overheads
> > > > are not to be
> > > > > preserved across SONET equipment), and see what happens in
> > > > the various
> > > > > cases.
> > > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > >
> > > > > If RGT = contiguous standard or contiguous arbitrary
> > > > concatenation, then
> > > > > only a _single_ label is returned (that one that denotes
> > > > the time slot at
> > > > > which the first of the concatenated channels begins).
> > > > >
> > > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > > labels (or
> > > > > # of labels = RNC in the general case) will
> > > > > need to be returned in the label mapping message (namely,
> > > > the times slots
> > > > > that denote where _each_ of the component STS-1s of the
> > > > STS-3 signal is to
> > > > > be placed, since in these cases the component STS-1s need
> > > > not occur in
> > > > > contiguous time slots).
> > > > >
> > > > > > Please clarify these doubts.
> > > > >
> > > > > Hope the above helps.
> > > > >
> > > > > > Can somebody please brief me on grouping type Bundle ?
> > > > >
> > > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > > setting up multiple, independent
> > > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > > three channels of STS-1 granularity, where each would be totally
> > > > > independent of the others, both at the intermediate nodes and at
> > > > > the end nodes.
> > > > >
> > > > > If, however, RGT=virtual concatenation, then what would really be
> > > > > setup in the SONET network would again be 3 channels of STS-1
> > > > > granularity, which to the intermediate nodes would be no different
> > > > > from the case above. To the end nodes, however, it would mean that
> > > > > they need to have the capability to handle virtually concatenated
> > > > > SONET channels (which means they need to be capable of appropriately> 
> > > > > dividing traffic across them [at the in> put], and "glueing" them back
> > > > > together [at the output]).
> > > > >
> > > > > > Is there any additional capability required in the network for
> > > > > > supporting different types of grouping types (RGTs) ?
> > > > >
> > > > > Not sure what you mean by "additional" capability? In "addition"
> > > > > to what?
> > > > >
> > > > > For contiguous standard concatenation, the network nodes need to
> > > > > be able to support standard SDH/SONET concatenation.
> > > > > For continuous arbitrary concatenation, the network nodes involved
> > > > > in the establishment of such a channel, need to be able to support
> > > > > arbitrary concatenation.
> > > > > For virtual concatenation, the intermediate nodes through which
> > > > > the channle passes need no additional functionality, but the
> > > > > end nodes must be able to support the processing of virtually
> > > > > concatenated channels.
> > > > > For bundling, absolutely no special functionality is required
> > > > > in either the intermediate nodes or the end nodes.
> > > > >
> > > > >
> > > > > >
> > > >
> 

Delivery-date: Tue, 27 Mar 2001 23:18:04 -0800
From: Heiles Juergen <[email-masked]>
To: "'Vishal Sharma'" <[email-masked]>, "'Hai Vodinh'" <[email-masked]>, [email-masked]
Cc: Heiles Juergen <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Wed, 28 Mar 2001 09:15:36 +0200

Vishal, Hai,

I fully agree with you for the LCAS case. With LCAS you can add or remove STS-SPEs or VT to increase or decrease the bandwdidth. But note that a new SPE/VT could take the same route or a diverse route as the already established SPE/VT cnnections.

Juergen

> -----Original Message-----
> From:	Vishal Sharma [SMTP:[email-masked]]
> Sent:	Friday, March 23, 2001 9:52 AM
> To:	'Hai Vodinh'; [email-masked]
> Cc:	[email-masked]; [email-masked]'
> Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> 
> Neil and Juergen,
> 
> I think Hai has already made the point. When I was talking about change
> in bandwidth, I was implicitly assuming that Hai was referring to the
> virtual concatenation case. (Correct me if I am wrong, but I didn't 
> think there was any other situation, proposed in the standards, 
> where you could dynamically change the bandwidth of an existing SONET
> channel.)
> [Although, one might conceive of situations where implementations that
> support
> arbitrary concatenation might allow for one to increase the bandwidth
> of an existing circuit simply by adding more STS-1s to it. For instance,
> if one was switching an arbitrarily concatenated STS-5, and wanted to make
> it an STS-7 (assuming that the 2 other STS-1s were contiguous with the
> 5 STS-1s that formed the STS-5 signal), one might be able to do it.]
> 
> I understand that if you wanted to setup
> a totally different SONET/SDH channel (with a different bandwidth),
> you would need to go the "create new->switch_to_new->delete old"
> route.
> 
> Also, Neil, I did read your earlier email. The reason I did not think that
> that comment applied here was because (I thought) the current discussion
> was only in the context of virtual concatenation with LCAS, 
> since that appears to be the only scheme which allows for the dynamic
> addition or deletion of channels to an existing (virtually 
> concatenated) connection.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:[email-masked]]
> > Sent: Thursday, March 22, 2001 12:56 PM
> > To: [email-masked]
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Neil
> > 
> > The 'create_new->switch_to_new->delete_old' scheme seems to 
> > me to be fairly
> > inefficient mechanism for making small bandwidth change to large pipe.
> > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would 
> > have to first
> > make a sts-1-46v, switch the client signal over, then delete 
> > the original
> > sts-1-43v.  I do agree that it is a more straight forward way 
> > to achieve the
> > goal, it is probably also simpler to keep track of the sts-1s 
> > also.  I think
> > however if bandwidth modification (to existing pipe) is an 
> > important service
> > then we need a more efficient mechanism. I'm not saying that 
> > this would be
> > easy.
> > 
> > My question to carriers would be: is b/w modification for virtually
> > concatenated SPE important? in the short term & long term?
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, March 22, 2001 1:38 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Vishal....you asked (in mail below) for operator input.....perhaps you
> > missed this item I posted Wed 14/03/2001 13:35 on the thread 
> > 'RE: Three
> > GMPLS related IDs' against this ID from Yangguang Xu
> > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> > intra-domain-0
> > 0.txt
> > 
> > <prior text snipped NH>
> > 10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
> > network with fixed BW selection at trail creation time it is 
> > very hard to
> > see what a 'modify' action could be....other than perhaps a change of> 
> > restoration priority and/or change of dedicated back-up 
> > trail/resource.  If
> > there is any notion of (working) BW change here (be it a 
> > scalar magnitude
> > change, ie same route, or a vector change, ie new route (with 
> > or without a
> > scalar magnitude change)), it would seem to me that this is 
> > really a new
> > pair of 'create_new->switch_to_new->delete_old' actions.  I 
> > note however
> > that this has been marked as TBD, but I think it would help 
> > if it was made
> > clear that BW changes cannot (IMO) be a single 'modify' action.
> > <post text snipped NH>
> > 
> > So in essence I agreed with what Juergen is saying.
> > 
> > neil
> > 
> > > -----Original Message-----
> > > From: Heiles Juergen [mailto:[email-masked]]
> > > Sent: 22 March 2001 09:07
> > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > 
> > > Vishal,
> > > 
> > > in the circuit switched world he connection has a fixed 
> > > bandwidth. You cannot change the bandwidth. You have to tear 
> > > down the connection and set-up a new one with a different 
> > > bandwidth. For example if you want to change from VC-3 
> > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> > > released and a VC-4 connection is setup. The route could be 
> > > different as some equipment migth support VC-3 but not VC-4s 
> > > or vice versa.
> > > Virtual concatenation toegether with LCAS provides 
> > > flexibility in certain steps. However it applies only to the 
> > > end points as you mentioned. Between the end points you still 
> > > setup connections with fixed bandwidth.
> > > 
> > > Regards
> > > 
> > > Juergen
> > > 
> > > > -----Original Message-----
> > > > From:	Vishal Sharma [SMTP:[email-masked]]
> > > > Sent:	Thursday, March 22, 2001 9:36 AM
> > > > To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc:	[email-masked]; Greg Bernstein (E-mail)
> > > > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > > > 
> > > > Hai,
> > > > 
> > > > Yes, now that you mention it, it probably is an important 
> > > capability.
> > > > (Although,
> > > > I am not sure how soon it needs to be made available.)
> > > > [Again, any carriers listening on this channel?? "Hello, 
> > calling all
> > > > carriers... we need some service provider input here."]
> > <snipped to end NH>
> > 

Delivery-date: Tue, 27 Mar 2001 20:57:57 -0800
Date: Tue, 27 Mar 2001 20:55:36 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Two-octet bandwidth values
Cc: Kireeti Kompella <[email-masked]>, [email-masked]
To: Qingming Ma <[email-masked]>

Well maybe the right thing to do is not to use ISIS as a reliable 
multicast mechanism and hence not overload the routing protocol by 
flooding all sorts of G-MPLS, hierarchical LSP and also WSJ ticker 
information ;-)

I would agree that the information that is being flooded is remotely 
routing related (although not directly related to IP) but is there a way 
to create another PDU type that can be flooded via ISIS but has 
different packet formats and does not crowd the existing sub-TLV.

Coming to your comment about the math on the OC768c, even if I was 
wrong, 67 Mbps is still a large value to be off by. That is larger than 
a DS1, do you think that people will not notice some TE calculation 
being off by 67 Mbps? What if I were bonding (PPP LBD is a WG item in 
PPP EXT WG) 10 OC192c's, then I will be off by more than 100 Mbps.

I am repeating myself here, but I think we have better things to work on 
then redefining existing TE TLVs.

Bora

On Tuesday, March 27, 2001, at 07:11 PM, Qingming Ma wrote:

> At 05:15 PM 3/26/01 -0800, Bora Akyol wrote:
>
>> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
>>
>>> Let's get the ball rolling.  Please send questions and comments to the
>>> list.  Here are mine:
>>>
>>> Questions to vendors:
>>> 1) Is floating point arithmetic a burdensome requirement?  Is having
>>>    a new library of functions for the two-octet "floating point"
>>>    representation a burdensome requirement?
>>
>> I don't see what exactly is wrong with the present approach, we have 
>> no problem working with the present TE TLVs and no problems with 
>> floating point.
>
> No one said the present approach is wrong. The problem you will soon
> use out all sub-TLLV space in ISIS for further extensions. You can work
> with the  present  TE TLVs,  if there is enough sub-TLV space.
>
>
>>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>>>    that more bandwidth TLVs are being proposed)?
>>>    (a) for ISIS?
>>>    (b) for OSPF?
>>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>>>        have different formats for the two protocols?
>>
>> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I 
>> think halving the size of the bandwidth TLVs is not very useful. It 
>> causes yet another "transition" problem just as people are getting 
>> used to the present scheme.
>
> Again, it may not be very useful, if there is sufficient sub-TLV space.
>
>
>
>>> Questions to vendors & carriers:
>>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>> This depends a lot on the bandwidth, on an OC768c this will translate 
>> to a whopping 400 Mbps, which to me is inadequate.  Our routers also 
>> support bundled links which we call "Bonds" that can achieve 
>> bandwidths much larger than 40 Gbps. So my answer to 10 bits of 
>> dynamic range is NO.
>
> First, you did not do your Math correct. If you have bandwidth
> value as large as OC768c, the accuracy can be at 67 Mbps
> level, rather than 400 Mbps. When you use the bandwidth value
> to select a path, I don't think you need to worry about the bandwidth
> value 67 Mbps more or less if the link has available bandwidth
> at 40 Gbps level.
>
>
>>> 2) Are you in favor of this draft, or against?
>>
>> Seems like we have more important stuff to focus on then this 
>> particular topic.
>>
>> Bora
>

Delivery-date: Tue, 27 Mar 2001 20:57:54 -0800
Date: Tue, 27 Mar 2001 20:55:34 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Two-octet bandwidth values
Cc: "Kireeti Kompella" <[email-masked]>, "CCAMP List" <[email-masked]>
To: "Frank Hujber" <[email-masked]>

I believe the argument is over an accuracy of 67 Mbps (out of an OC768c) 
not 10s of bits/sec.

I am not convinced that this TLV is needed.

Bora

On Tuesday, March 27, 2001, at 07:03 PM, Frank Hujber wrote:

> I guess, if the need to specify down to the tesn of bits per second is
> critical, then the only way is to find a way to expand the IEEE floating
> point format. Ugly.
>
> Is the possibility of adding a sub-TLV for this all that objectionable?
>
> Frank
> [email-masked]
>
> ----- Original Message -----
> From: "Bora Akyol" <[email-masked]>
> To: "Frank Hujber" <[email-masked]>
> Cc: "Kireeti Kompella" <[email-masked]>; "CCAMP List"
> <[email-masked]>; "John Drake" <[email-masked]>
> Sent: Tuesday, March 27, 2001 8:08 PM
> Subject: Re: Two-octet bandwidth values
>
>
>> Frank
>>
>> Bonds are not proprietary, our implementation (even though implemented
>> independently and without knowledge of the document) is quite a like 
>> the
>> PPP LBD draft in the PPP-EXT working group.
>>
>> The point is that 10 bits is not enough to represent large chunks of
>> bandwidth accurately.
>>
>> Bora
>>
>>
>> On Tuesday, March 27, 2001, at 01:44 PM, Frank Hujber wrote:
>>
>>> It occurs to me that the smallest increment of reservable bandwidth,
>>> from a
>>> practical perspective, is a DS1 (1.544 Mbps). If this is so, why do we
>>> need
>>> to be able to represent values to +/- 10bps?
>>>
>>> The builders of OXCs and PXCs can see down the road to OC-3072 even
>>> though
>>> there's not much being spent on it in the lab just yet, and some of
>>> aren't
>>> even looking much further back than OC-48. "Bonds" sound linke a
>>> proprietary
>>> implementation which no one will want to be beholden to.
>>>
>>> This ought to be considered further, even if it has to be put in a
>>> separate
>>> sub-TLV for backward compatibility reasons.
>>>
>>> Frank Hujber
>>> [email-masked]
>>> ----- Original Message -----
>>> From: John Drake <[email-masked]>
>>> To: 'Bora Akyol' <[email-masked]>; Kireeti Kompella
>>> <[email-masked]>
>>> Cc: <[email-masked]>; <[email-masked]>
>>> Sent: Monday, March 26, 2001 8:36 PM
>>> Subject: RE: Two-octet bandwidth values
>>>
>>>
>>>> ditto
>>>>
>>>> -----Original Message-----
>>>> From: Bora Akyol [mailto:[email-masked]]
>>>> Sent: Monday, March 26, 2001 5:16 PM
>>>> To: Kireeti Kompella
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: Re: Two-octet bandwidth values
>>>>
>>>>
>>>>
>>>> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
>>>>
>>>>> Let's get the ball rolling.  Please send questions and comments to 
>>>>> the
>>>>> list.  Here are mine:
>>>>>
>>>>> Questions to vendors:
>>>>> 1) Is floating point arithmetic a burdensome requirement?  Is having
>>>>>    a new library of functions for the two-octet "floating point"
>>>>>    representation a burdensome requirement?
>>>>>
>>>>
>>>> I don't see what exactly is wrong with the present approach, we have 
>>>> no
>>>> problem working with the present TE TLVs and no problems with 
>>>> floating
>>>> point.
>>>>
>>>>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>>>>>    that more bandwidth TLVs are being proposed)?
>>>>>    (a) for ISIS?
>>>>>    (b) for OSPF?
>>>>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>>>>>        have different formats for the two protocols?
>>>>>
>>>>
>>>> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I
>>>> think
>>>> halving the size of the bandwidth TLVs is not very useful. It causes
>>>> yet
>>>> another "transition" problem just as people are getting used to the
>>>> present scheme.
>>>>
>>>>
>>>>> Questions to vendors & carriers:
>>>>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>>>>>
>>>> This depends a lot on the bandwidth, on an OC768c this will translate
>>>> to
>>>> a whopping 400 Mbps, which to me is inadequate.  Our routers also
>>>> support bundled links which we call "Bonds" that can achieve 
>>>> bandwidths
>>>> much larger than 40 Gbps. So my answer to 10 bits of dynamic range is
>>>> NO.
>>>>
>>>>> 2) Are you in favor of this draft, or against?
>>>>>
>>>>
>>>> Seems like we have more important stuff to focus on then this
>>>> particular
>>>> topic.
>>>>
>>>> Bora
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Tue, 27 Mar 2001 20:18:36 -0800
Date: Tue, 27 Mar 2001 23:17:06 -0500
From: "Philip Matthews" <[email-masked]>
Organization: Nortel Networks
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: Two-octet bandwidth values

I don't see the advantage of making the change at this late date,
at least not to the existing TLVs. (We could use this for new
TLVs). 

As I see it, backwards compatibility is a big issue.
What is the carrot that convinces a carrier to make the switch
from the old-style TLVs to the new one?

- Philip Matthews
  Nortel Networks

Delivery-date: Tue, 27 Mar 2001 19:11:02 -0800
Date: Tue, 27 Mar 2001 19:11:06 -0800
To: Bora Akyol <[email-masked]>, Kireeti Kompella <[email-masked]>
From: Qingming Ma <[email-masked]>
Subject: Re: Two-octet bandwidth values
Cc: [email-masked]

At 05:15 PM 3/26/01 -0800, Bora Akyol wrote:

>On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
>
>>Let's get the ball rolling.  Please send questions and comments to the
>>list.  Here are mine:
>>
>>Questions to vendors:
>>1) Is floating point arithmetic a burdensome requirement?  Is having
>>    a new library of functions for the two-octet "floating point"
>>    representation a burdensome requirement?
>
>I don't see what exactly is wrong with the present approach, we have no 
>problem working with the present TE TLVs and no problems with floating point.

No one said the present approach is wrong. The problem you will soon
use out all sub-TLLV space in ISIS for further extensions. You can work
with the  present  TE TLVs,  if there is enough sub-TLV space.

>>2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>>    that more bandwidth TLVs are being proposed)?
>>    (a) for ISIS?
>>    (b) for OSPF?
>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>>        have different formats for the two protocols?
>
>I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I think 
>halving the size of the bandwidth TLVs is not very useful. It causes yet 
>another "transition" problem just as people are getting used to the 
>present scheme.

Again, it may not be very useful, if there is sufficient sub-TLV space.

>>Questions to vendors & carriers:
>>1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>This depends a lot on the bandwidth, on an OC768c this will translate to a 
>whopping 400 Mbps, which to me is inadequate.  Our routers also support 
>bundled links which we call "Bonds" that can achieve bandwidths much 
>larger than 40 Gbps. So my answer to 10 bits of dynamic range is NO.

First, you did not do your Math correct. If you have bandwidth
value as large as OC768c, the accuracy can be at 67 Mbps
level, rather than 400 Mbps. When you use the bandwidth value
to select a path, I don't think you need to worry about the bandwidth
value 67 Mbps more or less if the link has available bandwidth
at 40 Gbps level.

>>2) Are you in favor of this draft, or against?
>
>Seems like we have more important stuff to focus on then this particular 
>topic.
>
>Bora

Delivery-date: Tue, 27 Mar 2001 19:05:59 -0800
From: "Frank Hujber" <[email-masked]>
To: "Bora Akyol" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>,	"CCAMP List" <[email-masked]>,	"John Drake" <[email-masked]>
Subject: Re: Two-octet bandwidth values
Date: Tue, 27 Mar 2001 22:03:15 -0500

I guess, if the need to specify down to the tesn of bits per second is
critical, then the only way is to find a way to expand the IEEE floating
point format. Ugly.

Is the possibility of adding a sub-TLV for this all that objectionable?

Frank
[email-masked]

----- Original Message -----
From: "Bora Akyol" <[email-masked]>
To: "Frank Hujber" <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>; "CCAMP List"
<[email-masked]>; "John Drake" <[email-masked]>
Sent: Tuesday, March 27, 2001 8:08 PM
Subject: Re: Two-octet bandwidth values

> Frank
>
> Bonds are not proprietary, our implementation (even though implemented
> independently and without knowledge of the document) is quite a like the
> PPP LBD draft in the PPP-EXT working group.
>
> The point is that 10 bits is not enough to represent large chunks of
> bandwidth accurately.
>
> Bora
>
>
> On Tuesday, March 27, 2001, at 01:44 PM, Frank Hujber wrote:
>
> > It occurs to me that the smallest increment of reservable bandwidth,
> > from a
> > practical perspective, is a DS1 (1.544 Mbps). If this is so, why do we
> > need
> > to be able to represent values to +/- 10bps?
> >
> > The builders of OXCs and PXCs can see down the road to OC-3072 even
> > though
> > there's not much being spent on it in the lab just yet, and some of
> > aren't
> > even looking much further back than OC-48. "Bonds" sound linke a
> > proprietary
> > implementation which no one will want to be beholden to.
> >
> > This ought to be considered further, even if it has to be put in a
> > separate
> > sub-TLV for backward compatibility reasons.
> >
> > Frank Hujber
> > [email-masked]
> > ----- Original Message -----
> > From: John Drake <[email-masked]>
> > To: 'Bora Akyol' <[email-masked]>; Kireeti Kompella
> > <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Monday, March 26, 2001 8:36 PM
> > Subject: RE: Two-octet bandwidth values
> >
> >
> >> ditto
> >>
> >> -----Original Message-----
> >> From: Bora Akyol [mailto:[email-masked]]
> >> Sent: Monday, March 26, 2001 5:16 PM
> >> To: Kireeti Kompella
> >> Cc: [email-masked]; [email-masked]
> >> Subject: Re: Two-octet bandwidth values
> >>
> >>
> >>
> >> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
> >>
> >>> Let's get the ball rolling.  Please send questions and comments to the
> >>> list.  Here are mine:
> >>>
> >>> Questions to vendors:
> >>> 1) Is floating point arithmetic a burdensome requirement?  Is having
> >>>    a new library of functions for the two-octet "floating point"
> >>>    representation a burdensome requirement?
> >>>
> >>
> >> I don't see what exactly is wrong with the present approach, we have no
> >> problem working with the present TE TLVs and no problems with floating
> >> point.
> >>
> >>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
> >>>    that more bandwidth TLVs are being proposed)?
> >>>    (a) for ISIS?
> >>>    (b) for OSPF?
> >>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
> >>>        have different formats for the two protocols?
> >>>
> >>
> >> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I
> >> think
> >> halving the size of the bandwidth TLVs is not very useful. It causes
> >> yet
> >> another "transition" problem just as people are getting used to the
> >> present scheme.
> >>
> >>
> >>> Questions to vendors & carriers:
> >>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
> >>>
> >> This depends a lot on the bandwidth, on an OC768c this will translate
> >> to
> >> a whopping 400 Mbps, which to me is inadequate.  Our routers also
> >> support bundled links which we call "Bonds" that can achieve bandwidths
> >> much larger than 40 Gbps. So my answer to 10 bits of dynamic range is
> >> NO.
> >>
> >>> 2) Are you in favor of this draft, or against?
> >>>
> >>
> >> Seems like we have more important stuff to focus on then this
> >> particular
> >> topic.
> >>
> >> Bora
> >>
> >>
> >
>
>

Delivery-date: Tue, 27 Mar 2001 17:12:24 -0800
Date: Tue, 27 Mar 2001 17:08:30 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Two-octet bandwidth values
Cc: "Kireeti Kompella" <[email-masked]>, "CCAMP List" <[email-masked]>, "John Drake" <[email-masked]>
To: "Frank Hujber" <[email-masked]>

Frank

Bonds are not proprietary, our implementation (even though implemented 
independently and without knowledge of the document) is quite a like the 
PPP LBD draft in the PPP-EXT working group.

The point is that 10 bits is not enough to represent large chunks of 
bandwidth accurately.

Bora

On Tuesday, March 27, 2001, at 01:44 PM, Frank Hujber wrote:

> It occurs to me that the smallest increment of reservable bandwidth, 
> from a
> practical perspective, is a DS1 (1.544 Mbps). If this is so, why do we 
> need
> to be able to represent values to +/- 10bps?
>
> The builders of OXCs and PXCs can see down the road to OC-3072 even 
> though
> there's not much being spent on it in the lab just yet, and some of 
> aren't
> even looking much further back than OC-48. "Bonds" sound linke a 
> proprietary
> implementation which no one will want to be beholden to.
>
> This ought to be considered further, even if it has to be put in a 
> separate
> sub-TLV for backward compatibility reasons.
>
> Frank Hujber
> [email-masked]
> ----- Original Message -----
> From: John Drake <[email-masked]>
> To: 'Bora Akyol' <[email-masked]>; Kireeti Kompella 
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, March 26, 2001 8:36 PM
> Subject: RE: Two-octet bandwidth values
>
>
>> ditto
>>
>> -----Original Message-----
>> From: Bora Akyol [mailto:[email-masked]]
>> Sent: Monday, March 26, 2001 5:16 PM
>> To: Kireeti Kompella
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: Two-octet bandwidth values
>>
>>
>>
>> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
>>
>>> Let's get the ball rolling.  Please send questions and comments to the
>>> list.  Here are mine:
>>>
>>> Questions to vendors:
>>> 1) Is floating point arithmetic a burdensome requirement?  Is having
>>>    a new library of functions for the two-octet "floating point"
>>>    representation a burdensome requirement?
>>>
>>
>> I don't see what exactly is wrong with the present approach, we have no
>> problem working with the present TE TLVs and no problems with floating
>> point.
>>
>>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>>>    that more bandwidth TLVs are being proposed)?
>>>    (a) for ISIS?
>>>    (b) for OSPF?
>>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>>>        have different formats for the two protocols?
>>>
>>
>> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I 
>> think
>> halving the size of the bandwidth TLVs is not very useful. It causes 
>> yet
>> another "transition" problem just as people are getting used to the
>> present scheme.
>>
>>
>>> Questions to vendors & carriers:
>>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>>>
>> This depends a lot on the bandwidth, on an OC768c this will translate 
>> to
>> a whopping 400 Mbps, which to me is inadequate.  Our routers also
>> support bundled links which we call "Bonds" that can achieve bandwidths
>> much larger than 40 Gbps. So my answer to 10 bits of dynamic range is 
>> NO.
>>
>>> 2) Are you in favor of this draft, or against?
>>>
>>
>> Seems like we have more important stuff to focus on then this 
>> particular
>> topic.
>>
>> Bora
>>
>>
>

Delivery-date: Tue, 27 Mar 2001 13:43:29 -0800
From: "Frank Hujber" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>,	"CCAMP List" <[email-masked]>,	"John Drake" <[email-masked]>
Subject: Re: Two-octet bandwidth values
Date: Tue, 27 Mar 2001 16:44:26 -0500

It occurs to me that the smallest increment of reservable bandwidth, from a
practical perspective, is a DS1 (1.544 Mbps). If this is so, why do we need
to be able to represent values to +/- 10bps?

The builders of OXCs and PXCs can see down the road to OC-3072 even though
there's not much being spent on it in the lab just yet, and some of aren't
even looking much further back than OC-48. "Bonds" sound linke a proprietary
implementation which no one will want to be beholden to.

This ought to be considered further, even if it has to be put in a separate
sub-TLV for backward compatibility reasons.

Frank Hujber
[email-masked]
----- Original Message -----
From: John Drake <[email-masked]>
To: 'Bora Akyol' <[email-masked]>; Kireeti Kompella <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, March 26, 2001 8:36 PM
Subject: RE: Two-octet bandwidth values

> ditto
>
> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Monday, March 26, 2001 5:16 PM
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]
> Subject: Re: Two-octet bandwidth values
>
>
>
> On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:
>
> > Let's get the ball rolling.  Please send questions and comments to the
> > list.  Here are mine:
> >
> > Questions to vendors:
> > 1) Is floating point arithmetic a burdensome requirement?  Is having
> >    a new library of functions for the two-octet "floating point"
> >    representation a burdensome requirement?
> >
>
> I don't see what exactly is wrong with the present approach, we have no
> problem working with the present TE TLVs and no problems with floating
> point.
>
> > 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
> >    that more bandwidth TLVs are being proposed)?
> >    (a) for ISIS?
> >    (b) for OSPF?
> >    (c) if the answers for ISIS and OSPF differ, is it acceptable to
> >        have different formats for the two protocols?
> >
>
> I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I think
> halving the size of the bandwidth TLVs is not very useful. It causes yet
> another "transition" problem just as people are getting used to the
> present scheme.
>
>
> > Questions to vendors & carriers:
> > 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
> >
> This depends a lot on the bandwidth, on an OC768c this will translate to
> a whopping 400 Mbps, which to me is inadequate.  Our routers also
> support bundled links which we call "Bonds" that can achieve bandwidths
> much larger than 40 Gbps. So my answer to 10 bits of dynamic range is NO.
>
> > 2) Are you in favor of this draft, or against?
> >
>
> Seems like we have more important stuff to focus on then this particular
> topic.
>
> Bora
>
>

Envelope-to: [email-masked]
Delivery-date: Tue, 27 Mar 2001 08:08:45 -0800
Message-Id: <[email-masked]>
To: John Drake <[email-masked]>
cc: "'Bora Akyol'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Two-octet bandwidth values 
Date: Tue, 27 Mar 2001 11:03:42 -0500
From: George Swallow <[email-masked]>

> > 2) Are you in favor of this draft, or against?
> >
> 
> Seems like we have more important stuff to focus on then this particular 
> topic.

I agree.  Let's table this one.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Mon, 26 Mar 2001 21:10:37 -0800
Date: Mon, 26 Mar 2001 21:08:58 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: FW: Two-octet bandwidth values
Cc: [email-masked]
To: "[email-masked]'" <[email-masked]>

So it looks like the right thing to do is to separate non-routing 
essential TLVs from the routing essential TLVs.

It seems to me that the IGPs are being used as a reliable multicast 
protocol to distribute mostly non-routing related information.

Is there anyway in which we can distribute this information in a 
separate packet not limited by 244 bytes?

Bora

On Monday, March 26, 2001, at 08:38 PM, Qingming Ma wrote:

> Hello everyone,
>
> Thanks for comments!  As Dean pointed out, the focus of this
> draft is on space, particular ISIS sub-TLV space,  which is
> limited to 244 bytes (255 - 11). As stated in Tony Li's ISIS-TE
> extensions draft that there is no defined mechanism for extending
> sub-TLV space and wasting sub-TLV space is discouraged.
>
> Considering the current situation, the total sub-TLV size for generic
> TE extensions, GMPLS extensions, and DiffServ TE extensions
> together is 222 bytes without taking into account of alignment.
> There is no enough sub-TLV space for the proposed LSP
> restoration draft if we want to go with them. More extensions related to
> TE and/or Optical Control may be proposed in future. New TLVs
> may have to be defined  to accommodate new extensions if we do not
> conserve sub-TLV space now. By using two-octet BW values, the
> total sub-TLV size for all three types of extensions mentioned above
> can be reduced to 138 bytes.
>
> For OSPF, the sub-TLV space is not a urgent issue at this time.
> But short LSAs are always encouraged to reduce routing overhead.
>
> For backward compatibility, we may define new types for BW
> sub-TLVs that use two octets. Since there are plenty of unused
> types, it should not be a problem.
>
> Thanks,
>
> Qingming
>
> At 03:26 PM 3/26/01 -0800, Cheng, Dean wrote:
>
>
>> Also, since the "draft-katz-yeung-ospf-traffic-03.txt"
>> may be going to a RFC soon, would it be necessary to
>> consult with the OSPF WG at this point as well ?
>>
>> -----Original Message-----
>> From: Kireeti Kompella [mailto:[email-masked]]
>> Sent: Sunday, March 25, 2001 8:06 PM
>> To: [email-masked]
>> Subject: Two-octet bandwidth values
>>
>>
>> Let's get the ball rolling.  Please send questions and comments to the
>> list.  Here are mine:
>>
>> Questions to vendors:
>> 1) Is floating point arithmetic a burdensome requirement?  Is having
>>    a new library of functions for the two-octet "floating point"
>>    representation a burdensome requirement?
>>
>> I think the point for the two-octet approach is to save
>> packet space (or link resource), not work complexity.
>>
>> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>>    that more bandwidth TLVs are being proposed)?
>>    (a) for ISIS?
>> Yes
>>    (b) for OSPF?
>> Yes
>>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>>        have different formats for the two protocols?
>>
>> Questions to vendors & carriers:
>> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>>
>> Yes
>> 2) Are you in favor of this draft, or against?
>>
>> Yes
>>
>> Kireeti.
>>
>> Dean
>
>

Delivery-date: Mon, 26 Mar 2001 20:40:18 -0800
From: Qingming Ma <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: FW: Two-octet bandwidth values
Date: Mon, 26 Mar 2001 20:38:40 -0800

Hello everyone,

Thanks for comments!  As Dean pointed out, the focus of this
draft is on space, particular ISIS sub-TLV space,  which is
limited to 244 bytes (255 - 11). As stated in Tony Li's ISIS-TE
extensions draft that there is no defined mechanism for extending
sub-TLV space and wasting sub-TLV space is discouraged.

Considering the current situation, the total sub-TLV size for generic
TE extensions, GMPLS extensions, and DiffServ TE extensions
together is 222 bytes without taking into account of alignment.
There is no enough sub-TLV space for the proposed LSP
restoration draft if we want to go with them. More extensions related to
TE and/or Optical Control may be proposed in future. New TLVs
may have to be defined  to accommodate new extensions if we do not
conserve sub-TLV space now. By using two-octet BW values, the
total sub-TLV size for all three types of extensions mentioned above
can be reduced to 138 bytes.

For OSPF, the sub-TLV space is not a urgent issue at this time.
But short LSAs are always encouraged to reduce routing overhead.

For backward compatibility, we may define new types for BW
sub-TLVs that use two octets. Since there are plenty of unused
types, it should not be a problem.

Thanks,

Qingming

At 03:26 PM 3/26/01 -0800, Cheng, Dean wrote:

>Also, since the "draft-katz-yeung-ospf-traffic-03.txt"
>may be going to a RFC soon, would it be necessary to
>consult with the OSPF WG at this point as well ?
>
>-----Original Message-----
>From: Kireeti Kompella [mailto:[email-masked]]
>Sent: Sunday, March 25, 2001 8:06 PM
>To: [email-masked]
>Subject: Two-octet bandwidth values
>
>
>Let's get the ball rolling.  Please send questions and comments to the
>list.  Here are mine:
>
>Questions to vendors:
>1) Is floating point arithmetic a burdensome requirement?  Is having
>    a new library of functions for the two-octet "floating point"
>    representation a burdensome requirement?
>
>I think the point for the two-octet approach is to save
>packet space (or link resource), not work complexity.
>
>2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>    that more bandwidth TLVs are being proposed)?
>    (a) for ISIS?
>Yes
>    (b) for OSPF?
>Yes
>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>        have different formats for the two protocols?
>
>Questions to vendors & carriers:
>1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>
>Yes
>2) Are you in favor of this draft, or against?
>
>Yes
>
>Kireeti.
>
>Dean

Delivery-date: Mon, 26 Mar 2001 17:41:41 -0800
From: John Drake <[email-masked]>
To: 'Bora Akyol' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Two-octet bandwidth values
Date: Mon, 26 Mar 2001 17:36:32 -0800

ditto

-----Original Message-----
From: Bora Akyol [mailto:[email-masked]]
Sent: Monday, March 26, 2001 5:16 PM
To: Kireeti Kompella
Cc: [email-masked]; [email-masked]
Subject: Re: Two-octet bandwidth values

On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:

> Let's get the ball rolling.  Please send questions and comments to the
> list.  Here are mine:
>
> Questions to vendors:
> 1) Is floating point arithmetic a burdensome requirement?  Is having
>    a new library of functions for the two-octet "floating point"
>    representation a burdensome requirement?
>

I don't see what exactly is wrong with the present approach, we have no 
problem working with the present TE TLVs and no problems with floating 
point.

> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>    that more bandwidth TLVs are being proposed)?
>    (a) for ISIS?
>    (b) for OSPF?
>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>        have different formats for the two protocols?
>

I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I think 
halving the size of the bandwidth TLVs is not very useful. It causes yet 
another "transition" problem just as people are getting used to the 
present scheme.

> Questions to vendors & carriers:
> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>
This depends a lot on the bandwidth, on an OC768c this will translate to 
a whopping 400 Mbps, which to me is inadequate.  Our routers also 
support bundled links which we call "Bonds" that can achieve bandwidths 
much larger than 40 Gbps. So my answer to 10 bits of dynamic range is NO.

> 2) Are you in favor of this draft, or against?
>

Seems like we have more important stuff to focus on then this particular 
topic.

Bora

Delivery-date: Mon, 26 Mar 2001 17:18:29 -0800
Date: Mon, 26 Mar 2001 17:15:51 -0800
From: Bora Akyol <[email-masked]>
Subject: Re: Two-octet bandwidth values
Cc: [email-masked], [email-masked]
To: Kireeti Kompella <[email-masked]>

On Sunday, March 25, 2001, at 08:05 PM, Kireeti Kompella wrote:

> Let's get the ball rolling.  Please send questions and comments to the
> list.  Here are mine:
>
> Questions to vendors:
> 1) Is floating point arithmetic a burdensome requirement?  Is having
>    a new library of functions for the two-octet "floating point"
>    representation a burdensome requirement?
>

I don't see what exactly is wrong with the present approach, we have no 
problem working with the present TE TLVs and no problems with floating 
point.

> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>    that more bandwidth TLVs are being proposed)?
>    (a) for ISIS?
>    (b) for OSPF?
>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>        have different formats for the two protocols?
>

I think it is unacceptable to have OSPF and ISIS TE TLVs differ. I think 
halving the size of the bandwidth TLVs is not very useful. It causes yet 
another "transition" problem just as people are getting used to the 
present scheme.

> Questions to vendors & carriers:
> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
>
This depends a lot on the bandwidth, on an OC768c this will translate to 
a whopping 400 Mbps, which to me is inadequate.  Our routers also 
support bundled links which we call "Bonds" that can achieve bandwidths 
much larger than 40 Gbps. So my answer to 10 bits of dynamic range is NO.

> 2) Are you in favor of this draft, or against?
>

Seems like we have more important stuff to focus on then this particular 
topic.

Bora

Delivery-date: Mon, 26 Mar 2001 15:29:56 -0800
From: "Cheng, Dean" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Two-octet bandwidth values
Date: Mon, 26 Mar 2001 15:26:35 -0800

-----Original Message-----
From: Cheng, Dean [mailto:[email-masked]]
Sent: Monday, March 26, 2001 3:22 PM
To: [email-masked]
Subject: Re: Two-octet bandwidth values

Also, since the "draft-katz-yeung-ospf-traffic-03.txt"
may be going to a RFC soon, would it be necessary to
consult with the OSPF WG at this point as well ?

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 8:06 PM
To: [email-masked]
Subject: Two-octet bandwidth values

Let's get the ball rolling.  Please send questions and comments to the
list.  Here are mine:

Questions to vendors:
1) Is floating point arithmetic a burdensome requirement?  Is having
   a new library of functions for the two-octet "floating point"
   representation a burdensome requirement?

I think the point for the two-octet approach is to save
packet space (or link resource), not work complexity.

2) Is halving the size of the bandwidth TLVs a big win (keep in mind
   that more bandwidth TLVs are being proposed)?
   (a) for ISIS?
Yes
   (b) for OSPF?
Yes
   (c) if the answers for ISIS and OSPF differ, is it acceptable to
       have different formats for the two protocols?

Questions to vendors & carriers:
1) Is 10 bits of dynamic range (0.1% accuracy) good enough?

Yes
2) Are you in favor of this draft, or against?

Yes

Kireeti.

Dean

Delivery-date: Mon, 26 Mar 2001 15:26:05 -0800
From: "Cheng, Dean" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Two-octet bandwidth values
Date: Mon, 26 Mar 2001 15:22:24 -0800

Also, since the "draft-katz-yeung-ospf-traffic-03.txt"
may be going to a RFC soon, would it be necessary to
consult with the OSPF WG at this point as well ? 

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 8:06 PM
To: [email-masked]
Subject: Two-octet bandwidth values

Let's get the ball rolling.  Please send questions and comments to the
list.  Here are mine:

Questions to vendors:
1) Is floating point arithmetic a burdensome requirement?  Is having
   a new library of functions for the two-octet "floating point"
   representation a burdensome requirement?

I think the point for the two-octet approach is to save
packet space (or link resource), not work complexity.

2) Is halving the size of the bandwidth TLVs a big win (keep in mind
   that more bandwidth TLVs are being proposed)?
   (a) for ISIS?
Yes
   (b) for OSPF?
Yes
   (c) if the answers for ISIS and OSPF differ, is it acceptable to
       have different formats for the two protocols?

Questions to vendors & carriers:
1) Is 10 bits of dynamic range (0.1% accuracy) good enough?

Yes
2) Are you in favor of this draft, or against?

Yes

Kireeti.

Dean

Delivery-date: Mon, 26 Mar 2001 14:53:23 -0800
Date: Mon, 26 Mar 2001 23:44:29 +0100
From: Giles Heron <[email-masked]>
Reply-To: [email-masked]
Organization: Gone2 Inc.
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: Two-octet bandwidth values

Kireeti Kompella wrote:
> 
> Let's get the ball rolling.  Please send questions and comments to the
> list.  Here are mine:
> 
> Questions to vendors:
> 1) Is floating point arithmetic a burdensome requirement?  Is having
>    a new library of functions for the two-octet "floating point"
>    representation a burdensome requirement?
> 2) Is halving the size of the bandwidth TLVs a big win (keep in mind
>    that more bandwidth TLVs are being proposed)?
>    (a) for ISIS?
>    (b) for OSPF?
>    (c) if the answers for ISIS and OSPF differ, is it acceptable to
>        have different formats for the two protocols?
> 
> Questions to vendors & carriers:
> 1) Is 10 bits of dynamic range (0.1% accuracy) good enough?

Yes

> 2) Are you in favor of this draft, or against?

In favour I think.

Simplistically (sp?) it would seem that things should have been this way
from the start?

Whether it is worth migrating to this, or whether we should just stick
with what we have, is another question...

Giles

-- 
============================================================
Giles Heron      Principal Network Architect      Gone2 Inc.
ph: +44 7880 506185         "if you build it they will yawn"
============================================================

Delivery-date: Mon, 26 Mar 2001 08:49:50 -0800
From: Andre Fredette <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: [email-masked]
Date: Mon, 26 Mar 2001 11:47:26 -0500
Subject: Re: LMP vs. NTIP vs. "funiculus"

Maarten,

You make some good points.  I believe that one of the objectives of LMP is 
to reproduce the capabilities currently present in the transport plane.  As 
you point out, with the advent of PXCs, some of the functionality 
traditionally handled with in-band SONET signalling needs to be exchanged 
in another way.  We will also be dealing with other technologies, such as 
Ethernet, that does not have built-in overhead.

Also, as we move towards distributed control of multi-vendor optical 
networks via GMPLS, open protocols are needed between the different nodes 
for exchanging the necessary information.  In addition to the fault 
handling capabilities you describe, I think we need discovery capabilities 
that will reduce the required manual configuration.

I believe there are two questions at hand:
(1)  Which protocol should be used to exchange the information in 
GMPLS-controlled networks?, and
(2)  What information needs to be exchanged?

The mpls, and now ccamp, working groups in the IETF have been working on 
LMP to solve question (1) for the past year.  Unless there is an 
overwhelming need to create a new protocol, I think we should stick with 
LMP (and I haven't even seen an underwhelming reason to switch :-).

Question (2) could use some additional discussion as it pertains to 
transport systems.  We have a proposal in draft-fredette-lmp-wdm-01.  Some 
good ideas exist in draft-sahay-ccamp-ntip-00, and you've made some good 
points in your note.

Andre

At 01:05 PM 3/26/2001 +0200, Maarten Vissers wrote:
>When looking at the LMP work I am have the impression at the moment that
>it is partly duplicating capabilities already present in the transport
>plane.

Delivery-date: Mon, 26 Mar 2001 06:39:25 -0800
Date: Mon, 26 Mar 2001 09:37:23 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: Fong Liaw <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Question regarding bi-directional connection set up - And Port-ID in  Label object

Eric, 

Please see my comments embedded:

>     I'm not sure that merging them is the right thing to do.
> They do not represent the same thing.  I believe the
> suggested label is the label the upstream would like the
> downstream to assign/recognize while the upstream label
> (I believe) is the label that the upstream _has_ assigned
> for the use of the downstream in a corresponding reverse
> LSP.
> 

I agree with your understanding. However, one of the key differences between
layer 1 transport network and IP network is data traffic direction is not
related to connection creation direction in transport network.

For example,  A----B----.....----F----G
(1) A uni-directional (user-traffic from A-->G) light path can be initiated
either by A or G
(2) So does a bi-directional light path

So, in layer 1 transport network, downstream/upstream is according to signaling
direction in control plane. It should have nothing to do with user plane
traffic.

Suggested label, upstream label ... are used to specify which trib to use for
light path. What we need to have is directionality attribute for label.

>     There are two problems with trying to force the two to
> be the same:
> 
> o    one is being assigned and the other is being requested
>       (assignment may not occur as requested), and

In layer 1 transport network, label is bound to certain physical resource.

Upstream label is only useful for a bi-directional LSP in a network where ports
are uni-directionally identified.

If all ports are uni-directional, this shouldn't happen. Label should
directionality attribute. 

> o    it is not always the case that the same label can be
>       assigned, in both directions, and associated with the
>       two halves of the same bi-directional LSP.
> 

Directionality should be one attribute for "bundling". Transmit ports, receive
ports and bi-directional ports can be assigned to different bundles, with unique
bundle ID.

Source node should choose the correct bundle ID for the connection it desires.

Regards,

Yangguang

Delivery-date: Mon, 26 Mar 2001 04:16:30 -0800
Cc: [email-masked]
Date: Mon, 26 Mar 2001 14:14:43 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

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

Neil,

Your observation that the VC-n-Xv LCAS trail isn't networked it self is
correct. The VC-n-Xv LCAS is to be viewed as a sublayer located between
VC-n Trail Termination functions and VC-n/Client Adaptation function.

> ... Further, although I am not familar with the actual LCAS framing
> algorithm I am sure it will impose constraints on the nature/type
> of add/remove L1 trails that can be used, ie I am sure you cannot
> mix arbitrary L1 server trails.....so this will impose BW
> granularity/route-availability constraints on the server SDH layer
> networks, as defined by the LCAS algorithm.

The VC-n-Xv signal definition assumes one type of VC-n (e.g. n=4) being
used in a virtual concatenated group. If you would like to identify this
as a "constraint" because you want to mix e.g. VC-12, VC-3 and VC-4
signals in one virtual concatenated group, I would have to agree with
you. But, I don't view it as a constraint myself, while nobody has
requested such type mix being supported.

A state of the art VC-4-Xv LCAS implementation transporting the ethernet
packets in a 1 GbE interface signal can accomodate 16 ms of differential
delay; this is about 3000 km of fiber. So as long as the X (X<=7) VC-4
signals are routed through the network with diff delays between each two
VC-4 routes of less than 16 ms, there are no constraints. 
I.e. you may even route each VC-4 signal in the group via different
fibers/ducts and different nodes to the endpoint; e.g. VC--4 #1 is
routed via nodes B,C,D to Z, VC-4 #2 via nodes E,F to Z, VC-4 #3 via
nodes G,H,I,J,K,L to Z, etc.

The delay compensation process in node Z is adaptive, and optimises its
operation for minimum transfer delay (latency). E.g. if diff delay is in
microsecond range, then latency is in microsecond range; if diff delay
is in millisecond range, then latency is in millisecond range; etc.

As such, I can't see any real constraints at this moment, and with
technology continuously enhancing (e.g. buffer sizes) it will only be
better in future.

Regards,

Maarten

[email-masked] wrote:
> 
> Hai Vodinh [mailto:[email-masked]] wrote Sent: 23 March 2001
> 23:13
> > Maarten,
> >
> > Thanks for the clear and concise explanation of how LCAS work.
> > The 'create_new->switch_to_new->delete_old' scheme definitely
> > won't work for LCAS then.
> >
> > Hai
> From the trail defined by the *LCAS framing perspective* this is
> correct....with the additional (minor, but subtley important) observation
> that these new (LCAS) layers are not networked themselves.  But you are
> still creating (and deleting, potentially at least) new (old) pt-pt trails
> in the SDH fabric. However, for the general pt-pt L1 trail case then what
> I/Juegen said is perfectly correct.....LCAS is an exception not the rule
> *and* it is because there is a new trail entity ('the LCAS group') being
> created above the basic L1 server fabric.  Further, although I am not
> familar with the actual LCAS framing algorithm I am sure it will impose
> constraints on the nature/type of add/remove L1 trails that can be used, ie
> I am sure you cannot mix arbitrary L1 server trails.....so this will impose
> BW granularity/route-availability constraints on the server SDH layer
> networks, as defined by the LCAS algorithm.
> neil
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Friday, March 23, 2001 2:38 AM
> > To: Hai Vodinh
> > Cc: [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Neil, Hai,
> >
> > LCAS  is developed to grow and shrink the bandwidth of a connection
> > without introducing any interruption to the bit stream going over it.
> > LCAS is the coordination protocol which synchronises the tail end with
> > the head end.
> >
> > So, when a service (manager) detects that it is time to increase the
> > bandwidth of the (virtual concatenated) connection, it will
> > request one
> > or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
> > Once the  trail is set-up (trail signal fail (TSF) condition clears at
> > tail end), the tail end will inform the head end via the LCAS protocol
> > (Member State from "fail" to "ok") that it is ready to include the new
> > trail into the connection. The head end will then include the
> > new trail
> > into the group, increasing the bandwidth of the connection;
> > before bits
> > are send over the new member, the tail end is notified that
> > at the next
> > frame start bits are transmitted over the new member as well.
> >
> > I hope this illustrates that you can not use
> > 'create_new->switch_to_new->delete_old' scheme in this case.
> >
> > Ethernet over SDH/SONET will be deploying this LCAS technique for its
> > bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
> > Ethernet streams. The Ethernet PHY will be terminated,
> > ethernet packets
> > extracted, encapsulated via GFP and mapped into virtual concatenated
> > STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
> > grows, the virtual concatenated signal is increased.
> >
> >       Note 1 - same can be done ofcourse for IP/PPP packet streams.
> >       Note 2 - mapping in virtual concatenated STS/VT/VC signal
> >                with LCAS may ofcourse be performed within the
> >                channalized interface port of an IP Router or
> >                Ethernet Switch. It is not required to do this in
> >                the SONET/SDH transport equipment.
> >
> > If such virtual concatenated group of STS/VT/VC signals is diverse
> > routed (half over one fiber, other half over another fiber), a signal
> > fail condition in one of the two fibers will not stop transport, only
> > reduce the bandwidth to 50%. The LCAS protocol will help to
> > temporarily
> > reduce the connection bandwidth being used to the fault free part, and
> > the signal flow is restored. As soon as the failed trails are
> > restored,
> > the LCAS protocol will include those again (hitless) in its connection
> > bandwidth, so that the full capacity can be used again.
> >
> >       Note 3 - if the virtual concatenated group is transported over
> >                3 different fibers, the failure group decreases and
> >                after a signal fail still 67% of the bandwidth is
> >                available.
> >
> > Recovery can be after a repair action, a protection switch
> > action in the
> > network's transport plane, a restoration action by the
> > network's control
> > plane restoring the failed trails, or a redial action of the trail
> > endpoints.
> >
> >
> >
> > Regards,
> >
> > Maarten
> >
> >
> > Hai Vodinh wrote:
> > >
> > > Neil
> > >
> > > The 'create_new->switch_to_new->delete_old' scheme seems to me to be
> > fairly
> > > inefficient mechanism for making small bandwidth change to
> > large pipe.
> > > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would
> > have to first
> > > make a sts-1-46v, switch the client signal over, then
> > delete the original
> > > sts-1-43v.  I do agree that it is a more straight forward
> > way to achieve
> > the
> > > goal, it is probably also simpler to keep track of the
> > sts-1s also.  I
> > think
> > > however if bandwidth modification (to existing pipe) is an important
> > service
> > > then we need a more efficient mechanism. I'm not saying
> > that this would be
> > > easy.
> > >
> > > My question to carriers would be: is b/w modification for virtually
> > > concatenated SPE important? in the short term & long term?
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, March 22, 2001 1:38 AM
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Vishal....you asked (in mail below) for operator
> > input.....perhaps you
> > > missed this item I posted Wed 14/03/2001 13:35 on the
> > thread 'RE: Three
> > > GMPLS related IDs' against this ID from Yangguang Xu
> > >
> > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> > intra-domain-0
> > > 0.txt
> > >
> > > <prior text snipped NH>
> > > 10      In section 5.4.1.5 'actions' on trails are defined.
> >  For a CO
> > > network with fixed BW selection at trail creation time it
> > is very hard to
> > > see what a 'modify' action could be....other than perhaps a
> > change of
> > > restoration priority and/or change of dedicated back-up
> > trail/resource.
> > If
> > > there is any notion of (working) BW change here (be it a
> > scalar magnitude
> > > change, ie same route, or a vector change, ie new route
> > (with or without a
> > > scalar magnitude change)), it would seem to me that this is
> > really a new
> > > pair of 'create_new->switch_to_new->delete_old' actions.  I
> > note however
> > > that this has been marked as TBD, but I think it would help
> > if it was made
> > > clear that BW changes cannot (IMO) be a single 'modify' action.
> > > <post text snipped NH>
> > >
> > > So in essence I agreed with what Juergen is saying.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Heiles Juergen [mailto:[email-masked]]
> > > > Sent: 22 March 2001 09:07
> > > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Vishal,
> > > >
> > > > in the circuit switched world he connection has a fixed
> > > > bandwidth. You cannot change the bandwidth. You have to tear
> > > > down the connection and set-up a new one with a different
> > > > bandwidth. For example if you want to change from VC-3
> > > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > > > released and a VC-4 connection is setup. The route could be
> > > > different as some equipment migth support VC-3 but not VC-4s
> > > > or vice versa.
> > > > Virtual concatenation toegether with LCAS provides
> > > > flexibility in certain steps. However it applies only to the
> > > > end points as you mentioned. Between the end points you still
> > > > setup connections with fixed bandwidth.
> > > >
> > > > Regards
> > > >
> > > > Juergen
> > > >
> > > > > -----Original Message-----
> > > > > From:       Vishal Sharma [SMTP:[email-masked]]
> > > > > Sent:       Thursday, March 22, 2001 9:36 AM
> > > > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > > > Subject:    RE: Please Clarify Doubts regarding RGT & RNC
> > > > >
> > > > > Hai,
> > > > >
> > > > > Yes, now that you mention it, it probably is an important
> > > > capability.
> > > > > (Although,
> > > > > I am not sure how soon it needs to be made available.)
> > > > > [Again, any carriers listening on this channel??
> > "Hello, calling all
> > > > > carriers... we need some service provider input here."]
> > > <snipped to end NH>
> >
--------------8B2773F431F64573694D8C9F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------8B2773F431F64573694D8C9F--

Delivery-date: Mon, 26 Mar 2001 03:07:27 -0800
Cc: q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Mon, 26 Mar 2001 13:05:17 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: LMP vs. NTIP vs. "funiculus"

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

When looking at the LMP work I am have the impression at the moment that
it is partly duplicating capabilities already present in the transport
plane.

The transport plane supports a "single fault, single alarm" capability
via its alarm suppression mechanism (AIS, FDI), as well as a "single
ended maintenance" capability via its remote signals mechanism (RDI/REI,
BDI/BEI).

With the introduction of optical fabric equipment (referred to as PXC or
OXC) an extension of the transport plane's operation is required. In the
past a "fabric" itself was never a stand-alone piece of equipment; it
was always surrounded by interface port units. The interconnect between
interface port unit and fabric unit was implemented as the backplane
within equipment.

With the separation of the interface port units from the fabric unit(s),
the backplane interface is becoming an external interface and needs to
be addressed in standards to guarantee interworking over this interface.

Within ITU-T SG15, this interface has been introduced by me some time
ago as the "funiculus" (umbilical cord) between the optical line system
(OLS, DWDM) and the optical fabric (OXC). It is envisaged to be part of
a new "Line-Fabric (LF)" interface OTM-LF, which is to be developed in
Q.11/15. 

Signals envisaged to go over it are:

- Forward Defect Indication (FDI) signal: 
	On detection of a transmission fault in the incoming
	(aggregate and/or tributary) signal(s), AIS is inserted
	in the downstream direction (towards the fabric card) in
	all tributary signals impacted by the fault - i.e. the
	FDI maintenance signal is transmitted in an in-band manner.
	If an interface port doesn't support this AIS insertion, an
	external FDI message is to be forwarded along the connection
	of the original signal.
	Also, if a signal fail condition is detected in the fabric, 
	FDI should be send downstream.
- Signal Fail, Signal Degrade status signal:
	On detection of a signal fail (SF) or signal degrade (SD)
	defect condition in the aggregate signal or in one or more
	of the tributary signals, a SF/SD indication signal (one per
	failed/degraded tributary signal) is send to the Fabric card
	via the backplane maintenance signal interface to initiate
	e.g. protection switching (transport plane) or restoration
	(control plane), and to provide status information on the 
	link connections (OK, FAIL and perhaps DEGRADE).
- Automatic Protection Switch (APS) signal:
	For the case of bi-directional protection switching, 
	the APS signal (of the aggregate) or APS signals of the 
	tributary signals are extracted in the port unit and send
	to the Fabric unit to coordinate bridge/selector operation
	at head end and tail end of the protected domain.
- Open Connection Indication signal:
	For the case an output port of the Fabric is not connected
	to an input port of the fabric, the Fabric will output an
	"Open Connection Indication (OCI)" maintenance signal to the
	interface port card suppressing the LOS alarm and to forward
	this information to downstream equipment.
- RDI/REI, BDI/DEI remote maintenance signals:
	For the case the protection implementation does not comply
	with its protection switch functional model (see for models
	T1X1.5/2000-079), RDI and REI information should be
	communicated to the Fabric, which will select the RDI/REI
	information from the "active" interface port card and forward
	this to both upstream "working" and "protection" interface
	port cards. 

In addition, this funiculus may have to include one or more management
comms channels (e.g. data communication channel, signalling
communication channel). If the network is a switched network, the
control plane will have to control a subset of the termination point
parameters (e.g. Expected Trace Identifier, error rate threshold,
TP-mode or ARC-mode, protection monitoring option (non-intrusive, tandem
connection), tandem connection monitoring, etc). If the control plane
process resides on the Fabric equipment, then this termination point
provisioning information has to be forwarded to the interface port cards
in the OLS.

Regards,

Maarten
--------------2616DF5F35846EF800470D3E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------2616DF5F35846EF800470D3E--

Delivery-date: Mon, 26 Mar 2001 00:49:10 -0800
Cc: q12/15 <[email-masked]>
Date: Mon, 26 Mar 2001 10:47:05 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: q12/15 <[email-masked]>
Subject: GMPLS and ASTN must control MI signals in atomic functions

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

All,

Ben Mack-Crane wrote in "Re: Please Clarify Doubts regarding RGT & RNC":
> For those familiar with functional modeling (and I recommend
> it to all as an excellent tool for understanding communication
> networks) ...

I fully support the above recommendation, and would like to start using
this transport network specification technique in the ccamp group.

	Note that the control plane (GMPLS, ASTN) must assign values
	to a subset of the Management Information (MI) signals which
	are defined in each atomic function. See below for more.

For those of you not familiar with functional modeling, here are some
references to introductions:

1) Broadband networking: ATM, SDH and SONET, Mike Sexton and Andy Reid 
http://www.artechhouse.com/artprogs/detail_disp?0-89006-578-0

2) Achieving global information networking, Eve Varma, Thierry Stephant
et al.
http://www.artechhouse.com/artprogs/detail_disp?0-89006-999-9

Furthermore ITU-T recommendations and ETSI standards contain
introductory sections:

* Network architecture level:
  --------------------------
ITU-T Recommendation G.805
http://ties.itu.int/u/tsg15/sg15/wp3/q12/g805/g805_0003.pdf

And the technology specific extensions G.803 (SDH), I.326 (ATM) and
G.872 (OTN).
http://www.itu.int/itudoc/itu-t/rec/g/g800up/g872.html
http://www.itu.int/itudoc/itu-t/rec/i/i326.html
http://ties.itu.int/u/tsg15/sg15/wp3/q12/g803/g803_0003.pdf

* Equipment level:
  ---------------
ETSI EN 300 417-1-1 sections 4 to 6
http://webapp.etsi.org/exchangefolder/en_3004170101v010103p.pdf
(or via search engine http://webapp.etsi.org/pda/QueryForm.asp )

ITU-T Recommendation G.806 section 5
http://www.itu.int/itudoc/itu-t/approved/g/g806.html

The atomic functions which are to be managed (partly) by the control
plane (GMPLS, ASTN) are specified in a series of ETIS standards and
ITU-T recommendations.

ETSI EN 300 417-x-1 (x=1,2,3,4,5,6,7) series
download (for free) via search engine
http://webapp.etsi.org/pda/QueryForm.asp

ITU-T Recommendation G.806 (general aspects), G.783 (SDH), G.705 (PDH),
draft G.798 (OTN), I.731 and I.732 and I.732 Annex D (ATM).

http://www.itu.int/itudoc/itu-t/approved/g/g783.html
http://www.itu.int/itudoc/itu-t/approved/g/g705.html
http://www.itu.int/itudoc/itu-t/approved/i/i731.html
http://www.itu.int/itudoc/itu-t/approved/i/i732.html
http://www.itu.int/itudoc/itu-t/approved/i/i732and.html

These atomic functions have so called "Management Information (MI)"
signals. A subset of those MI signals are connected via the "equipment
management function (EMF)" to the management plane and now also the
control plane. This subset has to be identified, so that it can be
included in the ASTN and GMPLS specifications.

E.g. the MI_ExTI, MI_TPmode, MI_TIMdis and MI_TIMAISdis are some of
these signals in trail termination functions which the control plane has
to assign values to as part of the trail creation process. Furthermore,
the control plane has to read the value of e.g. MI_TxTI signal in trail
termination functions; i.e. read MI_TxTI at A and then send this value
to Z where it is assigned to the MI_ExTI signal.

Regards,

Maarten

Ben Mack-Crane wrote in "Re: Please Clarify Doubts regarding RGT & RNC":
> 
> Vishal & Sambu,
> 
> I would like to add a bit to this discussion.
> 
> First some background:
> For those familiar with functional modeling (and I recommend
> it to all as an excellent tool for understanding communication
> networks) there are three (or maybe four) functional considerations
> that must be addressed in setting up a trail.
> 1) the type of characteristic information (which is necessary to
>    determine which link connections can support the connection)
> 2) the type of trail termination function (which must be matched
>    at the trail endpoints)
> 3) the client characteristic information and type of adaptation
>    (which may be separate considerations or bound together, and
>    also must be matched at the endpoints)
> 
> Generally, intermediate nodes need only know 1), and possibly parts
> of 2) if they support non-intrusive monitoring.  The endpoints
> need to be able to exchange info about 2) and 3).
> 
> The current signaling structure, however, does not provide separate
> fields for each of these areas.  There are only Signal Type and GPID
> fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).
> 
> A similar encoding is being used with RGT (that is, combining
> information needed in transit nodes and end nodes into one field).
> Thus (as has been explained) the difference between virtual
> concatenation and bundling is relevant to the endpoints and not
> the transit nodes.
> 
> Now to my point:
> The RGT field is also required to distinguish between differing
> connection requirements in transit nodes, and this has not been
> precisely explained yet.
> 
> Both virtual concatenation and bundling share the constraint that
> the set of link connections used must all be within the same higher
> order container.  This guarantees some degree of shared fate and
> limits delay difference.
> 
> I have stated this as a definition, but this is only one possible
> constraint.  Other possibilities include:
> 
> a) the set of link connections must be within one bit stream, but
>    may be in different higher order containers,
> b) the set of link connections must go to the same neighbor (the
>    loosest possible constraint within the signaling model), but
>    they may be in different bit streams (even different fibers).
> 
> Eventually we must be precise about what the constraint is for
> each RGT, and we may need to define additional RGT codepoints if
> we need to encode different constraints.  Note: there may be a
> label signaling problem if constraint b) is required.
> 
> Contiguous concatenation types have the specific constraint that
> the set of components be treated as a single byte stream in transit
> nodes (relative to pointer adjustment, etc.) and this implies the
> components must all be within the same higher order container.
> 
> I think the difference between standard and arbitrary contiguous
> concatenation should only be in the number of components allowed.
> Timeslot flexibility is a local constraint between neighbors, and
> both standard and arbitrary concatenated signals can make use of
> flexible timeslot allocation, if supported.  Given this, we may
> need to have a way to negotiate support for timeslot flexibility
> between neighbors (via LMP?) independently of the signaling of a
> specific LSP.
> 
> Regards,
> Ben
> 
> sambasiva mantha wrote:
> >
> > Vishal,
> >
> > I understand what is "bundling" group is for. What I was questioning was your
> > statement that no special handling is required for the bundling. They are
> > treated the same at the end nodes and at the intermediate nodes. What I was
> > pointing out was that when they are tagged as "bundling" group, then the
> > intermediate nodes also have to treat it specially.
> >
> > Sambu
> >
> > Vishal Sharma wrote:
> >
> > > Sambu,
> > >
> > > The "bundling" group type is defined to allow for the setup of multiple
> > > channels in parallel, such as three STS-1s in parallel, instead of setting
> > > up each individually. (Note that the draft currently allows for
> > > the bundling of only those channels that are in the same higher-order
> > > container.) This also allows the operator to control the fate of these
> > > bundled channels.
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: sambasiva mantha [mailto:[email-masked]]
> > > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > > To: Vishal Sharma
> > > > Cc: 'manoj juneja'; [email-masked]
> > > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Vishal,
> > > >
> > > > As  you pointed at the end of the email, if a speciality
> > > > funcitionality is not
> > > > required for "bundling" group type, then why there is a need for
> > > > distinguishing the group as such. In case of a SONET DCS the
> > > > bundling has a
> > > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > > which must be
> > > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > > operator to separate these STS-1s out in the sense they have
> > > > to come in on one
> > > > input port (OC-n say) and all the STS-1s in the bundle have
> > > > to cross connected
> > > > to the same outgoing output port (OC-m).
> > > >
> > > > Sambu
> > > >
> > > >
> > > > Vishal Sharma wrote:
> > > >
> > > > > Manoj,
> > > > >
> > > > > Some clarifications follow...
> > > > >
> > > > > -Vishal
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >         The GMPLS draft
> > > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > > Contiguous
> > > > > > arbitrary concatenation, Bundle.
> > > > > > How does the implementation of a control plane differ if
> > > > it receives
> > > > > > different RGT values ?
> > > > >
> > > > > The implementation of the control plane should not differ based on
> > > > > different RGT values, the implementation of the data plane is what
> > > > > differs in all of these cases, because each RGT value controls how
> > > > > the data bearing channels are  treated by the end nodes and the
> > > > > intermediate nodes.
> > > > >
> > > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > > the virtually
> > > > > concatenated channels as they would treat independent channels. The
> > > > > end points, however, treat these channels as "bonded"
> > > > together, and must
> > > > > have hardware and software support to "glue" the data
> > > > arriving on these
> > > > > channels together appropriately. (For instance, the hardware must
> > > > > support compensation for the differential delay that the component
> > > > > channels of the virtually concatenated stream may suffer.)
> > > > >
> > > > > > Another field RNC (Reuested Number of
> > > > > > Components) defines the number of such components requested.
> > > > > > My understanding is that if RNC is 2 and signal type is
> > > > STM-1. Then it
> > > > > > means that 2 STM-1 signals are requested and these are
> > > > concatenated
> > > > > > according to the RGT specified.
> > > > >
> > > > > Your understanding is correct.
> > > > >
> > > > > > Does this mean, the number of labels
> > > > > > requested depend on the RNC field ?  This means that is
> > > > RNC is "X",
> > > > > > then "X" number of labels are to be returned in Label
> > > > Mapping message
> > > > > > and the labels returned should be in accrodance with the requested
> > > > > > signal type.
> > > > >
> > > > > Not quite. The number of labels will be determined by a
> > > > combination of
> > > > > the RNC and RGT.
> > > > >
> > > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > > channel (which is transparent
> > > > > only at the path level, so that line and section overheads
> > > > are not to be
> > > > > preserved across SONET equipment), and see what happens in
> > > > the various
> > > > > cases.
> > > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > >
> > > > > If RGT = contiguous standard or contiguous arbitrary
> > > > concatenation, then
> > > > > only a _single_ label is returned (that one that denotes
> > > > the time slot at
> > > > > which the first of the concatenated channels begins).
> > > > >
> > > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > > labels (or
> > > > > # of labels = RNC in the general case) will
> > > > > need to be returned in the label mapping message (namely,
> > > > the times slots
> > > > > that denote where _each_ of the component STS-1s of the
> > > > STS-3 signal is to
> > > > > be placed, since in these cases the component STS-1s need
> > > > not occur in
> > > > > contiguous time slots).
> > > > >
> > > > > > Please clarify these doubts.
> > > > >
> > > > > Hope the above helps.
> > > > >
> > > > > > Can somebody please brief me on grouping type Bundle ?
> > > > >
> > > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > > setting up multiple, independent
> > > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > > three channels of STS-1 granularity, where each would be totally
> > > > > independent of the others, both at the intermediate nodes and at
> > > > > the end nodes.
> > > > >
> > > > > If, however, RGT=virtual concatenation, then what would really be
> > > > > setup in the SONET network would again be 3 channels of STS-1
> > > > > granularity, which to the intermediate nodes would be no different
> > > > > from the case above. To the end nodes, however, it would mean that
> > > > > they need to have the capability to handle virtually concatenated
> > > > > SONET channels (which means they need to be capable of appropriately
> > > > > dividing traffic across them [at the input], and "glueing" them back
> > > > > together [at the output]).
> > > > >
> > > > > > Is there any additional capability required in the network for
> > > > > > supporting different types of grouping types (RGTs) ?
> > > > >
> > > > > Not sure what you mean by "additional" capability? In "addition"
> > > > > to what?
> > > > >
> > > > > For contiguous standard concatenation, the network nodes need to
> > > > > be able to support standard SDH/SONET concatenation.
> > > > > For continuous arbitrary concatenation, the network nodes involved
> > > > > in the establishment of such a channel, need to be able to support
> > > > > arbitrary concatenation.
> > > > > For virtual concatenation, the intermediate nodes through which
> > > > > the channle passes need no additional functionality, but the
> > > > > end nodes must be able to support the processing of virtually
> > > > > concatenated channels.
> > > > > For bundling, absolutely no special functionality is required
> > > > > in either the intermediate nodes or the end nodes.
> > > > >
> > > > >
> > > > > >
> > > >

Ben Mack-Crane wrote:
> 
> Vishal & Sambu,
> 
> I would like to add a bit to this discussion.
> 
> First some background:
> For those familiar with functional modeling (and I recommend
> it to all as an excellent tool for understanding communication
> networks) there are three (or maybe four) functional considerations
> that must be addressed in setting up a trail.
> 1) the type of characteristic information (which is necessary to
>    determine which link connections can support the connection)
> 2) the type of trail termination function (which must be matched
>    at the trail endpoints)
> 3) the client characteristic information and type of adaptation
>    (which may be separate considerations or bound together, and
>    also must be matched at the endpoints)
> 
> Generally, intermediate nodes need only know 1), and possibly parts
> of 2) if they support non-intrusive monitoring.  The endpoints
> need to be able to exchange info about 2) and 3).
> 
> The current signaling structure, however, does not provide separate
> fields for each of these areas.  There are only Signal Type and GPID
> fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).
> 
> A similar encoding is being used with RGT (that is, combining
> information needed in transit nodes and end nodes into one field).
> Thus (as has been explained) the difference between virtual
> concatenation and bundling is relevant to the endpoints and not
> the transit nodes.
> 
> Now to my point:
> The RGT field is also required to distinguish between differing
> connection requirements in transit nodes, and this has not been
> precisely explained yet.
> 
> Both virtual concatenation and bundling share the constraint that
> the set of link connections used must all be within the same higher
> order container.  This guarantees some degree of shared fate and
> limits delay difference.
> 
> I have stated this as a definition, but this is only one possible
> constraint.  Other possibilities include:
> 
> a) the set of link connections must be within one bit stream, but
>    may be in different higher order containers,
> b) the set of link connections must go to the same neighbor (the
>    loosest possible constraint within the signaling model), but
>    they may be in different bit streams (even different fibers).
> 
> Eventually we must be precise about what the constraint is for
> each RGT, and we may need to define additional RGT codepoints if
> we need to encode different constraints.  Note: there may be a
> label signaling problem if constraint b) is required.
> 
> Contiguous concatenation types have the specific constraint that
> the set of components be treated as a single byte stream in transit
> nodes (relative to pointer adjustment, etc.) and this implies the
> components must all be within the same higher order container.
> 
> I think the difference between standard and arbitrary contiguous
> concatenation should only be in the number of components allowed.
> Timeslot flexibility is a local constraint between neighbors, and
> both standard and arbitrary concatenated signals can make use of
> flexible timeslot allocation, if supported.  Given this, we may
> need to have a way to negotiate support for timeslot flexibility
> between neighbors (via LMP?) independently of the signaling of a
> specific LSP.
> 
> Regards,
> Ben
> 
> sambasiva mantha wrote:
> >
> > Vishal,
> >
> > I understand what is "bundling" group is for. What I was questioning was your
> > statement that no special handling is required for the bundling. They are
> > treated the same at the end nodes and at the intermediate nodes. What I was
> > pointing out was that when they are tagged as "bundling" group, then the
> > intermediate nodes also have to treat it specially.
> >
> > Sambu
> >
> > Vishal Sharma wrote:
> >
> > > Sambu,
> > >
> > > The "bundling" group type is defined to allow for the setup of multiple
> > > channels in parallel, such as three STS-1s in parallel, instead of setting
> > > up each individually. (Note that the draft currently allows for
> > > the bundling of only those channels that are in the same higher-order
> > > container.) This also allows the operator to control the fate of these
> > > bundled channels.
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: sambasiva mantha [mailto:[email-masked]]
> > > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > > To: Vishal Sharma
> > > > Cc: 'manoj juneja'; [email-masked]
> > > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Vishal,
> > > >
> > > > As  you pointed at the end of the email, if a speciality
> > > > funcitionality is not
> > > > required for "bundling" group type, then why there is a need for
> > > > distinguishing the group as such. In case of a SONET DCS the
> > > > bundling has a
> > > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > > which must be
> > > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > > operator to separate these STS-1s out in the sense they have
> > > > to come in on one
> > > > input port (OC-n say) and all the STS-1s in the bundle have
> > > > to cross connected
> > > > to the same outgoing output port (OC-m).
> > > >
> > > > Sambu
> > > >
> > > >
> > > > Vishal Sharma wrote:
> > > >
> > > > > Manoj,
> > > > >
> > > > > Some clarifications follow...
> > > > >
> > > > > -Vishal
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > > >
> > > > > >
> > > > > > Hi All,
> > > > > >         The GMPLS draft
> > > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > > Contiguous
> > > > > > arbitrary concatenation, Bundle.
> > > > > > How does the implementation of a control plane differ if
> > > > it receives
> > > > > > different RGT values ?
> > > > >
> > > > > The implementation of the control plane should not differ based on
> > > > > different RGT values, the implementation of the data plane is what
> > > > > differs in all of these cases, because each RGT value controls how
> > > > > the data bearing channels are  treated by the end nodes and the
> > > > > intermediate nodes.
> > > > >
> > > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > > the virtually
> > > > > concatenated channels as they would treat independent channels. The
> > > > > end points, however, treat these channels as "bonded"
> > > > together, and must
> > > > > have hardware and software support to "glue" the data
> > > > arriving on these
> > > > > channels together appropriately. (For instance, the hardware must
> > > > > support compensation for the differential delay that the component
> > > > > channels of the virtually concatenated stream may suffer.)
> > > > >
> > > > > > Another field RNC (Reuested Number of
> > > > > > Components) defines the number of such components requested.
> > > > > > My understanding is that if RNC is 2 and signal type is
> > > > STM-1. Then it
> > > > > > means that 2 STM-1 signals are requested and these are
> > > > concatenated
> > > > > > according to the RGT specified.
> > > > >
> > > > > Your understanding is correct.
> > > > >
> > > > > > Does this mean, the number of labels
> > > > > > requested depend on the RNC field ?  This means that is
> > > > RNC is "X",
> > > > > > then "X" number of labels are to be returned in Label
> > > > Mapping message
> > > > > > and the labels returned should be in accrodance with the requested
> > > > > > signal type.
> > > > >
> > > > > Not quite. The number of labels will be determined by a
> > > > combination of
> > > > > the RNC and RGT.
> > > > >
> > > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > > channel (which is transparent
> > > > > only at the path level, so that line and section overheads
> > > > are not to be
> > > > > preserved across SONET equipment), and see what happens in
> > > > the various
> > > > > cases.
> > > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > >
> > > > > If RGT = contiguous standard or contiguous arbitrary
> > > > concatenation, then
> > > > > only a _single_ label is returned (that one that denotes
> > > > the time slot at
> > > > > which the first of the concatenated channels begins).
> > > > >
> > > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > > labels (or
> > > > > # of labels = RNC in the general case) will
> > > > > need to be returned in the label mapping message (namely,
> > > > the times slots
> > > > > that denote where _each_ of the component STS-1s of the
> > > > STS-3 signal is to
> > > > > be placed, since in these cases the component STS-1s need
> > > > not occur in
> > > > > contiguous time slots).
> > > > >
> > > > > > Please clarify these doubts.
> > > > >
> > > > > Hope the above helps.
> > > > >
> > > > > > Can somebody please brief me on grouping type Bundle ?
> > > > >
> > > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > > setting up multiple, independent
> > > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > > three channels of STS-1 granularity, where each would be totally
> > > > > independent of the others, both at the intermediate nodes and at
> > > > > the end nodes.
> > > > >
> > > > > If, however, RGT=virtual concatenation, then what would really be
> > > > > setup in the SONET network would again be 3 channels of STS-1
> > > > > granularity, which to the intermediate nodes would be no different
> > > > > from the case above. To the end nodes, however, it would mean that
> > > > > they need to have the capability to handle virtually concatenated
> > > > > SONET channels (which means they need to be capable of appropriately
> > > > > dividing traffic across them [at the input], and "glueing" them back
> > > > > together [at the output]).
> > > > >
> > > > > > Is there any additional capability required in the network for
> > > > > > supporting different types of grouping types (RGTs) ?
> > > > >
> > > > > Not sure what you mean by "additional" capability? In "addition"
> > > > > to what?
> > > > >
> > > > > For contiguous standard concatenation, the network nodes need to
> > > > > be able to support standard SDH/SONET concatenation.
> > > > > For continuous arbitrary concatenation, the network nodes involved
> > > > > in the establishment of such a channel, need to be able to support
> > > > > arbitrary concatenation.
> > > > > For virtual concatenation, the intermediate nodes through which
> > > > > the channle passes need no additional functionality, but the
> > > > > end nodes must be able to support the processing of virtually
> > > > > concatenated channels.
> > > > > For bundling, absolutely no special functionality is required
> > > > > in either the intermediate nodes or the end nodes.
> > > > >
> > > > >
> > > > > >
> > > >
--------------4C822C4409B0BF08970F373F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------4C822C4409B0BF08970F373F--

Delivery-date: Sun, 25 Mar 2001 20:57:59 -0800
Date: Sat, 24 Mar 2001 08:06:55 -0600
From: Ben Mack-Crane <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Neil, Hai, Maarten,

Some of the people involved in SONET/SDH signaling work discussed
this a bit at the IETF this week, and we are thinking of the following
method to handle LCAS:

Since the components of the LCAS group are not all co-routed, they
cannot all be signaled together.  The RGT/RNC fields are intended
to be used for co-routed groups with various constraints on the
set of link connections that may be used to connect these groups
between neighbors (and possibly other transit behaviors like
pointer processing in contiguous conatenation).

Subsets of LCAS groups may be co-routed (and thus signaled as
a virtually concatenated group).  That these subsets are to be
combined at the egress into one LCAS group can be signaled by
using the same LSP ID/Tunnel ID in all the signaling messages.

Regards,
Ben  

[email-masked] wrote:
> 
> Hai Vodinh [mailto:[email-masked]] wrote Sent: 23 March 2001
> 23:13
> > Maarten,
> >
> > Thanks for the clear and concise explanation of how LCAS work.
> > The 'create_new->switch_to_new->delete_old' scheme definitely
> > won't work for LCAS then.
> >
> > Hai
> From the trail defined by the *LCAS framing perspective* this is
> correct....with the additional (minor, but subtley important) observation
> that these new (LCAS) layers are not networked themselves.  But you are
> still creating (and deleting, potentially at least) new (old) pt-pt trails
> in the SDH fabric. However, for the general pt-pt L1 trail case then what
> I/Juegen said is perfectly correct.....LCAS is an exception not the rule
> *and* it is because there is a new trail entity ('the LCAS group') being
> created above the basic L1 server fabric.  Further, although I am not
> familar with the actual LCAS framing algorithm I am sure it will impose
> constraints on the nature/type of add/remove L1 trails that can be used, ie
> I am sure you cannot mix arbitrary L1 server trails.....so this will impose
> BW granularity/route-availability constraints on the server SDH layer
> networks, as defined by the LCAS algorithm.
> neil
> 
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Friday, March 23, 2001 2:38 AM
> > To: Hai Vodinh
> > Cc: [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Neil, Hai,
> >
> > LCAS  is developed to grow and shrink the bandwidth of a connection
> > without introducing any interruption to the bit stream going over it.
> > LCAS is the coordination protocol which synchronises the tail end with
> > the head end.
> >
> > So, when a service (manager) detects that it is time to increase the
> > bandwidth of the (virtual concatenated) connection, it will
> > request one
> > or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
> > Once the  trail is set-up (trail signal fail (TSF) condition clears at
> > tail end), the tail end will inform the head end via the LCAS protocol
> > (Member State from "fail" to "ok") that it is ready to include the new
> > trail into the connection. The head end will then include the
> > new trail
> > into the group, increasing the bandwidth of the connection;
> > before bits
> > are send over the new member, the tail end is notified that
> > at the next
> > frame start bits are transmitted over the new member as well.
> >
> > I hope this illustrates that you can not use
> > 'create_new->switch_to_new->delete_old' scheme in this case.
> >
> > Ethernet over SDH/SONET will be deploying this LCAS technique for its
> > bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
> > Ethernet streams. The Ethernet PHY will be terminated,
> > ethernet packets
> > extracted, encapsulated via GFP and mapped into virtual concatenated
> > STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
> > grows, the virtual concatenated signal is increased.
> >
> >       Note 1 - same can be done ofcourse for IP/PPP packet streams.
> >       Note 2 - mapping in virtual concatenated STS/VT/VC signal
> >                with LCAS may ofcourse be performed within the
> >                channalized interface port of an IP Router or
> >                Ethernet Switch. It is not required to do this in
> >                the SONET/SDH transport equipment.
> >
> > If such virtual concatenated group of STS/VT/VC signals is diverse
> > routed (half over one fiber, other half over another fiber), a signal
> > fail condition in one of the two fibers will not stop transport, only
> > reduce the bandwidth to 50%. The LCAS protocol will help to
> > temporarily
> > reduce the connection bandwidth being used to the fault free part, and
> > the signal flow is restored. As soon as the failed trails are
> > restored,
> > the LCAS protocol will include those again (hitless) in its connection
> > bandwidth, so that the full capacity can be used again.
> >
> >       Note 3 - if the virtual concatenated group is transported over
> >                3 different fibers, the failure group decreases and
> >                after a signal fail still 67% of the bandwidth is
> >                available.
> >
> > Recovery can be after a repair action, a protection switch
> > action in the
> > network's transport plane, a restoration action by the
> > network's control
> > plane restoring the failed trails, or a redial action of the trail
> > endpoints.
> >
> >
> >
> > Regards,
> >
> > Maarten
> >
> >
> > Hai Vodinh wrote:
> > >
> > > Neil
> > >
> > > The 'create_new->switch_to_new->delete_old' scheme seems to me to be
> > fairly
> > > inefficient mechanism for making small bandwidth change to
> > large pipe.
> > > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would
> > have to first
> > > make a sts-1-46v, switch the client signal over, then
> > delete the original
> > > sts-1-43v.  I do agree that it is a more straight forward
> > way to achieve
> > the
> > > goal, it is probably also simpler to keep track of the
> > sts-1s also.  I
> > think
> > > however if bandwidth modification (to existing pipe) is an important
> > service
> > > then we need a more efficient mechanism. I'm not saying
> > that this would be
> > > easy.
> > >
> > > My question to carriers would be: is b/w modification for virtually
> > > concatenated SPE important? in the short term & long term?
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, March 22, 2001 1:38 AM
> > > To: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Vishal....you asked (in mail below) for operator
> > input.....perhaps you
> > > missed this item I posted Wed 14/03/2001 13:35 on the
> > thread 'RE: Three
> > > GMPLS related IDs' against this ID from Yangguang Xu
> > >
> > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> > intra-domain-0
> > > 0.txt
> > >
> > > <prior text snipped NH>
> > > 10      In section 5.4.1.5 'actions' on trails are defined.
> >  For a CO
> > > network with fixed BW selection at trail creation time it
> > is very hard to
> > > see what a 'modify' action could be....other than perhaps a
> > change of
> > > restoration priority and/or change of dedicated back-up
> > trail/resource.
> > If
> > > there is any notion of (working) BW change here (be it a
> > scalar magnitude
> > > change, ie same route, or a vector change, ie new route
> > (with or without a
> > > scalar magnitude change)), it would seem to me that this is
> > really a new
> > > pair of 'create_new->switch_to_new->delete_old' actions.  I
> > note however
> > > that this has been marked as TBD, but I think it would help
> > if it was made
> > > clear that BW changes cannot (IMO) be a single 'modify' action.
> > > <post text snipped NH>
> > >
> > > So in essence I agreed with what Juergen is saying.
> > >
> > > neil
> > >
> > > > -----Original Message-----
> > > > From: Heiles Juergen [mailto:[email-masked]]
> > > > Sent: 22 March 2001 09:07
> > > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Vishal,
> > > >
> > > > in the circuit switched world he connection has a fixed
> > > > bandwidth. You cannot change the bandwidth. You have to tear
> > > > down the connection and set-up a new one with a different
> > > > bandwidth. For example if you want to change from VC-3
> > > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > > > released and a VC-4 connection is setup. The route could be
> > > > different as some equipment migth support VC-3 but not VC-4s
> > > > or vice versa.
> > > > Virtual concatenation toegether with LCAS provides
> > > > flexibility in certain steps. However it applies only to the
> > > > end points as you mentioned. Between the end points you still
> > > > setup connections with fixed bandwidth.
> > > >
> > > > Regards
> > > >
> > > > Juergen
> > > >
> > > > > -----Original Message-----
> > > > > From:       Vishal Sharma [SMTP:[email-masked]]
> > > > > Sent:       Thursday, March 22, 2001 9:36 AM
> > > > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > > > Subject:    RE: Please Clarify Doubts regarding RGT & RNC
> > > > >
> > > > > Hai,
> > > > >
> > > > > Yes, now that you mention it, it probably is an important
> > > > capability.
> > > > > (Although,
> > > > > I am not sure how soon it needs to be made available.)
> > > > > [Again, any carriers listening on this channel??
> > "Hello, calling all
> > > > > carriers... we need some service provider input here."]
> > > <snipped to end NH>
> >

Envelope-to: [email-masked]
Delivery-date: Sun, 25 Mar 2001 20:25:08 -0800
Date: Sun, 25 Mar 2001 20:22:55 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Heads up!

Hi Folks,

I'm trying to get some headway on some of the easier issues; to that
end, I'll be sending out some mail.

I'll leave the harder issues for Vijay to tackle :-)

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sun, 25 Mar 2001 20:11:33 -0800
Date: Sun, 25 Mar 2001 20:09:40 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Tunnel trace

Is the requirements draft on target?  Is the protocol spec on target?
Is either of interest?

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sun, 25 Mar 2001 20:07:34 -0800
Date: Sun, 25 Mar 2001 20:05:43 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Two-octet bandwidth values

Let's get the ball rolling.  Please send questions and comments to the
list.  Here are mine:

Questions to vendors:
1) Is floating point arithmetic a burdensome requirement?  Is having
   a new library of functions for the two-octet "floating point"
   representation a burdensome requirement?
2) Is halving the size of the bandwidth TLVs a big win (keep in mind
   that more bandwidth TLVs are being proposed)?
   (a) for ISIS?
   (b) for OSPF?
   (c) if the answers for ISIS and OSPF differ, is it acceptable to
       have different formats for the two protocols?

Questions to vendors & carriers:
1) Is 10 bits of dynamic range (0.1% accuracy) good enough?
2) Are you in favor of this draft, or against?

Kireeti.

Delivery-date: Sun, 25 Mar 2001 12:17:57 -0800
Date: Sun, 25 Mar 2001 12:04:52 -0800
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
CC: Hai Vodinh <[email-masked]>, "'Vishal Sharma'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, [email-masked]
Subject: Re: Virtual concat, LCAS and T1 documents... RE: Please Clarify Doubts  regarding RGT & RNC

Greg,
Actually, ITU-T DOES offer a similar service.
You can download up to 3 documents per email address for free. Go to
the main page:
http://www.itu.int/
choose "Electronic Bookshop", then select:
I wish to REGISTER in order to download up to three (3) Recommendations free of charge

Regards,
Steve Trowbridge
Vice Chairman, ITU-T Study Group 15

"Bernstein, Greg" wrote:
> 
> Hi folks, the only way of doing this with circuit switching is via an
> inverse multiplexing process like virtual concatenation plus a protocol such
> as the link channel adjustment scheme (LCAS).  This is a relatively new
> development, i.e., to find it you'll need to look at the letter ballot for
> the new version of the "basic SONET rates and formats" document: T1.105-200x
> T1X1.5/2000-193R1  (Draft ANSI T1.105-200x - Contents of LB809 with addendum
> information from T1X1.5/2000-129R2).  This can be found by rummaging through
> the www.t1.org web site.
> 
> Also standards documents can be obtain for free from the ATIS document
> center (look at the small print at the bottom of the web page for one free
> electronic download of the document you're interested in. Note that you can
> only download the same document once or so it says.  Hmmm I haven't tested
> this though).  Most of the SONET documents are in the T1.105 series.
> Unfortunately ITU doesn't offer a similar service.
> Hope this helps.
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> 
> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 12:00 PM
> To: 'Vishal Sharma'; Hai Vodinh; 'Zhi-Wei Lin'
> Cc: [email-masked]; Bernstein, Greg
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Vishal, Greg,
> 
> Thanks for the clarification on the difference between VC and bundling.  On
> my last question, isn't the abibility to get additional bandwidth for an
> already established signal a crucial requirement for the type of
> bandwidth-on-demand or more appropriately bandwidth-modification service
> that we are thinking of today?
> 
> Thanks,
> Hai
> 
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 11:45 PM
> To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: [email-masked]; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Hi Hai,
> 
> Greg has already provided an answer. I just wanted to add that in
> my initial explanation to Manoj, I did point out what the difference
> was between virtual concat. and bundling. For the intermediate
> nodes, there is no difference, the differene only comes in for
> the end points, which in the virtual concat. case have to know
> which channels are virtually concatenated, and compensate for
> differential delay across these channels.
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 5:14 PM
> > To: 'Zhi-Wei Lin'; Vishal Sharma
> > Cc: [email-masked]
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > I tend to agree with Zhi-Wei that when you need to set up multiple
> > connections these should be done separately (except perhaps
> > in the virtual
> > concatenated case) to keep the signaling protocol simple.
> >
> > I'm following the discussion and still don't have a clear
> > idea why both
> > virtual concatenation and bundling RGT are needed.  What is
> > the difference
> > between the two types?
> >
> > Here is another question: let's say I have a STS-1-4v SPE
> > already set up,
> > now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how
> > do I signal to
> > the network that the additional 2 STS-1s need to be co-routed
> > with the other
> 
> I am not sure that there is any easy way to day to perform such
> signaling.
> 
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 12:17 PM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Hi Vishal,
> >
> >
> >
> > > > 3 STS-3: ??? How would you signal this? Not supported?
> > >
> > > What do you wish to signal here? Three groups of STS-3 each?
> > > What does it mean? The STS-3 is a bundle, and you wish to signal
> > > a bundle of bundles?
> > >
> > > If that is so, and unless I am missing something, I think you'd have
> > > to signal them separately.
> > >
> > > BTW, I wasn't immediately able to see how this would be signaled
> > > even using the codepoints proposed in
> > > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > >
> >
> > I don't understand how that is a bundle. STS-3 as defined in
> > the T1.105
> > is the entire signal. So then if you can signal multiple STS-1s, my
> > question was why is this not supported for STS-3 or other STS-X.
> >
> > Right, draft-lin assumes that when you need to set up multiple
> > connections, these are done separately. Adding the capability for
> > multiple connection set-ups as part of the signaling mechanism is not
> > really necessary. Remember that the signaling mechanism is not the GUI
> > to the customer. The GUI that the customer sees can provide that
> > feature. The interface from GUI to the signaling can be a
> > batch function
> > that sets up the multiple connections. This simplifies the signaling
> > protocol, allows "bundling" of different connection types
> > set-up at once
> > (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2
> > STS-48c at
> > once) via a batch process, and does not complicate the protocol from
> > having to handle this issue.
> >
> > Some of the points mentioned by Ewart in the OIF discussion was: when
> > multiple connections are handled at once, what are the characteristics
> > of these connections? Do they all terminate at the same location? Are
> > they all co-routed or separately routed? How many labels do
> > you return?
> > If one label is returned, what happens when one connection
> > failed? What
> > if the multiple connections have different destinations? etc.
> >
> >
> > > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > > arbitrary)
> > > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > >
> > > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > >
> > > Again, as things stand today, you'd have to signal this separately.
> > >
> > > First, is there a requirement to signal these this way? Assuming
> > > there is, is there a proposal that allows for that?
> > >
> >
> > I wasn't sure whether there is requirement or not. I was
> > extending your
> > example with what was offered currently. My view was that it
> > seems that
> > some capabilities are available to certain signal types and
> > not to other
> > signal types. We probably need to extend or clarify the text,
> > or adopt a
> > different position in terms of what should and should not be
> > provided by
> > the signaling protocol, and leave "added features" to
> > separate functions
> > (the batch process I mentioned above).
> >
> >
> > > I cannot see how
> > draft-lin-ccamp-ipo-common-label-request-01.txt would
> > > do it either, since the RNC has been absorbed into the signal type
> > > in that case, and not all cases are enumerated.
> > >
> >
> > See above for comment.
> >
> > > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > >
> > > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > >
> > > Same as the two above.
> > >
> >
> > See above (sorry, too many "aboves") ;-)
> >
> > Zhi
> >

Delivery-date: Fri, 23 Mar 2001 22:42:07 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Sat, 24 Mar 2001 06:38:03 -0000

Hai Vodinh [mailto:[email-masked]] wrote Sent: 23 March 2001
23:13
> Maarten,
> 
> Thanks for the clear and concise explanation of how LCAS work.
> The 'create_new->switch_to_new->delete_old' scheme definitely 
> won't work for LCAS then.
> 
> Hai
>From the trail defined by the *LCAS framing perspective* this is
correct....with the additional (minor, but subtley important) observation
that these new (LCAS) layers are not networked themselves.  But you are
still creating (and deleting, potentially at least) new (old) pt-pt trails
in the SDH fabric. However, for the general pt-pt L1 trail case then what
I/Juegen said is perfectly correct.....LCAS is an exception not the rule
*and* it is because there is a new trail entity ('the LCAS group') being
created above the basic L1 server fabric.  Further, although I am not
familar with the actual LCAS framing algorithm I am sure it will impose
constraints on the nature/type of add/remove L1 trails that can be used, ie
I am sure you cannot mix arbitrary L1 server trails.....so this will impose
BW granularity/route-availability constraints on the server SDH layer
networks, as defined by the LCAS algorithm.
neil 

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 2:38 AM
> To: Hai Vodinh
> Cc: [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Neil, Hai,
> 
> LCAS  is developed to grow and shrink the bandwidth of a connection
> without introducing any interruption to the bit stream going over it.
> LCAS is the coordination protocol which synchronises the tail end with
> the head end.
> 
> So, when a service (manager) detects that it is time to increase the
> bandwidth of the (virtual concatenated) connection, it will 
> request one
> or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
> Once the  trail is set-up (trail signal fail (TSF) condition clears at
> tail end), the tail end will inform the head end via the LCAS protocol
> (Member State from "fail" to "ok") that it is ready to include the new
> trail into the connection. The head end will then include the 
> new trail
> into the group, increasing the bandwidth of the connection; 
> before bits
> are send over the new member, the tail end is notified that 
> at the next
> frame start bits are transmitted over the new member as well.
> 
> I hope this illustrates that you can not use 
> 'create_new->switch_to_new->delete_old' scheme in this case.
> 
> Ethernet over SDH/SONET will be deploying this LCAS technique for its
> bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
> Ethernet streams. The Ethernet PHY will be terminated, 
> ethernet packets
> extracted, encapsulated via GFP and mapped into virtual concatenated
> STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
> grows, the virtual concatenated signal is increased. 
> 
> 	Note 1 - same can be done ofcourse for IP/PPP packet streams.
> 	Note 2 - mapping in virtual concatenated STS/VT/VC signal
> 		 with LCAS may ofcourse be performed within the
> 		 channalized interface port of an IP Router or
> 		 Ethernet Switch. It is not required to do this in
> 		 the SONET/SDH transport equipment.
> 
> If such virtual concatenated group of STS/VT/VC signals is diverse
> routed (half over one fiber, other half over another fiber), a signal
> fail condition in one of the two fibers will not stop transport, only
> reduce the bandwidth to 50%. The LCAS protocol will help to 
> temporarily
> reduce the connection bandwidth being used to the fault free part, and
> the signal flow is restored. As soon as the failed trails are 
> restored,
> the LCAS protocol will include those again (hitless) in its connection
> bandwidth, so that the full capacity can be used again.
> 
> 	Note 3 - if the virtual concatenated group is transported over
> 		 3 different fibers, the failure group decreases and 
> 		 after a signal fail still 67% of the bandwidth is
> 		 available.
> 
> Recovery can be after a repair action, a protection switch 
> action in the
> network's transport plane, a restoration action by the 
> network's control
> plane restoring the failed trails, or a redial action of the trail
> endpoints.
> 
> 
> 
> Regards,
> 
> Maarten
> 
> 
> Hai Vodinh wrote:
> > 
> > Neil
> > 
> > The 'create_new->switch_to_new->delete_old' scheme seems to me to be
> fairly
> > inefficient mechanism for making small bandwidth change to 
> large pipe.
> > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would 
> have to first
> > make a sts-1-46v, switch the client signal over, then 
> delete the original
> > sts-1-43v.  I do agree that it is a more straight forward 
> way to achieve
> the
> > goal, it is probably also simpler to keep track of the 
> sts-1s also.  I
> think
> > however if bandwidth modification (to existing pipe) is an important
> service
> > then we need a more efficient mechanism. I'm not saying 
> that this would be
> > easy.
> > 
> > My question to carriers would be: is b/w modification for virtually
> > concatenated SPE important? in the short term & long term?
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, March 22, 2001 1:38 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > Vishal....you asked (in mail below) for operator 
> input.....perhaps you
> > missed this item I posted Wed 14/03/2001 13:35 on the 
> thread 'RE: Three
> > GMPLS related IDs' against this ID from Yangguang Xu
> >
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> intra-domain-0
> > 0.txt
> > 
> > <prior text snipped NH>
> > 10      In section 5.4.1.5 'actions' on trails are defined. 
>  For a CO
> > network with fixed BW selection at trail creation time it 
> is very hard to
> > see what a 'modify' action could be....other than perhaps a 
> change of
> > restoration priority and/or change of dedicated back-up 
> trail/resource.
> If
> > there is any notion of (working) BW change here (be it a 
> scalar magnitude
> > change, ie same route, or a vector change, ie new route 
> (with or without a
> > scalar magnitude change)), it would seem to me that this is 
> really a new
> > pair of 'create_new->switch_to_new->delete_old' actions.  I 
> note however
> > that this has been marked as TBD, but I think it would help 
> if it was made
> > clear that BW changes cannot (IMO) be a single 'modify' action.
> > <post text snipped NH>
> > 
> > So in essence I agreed with what Juergen is saying.
> > 
> > neil
> > 
> > > -----Original Message-----
> > > From: Heiles Juergen [mailto:[email-masked]]
> > > Sent: 22 March 2001 09:07
> > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Vishal,
> > >
> > > in the circuit switched world he connection has a fixed
> > > bandwidth. You cannot change the bandwidth. You have to tear
> > > down the connection and set-up a new one with a different
> > > bandwidth. For example if you want to change from VC-3
> > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > > released and a VC-4 connection is setup. The route could be
> > > different as some equipment migth support VC-3 but not VC-4s
> > > or vice versa.
> > > Virtual concatenation toegether with LCAS provides
> > > flexibility in certain steps. However it applies only to the
> > > end points as you mentioned. Between the end points you still
> > > setup connections with fixed bandwidth.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > > > -----Original Message-----
> > > > From:       Vishal Sharma [SMTP:[email-masked]]
> > > > Sent:       Thursday, March 22, 2001 9:36 AM
> > > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > > Subject:    RE: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > > Hai,
> > > >
> > > > Yes, now that you mention it, it probably is an important
> > > capability.
> > > > (Although,
> > > > I am not sure how soon it needs to be made available.)
> > > > [Again, any carriers listening on this channel?? 
> "Hello, calling all
> > > > carriers... we need some service provider input here."]
> > <snipped to end NH>
> 

Delivery-date: Fri, 23 Mar 2001 15:21:45 -0800
From: Hai Vodinh <[email-masked]>
To: Hai Vodinh <[email-masked]>
Cc: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 23 Mar 2001 15:13:01 -0800

Maarten,

Thanks for the clear and concise explanation of how LCAS work.
The 'create_new->switch_to_new->delete_old' scheme definitely 
won't work for LCAS then.

Hai

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Friday, March 23, 2001 2:38 AM
To: Hai Vodinh
Cc: [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Neil, Hai,

LCAS  is developed to grow and shrink the bandwidth of a connection
without introducing any interruption to the bit stream going over it.
LCAS is the coordination protocol which synchronises the tail end with
the head end.

So, when a service (manager) detects that it is time to increase the
bandwidth of the (virtual concatenated) connection, it will request one
or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
Once the  trail is set-up (trail signal fail (TSF) condition clears at
tail end), the tail end will inform the head end via the LCAS protocol
(Member State from "fail" to "ok") that it is ready to include the new
trail into the connection. The head end will then include the new trail
into the group, increasing the bandwidth of the connection; before bits
are send over the new member, the tail end is notified that at the next
frame start bits are transmitted over the new member as well.

I hope this illustrates that you can not use 
'create_new->switch_to_new->delete_old' scheme in this case.

Ethernet over SDH/SONET will be deploying this LCAS technique for its
bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
Ethernet streams. The Ethernet PHY will be terminated, ethernet packets
extracted, encapsulated via GFP and mapped into virtual concatenated
STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
grows, the virtual concatenated signal is increased. 

	Note 1 - same can be done ofcourse for IP/PPP packet streams.
	Note 2 - mapping in virtual concatenated STS/VT/VC signal
		 with LCAS may ofcourse be performed within the
		 channalized interface port of an IP Router or
		 Ethernet Switch. It is not required to do this in
		 the SONET/SDH transport equipment.

If such virtual concatenated group of STS/VT/VC signals is diverse
routed (half over one fiber, other half over another fiber), a signal
fail condition in one of the two fibers will not stop transport, only
reduce the bandwidth to 50%. The LCAS protocol will help to temporarily
reduce the connection bandwidth being used to the fault free part, and
the signal flow is restored. As soon as the failed trails are restored,
the LCAS protocol will include those again (hitless) in its connection
bandwidth, so that the full capacity can be used again.

	Note 3 - if the virtual concatenated group is transported over
		 3 different fibers, the failure group decreases and 
		 after a signal fail still 67% of the bandwidth is
		 available.

Recovery can be after a repair action, a protection switch action in the
network's transport plane, a restoration action by the network's control
plane restoring the failed trails, or a redial action of the trail
endpoints.

Regards,

Maarten

Hai Vodinh wrote:
> 
> Neil
> 
> The 'create_new->switch_to_new->delete_old' scheme seems to me to be
fairly
> inefficient mechanism for making small bandwidth change to large pipe.
> Think about addimg 3 sts-1s to a sts-1-43v pipe, you would have to first
> make a sts-1-46v, switch the client signal over, then delete the original
> sts-1-43v.  I do agree that it is a more straight forward way to achieve
the
> goal, it is probably also simpler to keep track of the sts-1s also.  I
think
> however if bandwidth modification (to existing pipe) is an important
service
> then we need a more efficient mechanism. I'm not saying that this would be
> easy.
> 
> My question to carriers would be: is b/w modification for virtually
> concatenated SPE important? in the short term & long term?
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 1:38 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Vishal....you asked (in mail below) for operator input.....perhaps you
> missed this item I posted Wed 14/03/2001 13:35 on the thread 'RE: Three
> GMPLS related IDs' against this ID from Yangguang Xu
>
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
> 0.txt
> 
> <prior text snipped NH>
> 10      In section 5.4.1.5 'actions' on trails are defined.  For a CO
> network with fixed BW selection at trail creation time it is very hard to
> see what a 'modify' action could be....other than perhaps a change of
> restoration priority and/or change of dedicated back-up trail/resource.
If
> there is any notion of (working) BW change here (be it a scalar magnitude
> change, ie same route, or a vector change, ie new route (with or without a
> scalar magnitude change)), it would seem to me that this is really a new
> pair of 'create_new->switch_to_new->delete_old' actions.  I note however
> that this has been marked as TBD, but I think it would help if it was made
> clear that BW changes cannot (IMO) be a single 'modify' action.
> <post text snipped NH>
> 
> So in essence I agreed with what Juergen is saying.
> 
> neil
> 
> > -----Original Message-----
> > From: Heiles Juergen [mailto:[email-masked]]
> > Sent: 22 March 2001 09:07
> > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc: [email-masked]; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Vishal,
> >
> > in the circuit switched world he connection has a fixed
> > bandwidth. You cannot change the bandwidth. You have to tear
> > down the connection and set-up a new one with a different
> > bandwidth. For example if you want to change from VC-3
> > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > released and a VC-4 connection is setup. The route could be
> > different as some equipment migth support VC-3 but not VC-4s
> > or vice versa.
> > Virtual concatenation toegether with LCAS provides
> > flexibility in certain steps. However it applies only to the
> > end points as you mentioned. Between the end points you still
> > setup connections with fixed bandwidth.
> >
> > Regards
> >
> > Juergen
> >
> > > -----Original Message-----
> > > From:       Vishal Sharma [SMTP:[email-masked]]
> > > Sent:       Thursday, March 22, 2001 9:36 AM
> > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > Subject:    RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Hai,
> > >
> > > Yes, now that you mention it, it probably is an important
> > capability.
> > > (Although,
> > > I am not sure how soon it needs to be made available.)
> > > [Again, any carriers listening on this channel?? "Hello, calling all
> > > carriers... we need some service provider input here."]
> <snipped to end NH>

Delivery-date: Fri, 23 Mar 2001 09:21:45 -0800
Date: Fri, 23 Mar 2001 10:14:01 -0600
From: Ben Mack-Crane <[email-masked]>
To: sambasiva mantha <[email-masked]>
CC: Vishal Sharma <[email-masked]>, "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Vishal & Sambu,

I would like to add a bit to this discussion.

First some background:
For those familiar with functional modeling (and I recommend
it to all as an excellent tool for understanding communication
networks) there are three (or maybe four) functional considerations
that must be addressed in setting up a trail.
1) the type of characteristic information (which is necessary to 
   determine which link connections can support the connection)
2) the type of trail termination function (which must be matched 
   at the trail endpoints)
3) the client characteristic information and type of adaptation 
   (which may be separate considerations or bound together, and
   also must be matched at the endpoints)

Generally, intermediate nodes need only know 1), and possibly parts
of 2) if they support non-intrusive monitoring.  The endpoints
need to be able to exchange info about 2) and 3).

The current signaling structure, however, does not provide separate
fields for each of these areas.  There are only Signal Type and GPID
fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).

A similar encoding is being used with RGT (that is, combining
information needed in transit nodes and end nodes into one field).
Thus (as has been explained) the difference between virtual
concatenation and bundling is relevant to the endpoints and not
the transit nodes.

Now to my point:
The RGT field is also required to distinguish between differing
connection requirements in transit nodes, and this has not been
precisely explained yet.

Both virtual concatenation and bundling share the constraint that
the set of link connections used must all be within the same higher
order container.  This guarantees some degree of shared fate and 
limits delay difference.

I have stated this as a definition, but this is only one possible
constraint.  Other possibilities include:

a) the set of link connections must be within one bit stream, but 
   may be in different higher order containers,
b) the set of link connections must go to the same neighbor (the
   loosest possible constraint within the signaling model), but
   they may be in different bit streams (even different fibers).

Eventually we must be precise about what the constraint is for
each RGT, and we may need to define additional RGT codepoints if
we need to encode different constraints.  Note: there may be a
label signaling problem if constraint b) is required.

Contiguous concatenation types have the specific constraint that
the set of components be treated as a single byte stream in transit
nodes (relative to pointer adjustment, etc.) and this implies the
components must all be within the same higher order container.

I think the difference between standard and arbitrary contiguous
concatenation should only be in the number of components allowed.
Timeslot flexibility is a local constraint between neighbors, and
both standard and arbitrary concatenated signals can make use of
flexible timeslot allocation, if supported.  Given this, we may
need to have a way to negotiate support for timeslot flexibility 
between neighbors (via LMP?) independently of the signaling of a
specific LSP.

Regards,
Ben

sambasiva mantha wrote:
> 
> Vishal,
> 
> I understand what is "bundling" group is for. What I was questioning was your
> statement that no special handling is required for the bundling. They are
> treated the same at the end nodes and at the intermediate nodes. What I was
> pointing out was that when they are tagged as "bundling" group, then the
> intermediate nodes also have to treat it specially.
> 
> Sambu
> 
> Vishal Sharma wrote:
> 
> > Sambu,
> >
> > The "bundling" group type is defined to allow for the setup of multiple
> > channels in parallel, such as three STS-1s in parallel, instead of setting
> > up each individually. (Note that the draft currently allows for
> > the bundling of only those channels that are in the same higher-order
> > container.) This also allows the operator to control the fate of these
> > bundled channels.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: sambasiva mantha [mailto:[email-masked]]
> > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > To: Vishal Sharma
> > > Cc: 'manoj juneja'; [email-masked]
> > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Vishal,
> > >
> > > As  you pointed at the end of the email, if a speciality
> > > funcitionality is not
> > > required for "bundling" group type, then why there is a need for
> > > distinguishing the group as such. In case of a SONET DCS the
> > > bundling has a
> > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > which must be
> > > contigous, are defined as part of a bundle, the DCS does not allow the
> > > operator to separate these STS-1s out in the sense they have
> > > to come in on one
> > > input port (OC-n say) and all the STS-1s in the bundle have
> > > to cross connected
> > > to the same outgoing output port (OC-m).
> > >
> > > Sambu
> > >
> > >
> > > Vishal Sharma wrote:
> > >
> > > > Manoj,
> > > >
> > > > Some clarifications follow...
> > > >
> > > > -Vishal
> > > >
> > > > > -----Original Message-----
> > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > To: [email-masked]
> > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > >
> > > > >
> > > > > Hi All,
> > > > >         The GMPLS draft
> > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > Contiguous
> > > > > arbitrary concatenation, Bundle.
> > > > > How does the implementation of a control plane differ if
> > > it receives
> > > > > different RGT values ?
> > > >
> > > > The implementation of the control plane should not differ based on
> > > > different RGT values, the implementation of the data plane is what
> > > > differs in all of these cases, because each RGT value controls how
> > > > the data bearing channels are  treated by the end nodes and the
> > > > intermediate nodes.
> > > >
> > > > For example, for virtual concatenation, the intermediate nodes treat
> > > > the virtually
> > > > concatenated channels as they would treat independent channels. The
> > > > end points, however, treat these channels as "bonded"
> > > together, and must
> > > > have hardware and software support to "glue" the data
> > > arriving on these
> > > > channels together appropriately. (For instance, the hardware must
> > > > support compensation for the differential delay that the component
> > > > channels of the virtually concatenated stream may suffer.)
> > > >
> > > > > Another field RNC (Reuested Number of
> > > > > Components) defines the number of such components requested.
> > > > > My understanding is that if RNC is 2 and signal type is
> > > STM-1. Then it
> > > > > means that 2 STM-1 signals are requested and these are
> > > concatenated
> > > > > according to the RGT specified.
> > > >
> > > > Your understanding is correct.
> > > >
> > > > > Does this mean, the number of labels
> > > > > requested depend on the RNC field ?  This means that is
> > > RNC is "X",
> > > > > then "X" number of labels are to be returned in Label
> > > Mapping message
> > > > > and the labels returned should be in accrodance with the requested
> > > > > signal type.
> > > >
> > > > Not quite. The number of labels will be determined by a
> > > combination of
> > > > the RNC and RGT.
> > > >
> > > > To understand this, let's consider the setting up of an STS-3 SONET
> > > > channel (which is transparent
> > > > only at the path level, so that line and section overheads
> > > are not to be
> > > > preserved across SONET equipment), and see what happens in
> > > the various
> > > > cases.
> > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > >
> > > > If RGT = contiguous standard or contiguous arbitrary
> > > concatenation, then
> > > > only a _single_ label is returned (that one that denotes
> > > the time slot at
> > > > which the first of the concatenated channels begins).
> > > >
> > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > labels (or
> > > > # of labels = RNC in the general case) will
> > > > need to be returned in the label mapping message (namely,
> > > the times slots
> > > > that denote where _each_ of the component STS-1s of the
> > > STS-3 signal is to
> > > > be placed, since in these cases the component STS-1s need
> > > not occur in
> > > > contiguous time slots).
> > > >
> > > > > Please clarify these doubts.
> > > >
> > > > Hope the above helps.
> > > >
> > > > > Can somebody please brief me on grouping type Bundle ?
> > > >
> > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > setting up multiple, independent
> > > > SONET channels across a SONET network. Thus, in my example above, if
> > > > RGT=bundle, what would really be setup in the SONET network would be
> > > > three channels of STS-1 granularity, where each would be totally
> > > > independent of the others, both at the intermediate nodes and at
> > > > the end nodes.
> > > >
> > > > If, however, RGT=virtual concatenation, then what would really be
> > > > setup in the SONET network would again be 3 channels of STS-1
> > > > granularity, which to the intermediate nodes would be no different
> > > > from the case above. To the end nodes, however, it would mean that
> > > > they need to have the capability to handle virtually concatenated
> > > > SONET channels (which means they need to be capable of appropriately
> > > > dividing traffic across them [at the input], and "glueing" them back
> > > > together [at the output]).
> > > >
> > > > > Is there any additional capability required in the network for
> > > > > supporting different types of grouping types (RGTs) ?
> > > >
> > > > Not sure what you mean by "additional" capability? In "addition"
> > > > to what?
> > > >
> > > > For contiguous standard concatenation, the network nodes need to
> > > > be able to support standard SDH/SONET concatenation.
> > > > For continuous arbitrary concatenation, the network nodes involved
> > > > in the establishment of such a channel, need to be able to support
> > > > arbitrary concatenation.
> > > > For virtual concatenation, the intermediate nodes through which
> > > > the channle passes need no additional functionality, but the
> > > > end nodes must be able to support the processing of virtually
> > > > concatenated channels.
> > > > For bundling, absolutely no special functionality is required
> > > > in either the intermediate nodes or the end nodes.
> > > >
> > > >
> > > > >
> > >

Delivery-date: Fri, 23 Mar 2001 08:21:22 -0800
From: Andre Fredette <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 23 Mar 2001 11:18:59 -0500
Subject: LMP vs. NTIP

Osama, Bilel,

In the ccamp meeting on Wednesday, you made the assertion that LMP is too 
complicated for transport systems and that NTIP is a much simpler and 
better protocol.

Is your assertion based solely on the fact that NTIP proposes the use of 
TCP for reliability, while LMP uses IP and protocol-level acks?

If not, please let us know which part of LMP is unnecessary.

Thanks,
Andre

Delivery-date: Fri, 23 Mar 2001 02:41:40 -0800
Cc: [email-masked]
Date: Fri, 23 Mar 2001 11:38:17 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Hai Vodinh <[email-masked]>
Original-CC: [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

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

Neil, Hai,

LCAS  is developed to grow and shrink the bandwidth of a connection
without introducing any interruption to the bit stream going over it.
LCAS is the coordination protocol which synchronises the tail end with
the head end.

So, when a service (manager) detects that it is time to increase the
bandwidth of the (virtual concatenated) connection, it will request one
or more additional STS1/STS3c/VT1.5/VC4/VC3/VC12 trails to be set-up.
Once the  trail is set-up (trail signal fail (TSF) condition clears at
tail end), the tail end will inform the head end via the LCAS protocol
(Member State from "fail" to "ok") that it is ready to include the new
trail into the connection. The head end will then include the new trail
into the group, increasing the bandwidth of the connection; before bits
are send over the new member, the tail end is notified that at the next
frame start bits are transmitted over the new member as well.

I hope this illustrates that you can not use 
'create_new->switch_to_new->delete_old' scheme in this case.

Ethernet over SDH/SONET will be deploying this LCAS technique for its
bandwidth optimized transport of 10M, 100M and 1G (and in future 10G)
Ethernet streams. The Ethernet PHY will be terminated, ethernet packets
extracted, encapsulated via GFP and mapped into virtual concatenated
STS/VT/VC signals. When the utilized bandwidth on the Ethernet PHY
grows, the virtual concatenated signal is increased. 

	Note 1 - same can be done ofcourse for IP/PPP packet streams.
	Note 2 - mapping in virtual concatenated STS/VT/VC signal
		 with LCAS may ofcourse be performed within the
		 channalized interface port of an IP Router or
		 Ethernet Switch. It is not required to do this in
		 the SONET/SDH transport equipment.

If such virtual concatenated group of STS/VT/VC signals is diverse
routed (half over one fiber, other half over another fiber), a signal
fail condition in one of the two fibers will not stop transport, only
reduce the bandwidth to 50%. The LCAS protocol will help to temporarily
reduce the connection bandwidth being used to the fault free part, and
the signal flow is restored. As soon as the failed trails are restored,
the LCAS protocol will include those again (hitless) in its connection
bandwidth, so that the full capacity can be used again.

	Note 3 - if the virtual concatenated group is transported over
		 3 different fibers, the failure group decreases and 
		 after a signal fail still 67% of the bandwidth is
		 available.

Recovery can be after a repair action, a protection switch action in the
network's transport plane, a restoration action by the network's control
plane restoring the failed trails, or a redial action of the trail
endpoints.

Regards,

Maarten

Hai Vodinh wrote:
> 
> Neil
> 
> The 'create_new->switch_to_new->delete_old' scheme seems to me to be fairly
> inefficient mechanism for making small bandwidth change to large pipe.
> Think about addimg 3 sts-1s to a sts-1-43v pipe, you would have to first
> make a sts-1-46v, switch the client signal over, then delete the original
> sts-1-43v.  I do agree that it is a more straight forward way to achieve the
> goal, it is probably also simpler to keep track of the sts-1s also.  I think
> however if bandwidth modification (to existing pipe) is an important service
> then we need a more efficient mechanism. I'm not saying that this would be
> easy.
> 
> My question to carriers would be: is b/w modification for virtually
> concatenated SPE important? in the short term & long term?
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 1:38 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> Vishal....you asked (in mail below) for operator input.....perhaps you
> missed this item I posted Wed 14/03/2001 13:35 on the thread 'RE: Three
> GMPLS related IDs' against this ID from Yangguang Xu
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
> 0.txt
> 
> <prior text snipped NH>
> 10      In section 5.4.1.5 'actions' on trails are defined.  For a CO
> network with fixed BW selection at trail creation time it is very hard to
> see what a 'modify' action could be....other than perhaps a change of
> restoration priority and/or change of dedicated back-up trail/resource.  If
> there is any notion of (working) BW change here (be it a scalar magnitude
> change, ie same route, or a vector change, ie new route (with or without a
> scalar magnitude change)), it would seem to me that this is really a new
> pair of 'create_new->switch_to_new->delete_old' actions.  I note however
> that this has been marked as TBD, but I think it would help if it was made
> clear that BW changes cannot (IMO) be a single 'modify' action.
> <post text snipped NH>
> 
> So in essence I agreed with what Juergen is saying.
> 
> neil
> 
> > -----Original Message-----
> > From: Heiles Juergen [mailto:[email-masked]]
> > Sent: 22 March 2001 09:07
> > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc: [email-masked]; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Vishal,
> >
> > in the circuit switched world he connection has a fixed
> > bandwidth. You cannot change the bandwidth. You have to tear
> > down the connection and set-up a new one with a different
> > bandwidth. For example if you want to change from VC-3
> > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > released and a VC-4 connection is setup. The route could be
> > different as some equipment migth support VC-3 but not VC-4s
> > or vice versa.
> > Virtual concatenation toegether with LCAS provides
> > flexibility in certain steps. However it applies only to the
> > end points as you mentioned. Between the end points you still
> > setup connections with fixed bandwidth.
> >
> > Regards
> >
> > Juergen
> >
> > > -----Original Message-----
> > > From:       Vishal Sharma [SMTP:[email-masked]]
> > > Sent:       Thursday, March 22, 2001 9:36 AM
> > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > Subject:    RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > > Hai,
> > >
> > > Yes, now that you mention it, it probably is an important
> > capability.
> > > (Although,
> > > I am not sure how soon it needs to be made available.)
> > > [Again, any carriers listening on this channel?? "Hello, calling all
> > > carriers... we need some service provider input here."]
> <snipped to end NH>
--------------AB8C0F7E00ACEA59946A3BEB
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------AB8C0F7E00ACEA59946A3BEB--

Delivery-date: Fri, 23 Mar 2001 01:55:19 -0800
Date: Fri, 23 Mar 2001 10:53:21 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: access to ITU-T and ETSI standards and contributions online

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

FYI, below are a number of links to ITU-T and ETSI transport network
related webpages, which contain published standards, draft standards,
contributions and correspondence. 

ITU-T published recommendations can be downloaded from
http://www.itu.int/itudoc/itu-t/rec/index.html

ITU-T pre-published recommendations can be downloaded from
http://www.itu.int/itudoc/itu-t/approved/

ITU-T recommendations are not available for free. Several alternatives
exist to get a recommendation. You find this described at
http://www.itu.int/ITU-T/publications/order.html

ITU-T draft recommendations and correspondence documents are available
via the web pages of the individual Questions (e.g. Q.9/15 for PDH, SDH
and OTN equipment and protection switching
http://ties.itu.int/u/tsg15/sg15/wp3/q9/, Q.11/15 for PDH, SDH and OTN
rates and formats
http://ties.itu.int/u/tsg15/sg15/wp3/q11/q11_index.htm)
Access is limited to TIES registered users. Information on TIES can be
found at http://www.itu.int/TIES/

The TIES root directory is at http://ties.itu.int/u/
Each Study Group (SG) has a subdirectory; e.g. SG15 subdirectory is at
http://ties.itu.int/u/tsg15/sg15/
Within each SG subdirectory you will find a directory for Temporary
Documents (td) containing all documents generated during the last
meeting, and directories for each Working Party (wp). E.g. SG15 WP3 is
at http://ties.itu.int/u/tsg15/sg15/wp3/
Each WP has a number of Questions (q). E.g. SG15 WP3 Q14 is at
http://ties.itu.int/u/tsg15/sg15/wp3/q14/
Questions organise their pages often per meeting date (e.g. 0102) and
per recommendation (e.g. G.ndisc).

A TIES registered user can also access the contributions and reports for
Study Group meetings at http://www.itu.int/itudoc/itu-t/ E.g. SG15
contributions/reports can be found at
http://www.itu.int/itudoc/itu-t/com15/index.html

ETSI publiscations can be downloaded (for free) from
http://webapp.etsi.org/pda/QueryForm.asp
ETSI uses a search engine to get to the standard. E.g. a search for
"SDH" will give you all SDH related standards.

Regards,

Maarten
--------------DEFA35EC59117D5A71032B47
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DEFA35EC59117D5A71032B47--

Delivery-date: Fri, 23 Mar 2001 01:05:49 -0800
From: Vishal Sharma <[email-masked]>
To: 'Hai Vodinh' <[email-masked]>, [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 23 Mar 2001 01:03:16 -0800

Juergen,

Also, one more point on your statement below....

-Vishal

> > -----Original Message-----

<snip>
> > > -----Original Message-----
> > > From: Heiles Juergen [mailto:[email-masked]]
> > > Sent: 22 March 2001 09:07
> > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: [email-masked]; Greg Bernstein (E-mail)
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > 
> > > Vishal,
> > > 
> > > in the circuit switched world he connection has a fixed 
> > > bandwidth. You cannot change the bandwidth. You have to tear 
> > > down the connection and set-up a new one with a different 
> > > bandwidth. For example if you want to change from VC-3 
> > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> > > released and a VC-4 connection is setup. The route could be 
> > > different as some equipment migth support VC-3 but not VC-4s 
> > > or vice versa.
> > > Virtual concatenation toegether with LCAS provides 
> > > flexibility in certain steps. However it applies only to the 
> > > end points as you mentioned. Between the end points you still 
> > > setup connections with fixed bandwidth.

This refers specifically to your last statement. It is true that between
the end points, each of the _component connections_ of a virtually
concatenated
signal is of fixed bandwidth, but one could always change the bandwidth of
the virtually concatenated signal itself (in discrete increments), by adding
or 
removing one or more of the component connections. So in that case, there
would be no need to tear down the entire signal and establish a different
one.

Delivery-date: Fri, 23 Mar 2001 00:59:33 -0800
From: Vishal Sharma <[email-masked]>
To: 'sambasiva mantha' <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 23 Mar 2001 00:56:48 -0800

Sambu,

I stand behind my statement :-).
In the "bundling" group, as defined, neither the intermediate nodes nor
the end nodes need to do anything special whatsoever.
I reiterate that the "bundle" group is merely for optimizing the setup
of multiple, _independent_, SDH/SONET circuits in parallel. The 
end result is exactly equivalent
to setting up each of the components of the "bundle" independently (which
would clearly require no special treatment at either the intermediate
or the end nodes).

(BTW, please note that setting up 3 STS-1s in parallel, is different from
setting up an STS-3, which is different from setting up an STS-3c, which,
in turn, is different from setting up an STS-3v, which, in turn, is
different
from setting up an STS-3a (a= arbitrarily concatenated).)

-Vishal

> -----Original Message-----
> From: sambasiva mantha [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 6:16 AM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> I understand what is "bundling" group is for. What I was 
> questioning was your
> statement that no special handling is required for the 
> bundling. They are
> treated the same at the end nodes and at the intermediate 
> nodes. What I was
> pointing out was that when they are tagged as "bundling" 
> group, then the
> intermediate nodes also have to treat it specially.
> 
> Sambu
> 
> 
> Vishal Sharma wrote:
> 
> > Sambu,
> >
> > The "bundling" group type is defined to allow for the setup 
> of multiple
> > channels in parallel, such as three STS-1s in parallel, 
> instead of setting
> > up each individually. (Note that the draft currently allows for
> > the bundling of only those channels that are in the same 
> higher-order
> > container.) This also allows the operator to control the 
> fate of these
> > bundled channels.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: sambasiva mantha [mailto:[email-masked]]
> > > Sent: Wednesday, March 21, 2001 9:09 AM
> > > To: Vishal Sharma
> > > Cc: 'manoj juneja'; [email-masked]
> > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Vishal,
> > >
> > > As  you pointed at the end of the email, if a speciality
> > > funcitionality is not
> > > required for "bundling" group type, then why there is a need for
> > > distinguishing the group as such. In case of a SONET DCS the
> > > bundling has a
> > > quite a unique function (see GR-2996). Once a group of STS-1s
> > > which must be
> > > contigous, are defined as part of a bundle, the DCS does 
> not allow the
> > > operator to separate these STS-1s out in the sense they have
> > > to come in on one
> > > input port (OC-n say) and all the STS-1s in the bundle have
> > > to cross connected
> > > to the same outgoing output port (OC-m).
> > >
> > > Sambu
> > >
> > >
> > > Vishal Sharma wrote:
> > >
> > > > Manoj,
> > > >
> > > > Some clarifications follow...
> > > >
> > > > -Vishal
> > > >
> > > > > -----Original Message-----
> > > > > From: manoj juneja [mailto:[email-masked]]
> > > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > > To: [email-masked]
> > > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > > >
> > > > >
> > > > > Hi All,
> > > > >         The GMPLS draft
> > > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > > defines different values for RGT (Requested Grouping 
> Type) viz.
> > > > > Virtual Concatenation, Contiguous standard concatenation,
> > > Contiguous
> > > > > arbitrary concatenation, Bundle.
> > > > > How does the implementation of a control plane differ if
> > > it receives
> > > > > different RGT values ?
> > > >
> > > > The implementation of the control plane should not 
> differ based on
> > > > different RGT values, the implementation of the data 
> plane is what
> > > > differs in all of these cases, because each RGT value 
> controls how
> > > > the data bearing channels are  treated by the end nodes and the
> > > > intermediate nodes.
> > > >
> > > > For example, for virtual concatenation, the 
> intermediate nodes treat
> > > > the virtually
> > > > concatenated channels as they would treat independent 
> channels. The
> > > > end points, however, treat these channels as "bonded"
> > > together, and must
> > > > have hardware and software support to "glue" the data
> > > arriving on these
> > > > channels together appropriately. (For instance, the 
> hardware must
> > > > support compensation for the differential delay that 
> the component
> > > > channels of the virtually concatenated stream may suffer.)
> > > >
> > > > > Another field RNC (Reuested Number of
> > > > > Components) defines the number of such components requested.
> > > > > My understanding is that if RNC is 2 and signal type is
> > > STM-1. Then it
> > > > > means that 2 STM-1 signals are requested and these are
> > > concatenated
> > > > > according to the RGT specified.
> > > >
> > > > Your understanding is correct.
> > > >
> > > > > Does this mean, the number of labels
> > > > > requested depend on the RNC field ?  This means that is
> > > RNC is "X",
> > > > > then "X" number of labels are to be returned in Label
> > > Mapping message
> > > > > and the labels returned should be in accrodance with 
> the requested
> > > > > signal type.
> > > >
> > > > Not quite. The number of labels will be determined by a
> > > combination of
> > > > the RNC and RGT.
> > > >
> > > > To understand this, let's consider the setting up of an 
> STS-3 SONET
> > > > channel (which is transparent
> > > > only at the path level, so that line and section overheads
> > > are not to be
> > > > preserved across SONET equipment), and see what happens in
> > > the various
> > > > cases.
> > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > >
> > > > If RGT = contiguous standard or contiguous arbitrary
> > > concatenation, then
> > > > only a _single_ label is returned (that one that denotes
> > > the time slot at
> > > > which the first of the concatenated channels begins).
> > > >
> > > > If, however, RGT = virtual concatenation or bundle, then 3
> > > labels (or
> > > > # of labels = RNC in the general case) will
> > > > need to be returned in the label mapping message (namely,
> > > the times slots
> > > > that denote where _each_ of the component STS-1s of the
> > > STS-3 signal is to
> > > > be placed, since in these cases the component STS-1s need
> > > not occur in
> > > > contiguous time slots).
> > > >
> > > > > Please clarify these doubts.
> > > >
> > > > Hope the above helps.
> > > >
> > > > > Can somebody please brief me on grouping type Bundle ?
> > > >
> > > > "Bundle" is nothing but an optimized way of simultaneously
> > > > setting up multiple, independent
> > > > SONET channels across a SONET network. Thus, in my 
> example above, if
> > > > RGT=bundle, what would really be setup in the SONET 
> network would be
> > > > three channels of STS-1 granularity, where each would be totally
> > > > independent of the others, both at the intermediate nodes and at
> > > > the end nodes.
> > > >
> > > > If, however, RGT=virtual concatenation, then what would 
> really be
> > > > setup in the SONET network would again be 3 channels of STS-1
> > > > granularity, which to the intermediate nodes would be 
> no different
> > > > from the case above. To the end nodes, however, it 
> would mean that
> > > > they need to have the capability to handle virtually 
> concatenated
> > > > SONET channels (which means they need to be capable of 
> appropriately
> > > > dividing traffic across them [at the input], and 
> "glueing" them back
> > > > together [at the output]).
> > > >
> > > > > Is there any additional capability required in the network for
> > > > > supporting different types of grouping types (RGTs) ?
> > > >
> > > > Not sure what you mean by "additional" capability? In "addition"
> > > > to what?
> > > >
> > > > For contiguous standard concatenation, the network nodes need to
> > > > be able to support standard SDH/SONET concatenation.
> > > > For continuous arbitrary concatenation, the network 
> nodes involved
> > > > in the establishment of such a channel, need to be able 
> to support
> > > > arbitrary concatenation.
> > > > For virtual concatenation, the intermediate nodes through which
> > > > the channle passes need no additional functionality, but the
> > > > end nodes must be able to support the processing of virtually
> > > > concatenated channels.
> > > > For bundling, absolutely no special functionality is required
> > > > in either the intermediate nodes or the end nodes.
> > > >
> > > >
> > > > >
> > >
> 

Delivery-date: Fri, 23 Mar 2001 00:54:17 -0800
From: Vishal Sharma <[email-masked]>
To: 'Hai Vodinh' <[email-masked]>, [email-masked]
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Fri, 23 Mar 2001 00:51:31 -0800

Neil and Juergen,

I think Hai has already made the point. When I was talking about change
in bandwidth, I was implicitly assuming that Hai was referring to the
virtual concatenation case. (Correct me if I am wrong, but I didn't 
think there was any other situation, proposed in the standards, 
where you could dynamically change the bandwidth of an existing SONET
channel.)
[Although, one might conceive of situations where implementations that
support
arbitrary concatenation might allow for one to increase the bandwidth
of an existing circuit simply by adding more STS-1s to it. For instance,
if one was switching an arbitrarily concatenated STS-5, and wanted to make
it an STS-7 (assuming that the 2 other STS-1s were contiguous with the
5 STS-1s that formed the STS-5 signal), one might be able to do it.]

I understand that if you wanted to setup
a totally different SONET/SDH channel (with a different bandwidth),
you would need to go the "create new->switch_to_new->delete old"
route.

Also, Neil, I did read your earlier email. The reason I did not think that
that comment applied here was because (I thought) the current discussion
was only in the context of virtual concatenation with LCAS, 
since that appears to be the only scheme which allows for the dynamic
addition or deletion of channels to an existing (virtually 
concatenated) connection.

-Vishal

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 12:56 PM
> To: [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Neil
> 
> The 'create_new->switch_to_new->delete_old' scheme seems to 
> me to be fairly
> inefficient mechanism for making small bandwidth change to large pipe.
> Think about addimg 3 sts-1s to a sts-1-43v pipe, you would 
> have to first
> make a sts-1-46v, switch the client signal over, then delete 
> the original
> sts-1-43v.  I do agree that it is a more straight forward way 
> to achieve the
> goal, it is probably also simpler to keep track of the sts-1s 
> also.  I think
> however if bandwidth modification (to existing pipe) is an 
> important service
> then we need a more efficient mechanism. I'm not saying that 
> this would be
> easy.
> 
> My question to carriers would be: is b/w modification for virtually
> concatenated SPE important? in the short term & long term?
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 1:38 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal....you asked (in mail below) for operator input.....perhaps you
> missed this item I posted Wed 14/03/2001 13:35 on the thread 
> 'RE: Three
> GMPLS related IDs' against this ID from Yangguang Xu
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> intra-domain-0
> 0.txt
> 
> <prior text snipped NH>
> 10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
> network with fixed BW selection at trail creation time it is 
> very hard to
> see what a 'modify' action could be....other than perhaps a change of
> restoration priority and/or change of dedicated back-up 
> trail/resource.  If
> there is any notion of (working) BW change here (be it a 
> scalar magnitude
> change, ie same route, or a vector change, ie new route (with 
> or without a
> scalar magnitude change)), it would seem to me that this is 
> really a new
> pair of 'create_new->switch_to_new->delete_old' actions.  I 
> note however
> that this has been marked as TBD, but I think it would help 
> if it was made
> clear that BW changes cannot (IMO) be a single 'modify' action.
> <post text snipped NH>
> 
> So in essence I agreed with what Juergen is saying.
> 
> neil
> 
> > -----Original Message-----
> > From: Heiles Juergen [mailto:[email-masked]]
> > Sent: 22 March 2001 09:07
> > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc: [email-masked]; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Vishal,
> > 
> > in the circuit switched world he connection has a fixed 
> > bandwidth. You cannot change the bandwidth. You have to tear 
> > down the connection and set-up a new one with a different 
> > bandwidth. For example if you want to change from VC-3 
> > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> > released and a VC-4 connection is setup. The route could be 
> > different as some equipment migth support VC-3 but not VC-4s 
> > or vice versa.
> > Virtual concatenation toegether with LCAS provides 
> > flexibility in certain steps. However it applies only to the 
> > end points as you mentioned. Between the end points you still 
> > setup connections with fixed bandwidth.
> > 
> > Regards
> > 
> > Juergen
> > 
> > > -----Original Message-----
> > > From:	Vishal Sharma [SMTP:[email-masked]]
> > > Sent:	Thursday, March 22, 2001 9:36 AM
> > > To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc:	[email-masked]; Greg Bernstein (E-mail)
> > > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > Hai,
> > > 
> > > Yes, now that you mention it, it probably is an important 
> > capability.
> > > (Although,
> > > I am not sure how soon it needs to be made available.)
> > > [Again, any carriers listening on this channel?? "Hello, 
> calling all
> > > carriers... we need some service provider input here."]
> <snipped to end NH>
> 

Delivery-date: Thu, 22 Mar 2001 14:43:43 -0800
From: "Bernstein, Greg" <[email-masked]>
To: Hai Vodinh <[email-masked]>, "'Vishal Sharma'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: [email-masked]
Subject: Virtual concat, LCAS and T1 documents... RE: Please Clarify Doubt s regarding RGT & RNC
Date: Thu, 22 Mar 2001 14:40:51 -0800

Hi folks, the only way of doing this with circuit switching is via an
inverse multiplexing process like virtual concatenation plus a protocol such
as the link channel adjustment scheme (LCAS).  This is a relatively new
development, i.e., to find it you'll need to look at the letter ballot for
the new version of the "basic SONET rates and formats" document: T1.105-200x
T1X1.5/2000-193R1  (Draft ANSI T1.105-200x - Contents of LB809 with addendum
information from T1X1.5/2000-129R2).  This can be found by rummaging through
the www.t1.org web site.  

Also standards documents can be obtain for free from the ATIS document
center (look at the small print at the bottom of the web page for one free
electronic download of the document you're interested in. Note that you can
only download the same document once or so it says.  Hmmm I haven't tested
this though).  Most of the SONET documents are in the T1.105 series.
Unfortunately ITU doesn't offer a similar service.
Hope this helps.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Hai Vodinh [mailto:[email-masked]]
Sent: Wednesday, March 21, 2001 12:00 PM
To: 'Vishal Sharma'; Hai Vodinh; 'Zhi-Wei Lin'
Cc: [email-masked]; Bernstein, Greg
Subject: RE: Please Clarify Doubts regarding RGT & RNC

Vishal, Greg,

Thanks for the clarification on the difference between VC and bundling.  On
my last question, isn't the abibility to get additional bandwidth for an
already established signal a crucial requirement for the type of
bandwidth-on-demand or more appropriately bandwidth-modification service
that we are thinking of today?

Thanks,
Hai

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 11:45 PM
To: 'Hai Vodinh'; 'Zhi-Wei Lin'
Cc: [email-masked]; Greg Bernstein (E-mail)
Subject: RE: Please Clarify Doubts regarding RGT & RNC

Hi Hai,

Greg has already provided an answer. I just wanted to add that in
my initial explanation to Manoj, I did point out what the difference
was between virtual concat. and bundling. For the intermediate
nodes, there is no difference, the differene only comes in for
the end points, which in the virtual concat. case have to know
which channels are virtually concatenated, and compensate for 
differential delay across these channels.

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 5:14 PM
> To: 'Zhi-Wei Lin'; Vishal Sharma
> Cc: [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> I tend to agree with Zhi-Wei that when you need to set up multiple
> connections these should be done separately (except perhaps 
> in the virtual
> concatenated case) to keep the signaling protocol simple.
> 
> I'm following the discussion and still don't have a clear 
> idea why both
> virtual concatenation and bundling RGT are needed.  What is 
> the difference
> between the two types?
> 
> Here is another question: let's say I have a STS-1-4v SPE 
> already set up,
> now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how 
> do I signal to
> the network that the additional 2 STS-1s need to be co-routed 
> with the other

I am not sure that there is any easy way to day to perform such 
signaling.

> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 12:17 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > > 3 STS-3: ??? How would you signal this? Not supported?
> > 
> > What do you wish to signal here? Three groups of STS-3 each?
> > What does it mean? The STS-3 is a bundle, and you wish to signal
> > a bundle of bundles?
> > 
> > If that is so, and unless I am missing something, I think you'd have
> > to signal them separately.
> > 
> > BTW, I wasn't immediately able to see how this would be signaled
> > even using the codepoints proposed in
> > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > 
> 
> I don't understand how that is a bundle. STS-3 as defined in 
> the T1.105
> is the entire signal. So then if you can signal multiple STS-1s, my
> question was why is this not supported for STS-3 or other STS-X.
> 
> Right, draft-lin assumes that when you need to set up multiple
> connections, these are done separately. Adding the capability for
> multiple connection set-ups as part of the signaling mechanism is not
> really necessary. Remember that the signaling mechanism is not the GUI
> to the customer. The GUI that the customer sees can provide that
> feature. The interface from GUI to the signaling can be a 
> batch function
> that sets up the multiple connections. This simplifies the signaling
> protocol, allows "bundling" of different connection types 
> set-up at once
> (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> STS-48c at
> once) via a batch process, and does not complicate the protocol from
> having to handle this issue.
> 
> Some of the points mentioned by Ewart in the OIF discussion was: when
> multiple connections are handled at once, what are the characteristics
> of these connections? Do they all terminate at the same location? Are
> they all co-routed or separately routed? How many labels do 
> you return?
> If one label is returned, what happens when one connection 
> failed? What
> if the multiple connections have different destinations? etc.
> 
> 
> > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > arbitrary)
> > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > >
> > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > 
> > Again, as things stand today, you'd have to signal this separately.
> > 
> > First, is there a requirement to signal these this way? Assuming
> > there is, is there a proposal that allows for that?
> > 
> 
> I wasn't sure whether there is requirement or not. I was 
> extending your
> example with what was offered currently. My view was that it 
> seems that
> some capabilities are available to certain signal types and 
> not to other
> signal types. We probably need to extend or clarify the text, 
> or adopt a
> different position in terms of what should and should not be 
> provided by
> the signaling protocol, and leave "added features" to 
> separate functions
> (the batch process I mentioned above).
> 
> 
> > I cannot see how 
> draft-lin-ccamp-ipo-common-label-request-01.txt would
> > do it either, since the RNC has been absorbed into the signal type
> > in that case, and not all cases are enumerated.
> > 
> 
> See above for comment.
> 
> > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > >
> > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > 
> > Same as the two above.
> > 
> 
> See above (sorry, too many "aboves") ;-)
> 
> Zhi
> 

Delivery-date: Thu, 22 Mar 2001 13:04:32 -0800
From: Hai Vodinh <[email-masked]>
To: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 22 Mar 2001 12:56:29 -0800

Neil

The 'create_new->switch_to_new->delete_old' scheme seems to me to be fairly
inefficient mechanism for making small bandwidth change to large pipe.
Think about addimg 3 sts-1s to a sts-1-43v pipe, you would have to first
make a sts-1-46v, switch the client signal over, then delete the original
sts-1-43v.  I do agree that it is a more straight forward way to achieve the
goal, it is probably also simpler to keep track of the sts-1s also.  I think
however if bandwidth modification (to existing pipe) is an important service
then we need a more efficient mechanism. I'm not saying that this would be
easy.

My question to carriers would be: is b/w modification for virtually
concatenated SPE important? in the short term & long term?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 1:38 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC

Vishal....you asked (in mail below) for operator input.....perhaps you
missed this item I posted Wed 14/03/2001 13:35 on the thread 'RE: Three
GMPLS related IDs' against this ID from Yangguang Xu
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
0.txt

<prior text snipped NH>
10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
network with fixed BW selection at trail creation time it is very hard to
see what a 'modify' action could be....other than perhaps a change of
restoration priority and/or change of dedicated back-up trail/resource.  If
there is any notion of (working) BW change here (be it a scalar magnitude
change, ie same route, or a vector change, ie new route (with or without a
scalar magnitude change)), it would seem to me that this is really a new
pair of 'create_new->switch_to_new->delete_old' actions.  I note however
that this has been marked as TBD, but I think it would help if it was made
clear that BW changes cannot (IMO) be a single 'modify' action.
<post text snipped NH>

So in essence I agreed with what Juergen is saying.

neil

> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: 22 March 2001 09:07
> To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: [email-masked]; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> in the circuit switched world he connection has a fixed 
> bandwidth. You cannot change the bandwidth. You have to tear 
> down the connection and set-up a new one with a different 
> bandwidth. For example if you want to change from VC-3 
> (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> released and a VC-4 connection is setup. The route could be 
> different as some equipment migth support VC-3 but not VC-4s 
> or vice versa.
> Virtual concatenation toegether with LCAS provides 
> flexibility in certain steps. However it applies only to the 
> end points as you mentioned. Between the end points you still 
> setup connections with fixed bandwidth.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From:	Vishal Sharma [SMTP:[email-masked]]
> > Sent:	Thursday, March 22, 2001 9:36 AM
> > To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc:	[email-masked]; Greg Bernstein (E-mail)
> > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > Hai,
> > 
> > Yes, now that you mention it, it probably is an important 
> capability.
> > (Although,
> > I am not sure how soon it needs to be made available.)
> > [Again, any carriers listening on this channel?? "Hello, calling all
> > carriers... we need some service provider input here."]
<snipped to end NH>

Delivery-date: Thu, 22 Mar 2001 06:20:30 -0800
Date: Thu, 22 Mar 2001 08:15:56 -0600
From: sambasiva mantha <[email-masked]>
Organization: Alcatel
To: Vishal Sharma <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Vishal,

I understand what is "bundling" group is for. What I was questioning was your
statement that no special handling is required for the bundling. They are
treated the same at the end nodes and at the intermediate nodes. What I was
pointing out was that when they are tagged as "bundling" group, then the
intermediate nodes also have to treat it specially.

Sambu

Vishal Sharma wrote:

> Sambu,
>
> The "bundling" group type is defined to allow for the setup of multiple
> channels in parallel, such as three STS-1s in parallel, instead of setting
> up each individually. (Note that the draft currently allows for
> the bundling of only those channels that are in the same higher-order
> container.) This also allows the operator to control the fate of these
> bundled channels.
>
> -Vishal
>
> > -----Original Message-----
> > From: sambasiva mantha [mailto:[email-masked]]
> > Sent: Wednesday, March 21, 2001 9:09 AM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Vishal,
> >
> > As  you pointed at the end of the email, if a speciality
> > funcitionality is not
> > required for "bundling" group type, then why there is a need for
> > distinguishing the group as such. In case of a SONET DCS the
> > bundling has a
> > quite a unique function (see GR-2996). Once a group of STS-1s
> > which must be
> > contigous, are defined as part of a bundle, the DCS does not allow the
> > operator to separate these STS-1s out in the sense they have
> > to come in on one
> > input port (OC-n say) and all the STS-1s in the bundle have
> > to cross connected
> > to the same outgoing output port (OC-m).
> >
> > Sambu
> >
> >
> > Vishal Sharma wrote:
> >
> > > Manoj,
> > >
> > > Some clarifications follow...
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: manoj juneja [mailto:[email-masked]]
> > > > Sent: Monday, March 19, 2001 3:35 PM
> > > > To: [email-masked]
> > > > Subject: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > >
> > > > Hi All,
> > > >         The GMPLS draft
> > > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > > defines different values for RGT (Requested Grouping Type) viz.
> > > > Virtual Concatenation, Contiguous standard concatenation,
> > Contiguous
> > > > arbitrary concatenation, Bundle.
> > > > How does the implementation of a control plane differ if
> > it receives
> > > > different RGT values ?
> > >
> > > The implementation of the control plane should not differ based on
> > > different RGT values, the implementation of the data plane is what
> > > differs in all of these cases, because each RGT value controls how
> > > the data bearing channels are  treated by the end nodes and the
> > > intermediate nodes.
> > >
> > > For example, for virtual concatenation, the intermediate nodes treat
> > > the virtually
> > > concatenated channels as they would treat independent channels. The
> > > end points, however, treat these channels as "bonded"
> > together, and must
> > > have hardware and software support to "glue" the data
> > arriving on these
> > > channels together appropriately. (For instance, the hardware must
> > > support compensation for the differential delay that the component
> > > channels of the virtually concatenated stream may suffer.)
> > >
> > > > Another field RNC (Reuested Number of
> > > > Components) defines the number of such components requested.
> > > > My understanding is that if RNC is 2 and signal type is
> > STM-1. Then it
> > > > means that 2 STM-1 signals are requested and these are
> > concatenated
> > > > according to the RGT specified.
> > >
> > > Your understanding is correct.
> > >
> > > > Does this mean, the number of labels
> > > > requested depend on the RNC field ?  This means that is
> > RNC is "X",
> > > > then "X" number of labels are to be returned in Label
> > Mapping message
> > > > and the labels returned should be in accrodance with the requested
> > > > signal type.
> > >
> > > Not quite. The number of labels will be determined by a
> > combination of
> > > the RNC and RGT.
> > >
> > > To understand this, let's consider the setting up of an STS-3 SONET
> > > channel (which is transparent
> > > only at the path level, so that line and section overheads
> > are not to be
> > > preserved across SONET equipment), and see what happens in
> > the various
> > > cases.
> > > In every case, the signal type = STS-1, and the RNC = 3.
> > >
> > > If RGT = contiguous standard or contiguous arbitrary
> > concatenation, then
> > > only a _single_ label is returned (that one that denotes
> > the time slot at
> > > which the first of the concatenated channels begins).
> > >
> > > If, however, RGT = virtual concatenation or bundle, then 3
> > labels (or
> > > # of labels = RNC in the general case) will
> > > need to be returned in the label mapping message (namely,
> > the times slots
> > > that denote where _each_ of the component STS-1s of the
> > STS-3 signal is to
> > > be placed, since in these cases the component STS-1s need
> > not occur in
> > > contiguous time slots).
> > >
> > > > Please clarify these doubts.
> > >
> > > Hope the above helps.
> > >
> > > > Can somebody please brief me on grouping type Bundle ?
> > >
> > > "Bundle" is nothing but an optimized way of simultaneously
> > > setting up multiple, independent
> > > SONET channels across a SONET network. Thus, in my example above, if
> > > RGT=bundle, what would really be setup in the SONET network would be
> > > three channels of STS-1 granularity, where each would be totally
> > > independent of the others, both at the intermediate nodes and at
> > > the end nodes.
> > >
> > > If, however, RGT=virtual concatenation, then what would really be
> > > setup in the SONET network would again be 3 channels of STS-1
> > > granularity, which to the intermediate nodes would be no different
> > > from the case above. To the end nodes, however, it would mean that
> > > they need to have the capability to handle virtually concatenated
> > > SONET channels (which means they need to be capable of appropriately
> > > dividing traffic across them [at the input], and "glueing" them back
> > > together [at the output]).
> > >
> > > > Is there any additional capability required in the network for
> > > > supporting different types of grouping types (RGTs) ?
> > >
> > > Not sure what you mean by "additional" capability? In "addition"
> > > to what?
> > >
> > > For contiguous standard concatenation, the network nodes need to
> > > be able to support standard SDH/SONET concatenation.
> > > For continuous arbitrary concatenation, the network nodes involved
> > > in the establishment of such a channel, need to be able to support
> > > arbitrary concatenation.
> > > For virtual concatenation, the intermediate nodes through which
> > > the channle passes need no additional functionality, but the
> > > end nodes must be able to support the processing of virtually
> > > concatenated channels.
> > > For bundling, absolutely no special functionality is required
> > > in either the intermediate nodes or the end nodes.
> > >
> > >
> > > >
> >

Delivery-date: Thu, 22 Mar 2001 01:43:07 -0800
From: [email-masked]
To: [email-masked], [email-masked],  [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 22 Mar 2001 09:38:09 -0000

Vishal....you asked (in mail below) for operator input.....perhaps you
missed this item I posted Wed 14/03/2001 13:35 on the thread 'RE: Three
GMPLS related IDs' against this ID from Yangguang Xu
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
0.txt

<prior text snipped NH>
10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
network with fixed BW selection at trail creation time it is very hard to
see what a 'modify' action could be....other than perhaps a change of
restoration priority and/or change of dedicated back-up trail/resource.  If
there is any notion of (working) BW change here (be it a scalar magnitude
change, ie same route, or a vector change, ie new route (with or without a
scalar magnitude change)), it would seem to me that this is really a new
pair of 'create_new->switch_to_new->delete_old' actions.  I note however
that this has been marked as TBD, but I think it would help if it was made
clear that BW changes cannot (IMO) be a single 'modify' action.
<post text snipped NH>

So in essence I agreed with what Juergen is saying.

neil

> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: 22 March 2001 09:07
> To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: [email-masked]; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> in the circuit switched world he connection has a fixed 
> bandwidth. You cannot change the bandwidth. You have to tear 
> down the connection and set-up a new one with a different 
> bandwidth. For example if you want to change from VC-3 
> (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> released and a VC-4 connection is setup. The route could be 
> different as some equipment migth support VC-3 but not VC-4s 
> or vice versa.
> Virtual concatenation toegether with LCAS provides 
> flexibility in certain steps. However it applies only to the 
> end points as you mentioned. Between the end points you still 
> setup connections with fixed bandwidth.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From:	Vishal Sharma [SMTP:[email-masked]]
> > Sent:	Thursday, March 22, 2001 9:36 AM
> > To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc:	[email-masked]; Greg Bernstein (E-mail)
> > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > Hai,
> > 
> > Yes, now that you mention it, it probably is an important 
> capability.
> > (Although,
> > I am not sure how soon it needs to be made available.)
> > [Again, any carriers listening on this channel?? "Hello, calling all
> > carriers... we need some service provider input here."]
<snipped to end NH>

Delivery-date: Thu, 22 Mar 2001 01:07:46 -0800
From: Heiles Juergen <[email-masked]>
To: "'Vishal Sharma'" <[email-masked]>, "'Hai Vodinh'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: [email-masked], "Greg Bernstein (E-mail)" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 22 Mar 2001 10:07:28 +0100

Vishal,

in the circuit switched world he connection has a fixed bandwidth. You cannot change the bandwidth. You have to tear down the connection and set-up a new one with a different bandwidth. For example if you want to change from VC-3 (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is released and a VC-4 connection is setup. The route could be different as some equipment migth support VC-3 but not VC-4s or vice versa.
Virtual concatenation toegether with LCAS provides flexibility in certain steps. However it applies only to the end points as you mentioned. Between the end points you still setup connections with fixed bandwidth.

Regards

Juergen

> -----Original Message-----
> From:	Vishal Sharma [SMTP:[email-masked]]
> Sent:	Thursday, March 22, 2001 9:36 AM
> To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc:	[email-masked]; Greg Bernstein (E-mail)
> Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> 
> Hai,
> 
> Yes, now that you mention it, it probably is an important capability.
> (Although,
> I am not sure how soon it needs to be made available.)
> [Again, any carriers listening on this channel?? "Hello, calling all
> carriers... we need some service provider input here."]
> 
> In the packet world, this was envisaged to be achieved as follows.
> If one uses RSVP-TE, a different SENDER TSPEC with a modified bandwidth
> parameter
> in the PATH message would be expected to change the reservations along the
> path. Thus, after at most one round trip delay, the sender could start
> transmitting
> data at the new (greater or lesser) rate. (Or more accurately, the sender
> could start transmitting with the new _traffic parameters_, with the
> assumption
> that the admission control at the intermediate nodes has done its job and
> reserved adequate resources for the modified parameters.)
> 
> Now whether the exact same mechanism works for the TDM case, or is adequate
> for the TDM case, I think needs more thought.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:[email-masked]]
> > Sent: Wednesday, March 21, 2001 12:00 PM
> > To: 'Vishal Sharma'; Hai Vodinh; 'Zhi-Wei Lin'
> > Cc: [email-masked]; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Vishal, Greg,
> > 
> > Thanks for the clarification on the difference between VC and 
> > bundling.  On
> > my last question, isn't the abibility to get additional 
> > bandwidth for an
> > already established signal a crucial requirement for the type of
> > bandwidth-on-demand or more appropriately 
> > bandwidth-modification service
> > that we are thinking of today?
> > 
> > Thanks,
> > Hai
> > 
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 11:45 PM
> > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc: [email-masked]; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Hi Hai,
> > 
> > Greg has already provided an answer. I just wanted to add that in
> > my initial explanation to Manoj, I did point out what the difference
> > was between virtual concat. and bundling. For the intermediate
> > nodes, there is no difference, the differene only comes in for
> > the end points, which in the virtual concat. case have to know
> > which channels are virtually concatenated, and compensate for 
> > differential delay across these channels.
> > 
> > > -----Original Message-----
> > > From: Hai Vodinh [mailto:[email-masked]]
> > > Sent: Tuesday, March 20, 2001 5:14 PM
> > > To: 'Zhi-Wei Lin'; Vishal Sharma
> > > Cc: [email-masked]
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > 
> > > I tend to agree with Zhi-Wei that when you need to set up multiple
> > > connections these should be done separately (except perhaps 
> > > in the virtual
> > > concatenated case) to keep the signaling protocol simple.> 
> > > 
> > > I'm following the discussion and still don't have a clear 
> > > idea why both
> > > virtual concatenation and bundling RGT are needed.  What is 
> > > the difference
> > > between the two types?
> > > 
> > > Here is another question: let's say I have a STS-1-4v SPE 
> > > already set up,
> > > now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how 
> > > do I signal to
> > > the network that the additional 2 STS-1s need to be co-routed 
> > > with the other
> > 
> > I am not sure that there is any easy way to day to perform such 
> > signaling.
> > 
> > 
> > > 
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > Sent: Tuesday, March 20, 2001 12:17 PM
> > > To: Vishal Sharma
> > > Cc: 'manoj juneja'; [email-masked]
> > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > 
> > > Hi Vishal,
> > > 
> > > 
> > > 
> > > > > 3 STS-3: ??? How would you signal this? Not supported?
> > > > 
> > > > What do you wish to signal here? Three groups of STS-3 each?
> > > > What does it mean? The STS-3 is a bundle, and you wish to signal
> > > > a bundle of bundles?
> > > > 
> > > > If that is so, and unless I am missing something, I think 
> > you'd have
> > > > to signal them separately.
> > > > 
> > > > BTW, I wasn't immediately able to see how this would be signaled
> > > > even using the codepoints proposed in
> > > > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > > > 
> > > 
> > > I don't understand how that is a bundle. STS-3 as defined in 
> > > the T1.105
> > > is the entire signal. So then if you can signal multiple STS-1s, my
> > > question was why is this not supported for STS-3 or other STS-X.
> > > 
> > > Right, draft-lin assumes that when you need to set up multiple
> > > connections, these are done separately. Adding the capability for
> > > multiple connection set-ups as part of the signaling 
> > mechanism is not
> > > really necessary. Remember that the signaling mechanism is 
> > not the GUI
> > > to the customer. The GUI that the customer sees can provide that
> > > feature. The interface from GUI to the signaling can be a 
> > > batch function
> > > that sets up the multiple connections. This simplifies the signaling
> > > protocol, allows "bundling" of different connection types 
> > > set-up at once
> > > (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> > > STS-48c at
> > > once) via a batch process, and does not complicate the protocol from
> > > having to handle this issue.
> > > 
> > > Some of the points mentioned by Ewart in the OIF discussion 
> > was: when
> > > multiple connections are handled at once, what are the 
> > characteristics
> > > of these connections? Do they all terminate at the same 
> > location? Are
> > > they all co-routed or separately routed? How many labels do 
> > > you return?
> > > If one label is returned, what happens when one connection 
> > > failed? What
> > > if the multiple connections have different destinations? etc.
> > > 
> > > 
> > > > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > > > arbitrary)
> > > > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > > >
> > > > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > > > 
> > > > Again, as things stand today, you'd have to signal this 
> > separately.
> > > > 
> > > > First, is there a requirement to signal these this way? Assuming
> > > > there is, is there a proposal that allows for that?
> > > > 
> > > 
> > > I wasn't sure whether there is requirement or not. I was 
> > > extending your
> > > example with what was offered currently. My view was that it 
> > > seems that
> > > some capabilities are available to certain signal types and 
> > > not to other
> > > signal types. We probably need to extend or clarify the text, 
> > > or adopt a
> > > different position in terms of what should and should not be 
> > > provided by
> > > the signaling protocol, and leave "added features" to > 
> > > separate functions
> > > (the batch process I mentioned above).
> > > 
> > > 
> > > > I cannot see how 
> > > draft-lin-ccamp-ipo-common-label-request-01.txt would
> > > > do it either, since the RNC has been absorbed into the signal type
> > > > in that case, and not all cases are enumerated.
> > > > 
> > > 
> > > See above for comment.
> > > 
> > > > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > > >
> > > > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > > > 
> > > > Same as the two above.
> > > > 
> > > 
> > > See above (sorry, too many "aboves") ;-)
> > > 
> > > Zhi
> > > 
> > 

Delivery-date: Thu, 22 Mar 2001 00:45:15 -0800
From: Vishal Sharma <[email-masked]>
To: 'sambasiva mantha' <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 22 Mar 2001 00:41:33 -0800

Sambu,

The "bundling" group type is defined to allow for the setup of multiple
channels in parallel, such as three STS-1s in parallel, instead of setting
up each individually. (Note that the draft currently allows for 
the bundling of only those channels that are in the same higher-order
container.) This also allows the operator to control the fate of these
bundled channels.

-Vishal

> -----Original Message-----
> From: sambasiva mantha [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 9:09 AM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> As  you pointed at the end of the email, if a speciality 
> funcitionality is not
> required for "bundling" group type, then why there is a need for
> distinguishing the group as such. In case of a SONET DCS the 
> bundling has a
> quite a unique function (see GR-2996). Once a group of STS-1s 
> which must be
> contigous, are defined as part of a bundle, the DCS does not allow the
> operator to separate these STS-1s out in the sense they have 
> to come in on one
> input port (OC-n say) and all the STS-1s in the bundle have 
> to cross connected
> to the same outgoing output port (OC-m).
> 
> Sambu
> 
> 
> Vishal Sharma wrote:
> 
> > Manoj,
> >
> > Some clarifications follow...
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: manoj juneja [mailto:[email-masked]]
> > > Sent: Monday, March 19, 2001 3:35 PM
> > > To: [email-masked]
> > > Subject: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Hi All,
> > >         The GMPLS draft
> > > "draft-ietf-mpls-generalized-signalling-02.txt"
> > > defines different values for RGT (Requested Grouping Type) viz.
> > > Virtual Concatenation, Contiguous standard concatenation, 
> Contiguous
> > > arbitrary concatenation, Bundle.
> > > How does the implementation of a control plane differ if 
> it receives
> > > different RGT values ?
> >
> > The implementation of the control plane should not differ based on
> > different RGT values, the implementation of the data plane is what
> > differs in all of these cases, because each RGT value controls how
> > the data bearing channels are  treated by the end nodes and the
> > intermediate nodes.
> >
> > For example, for virtual concatenation, the intermediate nodes treat
> > the virtually
> > concatenated channels as they would treat independent channels. The
> > end points, however, treat these channels as "bonded" 
> together, and must
> > have hardware and software support to "glue" the data 
> arriving on these
> > channels together appropriately. (For instance, the hardware must
> > support compensation for the differential delay that the component
> > channels of the virtually concatenated stream may suffer.)
> >
> > > Another field RNC (Reuested Number of
> > > Components) defines the number of such components requested.
> > > My understanding is that if RNC is 2 and signal type is 
> STM-1. Then it
> > > means that 2 STM-1 signals are requested and these are 
> concatenated
> > > according to the RGT specified.
> >
> > Your understanding is correct.
> >
> > > Does this mean, the number of labels
> > > requested depend on the RNC field ?  This means that is 
> RNC is "X",
> > > then "X" number of labels are to be returned in Label 
> Mapping message
> > > and the labels returned should be in accrodance with the requested
> > > signal type.
> >
> > Not quite. The number of labels will be determined by a 
> combination of
> > the RNC and RGT.
> >
> > To understand this, let's consider the setting up of an STS-3 SONET
> > channel (which is transparent
> > only at the path level, so that line and section overheads 
> are not to be
> > preserved across SONET equipment), and see what happens in 
> the various
> > cases.
> > In every case, the signal type = STS-1, and the RNC = 3.
> >
> > If RGT = contiguous standard or contiguous arbitrary 
> concatenation, then
> > only a _single_ label is returned (that one that denotes 
> the time slot at
> > which the first of the concatenated channels begins).
> >
> > If, however, RGT = virtual concatenation or bundle, then 3 
> labels (or
> > # of labels = RNC in the general case) will
> > need to be returned in the label mapping message (namely, 
> the times slots
> > that denote where _each_ of the component STS-1s of the 
> STS-3 signal is to
> > be placed, since in these cases the component STS-1s need 
> not occur in
> > contiguous time slots).
> >
> > > Please clarify these doubts.
> >
> > Hope the above helps.
> >
> > > Can somebody please brief me on grouping type Bundle ?
> >
> > "Bundle" is nothing but an optimized way of simultaneously
> > setting up multiple, independent
> > SONET channels across a SONET network. Thus, in my example above, if
> > RGT=bundle, what would really be setup in the SONET network would be
> > three channels of STS-1 granularity, where each would be totally
> > independent of the others, both at the intermediate nodes and at
> > the end nodes.
> >
> > If, however, RGT=virtual concatenation, then what would really be
> > setup in the SONET network would again be 3 channels of STS-1
> > granularity, which to the intermediate nodes would be no different
> > from the case above. To the end nodes, however, it would mean that
> > they need to have the capability to handle virtually concatenated
> > SONET channels (which means they need to be capable of appropriately
> > dividing traffic across them [at the input], and "glueing" them back
> > together [at the output]).
> >
> > > Is there any additional capability required in the network for
> > > supporting different types of grouping types (RGTs) ?
> >
> > Not sure what you mean by "additional" capability? In "addition"
> > to what?
> >
> > For contiguous standard concatenation, the network nodes need to
> > be able to support standard SDH/SONET concatenation.
> > For continuous arbitrary concatenation, the network nodes involved
> > in the establishment of such a channel, need to be able to support
> > arbitrary concatenation.
> > For virtual concatenation, the intermediate nodes through which
> > the channle passes need no additional functionality, but the
> > end nodes must be able to support the processing of virtually
> > concatenated channels.
> > For bundling, absolutely no special functionality is required
> > in either the intermediate nodes or the end nodes.
> >
> >
> > >
> 

Delivery-date: Thu, 22 Mar 2001 00:39:50 -0800
From: Vishal Sharma <[email-masked]>
To: 'Hai Vodinh' <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>
Cc: [email-masked], "Greg Bernstein (E-mail)" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Thu, 22 Mar 2001 00:36:02 -0800

Hai,

Yes, now that you mention it, it probably is an important capability.
(Although,
I am not sure how soon it needs to be made available.)
[Again, any carriers listening on this channel?? "Hello, calling all
carriers... we need some service provider input here."]

In the packet world, this was envisaged to be achieved as follows.
If one uses RSVP-TE, a different SENDER TSPEC with a modified bandwidth
parameter
in the PATH message would be expected to change the reservations along the
path. Thus, after at most one round trip delay, the sender could start
transmitting
data at the new (greater or lesser) rate. (Or more accurately, the sender
could start transmitting with the new _traffic parameters_, with the
assumption
that the admission control at the intermediate nodes has done its job and
reserved adequate resources for the modified parameters.)

Now whether the exact same mechanism works for the TDM case, or is adequate
for the TDM case, I think needs more thought.

-Vishal

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 12:00 PM
> To: 'Vishal Sharma'; Hai Vodinh; 'Zhi-Wei Lin'
> Cc: [email-masked]; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal, Greg,
> 
> Thanks for the clarification on the difference between VC and 
> bundling.  On
> my last question, isn't the abibility to get additional 
> bandwidth for an
> already established signal a crucial requirement for the type of
> bandwidth-on-demand or more appropriately 
> bandwidth-modification service
> that we are thinking of today?
> 
> Thanks,
> Hai
> 
> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 11:45 PM
> To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: [email-masked]; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Hai,
> 
> Greg has already provided an answer. I just wanted to add that in
> my initial explanation to Manoj, I did point out what the difference
> was between virtual concat. and bundling. For the intermediate
> nodes, there is no difference, the differene only comes in for
> the end points, which in the virtual concat. case have to know
> which channels are virtually concatenated, and compensate for 
> differential delay across these channels.
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 5:14 PM
> > To: 'Zhi-Wei Lin'; Vishal Sharma
> > Cc: [email-masked]
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > I tend to agree with Zhi-Wei that when you need to set up multiple
> > connections these should be done separately (except perhaps 
> > in the virtual
> > concatenated case) to keep the signaling protocol simple.
> > 
> > I'm following the discussion and still don't have a clear 
> > idea why both
> > virtual concatenation and bundling RGT are needed.  What is 
> > the difference
> > between the two types?
> > 
> > Here is another question: let's say I have a STS-1-4v SPE 
> > already set up,
> > now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how 
> > do I signal to
> > the network that the additional 2 STS-1s need to be co-routed 
> > with the other
> 
> I am not sure that there is any easy way to day to perform such 
> signaling.
> 
> 
> > 
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 12:17 PM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Hi Vishal,
> > 
> > 
> > 
> > > > 3 STS-3: ??? How would you signal this? Not supported?
> > > 
> > > What do you wish to signal here? Three groups of STS-3 each?
> > > What does it mean? The STS-3 is a bundle, and you wish to signal
> > > a bundle of bundles?
> > > 
> > > If that is so, and unless I am missing something, I think 
> you'd have
> > > to signal them separately.
> > > 
> > > BTW, I wasn't immediately able to see how this would be signaled
> > > even using the codepoints proposed in
> > > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > > 
> > 
> > I don't understand how that is a bundle. STS-3 as defined in 
> > the T1.105
> > is the entire signal. So then if you can signal multiple STS-1s, my
> > question was why is this not supported for STS-3 or other STS-X.
> > 
> > Right, draft-lin assumes that when you need to set up multiple
> > connections, these are done separately. Adding the capability for
> > multiple connection set-ups as part of the signaling 
> mechanism is not
> > really necessary. Remember that the signaling mechanism is 
> not the GUI
> > to the customer. The GUI that the customer sees can provide that
> > feature. The interface from GUI to the signaling can be a 
> > batch function
> > that sets up the multiple connections. This simplifies the signaling
> > protocol, allows "bundling" of different connection types 
> > set-up at once
> > (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> > STS-48c at
> > once) via a batch process, and does not complicate the protocol from
> > having to handle this issue.
> > 
> > Some of the points mentioned by Ewart in the OIF discussion 
> was: when
> > multiple connections are handled at once, what are the 
> characteristics
> > of these connections? Do they all terminate at the same 
> location? Are
> > they all co-routed or separately routed? How many labels do 
> > you return?
> > If one label is returned, what happens when one connection 
> > failed? What
> > if the multiple connections have different destinations? etc.
> > 
> > 
> > > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > > arbitrary)
> > > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > >
> > > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > > 
> > > Again, as things stand today, you'd have to signal this 
> separately.
> > > 
> > > First, is there a requirement to signal these this way? Assuming
> > > there is, is there a proposal that allows for that?
> > > 
> > 
> > I wasn't sure whether there is requirement or not. I was 
> > extending your
> > example with what was offered currently. My view was that it 
> > seems that
> > some capabilities are available to certain signal types and 
> > not to other
> > signal types. We probably need to extend or clarify the text, 
> > or adopt a
> > different position in terms of what should and should not be 
> > provided by
> > the signaling protocol, and leave "added features" to 
> > separate functions
> > (the batch process I mentioned above).
> > 
> > 
> > > I cannot see how 
> > draft-lin-ccamp-ipo-common-label-request-01.txt would
> > > do it either, since the RNC has been absorbed into the signal type
> > > in that case, and not all cases are enumerated.
> > > 
> > 
> > See above for comment.
> > 
> > > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > >
> > > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > > 
> > > Same as the two above.
> > > 
> > 
> > See above (sorry, too many "aboves") ;-)
> > 
> > Zhi
> > 
> 

Delivery-date: Wed, 21 Mar 2001 23:33:41 -0800
From: Jonathan Lang <[email-masked]>
To: 'Cheng-Yin Lee' <[email-masked]>, Jonathan Lang <[email-masked]>
Cc: [email-masked]
Subject: RE: New agenda for today (Wed March 21)
Date: Wed, 21 Mar 2001 23:27:36 -0800

Cheng-Yin,
  The "secondary" LSP (A-G-H-I-J-K-E) has reserved resources on the links,
but they have not yet been allocated to it.  This means that signal on J-K
is not cross-connected to K-E until the resources are needed for the
failover.

Cheers,
Jonathan

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 9:55 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: New agenda for today (Wed March 21)
> 
> 
> Hello,
> > 
> > Generalized MPLS Recovery Mechanisms, Jonathan Lang     (15 min)
> >         draft-lang-ccamp-recovery-00.txt
> 
> A question on one of the slides of this presentation showing extra
> traffic on an LSP (using links of the secondary path) being preempted
> when the primary path fails. As i recall, the slide shows something
> along this line :
> 
>     
> 
>        A--------B------C--------D------E
>        |                               |
>        |                               |
>  X-----G--------H------I--------J------K----Y
> 
> 
> A-B-C-D-E is the primary path
> A-G-H-I-J-K-E is the secondary path
> Another LSP X-G-H-I-J-K-Y was shown to carry extra traffic, 
> and this LSP
> will be preempted if a link on the path A-B-C-D-E fails. I don't quite
> follow how this works and how protection switching is effected. If a
> signal on J-K is cross connected to a signal on K-E for the secondary
> path how is the signal on J-K be cross connected to  K-Y for the extra
> traffic LSP? Could you pls clarify?
> 
> 
> thanks,
> cyl
> 

Delivery-date: Wed, 21 Mar 2001 12:08:02 -0800
From: Hai Vodinh <[email-masked]>
To: 'Vishal Sharma' <[email-masked]>, Hai Vodinh <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>
Cc: [email-masked], "Greg Bernstein (E-mail)" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Wed, 21 Mar 2001 11:59:58 -0800

Vishal, Greg,

Thanks for the clarification on the difference between VC and bundling.  On
my last question, isn't the abibility to get additional bandwidth for an
already established signal a crucial requirement for the type of
bandwidth-on-demand or more appropriately bandwidth-modification service
that we are thinking of today?

Thanks,
Hai

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 11:45 PM
To: 'Hai Vodinh'; 'Zhi-Wei Lin'
Cc: [email-masked]; Greg Bernstein (E-mail)
Subject: RE: Please Clarify Doubts regarding RGT & RNC

Hi Hai,

Greg has already provided an answer. I just wanted to add that in
my initial explanation to Manoj, I did point out what the difference
was between virtual concat. and bundling. For the intermediate
nodes, there is no difference, the differene only comes in for
the end points, which in the virtual concat. case have to know
which channels are virtually concatenated, and compensate for 
differential delay across these channels.

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 5:14 PM
> To: 'Zhi-Wei Lin'; Vishal Sharma
> Cc: [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> I tend to agree with Zhi-Wei that when you need to set up multiple
> connections these should be done separately (except perhaps 
> in the virtual
> concatenated case) to keep the signaling protocol simple.
> 
> I'm following the discussion and still don't have a clear 
> idea why both
> virtual concatenation and bundling RGT are needed.  What is 
> the difference
> between the two types?
> 
> Here is another question: let's say I have a STS-1-4v SPE 
> already set up,
> now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how 
> do I signal to
> the network that the additional 2 STS-1s need to be co-routed 
> with the other

I am not sure that there is any easy way to day to perform such 
signaling.

> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 12:17 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > > 3 STS-3: ??? How would you signal this? Not supported?
> > 
> > What do you wish to signal here? Three groups of STS-3 each?
> > What does it mean? The STS-3 is a bundle, and you wish to signal
> > a bundle of bundles?
> > 
> > If that is so, and unless I am missing something, I think you'd have
> > to signal them separately.
> > 
> > BTW, I wasn't immediately able to see how this would be signaled
> > even using the codepoints proposed in
> > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > 
> 
> I don't understand how that is a bundle. STS-3 as defined in 
> the T1.105
> is the entire signal. So then if you can signal multiple STS-1s, my
> question was why is this not supported for STS-3 or other STS-X.
> 
> Right, draft-lin assumes that when you need to set up multiple
> connections, these are done separately. Adding the capability for
> multiple connection set-ups as part of the signaling mechanism is not
> really necessary. Remember that the signaling mechanism is not the GUI
> to the customer. The GUI that the customer sees can provide that
> feature. The interface from GUI to the signaling can be a 
> batch function
> that sets up the multiple connections. This simplifies the signaling
> protocol, allows "bundling" of different connection types 
> set-up at once
> (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> STS-48c at
> once) via a batch process, and does not complicate the protocol from
> having to handle this issue.
> 
> Some of the points mentioned by Ewart in the OIF discussion was: when
> multiple connections are handled at once, what are the characteristics
> of these connections? Do they all terminate at the same location? Are
> they all co-routed or separately routed? How many labels do 
> you return?
> If one label is returned, what happens when one connection 
> failed? What
> if the multiple connections have different destinations? etc.
> 
> 
> > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > arbitrary)
> > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > >
> > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > 
> > Again, as things stand today, you'd have to signal this separately.
> > 
> > First, is there a requirement to signal these this way? Assuming
> > there is, is there a proposal that allows for that?
> > 
> 
> I wasn't sure whether there is requirement or not. I was 
> extending your
> example with what was offered currently. My view was that it 
> seems that
> some capabilities are available to certain signal types and 
> not to other
> signal types. We probably need to extend or clarify the text, 
> or adopt a
> different position in terms of what should and should not be 
> provided by
> the signaling protocol, and leave "added features" to 
> separate functions
> (the batch process I mentioned above).
> 
> 
> > I cannot see how 
> draft-lin-ccamp-ipo-common-label-request-01.txt would
> > do it either, since the RNC has been absorbed into the signal type
> > in that case, and not all cases are enumerated.
> > 
> 
> See above for comment.
> 
> > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > >
> > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > 
> > Same as the two above.
> > 
> 
> See above (sorry, too many "aboves") ;-)
> 
> Zhi
> 

Delivery-date: Wed, 21 Mar 2001 09:12:52 -0800
Date: Wed, 21 Mar 2001 11:09:17 -0600
From: sambasiva mantha <[email-masked]>
Organization: Alcatel
To: Vishal Sharma <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Vishal,

As  you pointed at the end of the email, if a speciality funcitionality is not
required for "bundling" group type, then why there is a need for
distinguishing the group as such. In case of a SONET DCS the bundling has a
quite a unique function (see GR-2996). Once a group of STS-1s which must be
contigous, are defined as part of a bundle, the DCS does not allow the
operator to separate these STS-1s out in the sense they have to come in on one
input port (OC-n say) and all the STS-1s in the bundle have to cross connected
to the same outgoing output port (OC-m).

Sambu

Vishal Sharma wrote:

> Manoj,
>
> Some clarifications follow...
>
> -Vishal
>
> > -----Original Message-----
> > From: manoj juneja [mailto:[email-masked]]
> > Sent: Monday, March 19, 2001 3:35 PM
> > To: [email-masked]
> > Subject: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Hi All,
> >         The GMPLS draft
> > "draft-ietf-mpls-generalized-signalling-02.txt"
> > defines different values for RGT (Requested Grouping Type) viz.
> > Virtual Concatenation, Contiguous standard concatenation, Contiguous
> > arbitrary concatenation, Bundle.
> > How does the implementation of a control plane differ if it receives
> > different RGT values ?
>
> The implementation of the control plane should not differ based on
> different RGT values, the implementation of the data plane is what
> differs in all of these cases, because each RGT value controls how
> the data bearing channels are  treated by the end nodes and the
> intermediate nodes.
>
> For example, for virtual concatenation, the intermediate nodes treat
> the virtually
> concatenated channels as they would treat independent channels. The
> end points, however, treat these channels as "bonded" together, and must
> have hardware and software support to "glue" the data arriving on these
> channels together appropriately. (For instance, the hardware must
> support compensation for the differential delay that the component
> channels of the virtually concatenated stream may suffer.)
>
> > Another field RNC (Reuested Number of
> > Components) defines the number of such components requested.
> > My understanding is that if RNC is 2 and signal type is STM-1. Then it
> > means that 2 STM-1 signals are requested and these are concatenated
> > according to the RGT specified.
>
> Your understanding is correct.
>
> > Does this mean, the number of labels
> > requested depend on the RNC field ?  This means that is RNC is "X",
> > then "X" number of labels are to be returned in Label Mapping message
> > and the labels returned should be in accrodance with the requested
> > signal type.
>
> Not quite. The number of labels will be determined by a combination of
> the RNC and RGT.
>
> To understand this, let's consider the setting up of an STS-3 SONET
> channel (which is transparent
> only at the path level, so that line and section overheads are not to be
> preserved across SONET equipment), and see what happens in the various
> cases.
> In every case, the signal type = STS-1, and the RNC = 3.
>
> If RGT = contiguous standard or contiguous arbitrary concatenation, then
> only a _single_ label is returned (that one that denotes the time slot at
> which the first of the concatenated channels begins).
>
> If, however, RGT = virtual concatenation or bundle, then 3 labels (or
> # of labels = RNC in the general case) will
> need to be returned in the label mapping message (namely, the times slots
> that denote where _each_ of the component STS-1s of the STS-3 signal is to
> be placed, since in these cases the component STS-1s need not occur in
> contiguous time slots).
>
> > Please clarify these doubts.
>
> Hope the above helps.
>
> > Can somebody please brief me on grouping type Bundle ?
>
> "Bundle" is nothing but an optimized way of simultaneously
> setting up multiple, independent
> SONET channels across a SONET network. Thus, in my example above, if
> RGT=bundle, what would really be setup in the SONET network would be
> three channels of STS-1 granularity, where each would be totally
> independent of the others, both at the intermediate nodes and at
> the end nodes.
>
> If, however, RGT=virtual concatenation, then what would really be
> setup in the SONET network would again be 3 channels of STS-1
> granularity, which to the intermediate nodes would be no different
> from the case above. To the end nodes, however, it would mean that
> they need to have the capability to handle virtually concatenated
> SONET channels (which means they need to be capable of appropriately
> dividing traffic across them [at the input], and "glueing" them back
> together [at the output]).
>
> > Is there any additional capability required in the network for
> > supporting different types of grouping types (RGTs) ?
>
> Not sure what you mean by "additional" capability? In "addition"
> to what?
>
> For contiguous standard concatenation, the network nodes need to
> be able to support standard SDH/SONET concatenation.
> For continuous arbitrary concatenation, the network nodes involved
> in the establishment of such a channel, need to be able to support
> arbitrary concatenation.
> For virtual concatenation, the intermediate nodes through which
> the channle passes need no additional functionality, but the
> end nodes must be able to support the processing of virtually
> concatenated channels.
> For bundling, absolutely no special functionality is required
> in either the intermediate nodes or the end nodes.
>
>
> >

Envelope-to: [email-masked]
Delivery-date: Wed, 21 Mar 2001 06:11:53 -0800
Date: Wed, 21 Mar 2001 06:04:06 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: New agenda for today (Wed March 21)

CCAMP Agenda

Wednesday, Morning Session
--------------------------

More agenda bashing					(5 min)

Signaling for Generalized MPLS, Lou Berger		(10 min)
	draft-generalized-sig...

Enhanced GMPLS Signaling, Papadimitriou Dimitri 	(10 min)
	draft-papadimitriou-enhanced-lsps-02.txt
	draft-fontana-gmpls-control-g709-00.txt

Lightpath Route Extensions, Murali Krishnaswamy		(5 min)
	draft-krishnaswamy-optical-rsvp-extn-00.txt

Enhanced GMPLS Signaling, Yangguang Xu, Zhi-Wei Lin	(15 min)
	draft-xu-ccamp-gmpls-sig-reorg-00.txt
	draft-lin-ccamp-ipo-common-label-request-00.txt

Restoration, Papadimitriou Dimitri 			(15 min)
	draft-pbh-packet-optical-escalation-00.txt
	draft-many-optical-restoration-00.txt
	draft-many-inference-srlg-00.txt

Signaling for Fast Restoration, Bala Rajagopalan 	(10 min)
	draft-bala-restoration-signaling-00.txt

Generalized MPLS Recovery Mechanisms, Jonathan Lang	(15 min)
	draft-lang-ccamp-recovery-00.txt

LMP, Jonathan Lang					(10 min)
	draft-ietf-mpls-lmp-02.txt

WDM LMP, Andre Fredette 				(15 min)
	draft-fredette-lmp-wdm-01.txt

NTIP, Osama Aboul-Magd					(15 min)
	draft-sahay-ccamp-ntip-00.txt

LMP MIB, Martin Dubuc					(10 min)
	draft-dubuc-mpls-lmp-mib-01.txt

Arm-wrestling						(10 min)

Kireeti.

Delivery-date: Tue, 20 Mar 2001 23:47:53 -0800
From: Vishal Sharma <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 23:40:57 -0800

Zhi,

If you were merely extending my example, then the problem will be solved
by adding a new signal type for STS-3 (if, as you say below, T1.105 defines
an STS-3 as an entire signal).

By looking at your questions, I got the impression that you knew that
the functionality required by your examples was needed, and further
that you meant that your current proposal covers it.
Since neither draft currently covers it, if we determine that multiple
bundles can be setup as a "batch" process at the application level, but
will be handled via separate signaling requests at the protocol level
then we are in agreement.

For some other comments, pl. see below.

-Vishal
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 12:17 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > > 3 STS-3: ??? How would you signal this? Not supported?
> > 
> > What do you wish to signal here? Three groups of STS-3 each?
> > What does it mean? The STS-3 is a bundle, and you wish to signal
> > a bundle of bundles?
> > 
> > If that is so, and unless I am missing something, I think you'd have
> > to signal them separately.
> > 
> > BTW, I wasn't immediately able to see how this would be signaled
> > even using the codepoints proposed in
> > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > 
> 
> I don't understand how that is a bundle. STS-3 as defined in 
> the T1.105
> is the entire signal. So then if you can signal multiple STS-1s, my
> question was why is this not supported for STS-3 or other STS-X.
> 
> Right, draft-lin assumes that when you need to set up multiple
> connections, these are done separately. Adding the capability for
> multiple connection set-ups as part of the signaling mechanism is not
> really necessary. Remember that the signaling mechanism is not the GUI
> to the customer. The GUI that the customer sees can provide that
> feature. The interface from GUI to the signaling can be a 
> batch function
> that sets up the multiple connections. This simplifies the signaling
> protocol, allows "bundling" of different connection types 
> set-up at once
> (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> STS-48c at
> once) via a batch process, and does not complicate the protocol from
> having to handle this issue.
> 
> Some of the points mentioned by Ewart in the OIF discussion was: when
> multiple connections are handled at once, what are the characteristics
> of these connections? Do they all terminate at the same location? Are
> they all co-routed or separately routed? How many labels do 
> you return?
> If one label is returned, what happens when one connection 
> failed? What
> if the multiple connections have different destinations? etc.

I would assume that an assumption in either virtually concatenated or
bundled connections clearly is that the start and terminate at the
same end nodes! 
Whether they are all co-routed or separately routed
may be determined by end node that requests their setup. 

If you
use virtual concatenation you could presumably return multiple
labels, one each of each of the channels comprising the virtually
concatenated signal.

I am not sure that in the bundle case or the virtually concatenated case
one would return only one label. Maybe one may get by with returning
just one, if by some chance the concatenated or bundled channels just
happen to be contiguous.

Not sure by what you mean by "what happens when one connection fails"? What
happens to what? and with respect to what?
Even if a connection fails, the head end will still know which slot numbers
contain healthy channels that are components of a virtually concatenated
channel or bundled channels.

> > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > arbitrary)
> > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > >
> > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > 
> > Again, as things stand today, you'd have to signal this separately.
> > 
> > First, is there a requirement to signal these this way? Assuming
> > there is, is there a proposal that allows for that?
> > 
> 
> I wasn't sure whether there is requirement or not. I was 
> extending your
> example with what was offered currently. My view was that it 
> seems that
> some capabilities are available to certain signal types and 
> not to other
> signal types. We probably need to extend or clarify the text, 
> or adopt a
> different position in terms of what should and should not be 
> provided by
> the signaling protocol, and leave "added features" to 
> separate functions
> (the batch process I mentioned above).
> 
> 
> > I cannot see how 
> draft-lin-ccamp-ipo-common-label-request-01.txt would
> > do it either, since the RNC has been absorbed into the signal type
> > in that case, and not all cases are enumerated.
> > 
> 
> See above for comment.
> 
> > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > >
> > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > 
> > Same as the two above.
> > 
> 
> See above (sorry, too many "aboves") ;-)
> 
> Zhi
> 

Delivery-date: Tue, 20 Mar 2001 23:47:50 -0800
From: Vishal Sharma <[email-masked]>
To: 'Hai Vodinh' <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>
Cc: [email-masked], "Greg Bernstein (E-mail)" <[email-masked]>
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 23:45:28 -0800

Hi Hai,

Greg has already provided an answer. I just wanted to add that in
my initial explanation to Manoj, I did point out what the difference
was between virtual concat. and bundling. For the intermediate
nodes, there is no difference, the differene only comes in for
the end points, which in the virtual concat. case have to know
which channels are virtually concatenated, and compensate for 
differential delay across these channels.

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 5:14 PM
> To: 'Zhi-Wei Lin'; Vishal Sharma
> Cc: [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> I tend to agree with Zhi-Wei that when you need to set up multiple
> connections these should be done separately (except perhaps 
> in the virtual
> concatenated case) to keep the signaling protocol simple.
> 
> I'm following the discussion and still don't have a clear 
> idea why both
> virtual concatenation and bundling RGT are needed.  What is 
> the difference
> between the two types?
> 
> Here is another question: let's say I have a STS-1-4v SPE 
> already set up,
> now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how 
> do I signal to
> the network that the additional 2 STS-1s need to be co-routed 
> with the other

I am not sure that there is any easy way to day to perform such 
signaling.

> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 12:17 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > > 3 STS-3: ??? How would you signal this? Not supported?
> > 
> > What do you wish to signal here? Three groups of STS-3 each?
> > What does it mean? The STS-3 is a bundle, and you wish to signal
> > a bundle of bundles?
> > 
> > If that is so, and unless I am missing something, I think you'd have
> > to signal them separately.
> > 
> > BTW, I wasn't immediately able to see how this would be signaled
> > even using the codepoints proposed in
> > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > 
> 
> I don't understand how that is a bundle. STS-3 as defined in 
> the T1.105
> is the entire signal. So then if you can signal multiple STS-1s, my
> question was why is this not supported for STS-3 or other STS-X.
> 
> Right, draft-lin assumes that when you need to set up multiple
> connections, these are done separately. Adding the capability for
> multiple connection set-ups as part of the signaling mechanism is not
> really necessary. Remember that the signaling mechanism is not the GUI
> to the customer. The GUI that the customer sees can provide that
> feature. The interface from GUI to the signaling can be a 
> batch function
> that sets up the multiple connections. This simplifies the signaling
> protocol, allows "bundling" of different connection types 
> set-up at once
> (e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 
> STS-48c at
> once) via a batch process, and does not complicate the protocol from
> having to handle this issue.
> 
> Some of the points mentioned by Ewart in the OIF discussion was: when
> multiple connections are handled at once, what are the characteristics
> of these connections? Do they all terminate at the same location? Are
> they all co-routed or separately routed? How many labels do 
> you return?
> If one label is returned, what happens when one connection 
> failed? What
> if the multiple connections have different destinations? etc.
> 
> 
> > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > arbitrary)
> > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > >
> > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > 
> > Again, as things stand today, you'd have to signal this separately.
> > 
> > First, is there a requirement to signal these this way? Assuming
> > there is, is there a proposal that allows for that?
> > 
> 
> I wasn't sure whether there is requirement or not. I was 
> extending your
> example with what was offered currently. My view was that it 
> seems that
> some capabilities are available to certain signal types and 
> not to other
> signal types. We probably need to extend or clarify the text, 
> or adopt a
> different position in terms of what should and should not be 
> provided by
> the signaling protocol, and leave "added features" to 
> separate functions
> (the batch process I mentioned above).
> 
> 
> > I cannot see how 
> draft-lin-ccamp-ipo-common-label-request-01.txt would
> > do it either, since the RNC has been absorbed into the signal type
> > in that case, and not all cases are enumerated.
> > 
> 
> See above for comment.
> 
> > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > >
> > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > 
> > Same as the two above.
> > 
> 
> See above (sorry, too many "aboves") ;-)
> 
> Zhi
> 

Delivery-date: Tue, 20 Mar 2001 21:40:32 -0800
Date: Wed, 21 Mar 2001 14:43:10 +0900
To: [email-masked]
From: Atsushi Iwata <[email-masked]>
Subject: Multi-area TE requirements and crankback routing

Hi, Rob, Kireeti, and CCAMP folks,

Thank you for having a nice discussion in the CCAMP WG today.
I made a presentation of the crankback routing extension for MPLS signaling 
in the CCAMP WG (draft-iwata-mpls-crankback-00.txt). 

I got a question from Rob. He mentioned that crankback routing would not be 
needed in a flat network but might be needed in a hierarchical network 
(i.e. in multi-area TE scenario). He also suggested me that we need a 
requirement draft of multi-area TE from TE WG before making our draft a WG draft.

Actually, I forgot to tell you one thing. A following draft discussing 
multi-area TE requirements will be presented by Jerry Ash in TE-WG on this 
Thursday.

G. Ash et al., "Requirements for Multi-Area TE", 
draft-ash-ccamp-multi-area-te-reqmts-00.txt, Feb.2001

This requirement draft categorizes several multi-area TE methods, all of 
which use crankback routing procedures for improving the LSP blocking 
probability. The improving the LSP blocking probability is an important 
factor in terms of network performance for the carrier perspective.

I think that we already have a good requirement draft in TE WG. Please 
attend the TE WG meeting on this Thursday, and discuss the crankback 
routing requirements as well.

Thank you.

----------------------------------------------------------------
Atsushi Iwata
Assistant Manager
Network Architecture TG,
Computer & Communication Media Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     [email-masked]
NEC-internal E-mail: [email-masked]

Delivery-date: Tue, 20 Mar 2001 20:35:27 -0800
From: "Bernstein, Greg" <[email-masked]>
To: "'Hai Vodinh'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 20:33:41 -0800

Hi Hai, the non-concatenated grouping in the RGT was not meant to be a
general bundling mechanism (such a mechanism was discussed and rejected in
San Diego), but rather since we already were dealing with multiple
concatenation types (standard, arbitrary, virtual) and an RNC field, the
folks that have SONET/SDH customers that deal in private lines such as DS3s,
T1s and E1s tend to set these up in batches and hence this is the prime use
of this grouping.
Hope this clarifies.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Hai Vodinh [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 7:14 PM
To: 'Zhi-Wei Lin'; Vishal Sharma
Cc: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC

I tend to agree with Zhi-Wei that when you need to set up multiple
connections these should be done separately (except perhaps in the virtual
concatenated case) to keep the signaling protocol simple.

I'm following the discussion and still don't have a clear idea why both
virtual concatenation and bundling RGT are needed.  What is the difference
between the two types?

Here is another question: let's say I have a STS-1-4v SPE already set up,
now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how do I signal to
the network that the additional 2 STS-1s need to be co-routed with the other
4 STS-1s?

Thanks,
Hai

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 12:17 PM
To: Vishal Sharma
Cc: 'manoj juneja'; [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Hi Vishal,

> > 3 STS-3: ??? How would you signal this? Not supported?
> 
> What do you wish to signal here? Three groups of STS-3 each?
> What does it mean? The STS-3 is a bundle, and you wish to signal
> a bundle of bundles?
> 
> If that is so, and unless I am missing something, I think you'd have
> to signal them separately.
> 
> BTW, I wasn't immediately able to see how this would be signaled
> even using the codepoints proposed in
> draft-lin-ccamp-ipo-common-label-request-01.txt.
> 

I don't understand how that is a bundle. STS-3 as defined in the T1.105
is the entire signal. So then if you can signal multiple STS-1s, my
question was why is this not supported for STS-3 or other STS-X.

Right, draft-lin assumes that when you need to set up multiple
connections, these are done separately. Adding the capability for
multiple connection set-ups as part of the signaling mechanism is not
really necessary. Remember that the signaling mechanism is not the GUI
to the customer. The GUI that the customer sees can provide that
feature. The interface from GUI to the signaling can be a batch function
that sets up the multiple connections. This simplifies the signaling
protocol, allows "bundling" of different connection types set-up at once
(e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 STS-48c at
once) via a batch process, and does not complicate the protocol from
having to handle this issue.

Some of the points mentioned by Ewart in the OIF discussion was: when
multiple connections are handled at once, what are the characteristics
of these connections? Do they all terminate at the same location? Are
they all co-routed or separately routed? How many labels do you return?
If one label is returned, what happens when one connection failed? What
if the multiple connections have different destinations? etc.

> > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > arbitrary)
> > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> >
> > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> 
> Again, as things stand today, you'd have to signal this separately.
> 
> First, is there a requirement to signal these this way? Assuming
> there is, is there a proposal that allows for that?
> 

I wasn't sure whether there is requirement or not. I was extending your
example with what was offered currently. My view was that it seems that
some capabilities are available to certain signal types and not to other
signal types. We probably need to extend or clarify the text, or adopt a
different position in terms of what should and should not be provided by
the signaling protocol, and leave "added features" to separate functions
(the batch process I mentioned above).

> I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
> do it either, since the RNC has been absorbed into the signal type
> in that case, and not all cases are enumerated.
> 

See above for comment.

> > 1 STS-7v: RNC=7, RGT=1 (virtual)
> >
> > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> 
> Same as the two above.
> 

See above (sorry, too many "aboves") ;-)

Zhi

Delivery-date: Tue, 20 Mar 2001 17:21:05 -0800
From: Hai Vodinh <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 17:13:49 -0800

I tend to agree with Zhi-Wei that when you need to set up multiple
connections these should be done separately (except perhaps in the virtual
concatenated case) to keep the signaling protocol simple.

I'm following the discussion and still don't have a clear idea why both
virtual concatenation and bundling RGT are needed.  What is the difference
between the two types?

Here is another question: let's say I have a STS-1-4v SPE already set up,
now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how do I signal to
the network that the additional 2 STS-1s need to be co-routed with the other
4 STS-1s?

Thanks,
Hai

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 12:17 PM
To: Vishal Sharma
Cc: 'manoj juneja'; [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Hi Vishal,

> > 3 STS-3: ??? How would you signal this? Not supported?
> 
> What do you wish to signal here? Three groups of STS-3 each?
> What does it mean? The STS-3 is a bundle, and you wish to signal
> a bundle of bundles?
> 
> If that is so, and unless I am missing something, I think you'd have
> to signal them separately.
> 
> BTW, I wasn't immediately able to see how this would be signaled
> even using the codepoints proposed in
> draft-lin-ccamp-ipo-common-label-request-01.txt.
> 

I don't understand how that is a bundle. STS-3 as defined in the T1.105
is the entire signal. So then if you can signal multiple STS-1s, my
question was why is this not supported for STS-3 or other STS-X.

Right, draft-lin assumes that when you need to set up multiple
connections, these are done separately. Adding the capability for
multiple connection set-ups as part of the signaling mechanism is not
really necessary. Remember that the signaling mechanism is not the GUI
to the customer. The GUI that the customer sees can provide that
feature. The interface from GUI to the signaling can be a batch function
that sets up the multiple connections. This simplifies the signaling
protocol, allows "bundling" of different connection types set-up at once
(e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 STS-48c at
once) via a batch process, and does not complicate the protocol from
having to handle this issue.

Some of the points mentioned by Ewart in the OIF discussion was: when
multiple connections are handled at once, what are the characteristics
of these connections? Do they all terminate at the same location? Are
they all co-routed or separately routed? How many labels do you return?
If one label is returned, what happens when one connection failed? What
if the multiple connections have different destinations? etc.

> > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > arbitrary)
> > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> >
> > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> 
> Again, as things stand today, you'd have to signal this separately.
> 
> First, is there a requirement to signal these this way? Assuming
> there is, is there a proposal that allows for that?
> 

I wasn't sure whether there is requirement or not. I was extending your
example with what was offered currently. My view was that it seems that
some capabilities are available to certain signal types and not to other
signal types. We probably need to extend or clarify the text, or adopt a
different position in terms of what should and should not be provided by
the signaling protocol, and leave "added features" to separate functions
(the batch process I mentioned above).

> I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
> do it either, since the RNC has been absorbed into the signal type
> in that case, and not all cases are enumerated.
> 

See above for comment.

> > 1 STS-7v: RNC=7, RGT=1 (virtual)
> >
> > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> 
> Same as the two above.
> 

See above (sorry, too many "aboves") ;-)

Zhi

Delivery-date: Tue, 20 Mar 2001 15:43:59 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Please Clarify on O-UNI Status
Date: Tue, 20 Mar 2001 16:43:13 -0700

Hi All,

   Please clarify on the following issue :

  Will IETF's MPLS WG going to adopt OIF UNI 1.0 specification
instead of its draft-ietf-mpls-ldp-optical-uni-00.txt?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 20 Mar 2001 15:32:33 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Date: Tue, 20 Mar 2001 16:31:40 -0700

Hi All,
        Please clarify on the following issue :

  Will IETF's MPLS WG going to adopt OIF UNI 1.0 specification instead of 
its draft-ietf-mpls-ldp-optical-uni-00.txt?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 20 Mar 2001 15:07:10 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Please Clarify on O-UNI Issues....
Date: Tue, 20 Mar 2001 16:05:42 -0700

Hi All,
         I was going through the draft 
"draft-ietf-mpls-ldp-optical-uni-00.txt", but I could not find the complete 
picture related to neighbor discovery, Address Resolution issues. Can 
someone please give a pointer to some other draft which is pre-requisite for 
this one (O-UNI draft). Is there more work going on O-UNI draft ?
I could not find even a single draft which talks from architectural 
viewpoint. There is one architecture document (gmpls-arch-00.txt), this 
document also lacks lot of information.

Please help.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 20 Mar 2001 12:19:53 -0800
Date: Tue, 20 Mar 2001 15:16:39 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Vishal Sharma <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Hi Vishal,

> > 3 STS-3: ??? How would you signal this? Not supported?
> 
> What do you wish to signal here? Three groups of STS-3 each?
> What does it mean? The STS-3 is a bundle, and you wish to signal
> a bundle of bundles?
> 
> If that is so, and unless I am missing something, I think you'd have
> to signal them separately.
> 
> BTW, I wasn't immediately able to see how this would be signaled
> even using the codepoints proposed in
> draft-lin-ccamp-ipo-common-label-request-01.txt.
> 

I don't understand how that is a bundle. STS-3 as defined in the T1.105
is the entire signal. So then if you can signal multiple STS-1s, my
question was why is this not supported for STS-3 or other STS-X.

Right, draft-lin assumes that when you need to set up multiple
connections, these are done separately. Adding the capability for
multiple connection set-ups as part of the signaling mechanism is not
really necessary. Remember that the signaling mechanism is not the GUI
to the customer. The GUI that the customer sees can provide that
feature. The interface from GUI to the signaling can be a batch function
that sets up the multiple connections. This simplifies the signaling
protocol, allows "bundling" of different connection types set-up at once
(e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 STS-48c at
once) via a batch process, and does not complicate the protocol from
having to handle this issue.

Some of the points mentioned by Ewart in the OIF discussion was: when
multiple connections are handled at once, what are the characteristics
of these connections? Do they all terminate at the same location? Are
they all co-routed or separately routed? How many labels do you return?
If one label is returned, what happens when one connection failed? What
if the multiple connections have different destinations? etc.

> > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > arbitrary)
> > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> >
> > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> 
> Again, as things stand today, you'd have to signal this separately.
> 
> First, is there a requirement to signal these this way? Assuming
> there is, is there a proposal that allows for that?
> 

I wasn't sure whether there is requirement or not. I was extending your
example with what was offered currently. My view was that it seems that
some capabilities are available to certain signal types and not to other
signal types. We probably need to extend or clarify the text, or adopt a
different position in terms of what should and should not be provided by
the signaling protocol, and leave "added features" to separate functions
(the batch process I mentioned above).

> I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
> do it either, since the RNC has been absorbed into the signal type
> in that case, and not all cases are enumerated.
> 

See above for comment.

> > 1 STS-7v: RNC=7, RGT=1 (virtual)
> >
> > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> 
> Same as the two above.
> 

See above (sorry, too many "aboves") ;-)

Zhi

Delivery-date: Tue, 20 Mar 2001 07:36:59 -0800
From: Heiles Juergen <[email-masked]>
To: "'Maarten Vissers'" <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SDH/SONET concatenation signal types
Date: Tue, 20 Mar 2001 16:34:43 +0100

Maarten,

I agree with you to restrict the signal types for virtual concatenation. In order to determine the requried signal types and otehr information lets have a look on the applicaitons and required features:

Virtual concatenation requires only support at the end nodes (trail termination). Intermediate nodes process only the individual signals (VCs). For the routing of the individual signals that form the virtual concatenated signal several options exist:
- don't care: the signals can have common or diverse routes
- common route: minimize differential delay
- diverse routes for all signals or group of signals: LCAS

If I assume that common routing is achieved by the bundling feature independent of virtual concatenation we don't need a special virtual concatenation signal lable for routing. Diverse routing is another feature that is/should be independent of virtual concatenation and a story of its own.
Only if bundling doesn't mean common routing and we don't need common routing for any other application we need a special VC-n-X signal type which just means X VC-n with common routing.

We still have the need to signal the virtual concatenation information between the trail terminating nodes in order to check if end poitns with matching capabilites are connected or are configured accordingly. What information is needed?
- A indication that it is a virtual concatenated signal
- The number of concatenated signals or LCAS

We have already the G-PID type which is also only used at the end points in order to check the client mapping. Putting the information into the G-PID is a possibility, may be not the best. Any ideas?

Regards

Juergen

> -----Original Message-----
> From:	Maarten Vissers [SMTP:[email-masked]]
> Sent:	Thursday, March 15, 2001 4:13 PM
> To:	Heiles Juergen
> Cc:	[email-masked]'
> Subject:	Re: SDH/SONET concatenation signal types
> 
> Juergen,
> 
> You hit an area which needs more work... 
> 
> VC-n-Xv up to now is associated with co-routing of all X VC-n signals
> inthe virtual concatenated group. The introduction of LCAS feature,
> requires that the X VC-n signals within a VC-n-Xv signal are NOT
> co-routed; the group should be at a minimum split over two diverse
> routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
> identifications are not adequatly representing the two (or more)
> subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
> VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
> VC-n-X1 and a VC-n-X2 connection are to be set-up.
> 
> As such, we could restrict the set of Types to VC-n-X and at the
> endpoints associate one or more VC-n-X's to the VC-n-Xv or VC-n-Xv LCAS.
> 
> trail						trail
> endpoint					endpoint
> VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv
> 
> 	       /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
> VC-n-Xv LCAS <=				    	   => VC-n-Xv LCAS
> 	       \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/
> 
> In either case, the LSPs are "VC-n-X" types. 
> At the end points of the trail (where you connect the Trail Termination
> Point, via matrix connections in the Fabric, to the Link end points) the
> additional mapping knowledge is needed.
> 
> Being at this point in thinking, I have to ask the question if we should
> differentiate between the type of "signal" being transported and the
> type of "transport entity" the "signal" is transported over. 
> 
> E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
> link connections" and a second "group of X2 VC-n link connections", and
> a "VC-n-Xv signal" is transported over a "group of X VC-n link
> connections".
> And in the simple case, a "VC-n signal" is transported over a "VC-n link
> connection".
> 
> 
> Regards,
> 
> Maarten
> 
> 
> 
> Heiles Juergen wrote:
> > 
> > I have a question on the different SDH/SONET concatenation signal types proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv LCAS, VC-n-X). Defining different signal types makes only sense if a different behaviour is assumed. What is the difference between these types? Is my interpretation correct?> 
> > 
> > VC-n-Xv: fixed virtual concatenation; co-routed
> > VC-n-Xv LCAS: flexible virtual concatenation; different routes
> > VC-n-X: no concatenation; co-routed
> > 
> > For the later as it could be also used for all other signal types would it be better to introduce some kind of grouping for signal types that have to be co-routed?
> > For all the 3 types how would you indication the timeslot, position of the individual VCs as the may/will not use contiguous slots. If different routes are used they even go accross via different interfaces and NEs and you cannot include  them in a single label request.
> > 
> > Regards
> > 
> > Juergen << File: Card for Maarten Vissers >> 

Delivery-date: Tue, 20 Mar 2001 03:03:05 -0800
From: Vishal Sharma <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Three GMPLS related IDs: draft-lin-ccamp-ipo-common-label-req uest-00.txt
Date: Tue, 20 Mar 2001 03:00:39 -0800

Folks,

This is the last in the sequel.

-Vishal

Now on to the comments:

i) First, a nit. The draft should be named "Common Label Request
and Label Specification ...," since that is precisely the order in which
it discusses things.

ii) Also, (unless the plan was to make the wild goose chase of the
implementer
interesting!) at various points "Signaling Type" needs to be
replaced with "Signal Type." The two don't mean the same thing. :-)

iii) Section 2, Abstract. The statement describing the very first change
needs to be expanded on somewhere in the rest of the text!
It is not just a new _set_ of Signal Type structures, it is a completely
new organization of what is there in GMPLS-SIG or in GMPLS-SIGEN, and
that needs to be made very clear to the reader. The text should say
that RGT, RNT, etc. have been all absorbed into the signal type.
(Of course, it is an entirely different matter to say "why" that makes
sense,
but we'll come to that shortly.)

iv) The final "signal type" discussed in Section 3.2.3 again breaks
things into a signal type and a concatenation type. So it seems such a
break-up is needed. What would be use then of eliminating RNC in 
GMPLS-SIG?
If there is a valid technical reason for doing things this way, it should
be clearly, succintly, and unambiguously articulated. I am afraid,
in this trilogy of drafts that does not seem to have been done adequately.

v) My major problem with this and its companion draft is that it proposes
changes (some of which could even be good ones), BUT it does not provide
a detailed enough justification for all of its changes. Nor does it provide
the reader with any insight about why the encoding proposed in this draft
is a good one, a better one, an easier one, or a sensible one.

(Note: I am not implying that the remaining GMPLS drafts do a good job
of this. I am here merely pointing to the _need_ to do so, in all drafts;
in particular, in drafts that propose changing things (pl. see, for example,
draft-mack-crane-gmpls-signaling-enhancements-00.txt and 
draft-bernstein-gmpls-optical-00.txt, which at least make an attempt to do
so). This is 
especially useful to enable the community to appreciate the _technical
merits_ of each proposal and is very^2 helpful to pick the right
ones.)

A lot of the community may not instantly know all of the technicalities of
SONET/SDH or optical technologies,
so it is all the more important to make a crystal clear _technical case_,
that
anyone can appreciate.

vi) So why does it make sense to combine RGT and RNT and transparency,
and signal type all into "signal type"?
Why is that more helpful/better/cleaner than a form of encoding that treats
these 
as separate entities?

-- If we resort to one big coding space for signal types, it would be
difficult
to add more as more signal types come in, since all combinations of those
signal types with RGT and RNC will have to be added. 

-- Further, what if an RNC or RGT option changes tomorrow? Now, we'd have 
to expand all existing signal types! If things were broken up, only the RGT 
or RNT codepoints would change.

vii) The encoding of signal types in Section 3.2.4 allows for two
ways to specify an STS-1, using value 5,  X=0 or value 7, X=1. 
Was this intended?

viii) Section 3.2.4, in the values for virtual concatenation (10-15), why
does
the draft stop at STS-3c-Xv? What about STS-12c-Xv, or higher?

ix)Similarly, in the values for co-routed groups (23-27), why stop at
STS-3c-X? What about STS-12c-X or higher?

x) Page 8, para 3, the number of vendor specific codepoints is 12
it seems, not 13.

xi) Section 4.2, the document spends many paragraphs trying to make
a case apparently for why HOVC and LOVC labels are independent, and 
should have dedicated channel IDs. However, I cannot see how this
follows from any of the preceding explanations. After a lot
of words, the reader is suddenly confronted with the blanket
statement " Therefore, HOVC.... labels. Each one will have a 
dedicated channel ID."

xii) Again, in Section 4.2, the notation for the sub-STM-0/STM-1 
signals is never introduced, even briefly. It is just thrown at
the reader. Where does that come from? What is the background?
The reader has no clue...

xiii) In the same section, para 6, the last sentence says "At any
moment, the complete aggregation bandwidth's multiplex structure
must be defined to prevent alarms to be raised." Uh?! Say what?

xiv) Section 4.2.3, please ... at least give an explanation of the
notation used in the title, in plain English, somewhere. (Not everyone
is an SDH/SONET expert, for crying out loud!)

xv) Again, maybe I am missing something, but how does the current
encoding allow to encode a signal like
3 STS-3? or 7 STS-3c-Xv?
Or doesn't it?

xvi) Also, it would be useful for the document to give references
to all the G.707, G.708, etc. documents that it refers to throughout,
together with pointers to how they may be obtained.
(Let's make people's life a little bit easier, let's at least help them
read, understand, and look at our drafts critically, instead of having
them put the drafts aside in a huge pile, never to be read.)

Delivery-date: Tue, 20 Mar 2001 02:40:54 -0800
From: Vishal Sharma <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, Vishal Sharma <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>
Cc: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 02:37:09 -0800

> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 2:33 AM
> To: 'Vishal Sharma'; 'Zhi-Wei Lin'
> Cc: 'manoj juneja'; [email-masked]
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> the problem is the mix of bundle and concatenation 
> information in the RTG. This allows you to request a bundle 
> of non-concatenated signals (e.g. STS-3, VC-4, VC-3) but not 
> a bundle of concatenated signals (e.g. STS-3c, VC-4-4c, 
> VC-4-16v). This is strange as a VC-4 and a VC-4-4c are not 
> different from a network point of view, except for the 
> bandwidth and a VC-4 is the same as a STS-3c-SPE. If bundling 
> is introduced it should apply to all signal types.

Agreed. I just pointed out below that in the GMPLS signaling
functional specification, as it stands, it is not possible to
request bundles of bundles (BTW, that was one of the cases
Zhi had), or bundles of concatenated signals.

> The concatenation information should therefore be part of the 
> signal type as proposed in 
> draft-lin-ccamp-ipo-common-label-request-01.txt. Bundling is 
> needed it is indicated by an RNC>1. 

Where is the RNC in draft-lin...? What I don't understand about
the encoding in this draft is how it will allow for the case you
have above?

> The case of virtual 
> concatenation and what bundling means needs some further 
> discussion. See the emails on "SDH/SONET concatenation signal types".

On which mailing list. CCAMP? (I ask because I had some problems receiving
CCAMP emails recently, and have missed quite a few in the last couple days.)

-Vishal

> 
> Juergen
> 
> > -----Original Message-----
> > From:	Vishal Sharma [SMTP:[email-masked]]
> > Sent:	Tuesday, March 20, 2001 8:50 AM
> > To:	'Zhi-Wei Lin'; Vishal Sharma
> > Cc:	'manoj juneja'; [email-masked]
> > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > Zhi-Wei,
> > 
> > Good points all. 
> > Please see below...
> > 
> > -Vishal
> > 
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > Sent: Monday, March 19, 2001 10:34 PM
> > > To: Vishal Sharma
> > > Cc: 'manoj juneja'; [email-masked]
> > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > > 
> > > 
> > > Hi Vishal,
> > > 
> > > 
> > > 
> > > > To understand this, let's consider the setting up of an 
> STS-3 SONET
> > > > channel (which is transparent
> > > > only at the path level, so that line and section overheads 
> > > are not to be
> > > > preserved across SONET equipment), and see what happens in 
> > > the various
> > > > cases.
> > > > In every case, the signal type = STS-1, and the RNC = 3.
> > > > 
> > > 
> > > So, in your example, for:
> > > 
> > > 1 STS-3: RNC=3, RGT=0
> > > 3 STS-1: RNC=3, RGT=4 (bundle)
> > > 
> > > 3 STS-3: ??? How would you signal this? Not supported?
> > 
> > What do you wish to signal here? Three groups of STS-3 each?
> > What does it mean? The STS-3 is a bundle, and you wish to signal
> > a bundle of bundles?
> > 
> > If that is so, and unless I am missing something, I think you'd have
> > to signal them separately.
> > 
> > BTW, I wasn't immediately able to see how this would be signaled
> > even using the codepoints proposed in 
> > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > 
> > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous 
> > > arbitrary)
> > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > 
> > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > 
> > Again, as things stand today, you'd have to signal this separately.
> > 
> > First, is there a requirement to signal these this way? Assuming
> > there is, is there a proposal that allows for that?
> > 
> > I cannot see how 
> draft-lin-ccamp-ipo-common-label-request-01.txt would
> > do it either, since the RNC has been absorbed into the signal type
> > in that case, and not all cases are enumerated.
> > 
> > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > 
> > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > 
> > Same as the two above.
> > 
> > 
> > > If the identified signals are really not supported, then 
> it would seem
> > > that there is some inconsistency and maybe (?) not well 
> > > organized fields
> > > that arbitrarily supports certain combinations and not others...
> > 
> > I think what the draft does at present is that it supports some base
> > combinations, which will allow you to realize the setting 
> up of the channels
> > that you mention below (as I've suggested above).
> > 
> > I am not sure if there is a desire (service providers 
> please speak up!) to
> > set up the types of channels you suggest above, in _one 
> round_ of signaling.
> > 
> > (It could certainly be argued that they are valid choices to want to
> > signal.)
> > If there is a requirement from SPs, then the signal
> > types/RGT/RNC might need to be extended to cover these cases.
> > 
> > > Am I correct? Do we need to fix this to make it 
> consistent in terms of> 
> > > supporting "like" signal types?
> > 
> > See above.
> 

Delivery-date: Tue, 20 Mar 2001 02:35:36 -0800
From: Heiles Juergen <[email-masked]>
To: "'Vishal Sharma'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Tue, 20 Mar 2001 11:33:20 +0100

Vishal,

the problem is the mix of bundle and concatenation information in the RTG. This allows you to request a bundle of non-concatenated signals (e.g. STS-3, VC-4, VC-3) but not a bundle of concatenated signals (e.g. STS-3c, VC-4-4c, VC-4-16v). This is strange as a VC-4 and a VC-4-4c are not different from a network point of view, except for the bandwidth and a VC-4 is the same as a STS-3c-SPE. If bundling is introduced it should apply to all signal types.
The concatenation information should therefore be part of the signal type as proposed in draft-lin-ccamp-ipo-common-label-request-01.txt. Bundling is needed it is indicated by an RNC>1. The case of virtual concatenation and what bundling means needs some further discussion. See the emails on "SDH/SONET concatenation signal types".

Regards

Juergen

> -----Original Message-----
> From:	Vishal Sharma [SMTP:[email-masked]]
> Sent:	Tuesday, March 20, 2001 8:50 AM
> To:	'Zhi-Wei Lin'; Vishal Sharma
> Cc:	'manoj juneja'; [email-masked]
> Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> 
> Zhi-Wei,
> 
> Good points all. 
> Please see below...
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Monday, March 19, 2001 10:34 PM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; [email-masked]
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > 
> > 
> > Hi Vishal,
> > 
> > 
> > 
> > > To understand this, let's consider the setting up of an STS-3 SONET
> > > channel (which is transparent
> > > only at the path level, so that line and section overheads 
> > are not to be
> > > preserved across SONET equipment), and see what happens in 
> > the various
> > > cases.
> > > In every case, the signal type = STS-1, and the RNC = 3.
> > > 
> > 
> > So, in your example, for:
> > 
> > 1 STS-3: RNC=3, RGT=0
> > 3 STS-1: RNC=3, RGT=4 (bundle)
> > 
> > 3 STS-3: ??? How would you signal this? Not supported?
> 
> What do you wish to signal here? Three groups of STS-3 each?
> What does it mean? The STS-3 is a bundle, and you wish to signal
> a bundle of bundles?
> 
> If that is so, and unless I am missing something, I think you'd have
> to signal them separately.
> 
> BTW, I wasn't immediately able to see how this would be signaled
> even using the codepoints proposed in 
> draft-lin-ccamp-ipo-common-label-request-01.txt.
> 
> > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous 
> > arbitrary)
> > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > 
> > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> 
> Again, as things stand today, you'd have to signal this separately.
> 
> First, is there a requirement to signal these this way? Assuming
> there is, is there a proposal that allows for that?
> 
> I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
> do it either, since the RNC has been absorbed into the signal type
> in that case, and not all cases are enumerated.
> 
> > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > 
> > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> 
> Same as the two above.
> 
> 
> > If the identified signals are really not supported, then it would seem
> > that there is some inconsistency and maybe (?) not well 
> > organized fields
> > that arbitrarily supports certain combinations and not others...
> 
> I think what the draft does at present is that it supports some base
> combinations, which will allow you to realize the setting up of the channels
> that you mention below (as I've suggested above).
> 
> I am not sure if there is a desire (service providers please speak up!) to
> set up the types of channels you suggest above, in _one round_ of signaling.
> 
> (It could certainly be argued that they are valid choices to want to
> signal.)
> If there is a requirement from SPs, then the signal
> types/RGT/RNC might need to be extended to cover these cases.
> 
> > Am I correct? Do we need to fix this to make it consistent in terms of> 
> > supporting "like" signal types?
> 
> See above.

Delivery-date: Tue, 20 Mar 2001 02:13:24 -0800
From: Vishal Sharma <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-sig-reorg-00.tx t
Date: Tue, 20 Mar 2001 02:10:33 -0800

Folks,

This is the second in a series of three emails.

(First, a note to Bert Wijnen. I have cc'd all the three lists, since
the original request was sent on all three, and I wanted to make
people aware that this subject is under active discussion. The 
authors may now reply to only CCAMP, if they wish, since people
on other lists have at least been made aware of the ongoing discussion,
and can always access the CCAMP archives to see what's going on;
BTW, talking of CCAMP archives, unlike MPLS or IPO, 
they appear as one undifferentiated file of emails, which is 
_very difficult_ to wade through.)

-Vishal

Now on to comments:

i) Section 4. The phrase "GMPLS signaling is .... consists of a set
of messages," does not appear to be accurate, since the GMPLS signaling
draft 
draft-ietf-mpls-generalized-signaling-02.txt, does not use this terminology.
In particular, saying that they are "Create/response,
Restoration/response...
... Notification," is likely to throw people off.

ii) The document classified G-label as "optional." Is that correct?
Why would that be so?

iii) Section 5.1, starts out well, but soon meanders...

The first two make sense, even the third and fourth ones (perhaps), but
the fifth is problematic. I think some justification should also be 
given about why it makes sense for GPID to be associated with 
each signal type.

BTW, the current signaling draft (see above) _does not_ associate the
GPID with anything. The GPID, as defined, is a flat, undifferentiated
space. The code points are neither interpreted in the context of
LSP encoding type nor signal type. 
The draft [GMPLS-SIGEN] was the one that proposed dividing GPID by
LSP encoding type, and you are proposing an even finer division.

Note that I am not commenting on the appropriateness or otherwise 
of any of these proposals. I am merely asking that if the draft
proposes reasons for modification, then it should provide them so
that the reader can appreciate the logic.

iv) The example under the sixth point is not clear. The RNC has
to be interpreted together with RGT (as you yourself observe in the
preceding sentence). 
If the RGT was standard contiguous or arbitrary  contiguous
concatenation, the interpretation would be "STS-3c", if RGT was
virtual concatenation, the interpretation would be "STS-3v", if
it was bundle, the interpretation would be "3 co-routed STS-1s."
Where is the problem? 
(Zhi, don't remind me again about 3 STS-3
or 3 STS-7v, etc. :-), since, as I explained in a separate email on this
thread, they cannot be signaled in one shot using
the definitions in the current signaling draft [GMPLS-SIG].)

v) Section 5.2. The Signal Type now incorporates the RNC and RGT of 
GMPLS-SIG. Again, it is not clear why this was necessary or desirable?
No adequate justification seems to have been provided for this choice.

One major problem with doing what you have done is that this leaves no
possibility to accomplish reason one in your "Reasons for Modification."
Namely, you cannot now have a generalized label that spans packet, TDM,
WDM, fiber, etc. (Perhaps you have have one that spans the optical
technologies,
but is that good enough?)

RGT and RNT are general concepts that are probably generalizable in a way
that each layer in a layered network can use them, so why throw away that
possibility by intertwining everything within "signal type"?

**(Note that even GMPLS-SIG does not truly have a generalized label, since
it proposes a "generalized label" and then again an "SDH/SONET label"!
However, I see no good technical or architectural reason for why that
needs to be the case. Indeed, GMPLS-SIGEN
states very eloquently why having a single label format makes a lot of
sense, and, as Yuanggang calls it, "puts the G in GMPLS".) **

vi) Section 5.2, the "Directionality" bits say "Indicates the direction
of the LSP," ... with respect to what? If the intent is to clarify/enhance
things, the explanation needs to be much clearer.

vii) The "Service Type" bits seem to have absorbed what in GMPLS-SIGEN
was the Link Protection Flags, and what in GMPLS-SIG is the Protection
TLV. If that is so, this needs to be explicitly stated somewhere.
This also is problematic. What if a service provider wants to provide
a service that is independent of the underlying protection? Or is protection
deemed to be an integral part of every/any service?
Again, doesn't appear very clear.

viii) The firs sentence in Section 6 should probably be modified to
"Current ER Object/TLV ... Logical Link (bundle) granularity, by
introducing a logical interface ID object."

ix) A confusion with Section 6 is, which ER object are you talking about??
Which draft or drafts are you referring to?? I think it would be much easier
on the reader, if at specific points this draft provides references to the
particular one of the three drafts ([GMPLS-SIGEN], [GMPLS-SIG], or
[GMPLS-ARCH])
that discusses the topic at hand.

x) Section 7.1.2. As in the GMPLS-ARCH draft, this section is very unclear.
It does not adequately explain what is happening, nor does it provide the
reader a view of why a hierarchical label is needed or makes sense?

The last sentence says "The hierarchical label ... at the stack bottom."
Why not show it with an example?

The sentence above that says, "Hierarchical format is a more generic form."
Than what?? Than having a single label? Why? How does it work? What is
the use? The reader is left wondering ...

xii)The last sentence in Section 7.2.1 says
"The Channel ID structure is ... and defined in [GMPLS-SIG] and
[GMPLS-SIGEN]."
Where?? 

This is very^2 confusing, since these two drafts do not use the same
terminology as the current draft. The draft should either clearly point out
where these drafts define something akin to the channel ID, or say what
these drafts call this beast, so that the reader is not left confused
and bewildered!!

(BTW, I hate the practice that we seem to have gotten into recently of
having
a plethora of drafts, with each covering a small morsel of the total
picture,
and then referring to each other, at crucial junctures in the drafts. This
leads the reader/implementer on a wild goose chase, and makes the drafts
quite incomprehensible!)

xiii)I think it has been already pointed out that Suggested Label and
Label Set are not, in fact, mutually exclusive. I may have a label set,
and from _within_ that set suggest a specific label to my neighboring node.
Thus,
both could be simultaneously present.
Hence, the assumption in Section 8.1 and the corresponding reason for
creating the suggested label set, are incorrect.

xiv) Section 8.2, pp. 9, last sentence under "Action: 8 bits" is 
unclear. If the transmit and receive labels are adjacent, how will
they be distinguished. Where and how will their placement have been
negotiated?

xv) Section 8.2, under G-label, "Specifies a label without an 
_object wrapper_" What is that?? Some explanation needed.

xvi)Finally, the reference to [GLABEL-REQ] at the end is wrong
and incomplete. Unless this is a new draft, I think what was meant
here was draft-lin-ccamp-ipo-common-label-request-00.txt. Also,
it is a good practice to give the complete title of the draft
"draft-lin ...." to make it easier for the reader to locate it.
(Especially useful considering that the implementer is running
on a wild goose chase trying to make sense of the myriad drafts across
which useful information tidbits are spread!)

Delivery-date: Tue, 20 Mar 2001 01:14:41 -0800
From: Vishal Sharma <[email-masked]>
To: [email-masked]
Cc: 'Zhi-Wei Lin' <[email-masked]>, [email-masked], [email-masked],  [email-masked]
Subject:  RE: Three GMPLS related IDs: draft-xu-ccamp-gmpls-arch-intra-dom ain-00.txt
Date: Tue, 20 Mar 2001 01:11:53 -0800

Folks,

I have read quite carefully through the three drafts that you
referred to, and have the following comments them (they'll come
one by one, in three emails).

draft-xu-ccamp-gmpls-arch-intra-domain-00.txt.

This is a v. good document, and provides a good overview of the various
issues that need to be considered while architecting a control plane
for optical networks, using MPLS/IP. 

Comments:

i) On pp. 8, in the sentence "INE maintains LSP ID..." the LSP ID is
introduced in this document for the first time. Where did this come
from? Is it assumed that the document is suddenly referring to the 
LSP ID in RSVP-TE? If so, the connection needs to be made clear.
If not, some introduction is needed before mentioning it.

ii) In the same paragraph the sentences "However, it does not ...
disseminate to other nodes," is unclear. What local information
needn't exist on other NEs?

iii) In Section 5, the phrase "Several physical attributes can be
abstracted into one logical attribute," needs more elaboration, with
examples.

iv) On pp. 10, second last para, "The user traffic _connection service_
performance..." What is "connection service"? Some explanation needed.

v) On pp. 13, under "Service Negotiation," ... "A typical example is...
assignment order." What is this example saying? Seems quite unclear
how it pertains to service negotiation.

vi) On pp. 19, in the paragraph just above Section 5.3.2., you say
"This implies that a time slot map.... routing decisions." Then,
"Alternately, in the logical link ... STS-N signals." This latter
phrase is not clear. What is the "logical link" representation?

vii)In Section 5.4.1, the analogies to apply MPLS control plane
concepts to circuit switched networks are both unclear. The first
one is especially unclear, since it's not clear to the reader
what exactly you seem to be drawing a parallel between?
The second one, though better, is still not well said.

viii) Similarly, on pp. 19, you talk again of a logical link (bundle).
I think the term "logical link" needs to be explained better throughout
the text. It was quite confusing.

ix)In Section 5.4.1.2.2, you introduce "Connection ID" for the first
time. Please define it first.

x) The hierarchical label format, and its use is very _unclear_.
I think if the text intends to make a case for that, the explanation just
above the hierarchical label format needs to be much much better.

xi) In Section 5.4.1.5, pp. 25, first paragraph. The phrase starting
with "If the incoming label... NEs in parallel," is again unclear.
To whom should the label be given at request time? I think what you
mean is that the label should be allocated at request time, and the
cross-connect (that allocated that label, to be passed to its
upstream neighbor during the confirmation phase) 
should start configuring itself accordingly.

xii) Section 5.4.1.6 on LSP tunneling and label stack, should have more
explanation. How is the hierarchical label used exactly?

xiii) Again in the "Delete" operation on pp. 25, you talk of LSP ID.
Not clear where this comes from. RSVP-TE?

xiv) Section 5.4.2, says (at last!) that "LSP ID can be defined
as a source NE address + a source NE ingress label." How does a
source NE have an ingress label?

xv) The phrase immediately following the last one "An LSP has
two sets of information ...." is again unclear. Does it mean an 
LSP has two sets of info. associated with it?

xvi) Section 5.4.1.7 "A new LSP can be concatenated through ..."
What does "concatenated through" mean??

xvii) At the end of the document, I came away with the feeling that
it somehow ended abruptly. I haven't put my finger on it yet, but
that is what I felt. I almost felt that more should have been there.

xviii) A number of references don't seem to be referred to in the text.
[LSP-HIER], [IPO-FRAM], [OSPF-OMPLS], [ISIS-OMPLS].

xix) In addition, a number of documents that probably should be referenced
in this one are not referenced. For example, 

draft-bernstein-gmpls-optical-00.txt, makes many points germane to
the subject of this draft.

draft-ietf-mpls-recovery-frmwrk-02.txt, and
draft-harrison-mpls-oam-00.txt, 
also make many points relevant to the discussions in Section 5.4.3.

There exist drafts on bundling that are not mentioned here.
draft-kompella-mpls-bundle-05.txt, for instance.

Delivery-date: Mon, 19 Mar 2001 23:52:16 -0800
From: Vishal Sharma <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, Vishal Sharma <[email-masked]>
Cc: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Mon, 19 Mar 2001 23:49:30 -0800

Zhi-Wei,

Good points all. 
Please see below...

-Vishal

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 10:34 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; [email-masked]
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > To understand this, let's consider the setting up of an STS-3 SONET
> > channel (which is transparent
> > only at the path level, so that line and section overheads 
> are not to be
> > preserved across SONET equipment), and see what happens in 
> the various
> > cases.
> > In every case, the signal type = STS-1, and the RNC = 3.
> > 
> 
> So, in your example, for:
> 
> 1 STS-3: RNC=3, RGT=0
> 3 STS-1: RNC=3, RGT=4 (bundle)
> 
> 3 STS-3: ??? How would you signal this? Not supported?

What do you wish to signal here? Three groups of STS-3 each?
What does it mean? The STS-3 is a bundle, and you wish to signal
a bundle of bundles?

If that is so, and unless I am missing something, I think you'd have
to signal them separately.

BTW, I wasn't immediately able to see how this would be signaled
even using the codepoints proposed in 
draft-lin-ccamp-ipo-common-label-request-01.txt.

> 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous 
> arbitrary)
> 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> 
> ==> 3 STS-3c: ??? How would you signal this? Not supported?

Again, as things stand today, you'd have to signal this separately.

First, is there a requirement to signal these this way? Assuming
there is, is there a proposal that allows for that?

I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
do it either, since the RNC has been absorbed into the signal type
in that case, and not all cases are enumerated.

> 1 STS-7v: RNC=7, RGT=1 (virtual)
> 
> ==> 7 STS-7v: ??? How would you signal this? Not supported?

Same as the two above.

> If the identified signals are really not supported, then it would seem
> that there is some inconsistency and maybe (?) not well 
> organized fields
> that arbitrarily supports certain combinations and not others...

I think what the draft does at present is that it supports some base
combinations, which will allow you to realize the setting up of the channels
that you mention below (as I've suggested above).

I am not sure if there is a desire (service providers please speak up!) to
set up the types of channels you suggest above, in _one round_ of signaling.

(It could certainly be argued that they are valid choices to want to
signal.)
If there is a requirement from SPs, then the signal
types/RGT/RNC might need to be extended to cover these cases.

> Am I correct? Do we need to fix this to make it consistent in terms of
> supporting "like" signal types?

See above.

Delivery-date: Mon, 19 Mar 2001 22:47:30 -0800
Date: Tue, 20 Mar 2001 01:45:16 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Vishal Sharma <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Clarification Required regarding LSP Encoding Type

Hi Vishal, Manoj,

Right, for "digital wrapper" (BTW, our draft re-named this OTN to be
consistent with the terms used in ITU), new signal types need to be
added to extend current text to include optical networks.

draft-lin-ccamp-ipo-common-label-request-01.txt contains an extension
for the G.709 (digital wrapper) signal types.

draft-fontana-gmpls-control-g709-00.txt also has extensions for G.709. I
have some concerns with this extension because of the introduction of
"OOS". I don't believe OOS is needed since it was not needed for the
other technology layers. It is also incorrect, since the "reduced
functionality" defined in G.709 states that it does not include
non-associated overhead, nothing regarding "limited overhead". I also do
not believe in the "transparency" field. In the OTN (and any other layer
networks such as SONET), each layer above is carried transparently by
the layer below, and thus to carry as transparent, simply specify the
lower layer signal type with an appropriate G-PID. 
The other issue is that OTN muxing is currently not standardized (but
will be soon), so we should at most specify fields as placeholders for
muxing capability, but not to define what it is since there could be
many ways of getting muxing capability (e.g., 16 ODU1 into ODU3, 8 ODU1
and 2 ODU2 into ODU3, 4 OTU2 into OCh, etc.)

Zhi

Vishal Sharma wrote:
> 
> Manoj,
> 
> Your understanding is correct.
> 
> > -----Original Message-----
> > From: manoj juneja [mailto:[email-masked]]
> > Sent: Monday, March 19, 2001 3:08 PM
> > To: [email-masked]
> > Subject: Clarification Required regarding LSP Encoding Type
> >
> >
> > Hi All,
> >         The draft "draft-ietf-mpls-generalized-signalling-02.txt"
> > defines different values for LSP encoding type. How does the
> > implementation of a control plane differ if it receives the
> > LSP encoding
> > type packet/SDH/Digital Wrapper/Lamda/Fiber etc.
> >
> > My understanding is that if the LSP encoding type is either
> > packet/ethernet,
> > then label is just a 32 bit integer (as we already have in
> > traditional
> > MPLS). But if LSP encoding type is SDH, SONET then the label
> > has to be in
> > the form of {S, U, K, L, M} format. If the LSP encoding type
> > is Lamda then
> > the label represents the lamda (specific frequency). If LSP
> > encoding type is
> > fiber, then label is the fiberId itself.  Please comment on
> > whether my
> > understanding is correct or I am overlooking something.
> 
> > Can u please describe a scenario in which the LSP encoding type
> > will be used as a "digital wrapper" ?
> 
> I am not sure that an LSP encoding type of "digital wrapper" by
> itself is enough. Looking at some of the Optical Transport Network
> concepts, I would suspect that one would need an LSP encoding type
> corresponding to the various layers defined in the OTN, but
> I'll leave it to my colleagues from Lucent to comment on this.
> (Maarten, Yuangang, Zhi?)
> 
> -Vishal

Delivery-date: Mon, 19 Mar 2001 22:37:15 -0800
Date: Tue, 20 Mar 2001 01:34:17 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Vishal Sharma <[email-masked]>
CC: "'manoj juneja'" <[email-masked]>, [email-masked]
Subject: Re: Please Clarify Doubts regarding RGT & RNC

Hi Vishal,

> To understand this, let's consider the setting up of an STS-3 SONET
> channel (which is transparent
> only at the path level, so that line and section overheads are not to be
> preserved across SONET equipment), and see what happens in the various
> cases.
> In every case, the signal type = STS-1, and the RNC = 3.
> 

So, in your example, for:

1 STS-3: RNC=3, RGT=0
3 STS-1: RNC=3, RGT=4 (bundle)

3 STS-3: ??? How would you signal this? Not supported?

1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous arbitrary)
1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)

==> 3 STS-3c: ??? How would you signal this? Not supported?

1 STS-7v: RNC=7, RGT=1 (virtual)

==> 7 STS-7v: ??? How would you signal this? Not supported?

If the identified signals are really not supported, then it would seem
that there is some inconsistency and maybe (?) not well organized fields
that arbitrarily supports certain combinations and not others...

Am I correct? Do we need to fix this to make it consistent in terms of
supporting "like" signal types?

Zhi

Delivery-date: Mon, 19 Mar 2001 19:28:50 -0800
From: Vishal Sharma <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Doubt about waveband Label
Date: Mon, 19 Mar 2001 19:26:29 -0800

Manoj,

Your point is well taken.

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 10:54 AM
> To: [email-masked]
> Subject: Doubt about waveband Label
> 
> 
> Hi All,
> 
>             In draft "draft-ietf-mpls-generalized-signalling-02.txt",
> it is mentioned that for waveband switching, the genralized label
> has the format (wavebandId - start label - end label).
> When the label request message is received on incoming interface,
> how to identify that the waveand label is requested ?
> Is it the LSP encoding type or some other parameter in label
> request message ? Please help.

As things stand, I cannot see any (obvious) way for an upstream
node to indicate to a downstream node that it requires a waveband
label. The LSP encoding type for the non SDH/SONET case only has 
a "lamda" encoding type, which is insufficient to distinguis between
whether a lambda label or a waveband label is desired. Although, one
might use the label set to restrict the choice of wavelengths to
the set desired in the waveband, there still does not appear to
be a way for the upstream node to tell the downstream node that 
it is a waveband for which a label is requested.

-Vishal

Delivery-date: Mon, 19 Mar 2001 19:13:21 -0800
From: Vishal Sharma <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Clarification Required regarding LSP Encoding Type
Date: Mon, 19 Mar 2001 19:11:01 -0800

Manoj,

Your understanding is correct. 

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 3:08 PM
> To: [email-masked]
> Subject: Clarification Required regarding LSP Encoding Type
> 
> 
> Hi All,
>         The draft "draft-ietf-mpls-generalized-signalling-02.txt"
> defines different values for LSP encoding type. How does the
> implementation of a control plane differ if it receives the 
> LSP encoding 
> type packet/SDH/Digital Wrapper/Lamda/Fiber etc.
> 
> My understanding is that if the LSP encoding type is either 
> packet/ethernet, 
> then label is just a 32 bit integer (as we already have in 
> traditional 
> MPLS). But if LSP encoding type is SDH, SONET then the label 
> has to be in 
> the form of {S, U, K, L, M} format. If the LSP encoding type 
> is Lamda then 
> the label represents the lamda (specific frequency). If LSP 
> encoding type is 
> fiber, then label is the fiberId itself.  Please comment on 
> whether my 
> understanding is correct or I am overlooking something.

> Can u please describe a scenario in which the LSP encoding type
> will be used as a "digital wrapper" ?

I am not sure that an LSP encoding type of "digital wrapper" by
itself is enough. Looking at some of the Optical Transport Network
concepts, I would suspect that one would need an LSP encoding type
corresponding to the various layers defined in the OTN, but
I'll leave it to my colleagues from Lucent to comment on this.
(Maarten, Yuangang, Zhi?)

-Vishal

Delivery-date: Mon, 19 Mar 2001 19:11:04 -0800
From: Vishal Sharma <[email-masked]>
To: 'manoj juneja' <[email-masked]>, [email-masked]
Subject: RE: Please Clarify Doubts regarding RGT & RNC
Date: Mon, 19 Mar 2001 19:08:05 -0800

Manoj,

Some clarifications follow...

-Vishal

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 3:35 PM
> To: [email-masked]
> Subject: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi All,
>         The GMPLS draft 
> "draft-ietf-mpls-generalized-signalling-02.txt"
> defines different values for RGT (Requested Grouping Type) viz.
> Virtual Concatenation, Contiguous standard concatenation, Contiguous
> arbitrary concatenation, Bundle.
> How does the implementation of a control plane differ if it receives
> different RGT values ? 

The implementation of the control plane should not differ based on
different RGT values, the implementation of the data plane is what
differs in all of these cases, because each RGT value controls how
the data bearing channels are  treated by the end nodes and the
intermediate nodes. 

For example, for virtual concatenation, the intermediate nodes treat 
the virtually
concatenated channels as they would treat independent channels. The
end points, however, treat these channels as "bonded" together, and must
have hardware and software support to "glue" the data arriving on these
channels together appropriately. (For instance, the hardware must
support compensation for the differential delay that the component
channels of the virtually concatenated stream may suffer.)

> Another field RNC (Reuested Number of
> Components) defines the number of such components requested.
> My understanding is that if RNC is 2 and signal type is STM-1. Then it
> means that 2 STM-1 signals are requested and these are concatenated
> according to the RGT specified. 

Your understanding is correct.

> Does this mean, the number of labels
> requested depend on the RNC field ?  This means that is RNC is "X",
> then "X" number of labels are to be returned in Label Mapping message
> and the labels returned should be in accrodance with the requested
> signal type.

Not quite. The number of labels will be determined by a combination of
the RNC and RGT. 

To understand this, let's consider the setting up of an STS-3 SONET 
channel (which is transparent
only at the path level, so that line and section overheads are not to be 
preserved across SONET equipment), and see what happens in the various
cases.
In every case, the signal type = STS-1, and the RNC = 3.

If RGT = contiguous standard or contiguous arbitrary concatenation, then
only a _single_ label is returned (that one that denotes the time slot at 
which the first of the concatenated channels begins). 

If, however, RGT = virtual concatenation or bundle, then 3 labels (or
# of labels = RNC in the general case) will
need to be returned in the label mapping message (namely, the times slots
that denote where _each_ of the component STS-1s of the STS-3 signal is to
be placed, since in these cases the component STS-1s need not occur in
contiguous time slots).

> Please clarify these doubts.

Hope the above helps. 

> Can somebody please brief me on grouping type Bundle ?

"Bundle" is nothing but an optimized way of simultaneously 
setting up multiple, independent
SONET channels across a SONET network. Thus, in my example above, if 
RGT=bundle, what would really be setup in the SONET network would be
three channels of STS-1 granularity, where each would be totally 
independent of the others, both at the intermediate nodes and at 
the end nodes.

If, however, RGT=virtual concatenation, then what would really be
setup in the SONET network would again be 3 channels of STS-1
granularity, which to the intermediate nodes would be no different
from the case above. To the end nodes, however, it would mean that
they need to have the capability to handle virtually concatenated
SONET channels (which means they need to be capable of appropriately 
dividing traffic across them [at the input], and "glueing" them back 
together [at the output]).

> Is there any additional capability required in the network for
> supporting different types of grouping types (RGTs) ?

Not sure what you mean by "additional" capability? In "addition"
to what?

For contiguous standard concatenation, the network nodes need to
be able to support standard SDH/SONET concatenation.
For continuous arbitrary concatenation, the network nodes involved
in the establishment of such a channel, need to be able to support
arbitrary concatenation.
For virtual concatenation, the intermediate nodes through which
the channle passes need no additional functionality, but the
end nodes must be able to support the processing of virtually
concatenated channels.
For bundling, absolutely no special functionality is required
in either the intermediate nodes or the end nodes.

> 

Delivery-date: Mon, 19 Mar 2001 17:08:53 -0800
From: Fred Baker <[email-masked]>
To: [email-masked]
Cc: scott_Bradner <[email-masked]>, bert Wijnen <[email-masked]>, harald Alvestrand <[email-masked]>
Subject: Establishment of Temporary Sub-IP Area
Date: Mon, 19 Mar 2001 17:07:08 -0800

The IESG has decided to incorporate the sub-IP working groups, which are 
currently chartered in the General Area, into a temporary area. The area 
directors will be Scott Bradner and Bert Wijnen. With that change, and 
perhaps some jiggling of IESG Technical Advisers, the current working group 
charters remain unchanged and represent your work plan.

Long term, the IESG expects to review the process of the development of 
this technology and determine whether the IETF needs to further formalize 
this area or not. The IESG currently believes that this will not be 
necessary; once a strong architecture is in place here, remaining work can 
be re-absorbed into other areas such as Operations or Routing. However, we 
know all too well that we have been incorrect in the past, and may be 
incorrect here.

Part of that discussion will have to be the meta-question of exactly what 
the boundaries of the IETF's role are. Clearly, the Internet Engineering 
Task Force is interested in the Engineering of the Internet, which we 
define as including any network, private or public, metropolitan, local, or 
global, which content embedded in an IP packet crosses between two domains. 
It includes a discussion of any link or intra-network technology IP uses, 
as in the past it has included discussions of Ethernet and extended 
Ethernets, occasional and continuous serial links, X.25 networks, Frame 
Relay, and ATM. But it does not necessarily include all aspects of those 
technologies, or all of their users. Clearly, we need to be prepared to 
step in when nobody else is doing a bit of work that the Internet depends 
on. Equally clearly, we do not presume expertise in every area, and are 
willing to capitalize on work done by other bodies such as ITU-T and IEEE. 
This dividing line is fuzzy and needs clarification.

The arguments that bring us to accept sub-IP work in the IETF are 
principally that
       · The work depends on IP expertise which is here,
       · That it is critical to the development of the IP infrastructure, and
       · That it directly or indirectly affects operations or routing at 
the IP layer.

For example, optical networking is clearly a next generation requirement 
for service providers and for fiber consortia. However, the obvious next 
hop router in a general network may differ from the obvious next hop router 
in an optical network. Therefore, the use of optical networking may change 
the results that we need to get from routing protocols. It would be better 
for us to determine how the routing protocols should model those networks 
than for another body to arbitrarily change them or substitute others.

I trust that you will find your new area directors supportive and helpful 
in accomplishing your goals, and expect that you will work with them to 
accomplish theirs. 

Delivery-date: Mon, 19 Mar 2001 15:36:52 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Please Clarify Doubts regarding RGT & RNC
Date: Mon, 19 Mar 2001 16:34:32 -0700

Hi All,
        The GMPLS draft "draft-ietf-mpls-generalized-signalling-02.txt"
defines different values for RGT (Requested Grouping Type) viz.
Virtual Concatenation, Contiguous standard concatenation, Contiguous
arbitrary concatenation, Bundle.
How does the implementation of a control plane differ if it receives
different RGT values ? Another field RNC (Reuested Number of
Components) defines the number of such components requested.
My understanding is that if RNC is 2 and signal type is STM-1. Then it
means that 2 STM-1 signals are requested and these are concatenated
according to the RGT specified. Does this mean, the number of labels
requested depend on the RNC field ?  This means that is RNC is "X",
then "X" number of labels are to be returned in Label Mapping message
and the labels returned should be in accrodance with the requested
signal type.

Please clarify these doubts.

Can somebody please brief me on grouping type Bundle ?

Is there any additional capability required in the network for
supporting different types of grouping types (RGTs) ?

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 15:10:45 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Clarification Required regarding LSP Encoding Type
Date: Mon, 19 Mar 2001 16:08:02 -0700

Hi All,
        The draft "draft-ietf-mpls-generalized-signalling-02.txt"
defines different values for LSP encoding type. How does the
implementation of a control plane differ if it receives the LSP encoding 
type packet/SDH/Digital Wrapper/Lamda/Fiber etc.

My understanding is that if the LSP encoding type is either packet/ethernet, 
then label is just a 32 bit integer (as we already have in traditional 
MPLS). But if LSP encoding type is SDH, SONET then the label has to be in 
the form of {S, U, K, L, M} format. If the LSP encoding type is Lamda then 
the label represents the lamda (specific frequency). If LSP encoding type is 
fiber, then label is the fiberId itself.  Please comment on whether my 
understanding is correct or I am overlooking something.
Can u please describe a scenario in which the LSP encoding type
will be used as a "digital wrapper" ?

Please clarify.

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 11:02:28 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Doubt about Signal Type
Date: Mon, 19 Mar 2001 12:00:32 -0700

Hi All,

The draft "draft-ietf-mpls-generalized-signalling-02.txt"
describes different values for signal types. The values 1-7 are
derived from the STM hierarchy. But how the remaining values are
interpretted (i.e. STM-1 MS, STM-1 RS etc) ? How is STM-4 different
from STM-1 MS and STM-1 RS ?
Is STM-1 MS or STM-1 RS a different signal type in SDH ? How does
implementation of a control plane for GMPLS differ if it receives
the signal type as STM-1/STM-1 MS/STM-1 RS ?

The draft "draft-ietf-mpls-generalized-cr-ldp-01.txt" gives reference
to only two messages of LDP viz. Label Request, Label Mapping. What
about the other messages like label withdraw and label release.
I believe that the generalized label TLV need to be included in
these messages too instead of the label TLV.

Please help me in understanding these drafts.

Regards,
manoj.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 10:57:39 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Doubts in latest GMPLS drafts (GMPLS Functional Specs and GMPLS-CR-LDP)
Date: Mon, 19 Mar 2001 11:57:00 -0700

Hi All,

        I have gone through the latest GMPLS drafts. But I could not make 
out clearly the message structure of even the Label Request Message.Can u 
pleae brief me the TLVs that will be present in generalized Label Request 
Message(both mandatory and optional) ?

The following TLVs are passed on the O-UNI :

         - Label Set
         - Suggested Label
         - Generalized Label TLV
         - LightPath TLV
         - Source Id TLV
         - Destination Id TLV
         - Service TLV

In an interworking scenario i.e. from O-UNI to GMPLS, whether LightPathId 
TLV, SourceId TLV, Destination Id TLV, Service TLV are passed on GMPLS or 
not ? I believe that these TLVs are just consumed at the UNI only.

Please clarify.

Regards,
manoj.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 10:55:45 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Doubt about waveband Id
Date: Mon, 19 Mar 2001 11:55:03 -0700

Hi All,
            In draft "draft-ietf-mpls-generalized-signalling-02.txt",
it is mentioned that wavebandId (32 bits) is selected by the sender
and reused in all the subsequent messages. What all subsequent
messages is it mentioning to ?

Thanks,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 10:55:16 -0800
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Subject: Doubt about waveband Label
Date: Mon, 19 Mar 2001 11:53:48 -0700

Hi All,

            In draft "draft-ietf-mpls-generalized-signalling-02.txt",
it is mentioned that for waveband switching, the genralized label
has the format (wavebandId - start label - end label).
When the label request message is received on incoming interface,
how to identify that the waveand label is requested ?
Is it the LSP encoding type or some other parameter in label
request message ? Please help.

Thanks,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Mon, 19 Mar 2001 05:28:15 -0800
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 19 Mar 2001 14:26:02 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Don Fedyk <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: 

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

Don,

Thanks for the pointer to this routing delay metrics draft.

On the delay issue itself, I did some further investigations to the
differntial delay compensation capabilities state of the art
implementations would support. 

As an example, 1 GbE interfaces are added to SONET/sDH equipment using a
VC-4-Xv LCAS (X=1..7) signal to transport the Ethernet packets in the
GbE interface signal. 

The differential delay compensation capability such a VC-4-Xv LCAS
egress point (where the payload signals in the individual VC-4s are
interleaved again and the ethernet packets are mapped into another 1 GbE
interface signal) supports is these days 16 ms (32 ms buffer). This is
equivalent to about a 3000 km fiber lenght difference (transfer delay in
fiber is 5 us/km).

Do you agree that there is not much to worry about in such case, unless
you try to go world wide.

Regards,

Maarten

Don Fedyk wrote:
> 
> Hai
> 
> On the comment for Routing Delay Metric please see draft
> 
> http://www.ietf.org/internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt
> 
> I have been a supporter of this for some time and I do believe such a
> feature is valuable to both Packet and Optical GMPLS networks. There has
> been reluctance on the part of the various routing groups to embrace this
> there are a few outstanding updates to make the draft clearer.
> The CCAMP area is where the work is supposed to fall right now. Our tactic
> with the draft was to introduce a few optional metrics to give flexibility
> in this area.
> 
> Don
> 
> > -----Original Message-----
> > From: Hai Vodinh [mailto:[email-masked]]
> > Sent: Thursday, March 15, 2001 3:41 PM
> > To: 'Maarten Vissers'; Heiles Juergen
> > Cc: [email-masked]'
> > Subject: RE: SDH/SONET concatenation signal types
> >
> >
> > The other big & complex issue that arises when considering
> > diverse route
> > for VC signal is that the differential delay for the paths
> > need to be taken
> > into account. This will help the end nodes to determine if they can
> > actually
> > deal with the differential delay. For example, if the end
> > node can only
> > deal with a differential delay of N frames between the paths
> > then some how
> > the path computation step has to return paths with
> > differential delay of <
> > N.
> >
> > This does need a lot more work. At a high level, signaling
> > needs to be able
> > to request path with some delay contrainst, and routing need
> > to have a delay
> > metric.
> >
> > Regards,
> > Hai
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[email-masked]]
> > Sent: Thursday, March 15, 2001 7:13 AM
> > To: Heiles Juergen
> > Cc: [email-masked]'
> > Subject: Re: SDH/SONET concatenation signal types
> >
> >
> > Juergen,
> >
> > You hit an area which needs more work...
> >
> > VC-n-Xv up to now is associated with co-routing of all X VC-n signals
> > inthe virtual concatenated group. The introduction of LCAS feature,
> > requires that the X VC-n signals within a VC-n-Xv signal are NOT
> > co-routed; the group should be at a minimum split over two diverse
> > routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
> > identifications are not adequatly representing the two (or more)
> > subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
> > VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
> > VC-n-X1 and a VC-n-X2 connection are to be set-up.
> >
> > As such, we could restrict the set of Types to VC-n-X and at the
> > endpoints associate one or more VC-n-X's to the VC-n-Xv or
> > VC-n-Xv LCAS.
> >
> > trail trail
> > endpoint endpoint
> > VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv
> >
> > /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
> > VC-n-Xv LCAS <= =>
> > VC-n-Xv LCAS
> > \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/
> >
> > In either case, the LSPs are "VC-n-X" types.
> > At the end points of the trail (where you connect the Trail
> > Termination
> > Point, via matrix connections in the Fabric, to the Link end
> > points) the
> > additional mapping knowledge is needed.
> >
> > Being at this point in thinking, I have to ask the question
> > if we should
> > differentiate between the type of "signal" being transported and the
> > type of "transport entity" the "signal" is transported over.
> >
> > E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
> > link connections" and a second "group of X2 VC-n link
> > connections", and
> > a "VC-n-Xv signal" is transported over a "group of X VC-n link
> > connections".
> > And in the simple case, a "VC-n signal" is transported over a
> > "VC-n link
> > connection".
> >
> >
> > Regards,
> >
> > Maarten
> >
> >
> >
> > Heiles Juergen wrote:
> > >
> > > I have a question on the different SDH/SONET concatenation
> > signal types
> > proposed in draft-lin-ccamp-ipo-common-label-request (e.g.
> > VC-n-Xv, VC-n-Xv
> > LCAS, VC-n-X). Defining different signal types makes only sense if a
> > different behaviour is assumed. What is the difference
> > between these types?
> > Is my interpretation correct?
> > >
> > > VC-n-Xv: fixed virtual concatenation; co-routed
> > > VC-n-Xv LCAS: flexible virtual concatenation; different routes
> > > VC-n-X: no concatenation; co-routed
> > >
> > > For the later as it could be also used for all other signal
> > types would it
> > be better to introduce some kind of grouping for signal types
> > that have to
> > be co-routed?
> > > For all the 3 types how would you indication the timeslot,
> > position of the
> > individual VCs as the may/will not use contiguous slots. If
> > different routes
> > are used they even go accross via different interfaces and NEs and you
> > cannot include them in a single label request.
> > >
> > > Regards
> > >
> > > Juergen
> >
> >
--------------B1C9BE6D212932D34B759A3F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------B1C9BE6D212932D34B759A3F--

Delivery-date: Fri, 16 Mar 2001 12:50:22 -0800
Date: Fri, 16 Mar 2001 15:45:03 -0500
To: [email-masked], [email-masked], [email-masked]
From: Don Fedyk <[email-masked]>
Subject: RE: SDH/SONET concatenation signal types
Cc: [email-masked]

Resend, Sorry the I did not avoid all the evils of my email program 
the first time :-(
---------------------- 
Hai

On the comment for Routing Delay Metric please see draft

http://www.ietf.org/internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt

I have been a supporter of this for some time and I do believe such a
feature is valuable to both Packet and Optical GMPLS networks. There has
been reluctance on the part of the various routing groups to embrace this
there are a few outstanding updates to make the draft clearer. 
The CCAMP area is where the work is supposed to fall right now. Our tactic
with the draft was to introduce a few optional metrics to give flexibility
in this area.

Don

> -----Original Message-----
> From: Hai Vodinh [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 3:41 PM
> To: 'Maarten Vissers'; Heiles Juergen
> Cc: [email-masked]'
> Subject: RE: SDH/SONET concatenation signal types
> 
> 
> The other big & complex issue that arises when considering 
> diverse route
> for VC signal is that the differential delay for the paths 
> need to be taken
> into account.  This will help the end nodes to determine if they can
> actually
> deal with the differential delay.  For example, if the end 
> node can only
> deal with a differential delay of N frames between the paths 
> then some how 
> the path computation step has to return paths with 
> differential delay of <
> N.
> 
> This does need a lot more work.  At a high level, signaling 
> needs to be able
> to request path with some delay contrainst, and routing need 
> to have a delay
> metric.
> 
> Regards,
> Hai
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 7:13 AM
> To: Heiles Juergen
> Cc: [email-masked]'
> Subject: Re: SDH/SONET concatenation signal types
> 
> 
> Juergen,
> 
> You hit an area which needs more work... 
> 
> VC-n-Xv up to now is associated with co-routing of all X VC-n signals
> inthe virtual concatenated group. The introduction of LCAS feature,
> requires that the X VC-n signals within a VC-n-Xv signal are NOT
> co-routed; the group should be at a minimum split over two diverse
> routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
> identifications are not adequatly representing the two (or more)
> subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
> VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
> VC-n-X1 and a VC-n-X2 connection are to be set-up.
> 
> As such, we could restrict the set of Types to VC-n-X and at the
> endpoints associate one or more VC-n-X's to the VC-n-Xv or 
> VC-n-Xv LCAS.
> 
> trail						trail
> endpoint					endpoint
> VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv
> 
> 	       /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
> VC-n-Xv LCAS <=				    	   => 
> VC-n-Xv LCAS
> 	       \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/
> 
> In either case, the LSPs are "VC-n-X" types. 
> At the end points of the trail (where you connect the Trail 
> Termination
> Point, via matrix connections in the Fabric, to the Link end 
> points) the
> additional mapping knowledge is needed.
> 
> Being at this point in thinking, I have to ask the question 
> if we should
> differentiate between the type of "signal" being transported and the
> type of "transport entity" the "signal" is transported over. 
> 
> E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
> link connections" and a second "group of X2 VC-n link 
> connections", and
> a "VC-n-Xv signal" is transported over a "group of X VC-n link
> connections".
> And in the simple case, a "VC-n signal" is transported over a 
> "VC-n link
> connection".
> 
> 
> Regards,
> 
> Maarten
> 
> 
> 
> Heiles Juergen wrote:
> > 
> > I have a question on the different SDH/SONET concatenation 
> signal types
> proposed in draft-lin-ccamp-ipo-common-label-request (e.g. 
> VC-n-Xv, VC-n-Xv
> LCAS, VC-n-X). Defining different signal types makes only sense if a
> different behaviour is assumed. What is the difference 
> between these types?
> Is my interpretation correct?
> > 
> > VC-n-Xv: fixed virtual concatenation; co-routed
> > VC-n-Xv LCAS: flexible virtual concatenation; different routes
> > VC-n-X: no concatenation; co-routed
> > 
> > For the later as it could be also used for all other signal 
> types would it
> be better to introduce some kind of grouping for signal types 
> that have to
> be co-routed?
> > For all the 3 types how would you indication the timeslot, 
> position of the
> individual VCs as the may/will not use contiguous slots. If 
> different routes
> are used they even go accross via different interfaces and NEs and you
> cannot include  them in a single label request.
> > 
> > Regards
> > 
> > Juergen
> 
> 

Delivery-date: Fri, 16 Mar 2001 12:27:19 -0800
Date: Fri, 16 Mar 2001 15:20:25 -0500
To: [email-masked], [email-masked], [email-masked]
From: Don Fedyk <[email-masked]>
Cc: [email-masked]

<bigger>Hai

On the comment for Routing Delay Metric please see draft

http://www.ietf.org/internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt

I have been a supporter of this for some time and I do believe such a

feature is valuable to both Packet and Optical GMPLS networks. There 
has

been reluctance on the part of the various routing groups to embrace
this

there are a few outstanding updates to make the draft clearer. 

The CCAMP area is where the work is supposed to fall right now. Our
tactic

with the draft was to introduce a few optional metrics to give
flexibility

in this area.

Don

> -----Original Message-----

> From: Hai Vodinh [mailto:[email-masked]]

> Sent: Thursday, March 15, 2001 3:41 PM

> To: 'Maarten Vissers'; Heiles Juergen

> Cc: [email-masked]'

> Subject: RE: SDH/SONET concatenation signal types

> 

> 

> The other big & complex issue that arises when considering 

> diverse route

> for VC signal is that the differential delay for the paths 

> need to be taken

> into account.  This will help the end nodes to determine if they can

> actually

> deal with the differential delay.  For example, if the end 

> node can only

> deal with a differential delay of N frames between the paths 

> then some how 

> the path computation step has to return paths with 

> differential delay of <<

> N.

> 

> This does need a lot more work.  At a high level, signaling 

> needs to be able

> to request path with some delay contrainst, and routing need 

> to have a delay

> metric.

> 

> Regards,

> Hai

> 

> -----Original Message-----

> From: Maarten Vissers [mailto:[email-masked]]

> Sent: Thursday, March 15, 2001 7:13 AM

> To: Heiles Juergen

> Cc: [email-masked]'

> Subject: Re: SDH/SONET concatenation signal types

> 

> 

> Juergen,

> 

> You hit an area which needs more work... 

> 

> VC-n-Xv up to now is associated with co-routing of all X VC-n signals

> inthe virtual concatenated group. The introduction of LCAS feature,

> requires that the X VC-n signals within a VC-n-Xv signal are NOT

> co-routed; the group should be at a minimum split over two diverse

> routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS

> identifications are not adequatly representing the two (or more)

> subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, 
the

> VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a

> VC-n-X1 and a VC-n-X2 connection are to be set-up.

> 

> As such, we could restrict the set of Types to VC-n-X and at the

> endpoints associate one or more VC-n-X's to the VC-n-Xv or 

> VC-n-Xv LCAS.

> 

> trail						trail

> endpoint					endpoint

> VC-n-Xv <<==> VC-n-X <<==> ..... <<==> VC-n-X <<==> VC-n-Xv

> 

> 	       /=> VC-n-X1 <<==> .. <<==> VC-n-X1 <<=\

> VC-n-Xv LCAS <<=				    	   => 

> VC-n-Xv LCAS

> 	       \=> VC-n-X2 <<==> .. <<==> VC-n-X2 <<=/

> 

> In either case, the LSPs are "VC-n-X" types. 

> At the end points of the trail (where you connect the Trail 

> Termination

> Point, via matrix connections in the Fabric, to the Link end 

> points) the

> additional mapping knowledge is needed.

> 

> Being at this point in thinking, I have to ask the question 

> if we should

> differentiate between the type of "signal" being transported and the

> type of "transport entity" the "signal" is transported over. 

> 

> E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n

> link connections" and a second "group of X2 VC-n link 

> connections", and

> a "VC-n-Xv signal" is transported over a "group of X VC-n link

> connections".

> And in the simple case, a "VC-n signal" is transported over a 

> "VC-n link

> connection".

> 

> 

> Regards,

> 

> Maarten

> 

> 

> 

> Heiles Juergen wrote:

> > 

> > I have a question on the different SDH/SONET concatenation 

> signal types

> proposed in draft-lin-ccamp-ipo-common-label-request (e.g. 

> VC-n-Xv, VC-n-Xv

> LCAS, VC-n-X). Defining different signal types makes only sense if a

> different behaviour is assumed. What is the difference 

> between these types?

> Is my interpretation correct?

> > 

> > VC-n-Xv: fixed virtual concatenation; co-routed

> > VC-n-Xv LCAS: flexible virtual concatenation; different routes

> > VC-n-X: no concatenation; co-routed

> > 

> > For the later as it could be also used for all other signal 

> types would it

> be better to introduce some kind of grouping for signal types 

> that have to

> be co-routed?

> > For all the 3 types how would you indication the timeslot, 

> position of the

> individual VCs as the may/will not use contiguous slots. If 

> different routes

> are used they even go accross via different interfaces and NEs and 
you

> cannot include  them in a single label request.

> > 

> > Regards

> > 

> > Juergen

> 

> 

</bigger>

Delivery-date: Fri, 16 Mar 2001 11:18:09 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: [IP-Optical] RE: Three GMPLS related IDs
Date: Fri, 16 Mar 2001 19:14:47 -0000

Sivakumar Sankaranarayanan [mailto:[email-masked]] wrote 15 March
2001 20:37

<snip>
> > 4       A further observation wrt the above is that it seems you are
> > advocating that all failures be conveyed by control-plane 
> message 'events'.
> > Are you suggesting that (at least) the 3 distinct areas of 
> (i) user-plane
> > failures, (ii) signalling protocol failures and (iii) 
> routing protocol
> > failures all get 'merged' into some generic form of event 
> notification?  I
> > would have thought that one would need notification (and 
> general defect
> > handling) per protocol type, and that this would be a 
> function of that
> > protocol only since the failure modes of each would be 
> different (and if one
> > changes one protocol one would not want to create backwards 
> compatibility
> > issues with another).
> >
> 
> [Siva]  Yes, currently there is no clear separation of the 
> events generated from
> 
> different sources. Maybe we need to discuss further on the rationales
> for this separation. For example, a user plane failure that impacts
> traffic would definitely need to be signaled to the control 
> plane.  However,
> when you say signaling "protocol" failures and routing "protocol"
> failures, what are you referring to, is it the failure of the 
> "box" that is
> implementing the signaling and routing software? Is it the 
> failure of the link
> in
> the SCN?  Is it a wrong routing decision?  If it is failure 
> of the DCN/SCN, then
> it should be protected by theDCN/SCN failure recovery 
> methods, e.g., protected
> signaling channels.  If it is a
> box failure, then it is a bigger problem and not only is 
> restoration mechanisms
> supposed to kick in, but some maintenance action is needed 
> and so the management
> 
> system would have to be informed as well.
NH=> What I meant by this was very simple.  If we consider the user-plane
this has defects which are either (i) inherited from lower layers or (ii)
caused within the layer.  The former generally manifests itself as a 'break'
to clients (where a client can be a higher user-plane layer network or the
peer control-plane or management-plane protocols).  'Within layer' defects
are technology dependent in terms of specification, and can be either simple
breaks, swapped trails or mismerged trails (latter only applies to pkt
case).  For example the definition of simple breaks is different for OTN,
SDH, ATM, MPLS, etc and can be, for example, LoS, LoF (loss of framing) or
loss of some keepalive/hello say.  For the swapped/mismerging cases one
needs some form of trail termination network-wide unique ID.  For the
routing, signalling and management protocols, these could also have failure
modes associated with the specific protocol, eg bad PATH message in RSVP,
bad LSA in the case of OSPF, etc.  There is also the case of internal 'box
failures', which are proprietary, and which could affect user and/or control
and/or management planes.  So all I was really saying here is that some
level of defect handling is required at a per transport, per protocol and
per box level.
<snipped to end> 

Delivery-date: Fri, 16 Mar 2001 11:16:50 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: [IP-Optical] RE: Three GMPLS related IDs
Date: Fri, 16 Mar 2001 19:14:46 -0000

Hi Zhi, you noted 15 March 2001 20:14
<snipped>
> If we extend Kireeti's voting weight, I would think an 
> operator's input
> would have more weight than other's inputs.
NH=> I think this depends on the issue.  For *networking aspects* (eg
addressing, OAM, performance metrics/objectives/apportionments, etc), and
certainly wrt to determining requirements, then operators should take a
strong interest.  However, I suspect the effects of cost-cutting might be
preventing as much carrier involvement as one would like/expect.  If the
issue is largely *implementational* then I think the vendor's views should
carry more weight.
> 
> > Thinking about the further concerns a carrier would have to 
> address in a
> > connection oriented switched-network, there needs to be a 
> consideration of
> > blocking probability and users having connection requests 
> refused, ie a GoS
> > metric. The result is that transport networks currently 
> designed around high
> > utilisation with long-holding connections need to be 
> redesigned around
> > ensuring a large enough pool of free capacity.  So, in 
> addition to having to
> > address the above issues up-front with SVC-like services, 
> carriers would
> > also be forced to define a 'erlang/pricing model' for 
> something akin to a
> > Gbit PSTN!  Depending upon the number of circuits and the 
> distribution of
> > traffic holding times it may not be possible to apply 
> simply erlang theory
> > as is, but rather some modifications will be 
> required.....and the demand
> > model will obviously be an interdependent function of the 
> pricing model.
> >
> 
> Yes. Simple availability metric does not fit the switched model very
> well.
NH=> True if holding time is not long compared to failure frequency.
However, one would expect the holding times to increase as one approaches
the duct layer.....but if this is not the case, then the operators had
better make sure they have paid enough attention to the demand/pricing
models and that these make ecomonic sense.

> Since availability measurements are obtained through time
> integration of errors, with short connection duration, this metric may
> not be appropriate in its current form. For example, if a connection
> lasts for one day, and during that time 1 or 2 bit error occur.
> Depending on the level of availability offered, this may result in
> non-compliance.
NH=> I see a distinction between availability and QoS.  I would not consider
a few bit errors (for example) to impact an availability metric/objective.
Further, I would strongly recommend *not* to incorporate normal up-state QoS
metrics (eg errors/delay) into some OR'd availability criteria.....it can
get very complex (and costly) to measure....and it is probably not worth it.
It is better IMO (for a well-engineered/designed network) to rely primarily
on defect indications to determine availability entry/exit criteria.  Have
read of our recent draft on MPLS OAM.....some rationale is given in there.
> 
> Parameters that have been used in traditional PSTN networks need to be
> re-examined and modified to fit the new switched network. 
> These include
> those you've mentioned, such as connect attempts, hold times, blocking
> probability,  erlang traffic model (which already takes hold 
> times into
> consideration)
NH=> I wonder how many other operators have actually given much thought to
this yet?  It certainly concerns many of us in BT at least.
> 
> > 6       Noted the point in para 4.2 regarding ENE 'having 
> to maintain
> > source/sink LSP inventory', but the SNE also needs to maintain its
> > server->client layer adaptation mappings....so that on 
> failure the correct
> > FDI information can be sent forward into all affected 
> clients (and this
> > process should recurse for clients of those clients, etc).
> >
> 
> Yes. Each NE would still provide the capabilities inherent in an NE,
> i.e., adaptation mappings, detection/generation/suppression of various
> defects/alarms. Because these are user plane functions, we did not
> include discussion of this. 
> 
> Do you think it would be worthwhile to have a sentence to describe the
> user plane functions?
NH=> You could do...but how much would one write?  Maybe some references to
where such material is specified might suffice.
>  
<snip>
> I agree with the observation that highest bandwidth does not 
> necessarily
> mean highest priority.  Highest bandwidth might be the least critical
> application, e.g., file transfer (low priority) vs. voice (high
> priority), the bandwidth needs might be reversed.
NH=> 2 things:
-	1st, an application's forwarding QoS requirements have no
relationship to its survivability needs.  So whilst voice might be mission
critical and data transfer not mission critical in one case, in another case
their requirements could be reversed......but in *both* cases they need the
same up-state forwarding treatment.  So, like-DS-class merging in an LSP
raises some availability issues at a per 'application level'.
-	2nd, how can we can rank restoration priority amongst LSPs?  For the
L-LSP case we potentially have the situation referred to above, ie merged
same DS class applications may not have the same survivability requirements.
In the E-LSP case the situation is even less clear for similar
considerations.
I also think there is a distinction in how one views the survivability needs
of a VPN and general public services, ie voice in a VPN might require
different survivability treatment to a general 'public voice' service.  I
therefore have a concern that some issues relating to availability/QoS have
currently not be thought through.......possibly because the emphasis to date
has been largely on QoS.  
> 
> We will add this discussion in the next revision. BTW, when you state
> "an ability to select the priority of restoration post failure between
> different trails", do you mean that for all protected connections, the
> highest priority protected connection get protected first, second
> highest priority get protected second, etc. and that you want the
> flexibility to decide what criteria is used to rank the restoration?
NH=> In essence yes.  What we don't want is compounded bumping....or at
least the ability to turn it off.
> 
<snip>
> Yes, I agree. theses issues should be viewed independently.  As you
> mention, even within routing protocol, there would be differences in
> term of the relevant aspects/constraints for route determination.
> Whether these differences could be handled via different protocol or
> simply as different extensions need to be further discussed. For
> example, would the same algorithm be applicable to both SDH and OTN
> networks (most likely?)
> 
> Do you suggest we expand this section to include discussions of these
> points? We would be very happy to work with you on extending the
> concepts that you've described.
NH=> I think there needs to be further discussion.  And, perhaps more
importantly, I think operators need help to get a better grasp of what the
various extensions and redundancies will actually mean for
routing/signalling protocols.  For example, is building 1 parent protocol
with extensions/redundancies better (or worse) than tailoring the protocol
for a particular technology?  Noting that in the former case, then the whole
parent protocol seems as though it would need some re-work each time a new
technology/layer was introduced.
> 
<snip>
> > 11      In section 5.4.3.1 you describe the 4 main stages of
> > prot-sw/restoration.  I agree.  But please don't overlook 
> these facts that
> > are relevant to the first item of failure detection:
> > -       1st, we must identify all failure modes
> > -       2nd, we must describe their entry/exit criteria
> > -       3rd, we must take correct consequent actions, eg 
> FDI upwards to stop
> > alarm storms, BDI backward (if single ended visibility of 
> both directions
> > needed), squelch traffic if trail ID mismatch (important to 
> protect customer
> > traffic...so this is a sort of security consideration, but 
> it also impacts
> > billing etc)
> > -       4th, we need to know/define what constitutes up and 
> down states of
> > the trail.....this defines the 2 aspects of availability 
> SLA and the QoS
> > SLA, where the latter only has meaning once the former is 
> defined (ie only
> > valid in up-state) and will generally be based on the 
> defect handling
> > covered by points 1st-3rd above.
> > See our draft on MPLS OAM (packet level) where we cover the 
> above for an
> > example of what is required in the user-plane:
> > 
http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a
> similar approach for the lower transport layers....and note that there
> should be some attempt at metric/objective harmonisation across the layers
> in order for any measurements/SLAs taken/applied at each layer to have
some
> cross-layer relative significance.
> 

Yes, these are very valid points. I believe for points 1-3 above, we can
provide a brief description and then refer to existing standards. For
point 4, we will need to extend the document. 

Would you happen to have some text available for us to include in the
next revision?
NH=> Not currently.

Delivery-date: Fri, 16 Mar 2001 09:55:33 -0800
Cc: Heiles Juergen <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Fri, 16 Mar 2001 18:50:48 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Hai Vodinh <[email-masked]>
Original-CC: Heiles Juergen <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SDH/SONET concatenation signal types

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

Hai,

Are you trying to tell me that the control plane will have less
capabilities than the management plane :-)?

I expect that in most cases equipment have enough delay compensation to
not have to worry about it. If 99% of all set-ups would result in a good
path, you may decide to redo the set-up if a diff delay alarm is
raised...

Note - The diff delay compensation capabillity is expressed in number of
milliseconds that can be accommodated (not in number of frames).

But for long connections it would be helpful to have transfer delay
values per fiber span (that's were most of the delay is in the network)
that would result in transfer delay values for each Link in a layer
network. 
As this would be a refinement, it could be a release 2 feature...

Nevertheless, I had the impression that there are control planes today
that support a lot of parameters per link; e.g. look at ATM. So why
can't SDH have one parameter... :-).

For me the control plane must be able to support the same functionality
that is now supported by the connection management in the management
plane. The control plane should not restrict the operator in deploying
the features offered by the transport plane.

Regards,

Maarten

Hai Vodinh wrote:
> 
> The other big & complex issue that arises when considering diverse route
> for VC signal is that the differential delay for the paths need to be taken
> into account.  This will help the end nodes to determine if they can
> actually
> deal with the differential delay.  For example, if the end node can only
> deal with a differential delay of N frames between the paths then some how
> the path computation step has to return paths with differential delay of <
> N.
> 
> This does need a lot more work.  At a high level, signaling needs to be able
> to request path with some delay contrainst, and routing need to have a delay
> metric.
> 
> Regards,
> Hai
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 7:13 AM
> To: Heiles Juergen
> Cc: [email-masked]'
> Subject: Re: SDH/SONET concatenation signal types
> 
> Juergen,
> 
> You hit an area which needs more work...
> 
> VC-n-Xv up to now is associated with co-routing of all X VC-n signals
> inthe virtual concatenated group. The introduction of LCAS feature,
> requires that the X VC-n signals within a VC-n-Xv signal are NOT
> co-routed; the group should be at a minimum split over two diverse
> routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
> identifications are not adequatly representing the two (or more)
> subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
> VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
> VC-n-X1 and a VC-n-X2 connection are to be set-up.
> 
> As such, we could restrict the set of Types to VC-n-X and at the
> endpoints associate one or more VC-n-X's to the VC-n-Xv or VC-n-Xv LCAS.
> 
> trail                                           trail
> endpoint                                        endpoint
> VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv
> 
>                /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
> VC-n-Xv LCAS <=                                    => VC-n-Xv LCAS
>                \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/
> 
> In either case, the LSPs are "VC-n-X" types.
> At the end points of the trail (where you connect the Trail Termination
> Point, via matrix connections in the Fabric, to the Link end points) the
> additional mapping knowledge is needed.
> 
> Being at this point in thinking, I have to ask the question if we should
> differentiate between the type of "signal" being transported and the
> type of "transport entity" the "signal" is transported over.
> 
> E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
> link connections" and a second "group of X2 VC-n link connections", and
> a "VC-n-Xv signal" is transported over a "group of X VC-n link
> connections".
> And in the simple case, a "VC-n signal" is transported over a "VC-n link
> connection".
> 
> Regards,
> 
> Maarten
> 
> Heiles Juergen wrote:
> >
> > I have a question on the different SDH/SONET concatenation signal types
> proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv
> LCAS, VC-n-X). Defining different signal types makes only sense if a
> different behaviour is assumed. What is the difference between these types?
> Is my interpretation correct?
> >
> > VC-n-Xv: fixed virtual concatenation; co-routed
> > VC-n-Xv LCAS: flexible virtual concatenation; different routes
> > VC-n-X: no concatenation; co-routed
> >
> > For the later as it could be also used for all other signal types would it
> be better to introduce some kind of grouping for signal types that have to
> be co-routed?
> > For all the 3 types how would you indication the timeslot, position of the
> individual VCs as the may/will not use contiguous slots. If different routes
> are used they even go accross via different interfaces and NEs and you
> cannot include  them in a single label request.
> >
> > Regards
> >
> > Juergen
--------------C76DCA3E4A5C54C968E4CB41
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------C76DCA3E4A5C54C968E4CB41--

Delivery-date: Thu, 15 Mar 2001 16:34:30 -0800
Date: Thu, 15 Mar 2001 19:33:30 -0500
From: Sivakumar Sankaranarayanan <[email-masked]>
To: [email-masked]
Subject: RE: Three GMPLS related IDs

Neil,
  I generally agree with your observations, please see below for some
specific
comments...

Regards,
Shiva.

[email-masked] wrote:

> Hi Yangguang, you wrote 05 March 2001 14:29:
> > FYI, three GMPLS related IDs have been submitted.
> >
> > Architecture:
> >
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
> 0.txt
> >
> >Signaling:
> >http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-reques
> t-01.txt
> >http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt
> >
> >Comments are welcomed.
>
> Here are my observations on the sig-reorg and arch-intra-domain IDs (I could
> not open the label-request one):
>
> sig-reorg ID:
>
> 1       I noticed that NSAPs are mentioned in 6.2.  Yes, I think this form
> of global addressing will be of considerable interest and importance to
> several carriers and should be included.  It is something we are currently
> looking closely at and almost certainly will require to be supported.

>
> 2       The 'connection ID' noted in para 7.2.2 seems to be the same
> (similar?) to a trail termination identifier and, as noted, requires global
> uniqueness.  I noted that you have this 'TBD' wrt size/format.....this seems
> a sensible decision since something larger that 32 bits will surely be
> required here.
>

[Siva] Agreed.  I think there are some issues with respect to whether
the
connetion ID is global or locally unique that needs to be addressed. For
global
uniqueness, there must be coordination amongst the providers and vendor
on the
format and range of values for the ID. For local uniqueness, there must
be some translation function that maps the locally unique connection IDs
to provide an end-to-end view of the ID.

>
> 3        I was a little unclear regarding the requirement given in the 1st
> bullet in para 9.1.  Agree that user and control plane *networks* can (and
> will usually) be disjoint....indeed the control-plane network *must* only
> take its survivability design cues from the duct network, since only that
> layer can define the inherited real disjoint connectivity.  Further, both
> the control plane and user plane network need their own OAM....and in the
> control plane not only is this for the 'physical transport' aspects, but
> also on a per protocol-type, ie the signalling protocol will have different
> failure modes to the routing protocol.  One feature that is required
> however, is that user-plane failures can map to control-plane actions for
> invoking restoration (the reverse of this is clearly not true)...for example
> to restore S-PVC-like user-plane trails (see also point 5 below).   So I
> would like to see these types of relationship made more clear.
>

[Siva] I think the document needs to have an expanded discussion on the
implications of the user plane and control plane.

>
> 4       A further observation wrt the above is that it seems you are
> advocating that all failures be conveyed by control-plane message 'events'.
> Are you suggesting that (at least) the 3 distinct areas of (i) user-plane
> failures, (ii) signalling protocol failures and (iii) routing protocol
> failures all get 'merged' into some generic form of event notification?  I
> would have thought that one would need notification (and general defect
> handling) per protocol type, and that this would be a function of that
> protocol only since the failure modes of each would be different (and if one
> changes one protocol one would not want to create backwards compatibility
> issues with another).
>

[Siva]  Yes, currently there is no clear separation of the events
generated from

different sources. Maybe we need to discuss further on the rationales
for this separation. For example, a user plane failure that impacts
traffic would definitely need to be signaled to the control plane. 
However,
when you say signaling "protocol" failures and routing "protocol"
failures, what are you referring to, is it the failure of the "box" that
is
implementing the signaling and routing software? Is it the failure of
the link
in
the SCN?  Is it a wrong routing decision?  If it is failure of the
DCN/SCN, then
it should be protected by theDCN/SCN failure recovery methods, e.g.,
protected
signaling channels.  If it is a
box failure, then it is a bigger problem and not only is restoration
mechanisms
supposed to kick in, but some maintenance action is needed and so the
management

system would have to be informed as well.

>
> Further, if some aspects of the control-plane fail I would still expect the
> user-plane defect handling to carry on as an autonomous function....for
> example, the sending of a FDI into client layers to suppress alarm storms
> and protect user-plane traffic, eg squelch traffic on misrouting if trail ID
> mismatch.  I am not sure we would want to make this low-level action
> dependent on a 'healthy control-plane'....and this seems quite important
> when one has a server->client adaptation function between 2 different
> technologies, eg OTN layer->SDH layer, and where a 'common control-plane'
> might not be appropriate across such a (different operator domain)
> boundary....a point you indeed make in para 4 in the Arch-intra-domain ID.
> Can you please explain the intent of this section more clearly and comment
> on the above points, including the network management of the control-plane
> ....maybe you have some new ideas here that are worth exploring further?
>

[Siva] Yes, I completely agree with your statements. I dont think we
should
reinvent what is already a global standard, i.e., existing transport
network
defect handling
 capabilities. For example, the equipment functional blocks described in
 G.783 (for SDH) and G.798 (for OTN) and the various defects and
 consequent actions described are still valid.

Regards
Siva.

Delivery-date: Thu, 15 Mar 2001 15:38:47 -0800
From: "Sharma, Prem" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Questions on GMPLS-02.txt
Date: Thu, 15 Mar 2001 15:37:03 -0800

Hi,

   The following paragraph is from
draft-ietf-mpls-generalized-signaling-02.txt.

   ...
   Note that since the nodes sending and receiving the new form of label
   know what kinds of link they are using, the generalized label does
   not contain a type field, instead the nodes are expected to know from
   context what type of label to expect.
   ...

   I'm not clear how the label type would be inferred, solely on the
knowledge
   of link types as mentioned in the above paragraph, if the link id and
label 
   type field are not provided alongwith the label when we have the scenario

   of two hybrid nodes connected together having the following:
    
     * The nodes have K no. of fibers between them.
     * Each fiber carries L no. of wavelengths.
     * Some of the wavelengths are SDH/SONET (TDM) switched and
       the others are lambda (or wavelength) switched.
     * The control channel (for GMPLS control signalling) is OOB/OOF 
       (Out of Band/Out of fiber)[Referring to LMP]. 

   If the "context" refers to the context based on the identifier of the LSP
   (through lightpath/cr-lsp id), then it makes sense. 

   Besides this, I have one comment. Though the GMPLS Func. Desc. draft
specifies
   the format of waveband labels, but the companion documents, like
architecture
   document, don't specify in what all scenarios such labels are going to be
   used/granted. IMO, it leaves a lot to assume.

   Pls. help and correct me if something has been overlooked.

Thanks in advance.
Prem

Delivery-date: Thu, 15 Mar 2001 12:46:44 -0800
From: Hai Vodinh <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SDH/SONET concatenation signal types
Date: Thu, 15 Mar 2001 12:41:21 -0800

The other big & complex issue that arises when considering diverse route
for VC signal is that the differential delay for the paths need to be taken
into account.  This will help the end nodes to determine if they can
actually
deal with the differential delay.  For example, if the end node can only
deal with a differential delay of N frames between the paths then some how 
the path computation step has to return paths with differential delay of <
N.

This does need a lot more work.  At a high level, signaling needs to be able
to request path with some delay contrainst, and routing need to have a delay
metric.

Regards,
Hai

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 7:13 AM
To: Heiles Juergen
Cc: [email-masked]'
Subject: Re: SDH/SONET concatenation signal types

Juergen,

You hit an area which needs more work... 

VC-n-Xv up to now is associated with co-routing of all X VC-n signals
inthe virtual concatenated group. The introduction of LCAS feature,
requires that the X VC-n signals within a VC-n-Xv signal are NOT
co-routed; the group should be at a minimum split over two diverse
routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
identifications are not adequatly representing the two (or more)
subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
VC-n-X1 and a VC-n-X2 connection are to be set-up.

As such, we could restrict the set of Types to VC-n-X and at the
endpoints associate one or more VC-n-X's to the VC-n-Xv or VC-n-Xv LCAS.

trail						trail
endpoint					endpoint
VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv

	       /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
VC-n-Xv LCAS <=				    	   => VC-n-Xv LCAS
	       \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/

In either case, the LSPs are "VC-n-X" types. 
At the end points of the trail (where you connect the Trail Termination
Point, via matrix connections in the Fabric, to the Link end points) the
additional mapping knowledge is needed.

Being at this point in thinking, I have to ask the question if we should
differentiate between the type of "signal" being transported and the
type of "transport entity" the "signal" is transported over. 

E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
link connections" and a second "group of X2 VC-n link connections", and
a "VC-n-Xv signal" is transported over a "group of X VC-n link
connections".
And in the simple case, a "VC-n signal" is transported over a "VC-n link
connection".

Regards,

Maarten

Heiles Juergen wrote:
> 
> I have a question on the different SDH/SONET concatenation signal types
proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv
LCAS, VC-n-X). Defining different signal types makes only sense if a
different behaviour is assumed. What is the difference between these types?
Is my interpretation correct?
> 
> VC-n-Xv: fixed virtual concatenation; co-routed
> VC-n-Xv LCAS: flexible virtual concatenation; different routes
> VC-n-X: no concatenation; co-routed
> 
> For the later as it could be also used for all other signal types would it
be better to introduce some kind of grouping for signal types that have to
be co-routed?
> For all the 3 types how would you indication the timeslot, position of the
individual VCs as the may/will not use contiguous slots. If different routes
are used they even go accross via different interfaces and NEs and you
cannot include  them in a single label request.
> 
> Regards
> 
> Juergen

Delivery-date: Thu, 15 Mar 2001 12:45:44 -0800
Date: Thu, 15 Mar 2001 15:42:37 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] RE: Three GMPLS related IDs

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

Hi Neil,

The label-request contribution was revised to include a mapping between
the EDCBA and SU mapping. Since this was submitted after the IETF
deadline, they did not post. Attached is the revised version of that
draft.

Regards,

Zhi

[email-masked] wrote:

> Here are my observations on the sig-reorg and arch-intra-domain IDs (I could
> not open the label-request one):
>
--------------EFA0801E37B34DECCDA65E0F
Content-Type: text/plain; charset=us-ascii;
 name="draft-lin-ccamp-ipo-common-label-request-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-lin-ccamp-ipo-common-label-request-01.txt"

Network Working Group                                
Internet Draft 
Expiration Date: September 2001                  Maarten Vissers 
                                                     Zhi-Wei Lin
                                                    Yangguang Xu
                                           Siva Sankaranarayanan

                                        Lucent Technologies, Inc.

                Common Label and Label Request Specification
                 for Automatic Switched Transport Network

             draft-lin-ccamp-ipo-common-label-request-01.txt

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Abstract

   This draft completes the [GMPLS-REORG] draft and details technology 
   specific issues. It proposes different approach and enhancement to 
   [GMPLS-SIG] and [GMPLS-SIGEN]. Changes are:

   -- New set of Signal Type structures of ETSI-PDH, ANSI-PDH, SONET, SDH and 
      OTN for Generalized Label Request [GMPLS-SIG].
   -- G-PIDs associated each signal type for G-Label Request.
   -- Label Channel ID [GMPLS-REORG] field structure.
   -- Conversion formula for ITU-T (G.707) EDCBA to SU numbering scheme.

Z. Lin et. al.                                                     Page [1]

Internet Draft      G-Label and G-Label Request Specification      March 2001

3. G-Label Request Specification

     0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | LSP Enc. Type |                Signal Type                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |  Service Type |  Dir  | Rserved |           G-PID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    LSP Encoding Type and Signal Type together identify the unique signal 
    type of the LSP. 

3.1 LSP Encoding

    LSP Encoding Type: 8 bit 

    Indicates the encoding technology of the LSP being requested.
    
                 Value        Type
                 -----        --------
                 3            ANSI PDH
                 4            ETSI PDH
                 5            SDH
                 6            SONET
                 7            OTN
                 8            Analog

3.2 Signaling Type and Associated G-PID

    Signaling Type: 24 bits 

    Indicates the specific signal type of the LSP being requested. This 
    field is interpreted according to the technology specified by LSP 
    Encoding Type. The Signal Type provides transit switches with the 
    information required to determine which link connection can support 
    the LSP.

    G-PID: 16 bits
 
    Indicates the payload carried by an LSP, i.e. an identifier of the 
    client layer of the LSP.  It's the same as Payload Types in G.709, 
    Signal Label in G.707 and L3PID in RSVP-TE. Each of signal type may 
    only allow certain types of client signals. The G-PID is mainly used by 
    the adaptation layer function at the LSP terminating points. G-PID is 
    associated with each signal type.

Z. Lin et. al.                                                     Page [2]

Internet Draft      G-Label and G-Label Request Specification      March 2001

3.2.1 ANSI PDH Signaling Type

   Permitted values and their meaning for LSP Encoding Type ANSI-PDH:

                 Value       Type
                 -----       ----
                 1           DS1 SF
                 2           DS1 ESF
                 3           DS2
                 4           DS3 M23
                 5           DS3 C-bit Parity
                 6           DS4

   When the technology encoding type is ANSI-PDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                 0           Unknown

3.2.2 ETSI PDH Signaling Type

   Permitted values and their meaning for LSP Encoding Type ETSI-PDH:

                 Value        Type
                 -----        ----
                 1            E1 P12x
                 2            E1 P12s
                 3            E2 P22x
                 4            E2 P22e
                 5            E3 P31x
                 6            E3 P31e
                 7            E3 P31s
                 8            E4 P4x
                 9            E4 P4e
                 10           E4 P4s

3.2.3 SDH Signaling Type

    For SONET/SDH, the 24-bit Signal Type SHALL be encoded in the following 
    format: 
     
     0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | LSP Enc. Type |     Type      |              X                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Z. Lin et. al.                                                     Page [3]

Internet Draft      G-Label and G-Label Request Specification      March 2001

    Type: 8 bits 
    
    Indicates specific signal type of a LSP encoding type 

    X : 16 bits 

    Indicates concatenation value.

    Permitted type values and their meaning for LSP Encoding Type SDH 
    are:
          
                 Value        Type
                 -----        --------
                 1            VC-11
                 2            VC-12
                 3            VC-2
                 4            VC-2-Xc (1<=x<=7)
                 5            VC-3
                 6            VC-4
                 7            VC-4-Xc (X=4,16,64,256)
                 8            MS-X (STM-X MS) (X=1,4,16,64,256)
                 9            STM-X (X=1,4,16,64,256)
                 10           VC-11-Xv (1<=X<=64)
                 11           VC-12-Xv (1<=X<=64)
                 12           VC-2-Xv (1<=X<=64)
                 13           VC-3-Xv (1<=X<=256)
                 14           VC-4-Xv (1<=X<=256)
                 15           VC-11-Xv LCAS
                 16           VC-12-Xv LCAS
                 17           VC-2-Xv LCAS
                 18           VC-3-Xv LCAS
                 19           VC-4-Xv LCAS
                 20           VC-11-X **
                 21           VC-12-X 
                 22           VC-2-X 
                 23           VC-3-X 
                 24           VC-4-X 
                 128          TUG-2
                 129          TUG-3
                 130          AUG-X (X=1,4,16,64,256)
                 131          VC-4-Xa (1<=X<=256)
                 132          STM-Xst
                 133-143	Reserved for vendor specific SDH signal type

   ** This is used at intermediate nodes to support the LCAS when a subset 
      of the link connections are co-routed. 

Z. Lin et. al.                                                     Page [4]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   The "MS-X" and "STM-X" Signal types represent transparent STM Multiplex 
   Section and Regenerator Section LSPs respectively. Note that the "STM-X" 
   signal type represents the complete STM-N signal, including all its SOH.

   The "VC-n-Xc" Signal Type represents a contiguous standard concatenated 
   VC-n signal (ITU-T Rec. G.707), which is transported via the AU and TU 
   timeslots according to the (E,D,C,B,A) and (K,L,M) structures.

   The "VC-n-Xv" Signal type represents a virtual concatenated VC-n signal. 

   The "VC-n-Xv LCAS" Signal type represents a VC-n-Xv signal with Link 
   Capacity Adjustment Scheme (LCAS) capability. The "VC-n-X" Signal type 
   represents a group of VC-n signals that are to be co-routed. 

   Besides the set of signal types derived from the SDH standards, a number of 
   additional signal types are defined. These additional signal types are 
   vendor specific extensions of the SDH standards.

   The "AUG-X" Signal type represents an AUG-X bandwidth, of which the 
   specific AU structure is not predefined. This AUG-X link will autonomously 
   adapt to the incoming AU structure. Idem for TUG-2 and TUG-3.

   The "VC-4-Xa" Signal type represents a contiguous arbitrary concatenated 
   VC-4 signal.

   The "STM-Xst" Signal type represents a "semi transparent" STM-X signal. The 
   AUG-X and some of the SOH (vendor specific selection) is transported 
   through the link connection. Interworking between equipment of different 
   vendors is not to be expected.

   To support other vendor specific SDH signal types a set of 13 code points 
   (133-143) is reserved. Within its subnetwork a vendor may assign these code 
   points to its specific signals.

   The G-PIDs associated with each Signal Type are (based on G.707):
      VC-11:     (1) async 1.544 Mbps, (2) bit sync 1.544 Mbps, (3) byte sync   
                     1.544 Mbps, (4) byte sync 384 kbps, (5) ATM, (6) HDLC  
                     framed, (7) GFP framed
      VC-12:     (1) async 2.048 Mbps - transparent, (2) async 2.048 Mbps - 
                     terminated, (3) byte sync 2.048 Mbps - transparent, (4) 
                     byte sync 2.048 Mbps - terminated, (3) 31x64 kbps, (4) 
                     ATM, (5) HDLC framed, (7) GFP framed
      VC-2:      (1) async 6.312 Mbps, (2) bit sync 6.312 Mbps, (3) ATM, (4) 
                     HDLC framed, (5) GFP framed
      VC-2-Xc:   (1) ATM, (2) HDLC framed w/ scrambling
      VC-3:      (1) 44.736 Mbps - transparent, (2) 44.736 Mbps - terminated, 
                     (3) 34.368 Mbps - transparent, (4) 34.368 Mbps - 
                     terminated G.751 frame, (5) 34.368 Mbps - terminated 
                     G.832 frame, (3) TUG (4) ATM, (5) HDLC framed w/ 
                     scrambling, (6) GFP framed

Z. Lin et. al.                                                     Page [5]

Internet Draft      G-Label and G-Label Request Specification      March 2001

      TUG-2:     (1) one TU-2, (2) three TU-12, (3) four TU-11
      TUG-3:     (1) one TU-3, (2) seven TUG-2
      VC-4:      (1) 139.264 Mbps - transparent, (2) 139.264 Mbps - terminated 
                     G.751 frame, (3) 139.264 Mbps - terminated G.832 frame, 
                     (4) TUG, (5) ATM, (6) HDLC framed w/ scrambling, (7) 
                     DQDB, (8) async FDDI, (9) GFP framed
      VC-4-4c:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-16c:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-64c:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-256c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      AUG-1:     (1) one AU-4,   (2) three AU-3
      AUG-4:     (1) four AUG-1, (2) one AU-4-4c
      AUG-16:    (1) four AUG-4, (2) one AU-4-16c
      AUG-64:    (1) four AUG-16, (2) one AU-4-64c
      AUG-256:   (1) four AUG-64, (2) one AU-4-256c
      MS-X:      (1) AUG-X
      STM-X: 
      VC-11-Xv:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-12-Xv:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-2-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-3-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-11-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-12-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-2-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-3-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-11-X group that is co-routed: (0) unknown
      VC-12-X group that is co-routed: (0) unknown
      VC-2-X group that is co-routed:  (0) unknown
      VC-3-X group that is co-routed:  (0) unknown
      VC-4-X group that is co-routed:  (0) unknown

3.2.4 SONET Signaling Type

    Permitted type values and their meaning for LSP Encoding Type SONET 
    are:

                 Value        Type
                 -----        --------
                 1            VT1.5
                 2            VT2
                 3            VT3
                 4            VT6
                 5            STS-1 SPE
                 6            STS-Xc SPE      (X=3,12,48,192,768)
                 7            STS-X SPE       (X=1,3,12,48,192,768)
                 8            STS-X Line      (X=1,3,12,48,192,768)

Z. Lin et. al.                                                     Page [6]

Internet Draft      G-Label and G-Label Request Specification      March 2001

                 9            STS-X           (X=1,3,12,48,192,768)
                 10           VT1.5-Xv        (1<=X<=64)
                 11           VT2-Xv          (1<=X<=64)
                 12           VT3-Xv          (1<=X<=64)
                 13           VT6-Xv          (1<=X<=64)
                 14           STS-1-Xv        (1<=X<=256)
                 15           STS-3c-Xv       (1<=X<=256)
                 16           VT1.5-Xv LCAS
                 17           VT2-Xv LCAS
                 18           VT3-Xv LCAS
                 19           VT6-Xv LCAS
                 20           STS-1-Xv LCAS
                 21           STS-3c-Xv LCAS
                 22           VT1.5-X **
                 23           VT2-X
                 24           VT3-X
                 25           VT6-X
                 26           STS-1-X
                 27           STS-3c-X
                 128          VTG
                 129          STS Group-X (X=3,12,48,192,768)
                 130          STS-3c-Xa (1<=X<=256)
                 131          STS-Xst
                 132-143      Reserved for vendor specific SONET signal type

   ** This is used at intermediate nodes to support the LCAS when a subset 
   of the link connections are co-routed. 

   The "STS-X Line" and "STS-X" Signal types represent transparent STS Line 
   and STS Section LSPs respectively. Note that the "STS-X" signal type 
   represents the complete STS-N signal, including all its TOH.

   The "STS-Xc" Signal Type represents a contiguous standard concatenated STS 
   signal (ANSI T1.105), which is transported via the STS timeslots according 
   to the (E,D,C,B,A) structures.

   The "VTn-Xv" and "STS-n-Xv" Signal types represent virtual concatenated VT    
   and STS signals. The "VTn-Xv LCAS" and "STS-n-Xv LCAS" Signal type 
   represent VTn-Xv and STS-n-Xv signal with Link Capacity Adjustment Scheme 
   (LCAS) capability. The "VTn-X" and "STS-n-X" Signal types represent a group 
   of VTn and STS-n signals that are to be co-routed. 

   Besides the set of signal types derived from the SONET standards, a number 
   of additional signal types are defined. These additional signal types are 
   vendor specific extensions of the SONET standards.

   The "STS Group-X" Signal type represents an STS Group bandwidth, of which 
   the specific STS structure is not predefined. This STS Group-X link will 
   autonomously adapt to the incoming STS structure. Idem VTG.

Z. Lin et. al.                                                     Page [7]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   The "STS-3c-Xa" Signal type represents a contiguous arbitrary concatenated 
   STS-3c signal.

   The "STS-Xst" Signal type represents a "semi transparent" STS-X signal. The 
   STS-X SPE and some of the TOH (vendor specific selection) is transported 
   through the link connection. Inter-working between equipment of different 
   vendors is not to be expected.

   To support other vendor specific SONET signal types a set of 13 code points 
   (132-143) is reserved. Within its subnetwork a vendor may assign these code 
   points to its specific signals.

   The G-PIDs associated with each Signal Type are (based on T1.105):
      VT1.5:       (1) async DS1 (1.544 Mbps), (2) bit sync DS1, byte sync 
                       DS1, (3) GFP framed
      VT2:         (1) async 2.048 Mbps, (2) bit sync 2.048 Mbps, (3) byte 
                       sync 2.048 Mbps, (4) GFP framed
      VT3:         (1) async DS1C (3.152 Mbps)
      VT6:         (1) async DS2 (6.312 Mbps), (2) GFP framed
      STS Group-X: (1) STS-X SPE
      STS-1 SPE:   (1) async DS3 (44.736 Mbps), (2) VTG, (3) GFP framed
      STS-3c SPE:  (1) ATM, (2) HDLC framed, (3) GFP framed, (4) SDL w/ 
                       scrambler
      STS-12c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-48c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-192c SPE:(1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler, 
                       10 Gbps Ethernet
      STS-768c SPE:(1)ATM,  (2) HDLC framed, (3) GFP framed, SDL w/ scrambler 
      STS-1 Line:
      STS-3 Line:
      STS-12 Line:
      STS-48 Line:
      STS-192 Line:
      STS-768 Line:
      STS-1:
      STS-3:
      STS-12:
      STS-48:
      STS-192:
      STS-768:
      VT1.5-Xv:    (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT2-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT3-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT6-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-1-Xv:    (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-3c-Xv:   (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT1.5-Xv LCAS:
      VT2-Xv LCAS:
      VT3-Xv LCAS:

Z. Lin et. al.                                                     Page [8]

Internet Draft      G-Label and G-Label Request Specification      March 2001

      VT6-Xv LCAS:
      STS-1-Xv LCAS:
      STS-3c-Xv LCAS:

3.2.5 OTN Signaling Type

   For OTN, the permitted signal types are
          
          Value        Type
          -----        --------
          1            ODU1
          2            ODU2
          3            ODU3

          10           OCh  - further typing will be added to OCh

   G-PIDs for ODU1 include:

          Value        Type
          -----        --------
          1            CBR2G5a  (asynchronous constant bit rate of 2.5 Gbps 
                                 such as STM-16 or OC-48)
          2            CBR2G5b  (bit synchronous constant bit rate of 2.5 Gbps 
                                 such as STM-16 or OC-48)          
          3            ATM2G5	
          4            GFP2G5   (used for transporting data, e.g., IP @ 2.5 
                                 Gbps)
          5            BSOT2G5  (mapping of non-specific client bit stream w/ 
                                 octet timing)
          6            BSNT2G5  (mapping of non-specific client bit stream w/o
                                 octet timing)

    G-PIDs for ODU2 include:

          Value        Type
          -----        --------
          1            CBR10Ga
          2            CBR10Gb
          3            ATM10G	
          4            GFP10G
          5            BSOT10G
          6            BSNT10G

    G-PIDs for ODU3 include:

          Value        Type
          -----        --------
          1            CBR40Ga

Z. Lin et. al.                                                     Page [9]

Internet Draft      G-Label and G-Label Request Specification      March 2001

          2            CBR40Gb
          3            ATM40G	
          4            GFP40G
          5            BSOT40G
          6            BSNT40G

    G-PIDs for OCh include:

          Value        Type
          -----        --------
           1           OTU1
           2           OTU1V
           3           OTU2
           4           OTU2V
           5           OTU3
           6           OTU3V
           7           STM-16/OC-48
           8           STM-64/OC-192
           9           STM-256/OC-256
           10          1 GbE

3.3 Directionality and Service Type are defined in [GMPLS-REORG].

4. G-label Channel ID Specification

4.1 G-Label Specification
   
   [GMPLS-REORG] introduces two type of Label format for automatically 
   switched transport network.

   Basic Format:

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  G-Label     (Port ID)                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | D |              G-Label     (Channel ID)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hierarchical Format:

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //                 G-Label     (Connection ID)                  // 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | D |              G-Label     (Channel ID)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Z. Lin et. al.                                                     Page [10]

Internet Draft      G-Label and G-Label Request Specification      March 2001

4.2 G-Label Channel ID for SONET/SDH

    For SDH/SONET, the label identifies both a timeslot in the SDH/SONET frame 
    as well as a Connection Termination Point (CTP) in the equipment.

    The Channel ID of the G-label represents for SDH/SONET either the AU/STS 
    timeslots or the TU/VT timeslots.

    SDH/SONET are technologies encompassing multiple independent layer 
    networks. Trails and connections in layer networks are set up and torn 
    down independent of trails and connections in their server layer networks. 
    Trails and connections in layer networks are modified independent of 
    trails and connections in their server and client layer networks.

    Typically, server layer trails must have been set up before client layer 
    connections and trails can be set up. Server layer trails provide the 
    client layer link connections (label switched hops). As such, STM-N/OC-N 
    (i.e. multiplex section/line) trails must have been established before 
    HOVC connections and trails can be set up. Similarly, VC-4/STS-1 trails 
    must have been established before LOVC/VT connections and trails can be 
    set up.

    There is a multiplicity of ports (physical and logical) in SDH/SONET 
    equipment; STM-N/OC-N physical ports, HOVC/STS logical ports, LOVC/VT 
    logical ports. In future hybrid OTN/SDH/SONET equipment STM-N/OC-N ports 
    might also be logical ports.

    HOVC/STS signals can be transported over STM-N/OC-N signals. LOVC/VT 
    signals can be transported over either VC-4/VC-3/STS-1 signals, or sub-
    STM-0/sub-STS-1 signals (e.g. sSTM-1k [k=1,2,4,8,16], sSTM-2n [n=1,2,4]), 
    or 34 376 and 139 264 kbit/s signals with G.832 framing.

    STM-N/OC-N signals aggregate HOVC/STS signals. The associated multiplex 
    structure may be adapted during the lifetime of the STM-N/OC-N trail to 
    accommodate the requested mix of HOVC/STS signal types. VC-4/VC-3/STS-1 
    signals aggregate LOVC/VT signals. The associated multiplex structure may 
    be adapted during the lifetime of the VC-4/VC-3/STS-1 trail to accommodate 
    the requested mix of LOVC/VT signal types. At any moment in time, the 
    complete aggregation bandwidth's multiplex structure must be defined to 
    prevent alarms to be raised.

    SDH/SONET equipment may have either no switch fabric, or a HOVC/STS switch 
    fabric, or a LOVC/VT switch fabric, or a HOVC/STS and a LOVC/VT switch 
    fabric. SDH/SONET interfaces on none-SDH/SONET equipment typically have no 
    switch fabric. Hybrid equipment may have SDH/SONET type switch fabrics in 
    addition to client layer (e.g. ATM VP, ATM, VC, IP, Ethernet) switch 
    fabrics and/or server layer (e.g. OTN OCh, OTN ODUk) switch fabrics. 

    Installing fibers between equipment will establish physical layer trails, 

Z. Lin et. al.                                                     Page [11]

Internet Draft      G-Label and G-Label Request Specification      March 2001

    but most likely no HOVC/STS or LOVC/VT trails, despite that there might be 
    some SDH/SONET interfaces without switch fabrics connected at the edge of 
    the (sub)network.

    Therefore, HOVC/STS labels are independent of LOVC/VT labels. Each one 
    will have a dedicated Channel ID.

4.2.1. HOVC/STS specific Channel ID in STM-N/OC-N

    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 
    (E,D,C,B,A) structure (TUs are named according the (K,L,M) structure). 
    This (E,D,C,B,A) structure identifies the AU type, the location in the 
    STM-N/OC-N frame and at the same time implies a restriction on the AU-4-
    Xc/STS-Xc types and the timeslots these signals can be transported over.
    Vendor specific extensions exist that have fewer restrictions. To 
    accommodate both cases in a single channel ID structure, HOVC/STS channel 
    IDs are represented by means of the "SU" structure. A conversion between 
    (E,D,C,B,A) and SU is included.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       S                               |   U   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   1. S is the index of a particular AUG-X/STS-X, AU/STS, STM-Xst signal.
      S=1->N indicates the first timeslot of a specific AUG-X/STS-X,
 
      AU/STS, STM-Xst inside an STM-N/STS-N multiplex. For example, S=1 
      indicates the first AUG-1/STS-3, and S=N indicates the last AUG-1/STS-3 of 
      this multiplex.  S=0 is invalid.

  2. U indicates if the AUG-1/STS-3 is subdivided. U=1 indicates that
     the AUG-1/STS-3 is not further subdivided and contains an
     AU-4/STS-3c. U=2->4 indicates a specific AU-3/STS-1 inside the
     given AUG-1/STS-3. For the other signals, U is not-applicable
     and is fixed to 0.

4.2.2. TU/VT specific Channel ID portion in VC-4 and STS-1

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                       |   K   |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For SDH VC-4 and VC-3, this is an extension of the numbering scheme defined 

Z. Lin et. al.                                                     Page [12]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   in G.707 section 7.3, i.e. the (K, L, M) and (L,M) numbering. For 
   SONET and SDH VC-3 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. K is only significant for SDH VC-4 and must be ignored for SONET and SDH 
      VC-3. 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.

   2. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
      is not significant for an unstructured VC-4, and must be 0 in this case. 
      L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further sub-divided 
      and contains a TU-3 in SDH; It is not applicable for SONET. L=2->8
      indicates a specific TUG-2/VT Group inside the corresponding
      higher order signal.
      L=9 indicates that the TUG3 structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU structure of the incoming signal. This signal
      is referred to as a TUG-3. 

   3. 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 and must be 0 in this case. M=1 indicates that the TUG-2/VT Group is  
      not further sub-divided and contains a TU-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 TU-12/VT-2 inside the     
      corresponding TUG-2/VT Group. M=7->10 indicates a specific
      TU-11/VT-1.5 inside the corresponding TUG-2/VT Group. 
      M=11 indicates that the TUG2/VTG structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU/VT structure of the incoming signal. This signal
      is referred to as a TUG-2/VTG. 

4.2.3	TU/VT specific channel portion in sSTM-1k and sSTM-2n

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                               |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Z. Lin et. al.                                                     Page [13]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   For SDH sSTM-2n, this is an extension of the numbering scheme defined in
   G.708, i.e. the (L,M) numbering. 

   1. L=1->n indicates a specific TUG-2/VT Group inside the sSTM-2n (n=1,2,4).
      L=5 indicates that the TUG2 structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU structure of the incoming signal. This signal
      is referred to as a TUG-2. 

   2. M indicates a specific branch of a TUG-2/VT Group. M=1 indicates that 
      the TUG-2/VT Group is not further sub-divided and contains a TU-2/VT-6. 
      M=2->4 indicates a specific TU-12/VT-2 inside the corresponding TUG-2/VT 
      Group. M=5->8 indicates a specific TU-11/VT-1.5 inside the corresponding 
      TUG-2/VT Group. 
      M=9 indicates that the TUG2/VTG structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU/VT structure of the incoming signal. This signal
      is referred to as a TUG-2/VTG. 

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                       |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For SDH sSTM-1k, this is an extension of the numbering scheme defined in
   G.708, i.e. the (M) numbering. 

   1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16).

4.2.4	TU/VT specific channel portion in P31s and P4s

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                       |   K   |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 139 264 kbit/s G.832 framed signal (P4s) option II, this is an    
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the 
   (K, L, M) numbering. 

   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.

  

Z. Lin et. al.                                                     Page [14]

Internet Draft      G-Label and G-Label Request Specification      March 2001
   
   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. K indicates a specific branch of a P4s. K=1->3 indicates a specific TUG-
      3 (A, B, C) inside the P4s.

   2. L indicates a specific branch of a TUG-3. L=1 indicates that
      the TUG-3 is not further sub-divided and contains a TU-3. L=2->8 (for 
      K=3, L is limited to 2->6) indicates a specific TUG-2.

   3. M indicates a specific branch of a TUG-2. It is not significant for an 
      unstructured TUG-3 and must be 0 in this case. M=1 indicates that the 
      TUG-2 is not further sub-divided and contains a TU-2. M=2->4 indicates a 
      specific TU-12 inside the corresponding TUG-2.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                               |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 139 264 kbit/s G.832 framed signal (P4s) option I, this is an   
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the 
   (L, M) numbering. 

   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. L indicates a specific branch of a P4s. L=1->20 
      indicates a specific TUG-2.

   2. M indicates a specific branch of a TUG-2. M=1 indicates that the TUG-2 
      is not further sub-divided and contains a TU-2. M=2->4 indicates a 
      specific TU-12 inside the corresponding TUG-2.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                       |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 34 368 kbit/s G.832 framed signal (P4s) option I, this is an 
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the  
   (L, M) numbering. For sSTM-1k, this is an extension of the numbering scheme 

Z. Lin et. al.                                                     Page [15]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   defined in G.708, i.e. the (M) numbering. 

   1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16).

4.3 OTN Label

    TBD

5. Security Considerations

   This document raises no new security concerns.

6. References

[GMPLS-REORG]	Y. Xu, et. al., "GMPLS Signaling Functional Spec. 
Modification and Reorganization", Work in Progress, March 2001.

[GMPLS-SIG]       P. Ashwood-Smith, et. al., "Generalized MPLS - Signaling 
Functional Description", Work in Progress, Nov. 2000.

[GMPLS-ARCH]      Y. Xu, et. al.,  "GMPLS Control Plane Architecture for ASTN", 
Work in Progress, Nov. 2000.

[GMPLS-SIGEN]     B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for 
Optical Technologies", Work in Progress, Nov. 2000.

7. Author Information
    
   Yangguang Xu
   21-2A41, 1600 Osgood Street
   North Andover, MA 01845
   Email:	[email-masked]
   
   Zhi-Wei Lin
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030 
   Email: [email-masked]

   Siva Sankaranarayanan    
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030 
   Email: [email-masked]

   Maarten Vissers
   Botterstraat 45
   Postbus 18
   1270 AA Huizen, Netherlands 
   Email: [email-masked]

Z. Lin et. al.                                                     Page [16]

Annex A: Conversion formula for EDCBA <-> SU

For the EDCBA to SU conversion, the following formula can be used:

	S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] + 
	      max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1

	              B
	U = ceiling[ --- , 0 ] + A
	             B+1

For the SU to EDCBA conversion, the following formula can be used:

	                   S
	E = max[ ceiling[ --- ], 0 ] 
	                  64

	      or 0 {for AU-4-256c & STM-64 or lower}

	                       S
	D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
	                      16
 
	      or 0 {for AU-4-64c or above & STM-16 or lower}

	                       S
	C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
	                       4
 
	      or 0 {for AU-4-16c or above & STM-4 or lower}

	B = [ ( S-1 ) modulo 4 ] + 1 
	      or 0 {for AU-4-4c or above & STM-1 or lower}

	A = U - 1
	      or 0 (for AU-4 or above)

Annex B: Sample conversion table

The following table provides the explicit mapping between the SU and the EDCBA numbering scheme:

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

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

--------------EFA0801E37B34DECCDA65E0F--

Delivery-date: Thu, 15 Mar 2001 12:19:28 -0800
Date: Thu, 15 Mar 2001 15:14:06 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] RE: Three GMPLS related IDs

Hi Neil,

I saw your comments for the set of GMPLS related I-Ds. My comments are
in-line (related to the arch-intra-domain ID).

> Arch-intra-domain ID:
> Note - I like this paper in general, and I guess the reason for this is that
> several operators have input (requirements) to it and it is not just sourced
> from vendors.
> 

Yes. I think this is a very critical aspect of working on any
specification, that operators have input into the process. After all, it
is the operators (however large or small) who will be deploying these
networks and will have to live with the consequences of a well-specified
(or not) standards. 

If we extend Kireeti's voting weight, I would think an operator's input
would have more weight than other's inputs.

> Thinking about the further concerns a carrier would have to address in a
> connection oriented switched-network, there needs to be a consideration of
> blocking probability and users having connection requests refused, ie a GoS
> metric. The result is that transport networks currently designed around high
> utilisation with long-holding connections need to be redesigned around
> ensuring a large enough pool of free capacity.  So, in addition to having to
> address the above issues up-front with SVC-like services, carriers would
> also be forced to define a 'erlang/pricing model' for something akin to a
> Gbit PSTN!  Depending upon the number of circuits and the distribution of
> traffic holding times it may not be possible to apply simply erlang theory
> as is, but rather some modifications will be required.....and the demand
> model will obviously be an interdependent function of the pricing model.
>

Yes. Simple availability metric does not fit the switched model very
well. Since availability measurements are obtained through time
integration of errors, with short connection duration, this metric may
not be appropriate in its current form. For example, if a connection
lasts for one day, and during that time 1 or 2 bit error occur.
Depending on the level of availability offered, this may result in
non-compliance. 

Parameters that have been used in traditional PSTN networks need to be
re-examined and modified to fit the new switched network. These include
those you've mentioned, such as connect attempts, hold times, blocking
probability,  erlang traffic model (which already takes hold times into
consideration)

> 6       Noted the point in para 4.2 regarding ENE 'having to maintain
> source/sink LSP inventory', but the SNE also needs to maintain its
> server->client layer adaptation mappings....so that on failure the correct
> FDI information can be sent forward into all affected clients (and this
> process should recurse for clients of those clients, etc).
>

Yes. Each NE would still provide the capabilities inherent in an NE,
i.e., adaptation mappings, detection/generation/suppression of various
defects/alarms. Because these are user plane functions, we did not
include discussion of this. 

Do you think it would be worthwhile to have a sentence to describe the
user plane functions?
 
> 7       In section 5.3 on path selection source (ERO) and hop-hop routing
> are compared.  However, the biggest advantage of source routing is not noted
> strongly enough.....and that is the fact that one does not need to wait
> until a failure to calculate an alternative route from the link-state
> database.  For very important routes one can pre-calculate an alternative
> path and reserve resources, so restoration is very fast.  This leads me to
> the next point here.
> 

Yes, that is certainly an advantage for fast restoration. We will add
text to convey this more clearly. do you happen to have some suggested
text handy for us to add?

> 8       Although not covered explicitly in this paper, I think something
> needs to be said about pre-emtion/bumping.  We have extensive experience of
> priority selected pre-emption/bumping schemes.  And this experience leads us
> to have a requirement that we must be able to turn-off any such schemes.
> Why?  Well, it only comes into any significant effect at high utilisations.
> But, because even small changes of loading around the 'congestion knee' can
> cause large swings in behaviour, it is at this time that predicting its
> effects can be most difficult, and a single failure event can cause multiple
> consequential failures as the bumping scheme ripples out.  We don't mind
> dumping 'extra' traffic, but once dumped there is no way we would want this
> to then dump some even lower priority traffic.  However, I clearly would not
> wish to stop anyone wanting such a scheme to try it out and discover its
> usefulness for themselves.  Our requirement therefore is (i) an ability to
> turn-off any bumping based on priority, but (ii) an ability to select the
> priority of restoration post failure between different trails.
> BTW - Although the largest BW trails seem like they should be restored 1st
> (if the most efficient packing density is the sole criterion), this may not
> be the case and we would want to identify trail restoration priority
> irrespective of BW.
> 

I agree with the observation that highest bandwidth does not necessarily
mean highest priority.  Highest bandwidth might be the least critical
application, e.g., file transfer (low priority) vs. voice (high
priority), the bandwidth needs might be reversed.

We will add this discussion in the next revision. BTW, when you state
"an ability to select the priority of restoration post failure between
different trails", do you mean that for all protected connections, the
highest priority protected connection get protected first, second
highest priority get protected second, etc. and that you want the
flexibility to decide what criteria is used to rank the restoration?

> 9       In section 5.3.3 you are hinting at quite an important point
> regarding routing protocols.  That is, the attributes of a routing protocol
> for an OTN will be quite different to that needed for SDH....or indeed IP.
> This leads to the question - do we create one all-embracing routing protocol
> for all technologies (and have lots of extensions and redundancies) or do we
> have different (specifically tailored) routing protocols for different
> technologies?  We can also say the same, and perhaps more strongly, about
> signalling protocols.  And indeed also addressing.....this facet definitely
> requires independent address spaces per distinct layer network even if based
> on the same generic structure.  The key point is here is that not only are
> these control-plane facets 'different' for different layer networks, but
> they are also orthogonal *within* a layer network.....a point which seems to
> get glossed over quite regularly.  This is not to decry any particular
> choice of addressing/signalling/routing protocol combination, just to point
> out that it is not a logical way of reasoning to say that either (i) all
> layers get treated the same or (ii) *if* you choose addressing schema X you
> *must* have signalling protocol Y and you *must* have routing protocol Z.
> Indeed for true CO fabrics like an OTN or SDH, it is very hard to agree to
> arguments that say it must be v4 (or v6) addressing and it must be RSVP
> (indeed it isn't since we also have CR_LDP) and it must be OSPF (and again
> indeed it isn't since we also have IS-IS).....but for the NNI BGP seems the
> only choice.  I have yet to hear what is technically wrong with a
> combination of NSAPs, PNNI signalling and IS-IS/BGP...and on the face of it,
> these would appear far more logical choices given the nature of the beast
> they are controlling;  noting that for S-PVC-like services this would also
> seem like a more 'off-the-shelf' solution.
>

Yes, I agree. theses issues should be viewed independently.  As you
mention, even within routing protocol, there would be differences in
term of the relevant aspects/constraints for route determination.
Whether these differences could be handled via different protocol or
simply as different extensions need to be further discussed. For
example, would the same algorithm be applicable to both SDH and OTN
networks (most likely?)

Do you suggest we expand this section to include discussions of these
points? We would be very happy to work with you on extending the
concepts that you've described.

> 10      In section 5.4.1.5 'actions' on trails are defined.  For a CO
> network with fixed BW selection at trail creation time it is very hard to
> see what a 'modify' action could be....other than perhaps a change of
> restoration priority and/or change of dedicated back-up trail/resource.  If
> there is any notion of (working) BW change here (be it a scalar magnitude
> change, ie same route, or a vector change, ie new route (with or without a
> scalar magnitude change)), it would seem to me that this is really a new
> pair of 'create_new->switch_to_new->delete_old' actions.  I note however
> that this has been marked as TBD, but I think it would help if it was made
> clear that BW changes cannot (IMO) be a single 'modify' action.
> 

Modify command can have different implications depending on what
attributes you're modifying and what capabilities exist in the network.
Two behaviours of modify are: disruptive modification and non-disruptive
modification. For example, in certain cases, you might be able to modify
the CoS of a connection without disruption (simply by adding a backup
path to the original connection, albeit likely not the optimized route),
or if you have LCAS capability, you might be able to increase the
bandwidth of a connection without impacting the existing traffic.

We will revise this to have more discussion regarding use of the modify
command. 

> 11      In section 5.4.3.1 you describe the 4 main stages of
> prot-sw/restoration.  I agree.  But please don't overlook these facts that
> are relevant to the first item of failure detection:
> -       1st, we must identify all failure modes
> -       2nd, we must describe their entry/exit criteria
> -       3rd, we must take correct consequent actions, eg FDI upwards to stop
> alarm storms, BDI backward (if single ended visibility of both directions
> needed), squelch traffic if trail ID mismatch (important to protect customer
> traffic...so this is a sort of security consideration, but it also impacts
> billing etc)
> -       4th, we need to know/define what constitutes up and down states of
> the trail.....this defines the 2 aspects of availability SLA and the QoS
> SLA, where the latter only has meaning once the former is defined (ie only
> valid in up-state) and will generally be based on the defect handling
> covered by points 1st-3rd above.
> See our draft on MPLS OAM (packet level) where we cover the above for an
> example of what is required in the user-plane:
> http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a
> similar approach for the lower transport layers....and note that there
> should be some attempt at metric/objective harmonisation across the layers
> in order for any measurements/SLAs taken/applied at each layer to have some
> cross-layer relative significance.
> 

Yes, these are very valid points. I believe for points 1-3 above, we can
provide a brief description and then refer to existing standards. For
point 4, we will need to extend the document. 

Would you happen to have some text available for us to include in the
next revision?

Regards,

Zhi

Delivery-date: Thu, 15 Mar 2001 07:35:01 -0800
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:31:09 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Fong Liaw <[email-masked]>
Original-CC: [email-masked], [email-masked]
Subject: Re: Question regarding bi-directional connection set up - And Port-ID in  Label object

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

Fong,

>    "An example of bundling is inverse
>    multiplexing, it is useful when a higher order signal needs to be
>    transported over a number of lower order signals, e.g. when a 10Gbps
>    signal must be transported over four 2.5Gbps signals. In that case,
>    the lower order signals must follow exactly the same path, and be
>    treated in the same way, in order to achieve the same characteristics
>    (e.g. delay). To support inverse multiplexing, a request is made to
>    open in parallel and in one single operation several LSPs at the same
>    time."

The above text is not aligned with today's transport layer capabilities
in SDH/SONET. VC-n/STS/VT virtual concatenated signals must NOT follow
exactly the same path, they may do so. The recent defined VC-n-Xv LCAS
(link capacity adjustment scheme) assumes that the group of X VC-n
signals is routed over at least two diverse routes. The need to co-route
all members of the group depends mainly on the differential delay that
the virtual concatenation egress point can accomodate. If it is very
low, you better co-route all signals. Otherwise, co-routing is not
necessary as long as the differential delay is less than the maximum
differential delay that the endpoint can compensate.

Regards,

Maarten
--------------A0B67469376A3D9CECED8179
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------A0B67469376A3D9CECED8179--

Delivery-date: Thu, 15 Mar 2001 07:17:16 -0800
Cc: "[email-masked]'" <[email-masked]>
Date: Thu, 15 Mar 2001 16:13:19 +0100
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Heiles Juergen <[email-masked]>
Original-CC: "[email-masked]'" <[email-masked]>
Subject: Re: SDH/SONET concatenation signal types

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

Juergen,

You hit an area which needs more work... 

VC-n-Xv up to now is associated with co-routing of all X VC-n signals
inthe virtual concatenated group. The introduction of LCAS feature,
requires that the X VC-n signals within a VC-n-Xv signal are NOT
co-routed; the group should be at a minimum split over two diverse
routes. To support this, the VC-n-Xv and the VC-n-Xv LCAS
identifications are not adequatly representing the two (or more)
subgroups of X1 VC-n and X2 VC-n signals (X1 + X2 = X). Therefore, the
VC-n-X was introduced. To set-up a VC-n-Xv LCAS trail, at a minimum a
VC-n-X1 and a VC-n-X2 connection are to be set-up.

As such, we could restrict the set of Types to VC-n-X and at the
endpoints associate one or more VC-n-X's to the VC-n-Xv or VC-n-Xv LCAS.

trail						trail
endpoint					endpoint
VC-n-Xv <==> VC-n-X <==> ..... <==> VC-n-X <==> VC-n-Xv

	       /=> VC-n-X1 <==> .. <==> VC-n-X1 <=\
VC-n-Xv LCAS <=				    	   => VC-n-Xv LCAS
	       \=> VC-n-X2 <==> .. <==> VC-n-X2 <=/

In either case, the LSPs are "VC-n-X" types. 
At the end points of the trail (where you connect the Trail Termination
Point, via matrix connections in the Fabric, to the Link end points) the
additional mapping knowledge is needed.

Being at this point in thinking, I have to ask the question if we should
differentiate between the type of "signal" being transported and the
type of "transport entity" the "signal" is transported over. 

E.g. a "VC-n-Xv LCAS signal" is transported over a "group of X1 VC-n
link connections" and a second "group of X2 VC-n link connections", and
a "VC-n-Xv signal" is transported over a "group of X VC-n link
connections".
And in the simple case, a "VC-n signal" is transported over a "VC-n link
connection".

Regards,

Maarten

Heiles Juergen wrote:
> 
> I have a question on the different SDH/SONET concatenation signal types proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv LCAS, VC-n-X). Defining different signal types makes only sense if a different behaviour is assumed. What is the difference between these types? Is my interpretation correct?
> 
> VC-n-Xv: fixed virtual concatenation; co-routed
> VC-n-Xv LCAS: flexible virtual concatenation; different routes
> VC-n-X: no concatenation; co-routed
> 
> For the later as it could be also used for all other signal types would it be better to introduce some kind of grouping for signal types that have to be co-routed?
> For all the 3 types how would you indication the timeslot, position of the individual VCs as the may/will not use contiguous slots. If different routes are used they even go accross via different interfaces and NEs and you cannot include  them in a single label request.
> 
> Regards
> 
> Juergen
--------------39147044A65038529A52F905
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------39147044A65038529A52F905--

Delivery-date: Thu, 15 Mar 2001 07:11:33 -0800
Date: Thu, 15 Mar 2001 10:06:55 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Fong Liaw <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Question regarding bi-directional connection set up - And Port-ID in  Label object

Fong,

> 
> Regarding how to encode the bi-directionality request,
> Removal of upstream label prevents pre-program the
> cross-connect, not desirable in some situation. So I would
> be in favor of keeping the upstream label object.
> 

I wasn't suggesting to get rid of upstream label (the concept). I proposed to
merge it with suggested label, label set into a single suggested label set
object. I gave reasons in my ID (draft-xu-ccamp-gmpls-sig-reorg-00.txt). A NE
should be able to specify labels of both directions for bi-directional LSP in
optical network. 

Thanks,

Yangguang

Delivery-date: Wed, 14 Mar 2001 14:36:31 -0800
From: Fong Liaw <[email-masked]>
To: 'Yangguang Xu' <[email-masked]>, Fong Liaw <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Question regarding bi-directional connection set up - And Por t-ID in Label object
Date: Wed, 14 Mar 2001 14:38:06 -0800

Yangquang

The one reason I think the port-id/label combination makes
sense is in the bundling/inverse multiplexing example given
in generalized-signaling-02.txt and quoted below.

   "An example of bundling is inverse
   multiplexing, it is useful when a higher order signal needs to be
   transported over a number of lower order signals, e.g. when a 10Gbps
   signal must be transported over four 2.5Gbps signals. In that case,
   the lower order signals must follow exactly the same path, and be
   treated in the same way, in order to achieve the same characteristics
   (e.g. delay). To support inverse multiplexing, a request is made to
   open in parallel and in one single operation several LSPs at the same
   time."   

However, I do not see other mechanisms that allow specify multiple 
links for this purpose. If we only need one set of object, 
the combination of port-id and label is less convincing, IMHO.  
I could also be missing other mechanisms that already address this, 
would appreciate a pointer.

Regarding how to encode the bi-directionality request,
Removal of upstream label prevents pre-program the 
cross-connect, not desirable in some situation. So I would 
be in favor of keeping the upstream label object.

Regards,
-Fong

>  -----Original Message-----
>  From: Yangguang Xu [mailto:[email-masked]]
>  Sent: Wednesday, March 14, 2001 1:31 PM
>  To: Fong Liaw
>  Cc: [email-masked]; [email-masked]
>  Subject: Re: Question regarding bi-directional connection set up
>  
>  
>  Fong,
>  
>  I totally agree with you that bi-directional LSP for 
>  SONET/SDH network is a
>  must. The issue is how to support it.
>  
>  It's useful to see how SONET/SDH NEs' ports are identified 
>  first. It is
>  different from IP router, which always use bi-directional 
>  interface ID (no
>  matter IP addressed or unnumbered). Some vendors identify 
>  the physical port
>  bi-directionally. (Port ID xxx actually indicate two 
>  physical ports, one IN, one
>  OUT). Other vendors identify the physical port 
>  uni-directionally. (transmitter
>  and receiver have different Port ID)
>  
>  This has two implications:
>  
>  (1) Label has directionality
>  (2) For SONET NEs whose port are bi-directionally 
>  identified, no upstream label
>  is needed for bi-directional LSPs
>  
>  Take a step further, Upstream label is not necessary at all. 
>  For optical
>  network, link connection creation direction is independent 
>  from the user traffic
>  flow direction (Here is where IP network is different from 
>  optical network).
>  When  A-----B want to set up a bi-directional link, either A 
>  or B can choose
>  which ports to use.  
>  
>  Regarding whether or not port ID should be part of the 
>  label. I think it should.
>  Port ID can be in the ERO but I don't think that's the good 
>  place because:
>  
>  (1) ERO is the result of source node source routing. It is 
>  in bundle ID
>  granularity. (a bundle ID is assigned to a collection of 
>  physicall ports that
>  share the same routing significance).
>  
>  (2) PortID + channel/subchannel ID is a meaningful unit. 
>  Breaking them into
>  pieces doesn't make sense
>  
>  All details can be found in 
>  
>  http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-
reorg-00.txt

Regards,

Yangguang  

>  > Yangquang
>  >
>  > I read your draft which puts port id in lable object
>  > and probably upstream label as well.  Do you not consider
>  > allowing asymmetric link for a connection a problem,
>  > in particular for SONET/SDH ?
>  >
> I think the rational of providing bi-directional LSP
> really should be enhanced to not just an optimization,
> but a MUST for SONET/SDH etc.

Delivery-date: Wed, 14 Mar 2001 14:27:48 -0800
From: "Fong, Man Wing" <[email-masked]>
To: [email-masked]
Subject: Questions on Protection Flag
Date: Wed, 14 Mar 2001 16:19:52 -0600

I have a few questions that regards to the Protection Flag on the
"draft-ietf-mpls-generalized-signaling-02". Would someone please help me
out?

1. Can the secondary LSP be setup with any other link protection scheme?
2. Can an extra traffic run on the secondary LSP?
3. Can the secondary LSP perform 1:N protection on multiple primary LSPs?
4. Does the secondary LSP has the same LSPID to the primary LSP?

Thanks.

Regards,

Man Wing

Delivery-date: Wed, 14 Mar 2001 13:33:27 -0800
Date: Wed, 14 Mar 2001 16:30:58 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Fong Liaw <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Question regarding bi-directional connection set up

Fong,

I totally agree with you that bi-directional LSP for SONET/SDH network is a
must. The issue is how to support it.

It's useful to see how SONET/SDH NEs' ports are identified first. It is
different from IP router, which always use bi-directional interface ID (no
matter IP addressed or unnumbered). Some vendors identify the physical port
bi-directionally. (Port ID xxx actually indicate two physical ports, one IN, one
OUT). Other vendors identify the physical port uni-directionally. (transmitter
and receiver have different Port ID)

This has two implications:

(1) Label has directionality
(2) For SONET NEs whose port are bi-directionally identified, no upstream label
is needed for bi-directional LSPs

Take a step further, Upstream label is not necessary at all. For optical
network, link connection creation direction is independent from the user traffic
flow direction (Here is where IP network is different from optical network).
When  A-----B want to set up a bi-directional link, either A or B can choose
which ports to use.  

Regarding whether or not port ID should be part of the label. I think it should.
Port ID can be in the ERO but I don't think that's the good place because:

(1) ERO is the result of source node source routing. It is in bundle ID
granularity. (a bundle ID is assigned to a collection of physicall ports that
share the same routing significance).

(2) PortID + channel/subchannel ID is a meaningful unit. Breaking them into
pieces doesn't make sense

All details can be found in 

http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt

Regards,

Yangguang  

>  > Yangquang
>  >
>  > I read your draft which puts port id in lable object
>  > and probably upstream label as well.  Do you not consider
>  > allowing asymmetric link for a connection a problem,
>  > in particular for SONET/SDH ?
>  >
> I think the rational of providing bi-directional LSP
> really should be enhanced to not just an optimization,
> but a MUST for SONET/SDH etc.

Delivery-date: Wed, 14 Mar 2001 06:29:51 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: Three GMPLS related IDs
Date: Wed, 14 Mar 2001 13:29:06 -0000

Hi Yangguang, you wrote 05 March 2001 14:29:
> FYI, three GMPLS related IDs have been submitted.
> 
> Architecture:
>
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
0.txt
>
>Signaling:
>http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-reques
t-01.txt
>http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt
>
>Comments are welcomed.

Here are my observations on the sig-reorg and arch-intra-domain IDs (I could
not open the label-request one):

sig-reorg ID:

1	I noticed that NSAPs are mentioned in 6.2.  Yes, I think this form
of global addressing will be of considerable interest and importance to
several carriers and should be included.  It is something we are currently
looking closely at and almost certainly will require to be supported.

2	The 'connection ID' noted in para 7.2.2 seems to be the same
(similar?) to a trail termination identifier and, as noted, requires global
uniqueness.  I noted that you have this 'TBD' wrt size/format.....this seems
a sensible decision since something larger that 32 bits will surely be
required here.

3	 I was a little unclear regarding the requirement given in the 1st
bullet in para 9.1.  Agree that user and control plane *networks* can (and
will usually) be disjoint....indeed the control-plane network *must* only
take its survivability design cues from the duct network, since only that
layer can define the inherited real disjoint connectivity.  Further, both
the control plane and user plane network need their own OAM....and in the
control plane not only is this for the 'physical transport' aspects, but
also on a per protocol-type, ie the signalling protocol will have different
failure modes to the routing protocol.  One feature that is required
however, is that user-plane failures can map to control-plane actions for
invoking restoration (the reverse of this is clearly not true)...for example
to restore S-PVC-like user-plane trails (see also point 5 below).   So I
would like to see these types of relationship made more clear.
 
4	A further observation wrt the above is that it seems you are
advocating that all failures be conveyed by control-plane message 'events'.
Are you suggesting that (at least) the 3 distinct areas of (i) user-plane
failures, (ii) signalling protocol failures and (iii) routing protocol
failures all get 'merged' into some generic form of event notification?  I
would have thought that one would need notification (and general defect
handling) per protocol type, and that this would be a function of that
protocol only since the failure modes of each would be different (and if one
changes one protocol one would not want to create backwards compatibility
issues with another).

Further, if some aspects of the control-plane fail I would still expect the
user-plane defect handling to carry on as an autonomous function....for
example, the sending of a FDI into client layers to suppress alarm storms
and protect user-plane traffic, eg squelch traffic on misrouting if trail ID
mismatch.  I am not sure we would want to make this low-level action
dependent on a 'healthy control-plane'....and this seems quite important
when one has a server->client adaptation function between 2 different
technologies, eg OTN layer->SDH layer, and where a 'common control-plane'
might not be appropriate across such a (different operator domain)
boundary....a point you indeed make in para 4 in the Arch-intra-domain ID.
Can you please explain the intent of this section more clearly and comment
on the above points, including the network management of the control-plane
....maybe you have some new ideas here that are worth exploring further?

Arch-intra-domain ID:
Note - I like this paper in general, and I guess the reason for this is that
several operators have input (requirements) to it and it is not just sourced
from vendors.  

5	A control-plane for CO transport networks is not a new idea.
Indeed, the original designers of SDH (and esp my BT colleague Andy Reid and
Mike Sexton now of Alcatel) tried to do this for SDH about 12 years
ago....maybe a bit ahead of its time then.  However, the key point I wanted
to make here is that simply automating the control-plane is not necessarily
the key issue for improving the speed of provision (this is certainly true
for us).....it is all the associated OSS/service-suround processes (eg order
handling, testing (which is more than a quick LMP-like connectivity
verification), billing, etc) that go along with this to create a service.
These points are also very well made in section 3 of
draft-bms-optical-sdhsonet-mpls-control-frmwrk-00.txt I have noted.

BTW - we have far more interest in S-PVC equivalent services than SVC
equivalent services, at least initially.  I can't speak for other carriers
but I would be surprised if they thought otherwise.  The advantages of
S-PVCs come from the fact that there is no need:
-	to develop new billing systems
-	no new interfaces to billing systems
-	no need to solve all the naming issues
-	low risk security issues
-	solve all the call admission control mechanisms
-	etc
Yet S-PVCs immediately open up the possibility of much faster provisioning;
though in BT's case what we have in our network management systems already
is pretty fast in itself.  And as a subset of the functions that are needed
to implement a switched service it will obviously be easier to implement.

Thinking about the further concerns a carrier would have to address in a
connection oriented switched-network, there needs to be a consideration of
blocking probability and users having connection requests refused, ie a GoS
metric. The result is that transport networks currently designed around high
utilisation with long-holding connections need to be redesigned around
ensuring a large enough pool of free capacity.  So, in addition to having to
address the above issues up-front with SVC-like services, carriers would
also be forced to define a 'erlang/pricing model' for something akin to a
Gbit PSTN!  Depending upon the number of circuits and the distribution of
traffic holding times it may not be possible to apply simply erlang theory
as is, but rather some modifications will be required.....and the demand
model will obviously be an interdependent function of the pricing model.  

6	Noted the point in para 4.2 regarding ENE 'having to maintain
source/sink LSP inventory', but the SNE also needs to maintain its
server->client layer adaptation mappings....so that on failure the correct
FDI information can be sent forward into all affected clients (and this
process should recurse for clients of those clients, etc).

7	In section 5.3 on path selection source (ERO) and hop-hop routing
are compared.  However, the biggest advantage of source routing is not noted
strongly enough.....and that is the fact that one does not need to wait
until a failure to calculate an alternative route from the link-state
database.  For very important routes one can pre-calculate an alternative
path and reserve resources, so restoration is very fast.  This leads me to
the next point here.

8	Although not covered explicitly in this paper, I think something
needs to be said about pre-emtion/bumping.  We have extensive experience of
priority selected pre-emption/bumping schemes.  And this experience leads us
to have a requirement that we must be able to turn-off any such schemes.
Why?  Well, it only comes into any significant effect at high utilisations.
But, because even small changes of loading around the 'congestion knee' can
cause large swings in behaviour, it is at this time that predicting its
effects can be most difficult, and a single failure event can cause multiple
consequential failures as the bumping scheme ripples out.  We don't mind
dumping 'extra' traffic, but once dumped there is no way we would want this
to then dump some even lower priority traffic.  However, I clearly would not
wish to stop anyone wanting such a scheme to try it out and discover its
usefulness for themselves.  Our requirement therefore is (i) an ability to
turn-off any bumping based on priority, but (ii) an ability to select the
priority of restoration post failure between different trails.
BTW - Although the largest BW trails seem like they should be restored 1st
(if the most efficient packing density is the sole criterion), this may not
be the case and we would want to identify trail restoration priority
irrespective of BW.

9	In section 5.3.3 you are hinting at quite an important point
regarding routing protocols.  That is, the attributes of a routing protocol
for an OTN will be quite different to that needed for SDH....or indeed IP.
This leads to the question - do we create one all-embracing routing protocol
for all technologies (and have lots of extensions and redundancies) or do we
have different (specifically tailored) routing protocols for different
technologies?  We can also say the same, and perhaps more strongly, about
signalling protocols.  And indeed also addressing.....this facet definitely
requires independent address spaces per distinct layer network even if based
on the same generic structure.  The key point is here is that not only are
these control-plane facets 'different' for different layer networks, but
they are also orthogonal *within* a layer network.....a point which seems to
get glossed over quite regularly.  This is not to decry any particular
choice of addressing/signalling/routing protocol combination, just to point
out that it is not a logical way of reasoning to say that either (i) all
layers get treated the same or (ii) *if* you choose addressing schema X you
*must* have signalling protocol Y and you *must* have routing protocol Z.
Indeed for true CO fabrics like an OTN or SDH, it is very hard to agree to
arguments that say it must be v4 (or v6) addressing and it must be RSVP
(indeed it isn't since we also have CR_LDP) and it must be OSPF (and again
indeed it isn't since we also have IS-IS).....but for the NNI BGP seems the
only choice.  I have yet to hear what is technically wrong with a
combination of NSAPs, PNNI signalling and IS-IS/BGP...and on the face of it,
these would appear far more logical choices given the nature of the beast
they are controlling;  noting that for S-PVC-like services this would also
seem like a more 'off-the-shelf' solution.

10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
network with fixed BW selection at trail creation time it is very hard to
see what a 'modify' action could be....other than perhaps a change of
restoration priority and/or change of dedicated back-up trail/resource.  If
there is any notion of (working) BW change here (be it a scalar magnitude
change, ie same route, or a vector change, ie new route (with or without a
scalar magnitude change)), it would seem to me that this is really a new
pair of 'create_new->switch_to_new->delete_old' actions.  I note however
that this has been marked as TBD, but I think it would help if it was made
clear that BW changes cannot (IMO) be a single 'modify' action.

11	In section 5.4.3.1 you describe the 4 main stages of
prot-sw/restoration.  I agree.  But please don't overlook these facts that
are relevant to the first item of failure detection:
-	1st, we must identify all failure modes
-	2nd, we must describe their entry/exit criteria
-	3rd, we must take correct consequent actions, eg FDI upwards to stop
alarm storms, BDI backward (if single ended visibility of both directions
needed), squelch traffic if trail ID mismatch (important to protect customer
traffic...so this is a sort of security consideration, but it also impacts
billing etc)
-	4th, we need to know/define what constitutes up and down states of
the trail.....this defines the 2 aspects of availability SLA and the QoS
SLA, where the latter only has meaning once the former is defined (ie only
valid in up-state) and will generally be based on the defect handling
covered by points 1st-3rd above.
See our draft on MPLS OAM (packet level) where we cover the above for an
example of what is required in the user-plane:
http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt We need a
similar approach for the lower transport layers....and note that there
should be some attempt at metric/objective harmonisation across the layers
in order for any measurements/SLAs taken/applied at each layer to have some
cross-layer relative significance.

neil

Envelope-to: [email-masked]
Delivery-date: Wed, 14 Mar 2001 01:42:11 -0800
Date: Wed, 14 Mar 2001 01:39:30 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CCAMP Agenda

One more once.

Sorry, Dimitri, we'll all have to come and listen to your talk
on Optical Rings in IPORPR.

Tom, there's only one round now, so work on those biceps!

Vijay & Kireeti
---------------

CCAMP Agenda

Tuesday, Afternoon Session III
------------------------------

Intro & Agenda bashing					(10 min)

Closed-Loop Automatic Link Provisioning, Lily Cheng	(10 min)
	draft-ietf-ipo-te-link-provisioning-00.txt

Using Two Octets for Bandwidth Values, Qingming Ma	(5 min)
	draft-ma-ospf-isis-te-00.txt

Tunnel Tracing, Ron Bonica				(10 min)
	draft-bonica-tunneltrace-01.txt
	draft-bonica-tunproto-00.txt

OAM Functionality for MPLS Networks, Shahram Davari	(10 min)
	draft-harrison-mpls-oam-00.txt

Crankback Routing Extensions, Atsushi Iwata		(10 min)
	draft-iwata-mpls-crankback-00.txt

Lightpath Route Extensions, Murali Krishnaswamy		(5 min)
	draft-krishnaswamy-optical-rsvp-extn-00.txt

Wednesday, Morning Session
--------------------------

More agenda bashing					(5 min)

Signaling for Generalized MPLS, Lou Berger		(15 min)
	draft-generalized-sig...

Enhanced GMPLS Signaling, Papadimitriou Dimitri 	(10 min)
	draft-papadimitriou-enhanced-lsps-02.txt
	draft-fontana-gmpls-control-g709-00.txt

Enhanced GMPLS Signaling, Yangguang Xu, Zhi-Wei Lin	(15 min)
	draft-xu-ccamp-gmpls-sig-reorg-00.txt
	draft-lin-ccamp-ipo-common-label-request-00.txt

Restoration, Papadimitriou Dimitri 			(15 min)
	draft-pbh-packet-optical-escalation-00.txt
	draft-many-optical-restoration-00.txt
	draft-many-inference-srlg-00.txt

Signaling for Fast Restoration, Bala Rajagopalan 	(10 min)
	draft-bala-restoration-signaling-00.txt

Generalized MPLS Recovery Mechanisms, Jonathan Lang	(15 min)
	draft-lang-ccamp-recovery-00.txt

Arm-wrestling						(5 min)

GMPLS Architecture, Eric Mannie				(10 min)
	draft-many-gmpls-architecture-00.txt

GMPLS Architecture, Yangguang Xu			(5 min)
	draft-xu-ccamp-gmpls-arch-intra-domain-00.txt

CCAMP Requirements, Dave Walker				(5 min)
	draft-walker-ccamp-req-00.txt

LMP, Jonathan Lang					(10 min)
	draft-ietf-mpls-lmp-02.txt

WDM LMP, Andre Fredette 				(15 min)
	draft-fredette-lmp-wdm-01.txt

LMP MIB, Martin Dubuc					(10 min)
	draft-dubuc-mpls-lmp-mib-01.txt

NTIP, Osama Aboul-Magd					(5 min)
	draft-sahay-ccamp-ntip-00.txt

Delivery-date: Tue, 13 Mar 2001 15:47:56 -0800
Date: Tue, 13 Mar 2001 18:47:56 -0500
From: Dave Walker <[email-masked]>
Reply-To: [email-masked]
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP Agenda

I can't wait until next week to start the agenda bashing...

Do you think it would be possible to squeeze in a brief discussion
of our requirements draft?  Either it's totally out-to-lunch and we
need a good scolding, or it provides a useful basis for framing the
good protocol work that the group is doing.

http://www.ietf.org/internet-drafts/draft-walker-ccamp-req-00.txt

Regards,

Dave Walker
SS8 Networks
Ottawa, Canada

Kireeti Kompella wrote:
> 
> Hi All,
> 
> Here it is.
> 
> Kireeti & Vijay.
> -------
> 
> CCAMP Agenda
> 
> Tuesday, Afternoon Session III
> ------------------------------
> 
> Intro & Agenda bashing                                  (10 min)
> 
> Closed-Loop Automatic Link Provisioning, Lily Cheng     (10 min)
>         draft-ietf-ipo-te-link-provisioning-00.txt
> 
> Using Two Octets for Bandwidth Values, Qingming Ma      (5 min)
>         draft-ma-ospf-isis-te-00.txt
> 
> Tunnel Tracing, Ron Bonica                              (10 min)
>         draft-bonica-tunneltrace-01.txt
>         draft-bonica-tunproto-00.txt
> 
> OAM Functionality for MPLS Networks, Shahram Davari     (10 min)
>         draft-harrison-mpls-oam-00.txt
> 
> Crankback Routing Extensions, Atsushi Iwata             (10 min)
>         draft-iwata-mpls-crankback-00.txt
> 
> Hybrid Mesh-Ring Optical Networks, Papadimitriou Dimitri (5 min)
> 
> Wednesday, Morning Session
> --------------------------
> 
> More agenda bashing                                     (5 min)
> 
> Signaling for Generalized MPLS, Lou Berger              (15 min)
>         draft-generalized-sig...
> 
> Enhanced GMPLS Signaling, Papadimitriou Dimitri         (10 min)
>         draft-papadimitriou-enhanced-lsps-02.txt
>         draft-fontana-gmpls-control-g709-00.txt
> 
> Enhanced GMPLS Signaling, Yangguang Xu, Zhi-Wei Lin     (10 min)
>         draft-xu-ccamp-gmpls-sig-reorg-00.txt
>         draft-lin-ccamp-ipo-common-label-request-00.txt
> 
> Arm-wrestling, round 1                                  (5 min)
> 
> GMPLS Architecture, Eric Mannie                         (10 min)
>         draft-many-gmpls-architecture-00.txt
> 
> GMPLS Architecture, Yangguang Xu                        (10 min)
>         draft-xu-ccamp-gmpls-arch-intra-domain-00.txt
> 
> Restoration, Papadimitriou Dimitri                      (15 min)
>         draft-pbh-packet-optical-escalation-00.txt
>         draft-many-optical-restoration-00.txt
>         draft-many-inference-srlg-00.txt
> 
> Signaling for Fast Restoration, Bala Rajagopalan        (10 min)
>         draft-bala-restoration-signaling-00.txt
> 
> Generalized MPLS Recovery Mechanisms, Jonathan Lang     (10 min)
>         draft-lang-ccamp-recovery-00.txt
> 
> Arm-wrestling, round 2                                  (5 min)
> 
> LMP, Jonathan Lang                                      (15 min)
>         draft-ietf-mpls-lmp-02.txt
> 
> WDM LMP, Andre Fredette                                 (15 min)
>         draft-fredette-lmp-wdm-01.txt
> 
> LMP MIB, Martin Dubuc                                   (10 min)
>         draft-dubuc-mpls-lmp-mib-01.txt

Envelope-to: [email-masked]
Delivery-date: Tue, 13 Mar 2001 14:50:07 -0800
Date: Tue, 13 Mar 2001 14:48:13 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP Agenda

Hi All,

Here it is.

Kireeti & Vijay.
-------

CCAMP Agenda

Tuesday, Afternoon Session III
------------------------------

Intro & Agenda bashing					(10 min)

Closed-Loop Automatic Link Provisioning, Lily Cheng	(10 min)
	draft-ietf-ipo-te-link-provisioning-00.txt

Using Two Octets for Bandwidth Values, Qingming Ma	(5 min)
	draft-ma-ospf-isis-te-00.txt

Tunnel Tracing, Ron Bonica				(10 min)
	draft-bonica-tunneltrace-01.txt
	draft-bonica-tunproto-00.txt

OAM Functionality for MPLS Networks, Shahram Davari	(10 min)
	draft-harrison-mpls-oam-00.txt

Crankback Routing Extensions, Atsushi Iwata		(10 min)
	draft-iwata-mpls-crankback-00.txt

Hybrid Mesh-Ring Optical Networks, Papadimitriou Dimitri (5 min)

Wednesday, Morning Session
--------------------------

More agenda bashing					(5 min)

Signaling for Generalized MPLS, Lou Berger		(15 min)
	draft-generalized-sig...

Enhanced GMPLS Signaling, Papadimitriou Dimitri 	(10 min)
	draft-papadimitriou-enhanced-lsps-02.txt
	draft-fontana-gmpls-control-g709-00.txt

Enhanced GMPLS Signaling, Yangguang Xu, Zhi-Wei Lin	(10 min)
	draft-xu-ccamp-gmpls-sig-reorg-00.txt
	draft-lin-ccamp-ipo-common-label-request-00.txt

Arm-wrestling, round 1					(5 min)

GMPLS Architecture, Eric Mannie				(10 min)
	draft-many-gmpls-architecture-00.txt

GMPLS Architecture, Yangguang Xu			(10 min)
	draft-xu-ccamp-gmpls-arch-intra-domain-00.txt

Restoration, Papadimitriou Dimitri 			(15 min)
	draft-pbh-packet-optical-escalation-00.txt
	draft-many-optical-restoration-00.txt
	draft-many-inference-srlg-00.txt

Signaling for Fast Restoration, Bala Rajagopalan 	(10 min)
	draft-bala-restoration-signaling-00.txt

Generalized MPLS Recovery Mechanisms, Jonathan Lang	(10 min)
	draft-lang-ccamp-recovery-00.txt

Arm-wrestling, round 2					(5 min)

LMP, Jonathan Lang					(15 min)
	draft-ietf-mpls-lmp-02.txt

WDM LMP, Andre Fredette 				(15 min)
	draft-fredette-lmp-wdm-01.txt

LMP MIB, Martin Dubuc					(10 min)
	draft-dubuc-mpls-lmp-mib-01.txt

Delivery-date: Tue, 13 Mar 2001 09:52:05 -0800
Date: Tue, 13 Mar 2001 12:55:02 -0500
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: CCAMP agenda

         Have your posted the CCAMP agenda?

         --tom

>Thanks to all of you who have submitted drafts and indicated their
>interest in speaking at the CCAMP WG in the upcoming IETF.  Vijay
>and I will try really hard to accommodate all those requests that
>we feel belong in CCAMP.  We'll send out the agenda as soon as we
>can.
>
>Since there are a lot of requests, it seems appropriate to waft in
>your direction a friendly reminder (as Vijay and I have ourselves
>been reminded by friendly folks on the IESG).  IETF veterans, please
>indulge us.
>
>1) Please do not make presentations.  Time slots will be short;
>    assume that attendees have read the draft.  If this is a first
>    draft, hit the highlights.  If this has been discussed before,
>    emphasize the deltas.
>2) Keep the talk technical.  Focus on those aspects that are hard
>    to get across with the written word.  Draw pictures, wave hands,
>    give the big picture.
>3) If issues have been raised on the mailing list, address them.  If
>    new issues come up, follow up on the mailing list.
>4) Leave time for questions/discussion.
>
>For those attending, PLEASE read the drafts.  Yes, there are a
>lot of them out there.  However, it will greatly increase your
>understanding, appreciation, blah, blah, blah.  Okay, no nagging.
>Just read the drafts.  (Lou, no comments please :-))
>
>Kireeti.

Delivery-date: Tue, 13 Mar 2001 06:37:02 -0800
To: Ron Bonica <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: FW: Questions about tunneltrace 
Reply-To: [email-masked]
Date: Tue, 13 Mar 2001 09:35:52 -0500
From: Eric Rosen <[email-masked]>

Ron> We  are  trying  to  avoid  the trap  into  which  draft-ietf-mpls-icmp
Ron> fell. 

Political incorrectness?

Ron> The basic  problem with that  draft was that  it looked inside  an MPLS
Ron> payload,  found and  IP header,  and  assumed that  the source  address
Ron> specified by that IP header  was meaningful within the LSRs layer three
Ron> routing context.

Ron> For example, lets  say that the source address is  10.1.1.1 and the LSR
Ron> has a route to 10.1.1.1.  Is the  host to which the LSR has a route the
Ron> same one the originated the datagram?  If the LSR does not have a route
Ron> to 10.1.1.1, it sends the ICMP  message to the egress LSR.  Is the host
Ron> to which  the egress LSR  has a route  the same one the  originated the
Ron> datagram?

RFC3032 describes a pretty simple  procedure for getting the ICMP message to
the egress  of the outermost tunnel  before routing it back  to the original
source.  Chances  are rather high that  the address means the  same thing at
both ends of the outermost tunnel.

But there is an advantage of sending the response to the ingress rather than
the egress.  This has  to do with the fact that if  one of the inner tunnels
is broken, the RFC3032 procedure may  not get the response to the egress, in
which case  responses never get back  to the original source,  and the trace
doesn't tell  you anything that  you didn't already know  (i.e., something's
broken).  So having a procedure for  getting back to the tunnel ingress does
seem like a good idea.  

I  would  question  though  whether  it  is  really  necessary  to  get  the
traceresponse  back to  the OUTERMOST  tunnel ingress.   I think  that  if a
traceresponse comes from the middle of  a tunnel, it is probably good enough
to get it back to the  ingress of the immediately containing tunnel, even if
this is an interior tunnel.

True, this won't work if there is  no route between the enduser who is doing
the trace and the ingress of  the interior tunnel.  However, I think that if
there is no such route, that's  because the owner of the tunnel ingress does
not want  the enduser to  be able to  send packets to  it.  GTTP opens  up a
security hole here.  Yes, GTTP provides an authentication mechanism that can
be used to close the hole.  But  unless there is good reason to believe that
service providers will often want to  leave this hole open, we might as well
just nail  it closed; this would  result in a  significant simplification of
the protocol.

To trace a tunnel, the enduser would always have to direct the traceprobe to
the ingress of  THAT tunnel.  The traceprobe packet  which the ingress sends
through the  tunnel could itself carry  the address of the  ingress, so that
the traceresponse  could come  back.  Then  there would be  no need  for ANY
router to maintain ANY state for a traceprobe.

I would  also suggest that when a  traceresponse is generated by  a node, it
contain  ALL the  information that  the node  would have  used to  route the
arriving  probe, had  the probe's  TTL not  expired.  To  make sure  ALL the
necessary information is included,  we should probably include an identifier
for the probe's incoming  interface, as well as the full set  of MPLS and IP
headers.  Call this a "forwarding information object". 

The original traceprobe sent by an  enduser should also be able to contain a
forwarding information  object.  This would  enable you to trace,  e.g., the
path of a  packet which arrives on a particular  interface with a particular
label stack. 

Once  you've  received  a  traceresponse  from every  node  along  the  path
(excluding nodes within tunnels), you need  to send a new traceprobe to each
of those nodes.  The traceprobe sent to a particular node should contain the
forwarding information  object returned  in that node's  traceresponse.  The
semantics  would be "if  this is  the forwarding  information for  a packet,
would you put the packet in a tunnel?  if so, please initiate a trace of the
tunnel".   Since a particular  node may  be the  ingress to  multiple nested
tunnels, we  need include a tunnel depth  number, but I don't  think we need
anything as complicated as the hop object.

It's still  not clear  to me  though that this  produces something  which is
significantly  better  than  a  pseudo-trace procedure  which  examines  the
control plane exclusively. 

Delivery-date: Tue, 13 Mar 2001 05:20:44 -0800
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SDH/SONET concatenation signal types
Date: Tue, 13 Mar 2001 14:16:51 +0100

I have a question on the different SDH/SONET concatenation signal types proposed in draft-lin-ccamp-ipo-common-label-request (e.g. VC-n-Xv, VC-n-Xv LCAS, VC-n-X). Defining different signal types makes only sense if a different behaviour is assumed. What is the difference between these types? Is my interpretation correct?

VC-n-Xv: fixed virtual concatenation; co-routed
VC-n-Xv LCAS: flexible virtual concatenation; different routes
VC-n-X: no concatenation; co-routed

For the later as it could be also used for all other signal types would it be better to introduce some kind of grouping for signal types that have to be co-routed?
For all the 3 types how would you indication the timeslot, position of the individual VCs as the may/will not use contiguous slots. If different routes are used they even go accross via different interfaces and NEs and you cannot include  them in a single label request.

Regards

Juergen

Delivery-date: Fri, 09 Mar 2001 08:59:21 -0800
From: Olle Pers <[email-masked]>
To: "'Raju Venkatraman'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS, SDH/SONET Question
Date: Fri, 9 Mar 2001 17:56:25 +0100 

*  -----Original Message-----
*  From: Raju Venkatraman [mailto:[email-masked]]
*  Sent: 9 mars 2001 00:39
*  To: [email-masked]
*  Subject: GMPLS, SDH/SONET Question
*  
*  
*  Hi,
*  
*  I have one doubt on GMPLS:
*  
*     Can there any scenario in which GMPLS enabled OXC/optical switch
*     extracts a wavelength (for wavelength switching) and extract the
*     SDH/SONET framing (for VC-x switching) on another wavelength in
*     the same incoming fiber? Should a generic (encompassing as many
*     requirements as possible) GMPLS control plane implementation
*     take care of such scenario? 
*  
*     Pls. help.
*  
*  Thanks in advance.
*  Raju
*  

Hi, 

Such an hybrid lambda-SDH crossconnect could fit well in some network
designs, replacing a co-located DXC + OXC pair. Similar products have been
announced.  
 
A "generic control plane" should be able to handle a network that includes
such hybrids, among pure OXCs, pure DXCs, and packet switches. 

So, if GMPLS wants to be (the signaling part of) that control plane, it
should support such a scenario. 

Do you have doubts that current GMPLS can handle this? 

Olle Pers
Telia
Sweden

Delivery-date: Thu, 08 Mar 2001 08:15:45 -0800
From: "Mannie, Eric" <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-many-gmpls-architecture-00.txt
Date: Thu, 8 Mar 2001 17:12:35 +0100 

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

FYI

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 1:28 PM
Subject: I-D ACTION:draft-many-gmpls-architecture-00.txt

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

	Title		: Generalized Multi-Protocol Label Switching (GMPLS)

                          Architecture
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-many-gmpls-architecture-00.txt
	Pages		: 37
	Date		: 27-Feb-01
	
Future data and transmission networks will consist of elements
such as routers, switches, DWDM systems, Add-Drop Multiplexors
(ADMs), photonic cross-connects (PXCs) or optical cross-
connects (OXCs), etc that will use Generalized MPLS (GMPLS) to
dynamically provision resources and to provide network
survivability using protection and restoration techniques.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-many-gmpls-architecture-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-many-gmpls-architecture-00.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-many-gmpls-architecture-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_000_01C0A7EA.96813590
Content-Type: message/rfc822

To: 
Subject: 
Date: Thu, 8 Mar 2001 17:12:43 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C0A7EA.96813590"

------_=_NextPart_002_01C0A7EA.96813590
Content-Type: text/plain

------_=_NextPart_002_01C0A7EA.96813590
Content-Type: application/octet-stream;
	name="ATT69309.txt"
Content-Disposition: attachment;
	filename="ATT69309.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-many-gmpls-architecture-00.txt

------_=_NextPart_002_01C0A7EA.96813590
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-many-gmpls-architecture-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C0A7EA.96813590--

------_=_NextPart_000_01C0A7EA.96813590--

Delivery-date: Wed, 07 Mar 2001 16:07:37 -0800
Date: Wed, 07 Mar 2001 19:05:17 -0500
To: [email-masked]
From: "Andre N. Fredette" <[email-masked]>
Subject: I-D ACTION:draft-fredette-lmp-wdm-01.txt

We plan to discuss this draft at the CCAMP meeting.  This version is an 
update to the one presented in the MPLS working group last time.

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-fredette-lmp-wdm-01.txt
>Date: Wed, 07 Mar 2001 07:44:52 -0500
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Link Management Protocol (LMP) for WDM 
> Transmission
>                           Systems
>         Author(s)       : A. Fredette et al.
>         Filename        : draft-fredette-lmp-wdm-01.txt
>         Pages           : 183
>         Date            : 06-Mar-01
>
>A suite of protocols is being developed in the IETF to allow
>networks consisting of photonic switches (PXCs), optical
>crossconnects (OXCs), routers, switches, DWDM transmission systems,
>and optical add-drop multiplexors (OADMs) to use an MPLS-based
>control plane to dynamically provision resources and to provide
>network survivability using protection and restoration techniques.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-fredette-lmp-wdm-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-fredette-lmp-wdm-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-fredette-lmp-wdm-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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-fredette-lmp-wdm-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-fredette-lmp-wdm-01.txt>

Delivery-date: Mon, 05 Mar 2001 15:07:21 -0800
Date: Mon, 05 Mar 2001 17:52:13 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: FW: Questions about tunneltrace
To: [email-masked], [email-masked]
Cc: [email-masked]

Eric, Yakov,

The following is a reponse to both of your postings. Comments inline.....

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, March 02, 2001 11:24 AM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: FW: Questions about tunneltrace
>
>
>
> Ron> Strictly  speaking,  I  am  not  tracing through  the
> user-plane,  but
> Ron> bouncing back and forth between the user-plane and the
> control-plane. I
> Ron> have no choice but to do so.
>
> Perhaps.   But then your  requirement of  not relying  on the
> control plane
> needs to be removed.

Point taken. I will remove it in the next version of the requirements draft.

>
> Once that requirement is removed, though, various other
> alternatives suggest
> themselves, such  as using  SNMP to  get the information  from
> the  MIBs, or
> having a special "trace packet" that accumulates the path
> information inside
> itself, and  then returns the entire trace  in one packet back
> to the user.
> It would be useful  to see some discussion of why the  proposal
> in the draft
> is better than these alternatives.  (Note  that I'm not saying
> that it isn't
> better than these alternatives.)
>

Again, point taken. I will add a section concerning alternative approaches
in the next version of the protocol specification.

> Ron> Isn't that the kind of layer violation that we are trying to avoid?
>
> Can you articulate this layer violation?
>

I will try. Somebody please jump in if I misspeak myself.

We are trying to avoid the trap into which draft-ietf-mpls-icmp fell. The
basic problem with that draft was that it looked inside an MPLS payload,
found and IP header, and assumed that the source address specified by that
IP header was meaningful within the LSRs layer three routing context.

For example, lets say that the source address is 10.1.1.1 and the LSR has a
route to 10.1.1.1. Is the host to which the LSR has a route the same one the
originated the datagram? If the LSR does not have a route to 10.1.1.1, it
sends the ICMP message to the egress LSR. Is the host to which the egress
LSR has a route the same one the originated the datagram?

GTTP dances around this issue by relaying the response through the head end
of each tunnel in the stack. But the price that it pays is to bounce back
and forth between the data and control planes.

(I hope that I haven't mangled the argument too badly.)

                                                  Ron
>
>
>

Delivery-date: Mon, 05 Mar 2001 06:30:04 -0800
Date: Mon, 05 Mar 2001 09:28:43 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked], [email-masked], [email-masked]
Subject: FYI: Three GMPLS related IDs

Hello All,

FYI, three GMPLS related IDs have been submitted.

Architecture:
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-00.txt

Signaling:
http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-request-01.txt
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt

Comments are welcomed.

Thanks,

Yangguang

Delivery-date: Mon, 05 Mar 2001 03:30:38 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Standards for IP stats collection? (corrected)
Date: Mon, 5 Mar 2001 11:09:47 -0000 

Hi Richard, thanks for your comments....my response below:

<snipped>
> I think (but am not quite sure from your wording) that you 
> find the goal of
> separating
> failure analysis at the physical/link layers from 
> availabiltiy & QoS at the IP
> layer unattainable.
NH=> Sorry I was not clear Richard.  One can separate availability and QoS
for CO entities.  How easy this is in practice depends on whether one has
started with a clear architectural understanding of the nature of the
problem, and thus ensures that functional measurements (of defects) are
based on pragmatic OAM tools, cf how difficult availability measurements are
for ATM (ie after 10 years study this could not be done.....since it was
based on some fundamental architectural errors of judgement at the outset
(and BTW too much emphasis on the I.356 QoS metric wish-list that would
never be cost-effective to measure) that made it too complex to solve) vs
what is in our recent MPLS draft.
With a CNLS layer the problem is not clear-cut due to the intrinsic
dependency of the user-plane on a stable/valid control-plane.....this is
*not* necessarily a weakness, nor should it be viewed as such (indeed it is
a strength for *certain* types of traffic).  The simple fact is that CO
networks and CNLS networks behave differently.  In the former we have the
opportunity to separate availability and QoS and in the latter we can't (at
least within the network, as ad hoc partitions of some HRX - hypothetical
reference connection) except on an end-end basis.  The basic behaviour
difference here is that on failure:
-	CO fabrics only affect the customers whose traffic is carried by the
failed trail(s), ie this traffic dies, and other non-affected customer
traffic sees no avail/QoS deterioration;
-	CNLS fabrics mutate failures into QoS hits since the overall traffic
demand is not constrained post-failure.....DiffServ then skews this
relationship (noting that there is no relationship between a traffic's
survivability requirements and its up-state QoS requirements, eg voice must
go EF for delay/jitter transfer requirements, but whether a *given* voice
traffic source is mission critical (ie must survive on failure) or not
cannot be inferred from the DS codepoints alone.  This can be expanded to AF
classes, ie there is no QoS/survivabiity relationship.

> My view is that these functions of network state are 
> inter-related and to seek
> to make them
> independent is quixotic.
> Here is a view:
> The various layers below IP will have outage phenomena. These 
> are measurable,
> albeit imperfectly.
> Both control-plane and data-plane will have outage phenomena. 
> These are
> measurable, I think.
NH=> Yes they are.  The key issue is whether one affects the other.  In CNLS
fabrics this is an intrinsic behaviour, in CO fabrics it does not have to
be.  For example, in plain IP the user-plane is effectively 'dead' for as
long as the IGP is incorrectly converged (eg post failure), whereas in
ER-MPLS or GMPLS (for example) there can be disjoint routed
user/control-planes (indeed, in GMPLS the control-plane will use a logically
seperate network from the user-plane, whose only survivability design cues
*must* come from the 'duct' layer), and in particular a key operator
requirement here is that failures of the control-plane *must not* affect the
user-plane.

> ("Outage" includes route stability loss during convergence, 
> for conventional IP
> routing. Ex.: Vern Paxsons 1996 paper on internet routing behavior.)
NH=> Yes, but that is not the whole story.  It is the fact that
post-failure/re-convergence there is no reduction in the traffic offered,
but rather a sharing of reduced network resource over the same traffic
demand.  It is this fact (coupled to the harder (to measure) initial outage
event) that creates a real difficulty of separation of availability and QoS
specification.  Indeed, this looks quite problematical for VPNs *if* we do
not have the ability to decouple VPN topological/resource survival (of LSPs)
from basic forwarding treatment (of packet aggregates from multiple
different VPNs).
 
> MPLS will have separate, but commensurate outage behavior 
> (despite fast
> reroute).
NH=> True for LSPs based on an IGP, eg LDP.  Not necessarily true for
ER-LSPs based on RSVP or CR_LDP.  And certainly not true for GMPLS when we
consider SDH/OTN fabrics.

> All of this feeds into the analysis of QoS at the IP layerand above.
NH=> True....but I would put it a different way.  A client layer network
*inherits* the performance of *all* the server layers below it...and then
adds its own performance impairments, which are only relevant to the client
layer considered.  This relationship recurses upwards.  The inheritance is
not linear in some cases, eg a us/ms error event in SDH can create several
seconds of outage in some client layers.....the actual behaviour depends on
the robustness of the client layer framing, and especially the
server->client adaptation functions, eg if ATM was a client of SDH then one
can create a loss of cell delineation event which can lead to a variable ATM
layer outage depending on what OAM functions are active (and in some cases
user traffic activity).

> QoS is both an IP connection availability (reachability) 
> issue, as well as a
> packet loss, delay etc. issue.
> Up/down state transitions can generally cause both (a) 
> reachability loss, and
> (b) data loss.
> So, *given adequate measurement and characterization* of the 
> phenomena,
> I don't see it as impossible. If this is naive, why?
NH=> Yes you can measure both IP availability and QoS but you can do so only
reliably/consistently at the end-points, ie the true source/sink of the IP
'connection' one is considering.  We cannot partition that end-end IP
'connection' since any arbitrary partitions we create cannot be regarded as
permanent, ie the routing can change post-failure (or indeed if new routes
are injected in the IGP/BGP).  This makes the definition of a global HRX
with end-end metric/objectives apportioned (on some basis, eg proportional
to length) amongst consitutent subnetwork partitions impossible....thus we
cannot realistically relate network availability/QoS to individual customers
on a subnetwork/partitioned basis. 
> 
> >
> > 3       Now we can consider QoS.....but be careful.  It 
> costs money to
> > measure/collect/process (in OSS) these....every technology 
> I have been
> > involved with has started with a large metric wish-list 
> that gets whittled
> > down to something more pragmatic later.  My advice is that 
> these should be
> > of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for
> > trouble-shooting as needed by operational people, or the continuous
> > measurement of 'important' paths, and (ii) general network 
> population
> > sampling (to get overall network trends and spot latent anomolous
> > behaviour).
> 
> Yes. The problem as I see it here is that many of the 
> measurement stds impose
> invasive problems on the network. RMON and general polling 
> via SNMP are
> examples.
NH=> The overriding concern I have as an operator is the measurement
cost/benefit ratio.  I have seen (too many times) over-enthusiastic and
unrealistic QoS measurement requirements stated (usually by those who do not
have to pay for it!) *and* a lack of attention to what is really important
to operators/customers, eg is it 'working'? can we detect/diagnose defects?
can we clearly articulate/measure availability?
> 
<snipped>
> > BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) 
> have just posted
NH=> I should have also added Hiroshi Ohta (NTT) to the authour
list....sorry Hiroshi from missing you off initially.
> > an ID for MPLS user-plane which deals with 1 and 2 above.
> 
> I would be interested in a link to your draft.
NH=> http://www.ietf.org/internet-drafts/draft-harrison-mpls-oam-00.txt
Note that some of the more complex diagrams are missing in here....if you
want to see these let me know off-list (to properly understand the flow
charts of near/far-end defect processing of LSPs and how to distinguish a
short-break from an unavailability event you may need them).  I have also
noted several typos that will need correcting when the ID gets up-issued.

<snipped to end>

Delivery-date: Mon, 05 Mar 2001 02:45:02 -0800
Date: Mon, 05 Mar 2001 05:38:39 -0500
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: IETF revised submission available

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

Hello,

I would like to inform folks that a revised version of the I-D is
attached. This I-D includes formulas for converting between the EDCBA
and SU mapping for the signal structures, as well as re-ordering of the
fields for better clarity. The I-D name is:

draft-lin-ccamp-ipo-common-label-request-01.txt

Comments welcome!

Regards,

Zhi
--------------8604794E7FE6420B3DE2A919
Content-Type: text/plain; charset=us-ascii;
 name="draft-lin-ccamp-ipo-common-label-request-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-lin-ccamp-ipo-common-label-request-01.txt"

Network Working Group                                
Internet Draft 
Expiration Date: September 2001                  Maarten Vissers 
                                                     Zhi-Wei Lin
                                                    Yangguang Xu
                                           Siva Sankaranarayanan

                                        Lucent Technologies, Inc.

                Common Label and Label Request Specification
                 for Automatic Switched Transport Network

             draft-lin-ccamp-ipo-common-label-request-01.txt

1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2. Abstract

   This draft completes the [GMPLS-REORG] draft and details technology 
   specific issues. It proposes different approach and enhancement to 
   [GMPLS-SIG] and [GMPLS-SIGEN]. Changes are:

   -- New set of Signal Type structures of ETSI-PDH, ANSI-PDH, SONET, SDH and 
      OTN for Generalized Label Request [GMPLS-SIG].
   -- G-PIDs associated each signal type for G-Label Request.
   -- Label Channel ID [GMPLS-REORG] field structure.
   -- Conversion formula for ITU-T (G.707) EDCBA to SU numbering scheme.

Z. Lin et. al.                                                     Page [1]

Internet Draft      G-Label and G-Label Request Specification      March 2001

3. G-Label Request Specification

     0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | LSP Enc. Type |                Signal Type                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |  Service Type |  Dir  | Rserved |           G-PID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    LSP Encoding Type and Signal Type together identify the unique signal 
    type of the LSP. 

3.1 LSP Encoding

    LSP Encoding Type: 8 bit 

    Indicates the encoding technology of the LSP being requested.
    
                 Value        Type
                 -----        --------
                 3            ANSI PDH
                 4            ETSI PDH
                 5            SDH
                 6            SONET
                 7            OTN
                 8            Analog

3.2 Signaling Type and Associated G-PID

    Signaling Type: 24 bits 

    Indicates the specific signal type of the LSP being requested. This 
    field is interpreted according to the technology specified by LSP 
    Encoding Type. The Signal Type provides transit switches with the 
    information required to determine which link connection can support 
    the LSP.

    G-PID: 16 bits
 
    Indicates the payload carried by an LSP, i.e. an identifier of the 
    client layer of the LSP.  It's the same as Payload Types in G.709, 
    Signal Label in G.707 and L3PID in RSVP-TE. Each of signal type may 
    only allow certain types of client signals. The G-PID is mainly used by 
    the adaptation layer function at the LSP terminating points. G-PID is 
    associated with each signal type.

Z. Lin et. al.                                                     Page [2]

Internet Draft      G-Label and G-Label Request Specification      March 2001

3.2.1 ANSI PDH Signaling Type

   Permitted values and their meaning for LSP Encoding Type ANSI-PDH:

                 Value       Type
                 -----       ----
                 1           DS1 SF
                 2           DS1 ESF
                 3           DS2
                 4           DS3 M23
                 5           DS3 C-bit Parity
                 6           DS4

   When the technology encoding type is ANSI-PDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                 0           Unknown

3.2.2 ETSI PDH Signaling Type

   Permitted values and their meaning for LSP Encoding Type ETSI-PDH:

                 Value        Type
                 -----        ----
                 1            E1 P12x
                 2            E1 P12s
                 3            E2 P22x
                 4            E2 P22e
                 5            E3 P31x
                 6            E3 P31e
                 7            E3 P31s
                 8            E4 P4x
                 9            E4 P4e
                 10           E4 P4s

3.2.3 SDH Signaling Type

    For SONET/SDH, the 24-bit Signal Type SHALL be encoded in the following 
    format: 
     
     0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | LSP Enc. Type |     Type      |              X                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Z. Lin et. al.                                                     Page [3]

Internet Draft      G-Label and G-Label Request Specification      March 2001

    Type: 8 bits 
    
    Indicates specific signal type of a LSP encoding type 

    X : 16 bits 

    Indicates concatenation value.

    Permitted type values and their meaning for LSP Encoding Type SDH 
    are:
          
                 Value        Type
                 -----        --------
                 1            VC-11
                 2            VC-12
                 3            VC-2
                 4            VC-2-Xc (1<=x<=7)
                 5            VC-3
                 6            VC-4
                 7            VC-4-Xc (X=4,16,64,256)
                 8            MS-X (STM-X MS) (X=1,4,16,64,256)
                 9            STM-X (X=1,4,16,64,256)
                 10           VC-11-Xv (1<=X<=64)
                 11           VC-12-Xv (1<=X<=64)
                 12           VC-2-Xv (1<=X<=64)
                 13           VC-3-Xv (1<=X<=256)
                 14           VC-4-Xv (1<=X<=256)
                 15           VC-11-Xv LCAS
                 16           VC-12-Xv LCAS
                 17           VC-2-Xv LCAS
                 18           VC-3-Xv LCAS
                 19           VC-4-Xv LCAS
                 20           VC-11-X **
                 21           VC-12-X 
                 22           VC-2-X 
                 23           VC-3-X 
                 24           VC-4-X 
                 128          TUG-2
                 129          TUG-3
                 130          AUG-X (X=1,4,16,64,256)
                 131          VC-4-Xa (1<=X<=256)
                 132          STM-Xst
                 133-143	Reserved for vendor specific SDH signal type

   ** This is used at intermediate nodes to support the LCAS when a subset 
      of the link connections are co-routed. 

Z. Lin et. al.                                                     Page [4]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   The "MS-X" and "STM-X" Signal types represent transparent STM Multiplex 
   Section and Regenerator Section LSPs respectively. Note that the "STM-X" 
   signal type represents the complete STM-N signal, including all its SOH.

   The "VC-n-Xc" Signal Type represents a contiguous standard concatenated 
   VC-n signal (ITU-T Rec. G.707), which is transported via the AU and TU 
   timeslots according to the (E,D,C,B,A) and (K,L,M) structures.

   The "VC-n-Xv" Signal type represents a virtual concatenated VC-n signal. 

   The "VC-n-Xv LCAS" Signal type represents a VC-n-Xv signal with Link 
   Capacity Adjustment Scheme (LCAS) capability. The "VC-n-X" Signal type 
   represents a group of VC-n signals that are to be co-routed. 

   Besides the set of signal types derived from the SDH standards, a number of 
   additional signal types are defined. These additional signal types are 
   vendor specific extensions of the SDH standards.

   The "AUG-X" Signal type represents an AUG-X bandwidth, of which the 
   specific AU structure is not predefined. This AUG-X link will autonomously 
   adapt to the incoming AU structure. Idem for TUG-2 and TUG-3.

   The "VC-4-Xa" Signal type represents a contiguous arbitrary concatenated 
   VC-4 signal.

   The "STM-Xst" Signal type represents a "semi transparent" STM-X signal. The 
   AUG-X and some of the SOH (vendor specific selection) is transported 
   through the link connection. Interworking between equipment of different 
   vendors is not to be expected.

   To support other vendor specific SDH signal types a set of 13 code points 
   (133-143) is reserved. Within its subnetwork a vendor may assign these code 
   points to its specific signals.

   The G-PIDs associated with each Signal Type are (based on G.707):
      VC-11:     (1) async 1.544 Mbps, (2) bit sync 1.544 Mbps, (3) byte sync   
                     1.544 Mbps, (4) byte sync 384 kbps, (5) ATM, (6) HDLC  
                     framed, (7) GFP framed
      VC-12:     (1) async 2.048 Mbps - transparent, (2) async 2.048 Mbps - 
                     terminated, (3) byte sync 2.048 Mbps - transparent, (4) 
                     byte sync 2.048 Mbps - terminated, (3) 31x64 kbps, (4) 
                     ATM, (5) HDLC framed, (7) GFP framed
      VC-2:      (1) async 6.312 Mbps, (2) bit sync 6.312 Mbps, (3) ATM, (4) 
                     HDLC framed, (5) GFP framed
      VC-2-Xc:   (1) ATM, (2) HDLC framed w/ scrambling
      VC-3:      (1) 44.736 Mbps - transparent, (2) 44.736 Mbps - terminated, 
                     (3) 34.368 Mbps - transparent, (4) 34.368 Mbps - 
                     terminated G.751 frame, (5) 34.368 Mbps - terminated 
                     G.832 frame, (3) TUG (4) ATM, (5) HDLC framed w/ 
                     scrambling, (6) GFP framed

Z. Lin et. al.                                                     Page [5]

Internet Draft      G-Label and G-Label Request Specification      March 2001

      TUG-2:     (1) one TU-2, (2) three TU-12, (3) four TU-11
      TUG-3:     (1) one TU-3, (2) seven TUG-2
      VC-4:      (1) 139.264 Mbps - transparent, (2) 139.264 Mbps - terminated 
                     G.751 frame, (3) 139.264 Mbps - terminated G.832 frame, 
                     (4) TUG, (5) ATM, (6) HDLC framed w/ scrambling, (7) 
                     DQDB, (8) async FDDI, (9) GFP framed
      VC-4-4c:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-16c:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-64c:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-256c: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      AUG-1:     (1) one AU-4,   (2) three AU-3
      AUG-4:     (1) four AUG-1, (2) one AU-4-4c
      AUG-16:    (1) four AUG-4, (2) one AU-4-16c
      AUG-64:    (1) four AUG-16, (2) one AU-4-64c
      AUG-256:   (1) four AUG-64, (2) one AU-4-256c
      MS-X:      (1) AUG-X
      STM-X: 
      VC-11-Xv:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-12-Xv:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-2-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-3-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-Xv:   (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-11-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-12-Xv LCAS: (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-2-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-3-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-4-Xv LCAS:  (1) ATM, (2) HDLC framed w/ scrambling, (3) GFP framed
      VC-11-X group that is co-routed: (0) unknown
      VC-12-X group that is co-routed: (0) unknown
      VC-2-X group that is co-routed:  (0) unknown
      VC-3-X group that is co-routed:  (0) unknown
      VC-4-X group that is co-routed:  (0) unknown

3.2.4 SONET Signaling Type

    Permitted type values and their meaning for LSP Encoding Type SONET 
    are:

                 Value        Type
                 -----        --------
                 1            VT1.5
                 2            VT2
                 3            VT3
                 4            VT6
                 5            STS-1 SPE
                 6            STS-Xc SPE      (X=3,12,48,192,768)
                 7            STS-X SPE       (X=1,3,12,48,192,768)
                 8            STS-X Line      (X=1,3,12,48,192,768)

Z. Lin et. al.                                                     Page [6]

Internet Draft      G-Label and G-Label Request Specification      March 2001

                 9            STS-X           (X=1,3,12,48,192,768)
                 10           VT1.5-Xv        (1<=X<=64)
                 11           VT2-Xv          (1<=X<=64)
                 12           VT3-Xv          (1<=X<=64)
                 13           VT6-Xv          (1<=X<=64)
                 14           STS-1-Xv        (1<=X<=256)
                 15           STS-3c-Xv       (1<=X<=256)
                 16           VT1.5-Xv LCAS
                 17           VT2-Xv LCAS
                 18           VT3-Xv LCAS
                 19           VT6-Xv LCAS
                 20           STS-1-Xv LCAS
                 21           STS-3c-Xv LCAS
                 22           VT1.5-X **
                 23           VT2-X
                 24           VT3-X
                 25           VT6-X
                 26           STS-1-X
                 27           STS-3c-X
                 128          VTG
                 129          STS Group-X (X=3,12,48,192,768)
                 130          STS-3c-Xa (1<=X<=256)
                 131          STS-Xst
                 132-143      Reserved for vendor specific SONET signal type

   ** This is used at intermediate nodes to support the LCAS when a subset 
   of the link connections are co-routed. 

   The "STS-X Line" and "STS-X" Signal types represent transparent STS Line 
   and STS Section LSPs respectively. Note that the "STS-X" signal type 
   represents the complete STS-N signal, including all its TOH.

   The "STS-Xc" Signal Type represents a contiguous standard concatenated STS 
   signal (ANSI T1.105), which is transported via the STS timeslots according 
   to the (E,D,C,B,A) structures.

   The "VTn-Xv" and "STS-n-Xv" Signal types represent virtual concatenated VT    
   and STS signals. The "VTn-Xv LCAS" and "STS-n-Xv LCAS" Signal type 
   represent VTn-Xv and STS-n-Xv signal with Link Capacity Adjustment Scheme 
   (LCAS) capability. The "VTn-X" and "STS-n-X" Signal types represent a group 
   of VTn and STS-n signals that are to be co-routed. 

   Besides the set of signal types derived from the SONET standards, a number 
   of additional signal types are defined. These additional signal types are 
   vendor specific extensions of the SONET standards.

   The "STS Group-X" Signal type represents an STS Group bandwidth, of which 
   the specific STS structure is not predefined. This STS Group-X link will 
   autonomously adapt to the incoming STS structure. Idem VTG.

Z. Lin et. al.                                                     Page [7]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   The "STS-3c-Xa" Signal type represents a contiguous arbitrary concatenated 
   STS-3c signal.

   The "STS-Xst" Signal type represents a "semi transparent" STS-X signal. The 
   STS-X SPE and some of the TOH (vendor specific selection) is transported 
   through the link connection. Inter-working between equipment of different 
   vendors is not to be expected.

   To support other vendor specific SONET signal types a set of 13 code points 
   (132-143) is reserved. Within its subnetwork a vendor may assign these code 
   points to its specific signals.

   The G-PIDs associated with each Signal Type are (based on T1.105):
      VT1.5:       (1) async DS1 (1.544 Mbps), (2) bit sync DS1, byte sync 
                       DS1, (3) GFP framed
      VT2:         (1) async 2.048 Mbps, (2) bit sync 2.048 Mbps, (3) byte 
                       sync 2.048 Mbps, (4) GFP framed
      VT3:         (1) async DS1C (3.152 Mbps)
      VT6:         (1) async DS2 (6.312 Mbps), (2) GFP framed
      STS Group-X: (1) STS-X SPE
      STS-1 SPE:   (1) async DS3 (44.736 Mbps), (2) VTG, (3) GFP framed
      STS-3c SPE:  (1) ATM, (2) HDLC framed, (3) GFP framed, (4) SDL w/ 
                       scrambler
      STS-12c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-48c SPE: (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-192c SPE:(1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler, 
                       10 Gbps Ethernet
      STS-768c SPE:(1)ATM,  (2) HDLC framed, (3) GFP framed, SDL w/ scrambler 
      STS-1 Line:
      STS-3 Line:
      STS-12 Line:
      STS-48 Line:
      STS-192 Line:
      STS-768 Line:
      STS-1:
      STS-3:
      STS-12:
      STS-48:
      STS-192:
      STS-768:
      VT1.5-Xv:    (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT2-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT3-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT6-Xv:      (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-1-Xv:    (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      STS-3c-Xv:   (1) ATM, (2) HDLC framed, (3) GFP framed, SDL w/ scrambler
      VT1.5-Xv LCAS:
      VT2-Xv LCAS:
      VT3-Xv LCAS:

Z. Lin et. al.                                                     Page [8]

Internet Draft      G-Label and G-Label Request Specification      March 2001

      VT6-Xv LCAS:
      STS-1-Xv LCAS:
      STS-3c-Xv LCAS:

3.2.5 OTN Signaling Type

   For OTN, the permitted signal types are
          
          Value        Type
          -----        --------
          1            ODU1
          2            ODU2
          3            ODU3

          10           OCh  - further typing will be added to OCh

   G-PIDs for ODU1 include:

          Value        Type
          -----        --------
          1            CBR2G5a  (asynchronous constant bit rate of 2.5 Gbps 
                                 such as STM-16 or OC-48)
          2            CBR2G5b  (bit synchronous constant bit rate of 2.5 Gbps 
                                 such as STM-16 or OC-48)          
          3            ATM2G5	
          4            GFP2G5   (used for transporting data, e.g., IP @ 2.5 
                                 Gbps)
          5            BSOT2G5  (mapping of non-specific client bit stream w/ 
                                 octet timing)
          6            BSNT2G5  (mapping of non-specific client bit stream w/o
                                 octet timing)

    G-PIDs for ODU2 include:

          Value        Type
          -----        --------
          1            CBR10Ga
          2            CBR10Gb
          3            ATM10G	
          4            GFP10G
          5            BSOT10G
          6            BSNT10G

    G-PIDs for ODU3 include:

          Value        Type
          -----        --------
          1            CBR40Ga

Z. Lin et. al.                                                     Page [9]

Internet Draft      G-Label and G-Label Request Specification      March 2001

          2            CBR40Gb
          3            ATM40G	
          4            GFP40G
          5            BSOT40G
          6            BSNT40G

    G-PIDs for OCh include:

          Value        Type
          -----        --------
           1           OTU1
           2           OTU1V
           3           OTU2
           4           OTU2V
           5           OTU3
           6           OTU3V
           7           STM-16/OC-48
           8           STM-64/OC-192
           9           STM-256/OC-256
           10          1 GbE

3.3 Directionality and Service Type are defined in [GMPLS-REORG].

4. G-label Channel ID Specification

4.1 G-Label Specification
   
   [GMPLS-REORG] introduces two type of Label format for automatically 
   switched transport network.

   Basic Format:

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                  G-Label     (Port ID)                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | D |              G-Label     (Channel ID)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hierarchical Format:

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //                 G-Label     (Connection ID)                  // 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | D |              G-Label     (Channel ID)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Z. Lin et. al.                                                     Page [10]

Internet Draft      G-Label and G-Label Request Specification      March 2001

4.2 G-Label Channel ID for SONET/SDH

    For SDH/SONET, the label identifies both a timeslot in the SDH/SONET frame 
    as well as a Connection Termination Point (CTP) in the equipment.

    The Channel ID of the G-label represents for SDH/SONET either the AU/STS 
    timeslots or the TU/VT timeslots.

    SDH/SONET are technologies encompassing multiple independent layer 
    networks. Trails and connections in layer networks are set up and torn 
    down independent of trails and connections in their server layer networks. 
    Trails and connections in layer networks are modified independent of 
    trails and connections in their server and client layer networks.

    Typically, server layer trails must have been set up before client layer 
    connections and trails can be set up. Server layer trails provide the 
    client layer link connections (label switched hops). As such, STM-N/OC-N 
    (i.e. multiplex section/line) trails must have been established before 
    HOVC connections and trails can be set up. Similarly, VC-4/STS-1 trails 
    must have been established before LOVC/VT connections and trails can be 
    set up.

    There is a multiplicity of ports (physical and logical) in SDH/SONET 
    equipment; STM-N/OC-N physical ports, HOVC/STS logical ports, LOVC/VT 
    logical ports. In future hybrid OTN/SDH/SONET equipment STM-N/OC-N ports 
    might also be logical ports.

    HOVC/STS signals can be transported over STM-N/OC-N signals. LOVC/VT 
    signals can be transported over either VC-4/VC-3/STS-1 signals, or sub-
    STM-0/sub-STS-1 signals (e.g. sSTM-1k [k=1,2,4,8,16], sSTM-2n [n=1,2,4]), 
    or 34 376 and 139 264 kbit/s signals with G.832 framing.

    STM-N/OC-N signals aggregate HOVC/STS signals. The associated multiplex 
    structure may be adapted during the lifetime of the STM-N/OC-N trail to 
    accommodate the requested mix of HOVC/STS signal types. VC-4/VC-3/STS-1 
    signals aggregate LOVC/VT signals. The associated multiplex structure may 
    be adapted during the lifetime of the VC-4/VC-3/STS-1 trail to accommodate 
    the requested mix of LOVC/VT signal types. At any moment in time, the 
    complete aggregation bandwidth's multiplex structure must be defined to 
    prevent alarms to be raised.

    SDH/SONET equipment may have either no switch fabric, or a HOVC/STS switch 
    fabric, or a LOVC/VT switch fabric, or a HOVC/STS and a LOVC/VT switch 
    fabric. SDH/SONET interfaces on none-SDH/SONET equipment typically have no 
    switch fabric. Hybrid equipment may have SDH/SONET type switch fabrics in 
    addition to client layer (e.g. ATM VP, ATM, VC, IP, Ethernet) switch 
    fabrics and/or server layer (e.g. OTN OCh, OTN ODUk) switch fabrics. 

    Installing fibers between equipment will establish physical layer trails, 

Z. Lin et. al.                                                     Page [11]

Internet Draft      G-Label and G-Label Request Specification      March 2001

    but most likely no HOVC/STS or LOVC/VT trails, despite that there might be 
    some SDH/SONET interfaces without switch fabrics connected at the edge of 
    the (sub)network.

    Therefore, HOVC/STS labels are independent of LOVC/VT labels. Each one 
    will have a dedicated Channel ID.

4.2.1. HOVC/STS specific Channel ID in STM-N/OC-N

    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 
    (E,D,C,B,A) structure (TUs are named according the (K,L,M) structure). 
    This (E,D,C,B,A) structure identifies the AU type, the location in the 
    STM-N/OC-N frame and at the same time implies a restriction on the AU-4-
    Xc/STS-Xc types and the timeslots these signals can be transported over.
    Vendor specific extensions exist that have fewer restrictions. To 
    accommodate both cases in a single channel ID structure, HOVC/STS channel 
    IDs are represented by means of the "SU" structure. A conversion between 
    (E,D,C,B,A) and SU is included.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       S                               |   U   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   1. S is the index of a particular AUG-X/STS-X, AU/STS, STM-Xst signal.
      S=1->N indicates the first timeslot of a specific AUG-X/STS-X,
 
      AU/STS, STM-Xst inside an STM-N/STS-N multiplex. For example, S=1 
      indicates the first AUG-1/STS-3, and S=N indicates the last AUG-1/STS-3 of 
      this multiplex.  S=0 is invalid.

  2. U indicates if the AUG-1/STS-3 is subdivided. U=1 indicates that
     the AUG-1/STS-3 is not further subdivided and contains an
     AU-4/STS-3c. U=2->4 indicates a specific AU-3/STS-1 inside the
     given AUG-1/STS-3. For the other signals, U is not-applicable
     and is fixed to 0.

4.2.2. TU/VT specific Channel ID portion in VC-4 and STS-1

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                       |   K   |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For SDH VC-4 and VC-3, this is an extension of the numbering scheme defined 

Z. Lin et. al.                                                     Page [12]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   in G.707 section 7.3, i.e. the (K, L, M) and (L,M) numbering. For 
   SONET and SDH VC-3 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. K is only significant for SDH VC-4 and must be ignored for SONET and SDH 
      VC-3. 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.

   2. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
      is not significant for an unstructured VC-4, and must be 0 in this case. 
      L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further sub-divided 
      and contains a TU-3 in SDH; It is not applicable for SONET. L=2->8
      indicates a specific TUG-2/VT Group inside the corresponding
      higher order signal.
      L=9 indicates that the TUG3 structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU structure of the incoming signal. This signal
      is referred to as a TUG-3. 

   3. 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 and must be 0 in this case. M=1 indicates that the TUG-2/VT Group is  
      not further sub-divided and contains a TU-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 TU-12/VT-2 inside the     
      corresponding TUG-2/VT Group. M=7->10 indicates a specific
      TU-11/VT-1.5 inside the corresponding TUG-2/VT Group. 
      M=11 indicates that the TUG2/VTG structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU/VT structure of the incoming signal. This signal
      is referred to as a TUG-2/VTG. 

4.2.3	TU/VT specific channel portion in sSTM-1k and sSTM-2n

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                               |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Z. Lin et. al.                                                     Page [13]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   For SDH sSTM-2n, this is an extension of the numbering scheme defined in
   G.708, i.e. the (L,M) numbering. 

   1. L=1->n indicates a specific TUG-2/VT Group inside the sSTM-2n (n=1,2,4).
      L=5 indicates that the TUG2 structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU structure of the incoming signal. This signal
      is referred to as a TUG-2. 

   2. M indicates a specific branch of a TUG-2/VT Group. M=1 indicates that 
      the TUG-2/VT Group is not further sub-divided and contains a TU-2/VT-6. 
      M=2->4 indicates a specific TU-12/VT-2 inside the corresponding TUG-2/VT 
      Group. M=5->8 indicates a specific TU-11/VT-1.5 inside the corresponding 
      TUG-2/VT Group. 
      M=9 indicates that the TUG2/VTG structure is not predefined;
      instead it is determined by the incoming signal and autonomously
      adapts to the TU/VT structure of the incoming signal. This signal
      is referred to as a TUG-2/VTG. 

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                       |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For SDH sSTM-1k, this is an extension of the numbering scheme defined in
   G.708, i.e. the (M) numbering. 

   1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16).

4.2.4	TU/VT specific channel portion in P31s and P4s

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                       |   K   |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 139 264 kbit/s G.832 framed signal (P4s) option II, this is an    
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the 
   (K, L, M) numbering. 

   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.

  

Z. Lin et. al.                                                     Page [14]

Internet Draft      G-Label and G-Label Request Specification      March 2001
   
   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. K indicates a specific branch of a P4s. K=1->3 indicates a specific TUG-
      3 (A, B, C) inside the P4s.

   2. L indicates a specific branch of a TUG-3. L=1 indicates that
      the TUG-3 is not further sub-divided and contains a TU-3. L=2->8 (for 
      K=3, L is limited to 2->6) indicates a specific TUG-2.

   3. M indicates a specific branch of a TUG-2. It is not significant for an 
      unstructured TUG-3 and must be 0 in this case. M=1 indicates that the 
      TUG-2 is not further sub-divided and contains a TU-2. M=2->4 indicates a 
      specific TU-12 inside the corresponding TUG-2.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                               |   L   |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 139 264 kbit/s G.832 framed signal (P4s) option I, this is an   
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the 
   (L, M) numbering. 

   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. L indicates a specific branch of a P4s. L=1->20 
      indicates a specific TUG-2.

   2. M indicates a specific branch of a TUG-2. M=1 indicates that the TUG-2 
      is not further sub-divided and contains a TU-2. M=2->4 indicates a 
      specific TU-12 inside the corresponding TUG-2.

    0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                       |   M   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   For the 34 368 kbit/s G.832 framed signal (P4s) option I, this is an 
   extension of the numbering scheme defined in ETSI EN 300 417-5-1, i.e. the  
   (L, M) numbering. For sSTM-1k, this is an extension of the numbering scheme 

Z. Lin et. al.                                                     Page [15]

Internet Draft      G-Label and G-Label Request Specification      March 2001

   defined in G.708, i.e. the (M) numbering. 

   1. M=1->k indicates a specific TU-12 inside the sSTM-1k (k=1,2,4,8,16).

4.3 OTN Label

    TBD

5. Security Considerations

   This document raises no new security concerns.

6. References

[GMPLS-REORG]	Y. Xu, et. al., "GMPLS Signaling Functional Spec. 
Modification and Reorganization", Work in Progress, March 2001.

[GMPLS-SIG]       P. Ashwood-Smith, et. al., "Generalized MPLS - Signaling 
Functional Description", Work in Progress, Nov. 2000.

[GMPLS-ARCH]      Y. Xu, et. al.,  "GMPLS Control Plane Architecture for ASTN", 
Work in Progress, Nov. 2000.

[GMPLS-SIGEN]     B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for 
Optical Technologies", Work in Progress, Nov. 2000.

7. Author Information
    
   Yangguang Xu
   21-2A41, 1600 Osgood Street
   North Andover, MA 01845
   Email:	[email-masked]
   
   Zhi-Wei Lin
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030 
   Email: [email-masked]

   Siva Sankaranarayanan    
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030 
   Email: [email-masked]

   Maarten Vissers
   Botterstraat 45
   Postbus 18
   1270 AA Huizen, Netherlands 
   Email: [email-masked]

Z. Lin et. al.                                                     Page [16]

Annex A: Conversion formula for EDCBA <-> SU

For the EDCBA to SU conversion, the following formula can be used:

	S = max[ (E-1)*64, 0 ] + max[ (D-1)*16, 0 ] + 
	      max[ (C-1)*4, 0 ] + max[ B-1, 0 ] + 1

	              B
	U = ceiling[ --- , 0 ] + A
	             B+1

For the SU to EDCBA conversion, the following formula can be used:

	                   S
	E = max[ ceiling[ --- ], 0 ] 
	                  64

	      or 0 {for AU-4-256c & STM-64 or lower}

	                       S
	D = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
	                      16
 
	      or 0 {for AU-4-64c or above & STM-16 or lower}

	                       S
	C = [ [ max[ ceiling[ --- ], 0 ] - 1 ] modulo 4 ] + 1
	                       4
 
	      or 0 {for AU-4-16c or above & STM-4 or lower}

	B = [ ( S-1 ) modulo 4 ] + 1 
	      or 0 {for AU-4-4c or above & STM-1 or lower}

	A = U - 1
	      or 0 (for AU-4 or above)

Annex B: Sample conversion table

The following table provides the explicit mapping between the SU and the EDCBA numbering scheme:

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

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

--------------8604794E7FE6420B3DE2A919--

Delivery-date: Sat, 03 Mar 2001 11:44:03 -0800
Date: Sat, 03 Mar 2001 14:28:02 -0500
From: "Richard W. Tibbs" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Standards for IP stats collection? (corrected)

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

Neil -- your comments on inter-relation between failure modes and QOS are very
on target.
You are right that the issues are a pandora's box, but I don't find the
availability analysis
of the IP layer quite as hopeless. I have a few comments below.
I would appreciate anyone's responses as to the "hopelessness index" of this
problem.

[email-masked] wrote:

> Bert....I can understand your earlier comment (wrt wanting limiting WG
> coverage), but I can probably understand why Vishal wrote to several lists:
> -       IP need its own perf management regime
> -       MPLS ditto
> -       GMPLS ditto....and there can be several layer networks involved
> here, eg SDH (which has several distinct internal layer networks) and OTN.
>
> This is unavoidable as each of the above create layer networks that must be
> managed in their own right.  And to do a proper job its not simply QoS Perf
> stats that are at issue for operators, its more like this:
>
> 1       user-plane and control-plane need their own OAM once dealing with CO
> paths, eg GMPLS/MPLS-ER-LSPs, since one cannot assume user/control-plane
> congruence of function or routing....so they are independent.  In the
> user-plane one must have an initial clear view of defects (entry/exit
> criteria) and their handling (ie correct consequent actions).  For an
> operator this is an operational must-have.
>
> 2       After above, the next issue is availability.  This has to be defined
> before QoS metrics/objectives can be considered.  Why?  QoS metrics are only
> valid when a path is in the up-state, otherwise the QoS metrics have no
> viable time-base and/or can get (statistically) distorted by events which
> should be regarded as down-time ....so up/down-state transitions need to be
> clearly identified next.  Note - this issue is not clear-cut for the IP
> layer when dealing with destination-based hop-hop routing.  Indeed, there
> are very difficult issues with failures mutating into QoS hits which I have
> raised on the MPLS list before which make availability analysis of the IP
> layer impossible (IMO) for the *network* (ie as subnetwork partitioned
> allocations of a global reference connection) except on a true end-end
> basis.

I think (but am not quite sure from your wording) that you find the goal of
separating
failure analysis at the physical/link layers from availabiltiy & QoS at the IP
layer unattainable.
My view is that these functions of network state are inter-related and to seek
to make them
independent is quixotic.
Here is a view:
The various layers below IP will have outage phenomena. These are measurable,
albeit imperfectly.
Both control-plane and data-plane will have outage phenomena. These are
measurable, I think.
("Outage" includes route stability loss during convergence, for conventional IP
routing. Ex.: Vern Paxsons 1996 paper on internet routing behavior.)
MPLS will have separate, but commensurate outage behavior (despite fast
reroute).
All of this feeds into the analysis of QoS at the IP layerand above.
QoS is both an IP connection availability (reachability) issue, as well as a
packet loss, delay etc. issue.
Up/down state transitions can generally cause both (a) reachability loss, and
(b) data loss.
So, *given adequate measurement and characterization* of the phenomena,
I don't see it as impossible. If this is naive, why?

>
>
> 3       Now we can consider QoS.....but be careful.  It costs money to
> measure/collect/process (in OSS) these....every technology I have been
> involved with has started with a large metric wish-list that gets whittled
> down to something more pragmatic later.  My advice is that these should be
> of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for
> trouble-shooting as needed by operational people, or the continuous
> measurement of 'important' paths, and (ii) general network population
> sampling (to get overall network trends and spot latent anomolous
> behaviour).

Yes. The problem as I see it here is that many of the measurement stds impose
invasive problems on the network. RMON and general polling via SNMP are
examples.

>
>
> 4       policing/re-classification actions need monitoring.
>
> 5       nodal/link utilisations need monitoring and fed to a TE function and
> the design/forecasting cycle.
>
> So one needs a framework, where these pieces relate but where one piece does
> not attempt to the job of all the others.
>
> BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) have just posted
> an ID for MPLS user-plane which deals with 1 and 2 above.

I would be interested in a link to your draft.

>
>
> neil
>
> > -----Original Message-----
> > From: Sambasiva R. Mantha [mailto:[email-masked]]
> > Sent: 02 March 2001 20:50
> > To: terry martin
> > Cc: [email-masked]; Bora Akyol; Vishal Sharma; [email-masked]';
> > [email-masked]'; [email-masked]
> > Subject: Re: Standards for IP stats collection? (corrected)
> >
> >
> > I would like to correct a little bit regarding GR-253. The
> > GR-253 requires 8
> > hours of 15-minute registers and 7 one-day registers and not
> > 3-5 days. This
> > means that a SONET must have 33 15-minute registers (32
> > registers for previous 8
> > hours and 1 for current 15 minutes) and 7 1-day (previous
> > day) registers.
> > I would agree with Manohar that these PM registers are an
> > over-kill for LSPs as
> > they really donot contribute anything to the traffic flowing
> > through the NE.
> >
> > Sambu
> >
> >
> > terry martin wrote:
> >
> > > RMON is the only protocol standard that dictates
> > information collection
> > > requirements.  That is the only IP service that is
> > structured to collect
> > > trend stats.  I think it is also 15 minute intervals for
> > 3-5 days depending
> > > on how much memory you get in the unit.
> > >
> > > There are structure requirements for collection, type of
> > traffic collected
> > > and how it is presented.
> > >
> > > Need sources- let me know
> > >
> > > Terry Martin MS Telecommunication Engineering
> > > Senior Consultant
> > > [email-masked]
> > > 503-612-4422
> > >
> > > ----- Original Message -----
> > > From: "Manohar Naidu Ellanti" <[email-masked]>
> > > To: "Bora Akyol" <[email-masked]>; "Vishal Sharma"
> > > <[email-masked]>
> > > Cc: "[email-masked]'" <[email-masked]>; "[email-masked]'" <[email-masked]>;
> > > <[email-masked]>
> > > Sent: Thursday, March 01, 2001 9:14 PM
> > > Subject: RE: Standards for IP stats collection? (corrected)
> > >
> > > > It will be interesting to see if there is a need for TDM
> > world operational
> > > > features to be carried into MPLS world.
> > > >
> > > > I think the reason for 15 minutes etc PM counters for
> > things like Severely
> > > > Errored Seconds etc was to deduce the quality of
> > transmission line and use
> > > > this to feed into link cost. For instance realiability
> > metric could be
> > > based
> > > > on such information for the link.
> > > >
> > > > For LSPs does it really make sense ? to have TDM world operational
> > > features.
> > > > There is not even CRC or any header information to
> > determine if MPLS
> > > packet
> > > > was received correctly. It is more at lower layers. It
> > would be nice to
> > > see
> > > > some useful features carried forward and avoid
> > unnecessary requirements
> > > from
> > > > GR-XXX.
> > > >
> > > > -Manohar
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Bora
> > > > Akyol
> > > > Sent: Thursday, March 01, 2001 8:57 PM
> > > > To: Vishal Sharma
> > > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > > Subject: Re: Standards for IP stats collection? (corrected)
> > > >
> > > >
> > > > Vishal
> > > >
> > > > I don't think that there are such standards for routers.
> > I know that some
> > > > routers store such data on flash cards for later
> > retrieval and some on
> > > > hard disks.
> > > >
> > > > I would be curious to see how people are storing this
> > data and for how
> > > > long?
> > > >
> > > > Bora
> > > >
> > > >
> > > > On Thu, 1 Mar 2001, Vishal Sharma wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > > For the TDM world, GR-253 lays out strict standards for
> > > > > the length of time that a carrier-class box should collect
> > > > > and store statistics on-board, for retrieval later. The
> > > > > number is something like 15-min intervals for 3 days.
> > > > > The purpose supposedly is that if the connection to the EMS
> > > > > dies, the box at least should allow the provider to recover
> > > > > statistics data from it.
> > > > >
> > > > > My question is: what are similar standards (or existing
> > > > > best practices) in the IP carrier community today? How much
> > > > > statistics-related information do carriers like to have from
> > > > > IP boxes?
> > > > > What would carriers like to have?
> > > > >
> > > > > (The only reference I could find on this was Blain Christian's
> > > > > draft
> > > > >
> > > >
> > >
> > http://search.ietf.org/internet-drafts/draft-christian-tewg-me
> asurement-00.t
> > > > xt)
> > > >
> > > > Are there others?
> > > > Do people (read carriers) have any thoughts or suggestions or
> > > > pointers?
> > > >
> > > > Thanks,
> > > >
> > > > -Vishal
> > > >
> > >
> > >

--
http://www.makesystems.com

--------------B61D069BAF8B007E254C294F
Content-Type: text/x-vcard; charset=us-ascii;
 name="rtibbs.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard W. Tibbs
Content-Disposition: attachment;
 filename="rtibbs.vcf"

begin:vcard 
n:Tibbs;Richard
tel;cell:919.412.4129
tel;home:919.787.4387
tel;work:919.412.4129
x-mozilla-html:FALSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;3408 Cherry Lane=0D=0A;Raleigh;NC;27607;
fn:Dr. Richard Tibbs
end:vcard

--------------B61D069BAF8B007E254C294F--

Delivery-date: Sat, 03 Mar 2001 10:55:55 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: Standards for IP stats collection? (corrected)
Date: Sat, 3 Mar 2001 18:51:42 -0000 

Bert....I can understand your earlier comment (wrt wanting limiting WG
coverage), but I can probably understand why Vishal wrote to several lists:
-	IP need its own perf management regime
-	MPLS ditto
-	GMPLS ditto....and there can be several layer networks involved
here, eg SDH (which has several distinct internal layer networks) and OTN.

This is unavoidable as each of the above create layer networks that must be
managed in their own right.  And to do a proper job its not simply QoS Perf
stats that are at issue for operators, its more like this:

1	user-plane and control-plane need their own OAM once dealing with CO
paths, eg GMPLS/MPLS-ER-LSPs, since one cannot assume user/control-plane
congruence of function or routing....so they are independent.  In the
user-plane one must have an initial clear view of defects (entry/exit
criteria) and their handling (ie correct consequent actions).  For an
operator this is an operational must-have.

2	After above, the next issue is availability.  This has to be defined
before QoS metrics/objectives can be considered.  Why?  QoS metrics are only
valid when a path is in the up-state, otherwise the QoS metrics have no
viable time-base and/or can get (statistically) distorted by events which
should be regarded as down-time ....so up/down-state transitions need to be
clearly identified next.  Note - this issue is not clear-cut for the IP
layer when dealing with destination-based hop-hop routing.  Indeed, there
are very difficult issues with failures mutating into QoS hits which I have
raised on the MPLS list before which make availability analysis of the IP
layer impossible (IMO) for the *network* (ie as subnetwork partitioned
allocations of a global reference connection) except on a true end-end
basis.

3	Now we can consider QoS.....but be careful.  It costs money to
measure/collect/process (in OSS) these....every technology I have been
involved with has started with a large metric wish-list that gets whittled
down to something more pragmatic later.  My advice is that these should be
of 2 types of QoS metric collection: (i) ad hoc 'sw-on' function for
trouble-shooting as needed by operational people, or the continuous
measurement of 'important' paths, and (ii) general network population
sampling (to get overall network trends and spot latent anomolous
behaviour).

4	policing/re-classification actions need monitoring.

5	nodal/link utilisations need monitoring and fed to a TE function and
the design/forecasting cycle.

So one needs a framework, where these pieces relate but where one piece does
not attempt to the job of all the others.

BTW - We (ie me/Shahram Davari/Ben Mack-Crane/Peter Willis) have just posted
an ID for MPLS user-plane which deals with 1 and 2 above.

neil

> -----Original Message-----
> From: Sambasiva R. Mantha [mailto:[email-masked]]
> Sent: 02 March 2001 20:50
> To: terry martin
> Cc: [email-masked]; Bora Akyol; Vishal Sharma; [email-masked]';
> [email-masked]'; [email-masked]
> Subject: Re: Standards for IP stats collection? (corrected)
> 
> 
> I would like to correct a little bit regarding GR-253. The 
> GR-253 requires 8
> hours of 15-minute registers and 7 one-day registers and not 
> 3-5 days. This
> means that a SONET must have 33 15-minute registers (32 
> registers for previous 8
> hours and 1 for current 15 minutes) and 7 1-day (previous 
> day) registers.
> I would agree with Manohar that these PM registers are an 
> over-kill for LSPs as
> they really donot contribute anything to the traffic flowing 
> through the NE.
> 
> Sambu
> 
> 
> terry martin wrote:
> 
> > RMON is the only protocol standard that dictates 
> information collection
> > requirements.  That is the only IP service that is 
> structured to collect
> > trend stats.  I think it is also 15 minute intervals for 
> 3-5 days depending
> > on how much memory you get in the unit.
> >
> > There are structure requirements for collection, type of 
> traffic collected
> > and how it is presented.
> >
> > Need sources- let me know
> >
> > Terry Martin MS Telecommunication Engineering
> > Senior Consultant
> > [email-masked]
> > 503-612-4422
> >
> > ----- Original Message -----
> > From: "Manohar Naidu Ellanti" <[email-masked]>
> > To: "Bora Akyol" <[email-masked]>; "Vishal Sharma"
> > <[email-masked]>
> > Cc: "[email-masked]'" <[email-masked]>; "[email-masked]'" <[email-masked]>;
> > <[email-masked]>
> > Sent: Thursday, March 01, 2001 9:14 PM
> > Subject: RE: Standards for IP stats collection? (corrected)
> >
> > > It will be interesting to see if there is a need for TDM 
> world operational
> > > features to be carried into MPLS world.
> > >
> > > I think the reason for 15 minutes etc PM counters for 
> things like Severely
> > > Errored Seconds etc was to deduce the quality of 
> transmission line and use
> > > this to feed into link cost. For instance realiability 
> metric could be
> > based
> > > on such information for the link.
> > >
> > > For LSPs does it really make sense ? to have TDM world operational
> > features.
> > > There is not even CRC or any header information to 
> determine if MPLS
> > packet
> > > was received correctly. It is more at lower layers. It 
> would be nice to
> > see
> > > some useful features carried forward and avoid 
> unnecessary requirements
> > from
> > > GR-XXX.
> > >
> > > -Manohar
> > >
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Bora
> > > Akyol
> > > Sent: Thursday, March 01, 2001 8:57 PM
> > > To: Vishal Sharma
> > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > Subject: Re: Standards for IP stats collection? (corrected)
> > >
> > >
> > > Vishal
> > >
> > > I don't think that there are such standards for routers. 
> I know that some
> > > routers store such data on flash cards for later 
> retrieval and some on
> > > hard disks.
> > >
> > > I would be curious to see how people are storing this 
> data and for how
> > > long?
> > >
> > > Bora
> > >
> > >
> > > On Thu, 1 Mar 2001, Vishal Sharma wrote:
> > >
> > > > Hello All,
> > > >
> > > > For the TDM world, GR-253 lays out strict standards for
> > > > the length of time that a carrier-class box should collect
> > > > and store statistics on-board, for retrieval later. The
> > > > number is something like 15-min intervals for 3 days.
> > > > The purpose supposedly is that if the connection to the EMS
> > > > dies, the box at least should allow the provider to recover
> > > > statistics data from it.
> > > >
> > > > My question is: what are similar standards (or existing
> > > > best practices) in the IP carrier community today? How much
> > > > statistics-related information do carriers like to have from
> > > > IP boxes?
> > > > What would carriers like to have?
> > > >
> > > > (The only reference I could find on this was Blain Christian's
> > > > draft
> > > >
> > >
> > 
> http://search.ietf.org/internet-drafts/draft-christian-tewg-me
asurement-00.t
> > > xt)
> > >
> > > Are there others?
> > > Do people (read carriers) have any thoughts or suggestions or
> > > pointers?
> > >
> > > Thanks,
> > >
> > > -Vishal
> > >
> >
> >

Delivery-date: Fri, 02 Mar 2001 13:27:09 -0800
From: Michael Waldo <[email-masked]>
To: "'Sambasiva R. Mantha'" <[email-masked]>, terry martin <[email-masked]>
Cc: [email-masked], Bora Akyol <[email-masked]>, Vishal Sharma <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Standards for IP stats collection? (corrected)
Date: Fri, 2 Mar 2001 15:25:53 -0600 

Sounds right for the 15-minute counters, but only current and 1 previous day
counters are required for each monitored parameter.

R6-301 [634v2], GR-253-CORE, Issue 3, September 2000 
R6-297 [634v2], GR-253-CORE, Issue 2, December 1995, Revision 2, January
1999

-Waldo

-----Original Message-----
From: Sambasiva R. Mantha [mailto:[email-masked]]
Sent: Friday, March 02, 2001 2:50 PM
To: terry martin
Cc: [email-masked]; Bora Akyol; Vishal Sharma; [email-masked]';
[email-masked]'; [email-masked]
Subject: Re: Standards for IP stats collection? (corrected)

I would like to correct a little bit regarding GR-253. The GR-253 requires 8
hours of 15-minute registers and 7 one-day registers and not 3-5 days. This
means that a SONET must have 33 15-minute registers (32 registers for
previous 8
hours and 1 for current 15 minutes) and 7 1-day (previous day) registers.
I would agree with Manohar that these PM registers are an over-kill for LSPs
as
they really donot contribute anything to the traffic flowing through the NE.

Sambu

terry martin wrote:

> RMON is the only protocol standard that dictates information collection
> requirements.  That is the only IP service that is structured to collect
> trend stats.  I think it is also 15 minute intervals for 3-5 days
depending
> on how much memory you get in the unit.
>
> There are structure requirements for collection, type of traffic collected
> and how it is presented.
>
> Need sources- let me know
>
> Terry Martin MS Telecommunication Engineering
> Senior Consultant
> [email-masked]
> 503-612-4422
>
> ----- Original Message -----
> From: "Manohar Naidu Ellanti" <[email-masked]>
> To: "Bora Akyol" <[email-masked]>; "Vishal Sharma"
> <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>; "[email-masked]'" <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, March 01, 2001 9:14 PM
> Subject: RE: Standards for IP stats collection? (corrected)
>
> > It will be interesting to see if there is a need for TDM world
operational
> > features to be carried into MPLS world.
> >
> > I think the reason for 15 minutes etc PM counters for things like
Severely
> > Errored Seconds etc was to deduce the quality of transmission line and
use
> > this to feed into link cost. For instance realiability metric could be
> based
> > on such information for the link.
> >
> > For LSPs does it really make sense ? to have TDM world operational
> features.
> > There is not even CRC or any header information to determine if MPLS
> packet
> > was received correctly. It is more at lower layers. It would be nice to
> see
> > some useful features carried forward and avoid unnecessary requirements
> from
> > GR-XXX.
> >
> > -Manohar
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
> > Akyol
> > Sent: Thursday, March 01, 2001 8:57 PM
> > To: Vishal Sharma
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > Subject: Re: Standards for IP stats collection? (corrected)
> >
> >
> > Vishal
> >
> > I don't think that there are such standards for routers. I know that
some
> > routers store such data on flash cards for later retrieval and some on
> > hard disks.
> >
> > I would be curious to see how people are storing this data and for how
> > long?
> >
> > Bora
> >
> >
> > On Thu, 1 Mar 2001, Vishal Sharma wrote:
> >
> > > Hello All,
> > >
> > > For the TDM world, GR-253 lays out strict standards for
> > > the length of time that a carrier-class box should collect
> > > and store statistics on-board, for retrieval later. The
> > > number is something like 15-min intervals for 3 days.
> > > The purpose supposedly is that if the connection to the EMS
> > > dies, the box at least should allow the provider to recover
> > > statistics data from it.
> > >
> > > My question is: what are similar standards (or existing
> > > best practices) in the IP carrier community today? How much
> > > statistics-related information do carriers like to have from
> > > IP boxes?
> > > What would carriers like to have?
> > >
> > > (The only reference I could find on this was Blain Christian's
> > > draft
> > >
> >
>
http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t
> > > xt)
> > >
> > > Are there others?
> > > Do people (read carriers) have any thoughts or suggestions or
> > > pointers?
> > >
> > > Thanks,
> > >
> > > -Vishal
> > >
> >
> >

Delivery-date: Fri, 02 Mar 2001 13:09:35 -0800
Date: Fri, 02 Mar 2001 14:49:39 -0600
From: "Sambasiva R. Mantha" <[email-masked]>
Organization: Alcatel USA 
To: terry martin <[email-masked]>
CC: [email-masked], Bora Akyol <[email-masked]>, Vishal Sharma <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Standards for IP stats collection? (corrected)

I would like to correct a little bit regarding GR-253. The GR-253 requires 8
hours of 15-minute registers and 7 one-day registers and not 3-5 days. This
means that a SONET must have 33 15-minute registers (32 registers for previous 8
hours and 1 for current 15 minutes) and 7 1-day (previous day) registers.
I would agree with Manohar that these PM registers are an over-kill for LSPs as
they really donot contribute anything to the traffic flowing through the NE.

Sambu

terry martin wrote:

> RMON is the only protocol standard that dictates information collection
> requirements.  That is the only IP service that is structured to collect
> trend stats.  I think it is also 15 minute intervals for 3-5 days depending
> on how much memory you get in the unit.
>
> There are structure requirements for collection, type of traffic collected
> and how it is presented.
>
> Need sources- let me know
>
> Terry Martin MS Telecommunication Engineering
> Senior Consultant
> [email-masked]
> 503-612-4422
>
> ----- Original Message -----
> From: "Manohar Naidu Ellanti" <[email-masked]>
> To: "Bora Akyol" <[email-masked]>; "Vishal Sharma"
> <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>; "[email-masked]'" <[email-masked]>;
> <[email-masked]>
> Sent: Thursday, March 01, 2001 9:14 PM
> Subject: RE: Standards for IP stats collection? (corrected)
>
> > It will be interesting to see if there is a need for TDM world operational
> > features to be carried into MPLS world.
> >
> > I think the reason for 15 minutes etc PM counters for things like Severely
> > Errored Seconds etc was to deduce the quality of transmission line and use
> > this to feed into link cost. For instance realiability metric could be
> based
> > on such information for the link.
> >
> > For LSPs does it really make sense ? to have TDM world operational
> features.
> > There is not even CRC or any header information to determine if MPLS
> packet
> > was received correctly. It is more at lower layers. It would be nice to
> see
> > some useful features carried forward and avoid unnecessary requirements
> from
> > GR-XXX.
> >
> > -Manohar
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
> > Akyol
> > Sent: Thursday, March 01, 2001 8:57 PM
> > To: Vishal Sharma
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > Subject: Re: Standards for IP stats collection? (corrected)
> >
> >
> > Vishal
> >
> > I don't think that there are such standards for routers. I know that some
> > routers store such data on flash cards for later retrieval and some on
> > hard disks.
> >
> > I would be curious to see how people are storing this data and for how
> > long?
> >
> > Bora
> >
> >
> > On Thu, 1 Mar 2001, Vishal Sharma wrote:
> >
> > > Hello All,
> > >
> > > For the TDM world, GR-253 lays out strict standards for
> > > the length of time that a carrier-class box should collect
> > > and store statistics on-board, for retrieval later. The
> > > number is something like 15-min intervals for 3 days.
> > > The purpose supposedly is that if the connection to the EMS
> > > dies, the box at least should allow the provider to recover
> > > statistics data from it.
> > >
> > > My question is: what are similar standards (or existing
> > > best practices) in the IP carrier community today? How much
> > > statistics-related information do carriers like to have from
> > > IP boxes?
> > > What would carriers like to have?
> > >
> > > (The only reference I could find on this was Blain Christian's
> > > draft
> > >
> >
> http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t
> > > xt)
> > >
> > > Are there others?
> > > Do people (read carriers) have any thoughts or suggestions or
> > > pointers?
> > >
> > > Thanks,
> > >
> > > -Vishal
> > >
> >
> >

Delivery-date: Fri, 02 Mar 2001 12:13:46 -0800
Date: Fri, 02 Mar 2001 15:00:53 -0500
From: "Richard W. Tibbs" <[email-masked]>
Reply-To: [email-masked]
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Vishal Sharma <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Standards for IP stats collection? (corrected)

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

I have weighed in with opinions on this subject before, so again --
IP statistics collection can be divided into two areas:
Traffic characteristics, and
Performance characteristics.
The IPPM wg as well as ITU Y.1540/1541 focus almost exclusively on the second
area.
Unless te-wg or ccamp can give greater effort in the first area, there is truly
a hole in the
fabric of traffic engineering, IMHO.
Blaine's draft, which I am contributing to, seems to be a possibile point to
start.
One point I return to (ad nauseum, I know) is the need to understand
traffic characteristics on time scales as small as seconds.
15-minute intervals were fine for best-effort.
Not so fine anymore, I think.

"Wijnen, Bert (Bert)" wrote:

> I wonder why we need to have this posted to 3 mailing lists.
> I suggest that after this email we just stick to te-wg.
>
> In RFC2493 we have defined a set of Textual Conventions for
> this sort of 15-minute interval history.
> They are meant for general use.
>
> Up till now, only RFC2495, 2496, 2558 and 2662 use them.
>
> Bert
>
> > ----------
> > From:         Vishal Sharma[SMTP:[email-masked]]
> > Sent:         Friday, March 02, 2001 4:32 AM
> > To:   [email-masked]'
> > Cc:   [email-masked]'; [email-masked]'
> > Subject:      Standards for IP stats collection? (corrected)
> >
> > Hello All,
> >
> > For the TDM world, GR-253 lays out strict standards for
> > the length of time that a carrier-class box should collect
> > and store statistics on-board, for retrieval later. The
> > number is something like 15-min intervals for 3 days.
> > The purpose supposedly is that if the connection to the EMS
> > dies, the box at least should allow the provider to recover
> > statistics data from it.
> >
> > My question is: what are similar standards (or existing
> > best practices) in the IP carrier community today? How much
> > statistics-related information do carriers like to have from
> > IP boxes?
> > What would carriers like to have?
> >
> > (The only reference I could find on this was Blain Christian's
> > draft
> > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00
> > .t
> > xt)
> >
> > Are there others?
> > Do people (read carriers) have any thoughts or suggestions or
> > pointers?
> >
> > Thanks,
> >
> > -Vishal
> >

--
http://www.makesystems.com

--------------47981B162FD3952DE8717AA4
Content-Type: text/x-vcard; charset=us-ascii;
 name="rtibbs.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard W. Tibbs
Content-Disposition: attachment;
 filename="rtibbs.vcf"

begin:vcard 
n:Tibbs;Richard
tel;cell:919.412.4129
tel;home:919.787.4387
tel;work:919.412.4129
x-mozilla-html:FALSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;3408 Cherry Lane=0D=0A;Raleigh;NC;27607;
fn:Dr. Richard Tibbs
end:vcard

--------------47981B162FD3952DE8717AA4--

Delivery-date: Fri, 02 Mar 2001 08:25:00 -0800
To: Ron Bonica <[email-masked]>
cc: [email-masked]
Subject: Re: FW: Questions about tunneltrace 
Reply-To: [email-masked]
Date: Fri, 02 Mar 2001 11:23:46 -0500
From: Eric Rosen <[email-masked]>

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

Perhaps.   But then your  requirement of  not relying  on the  control plane
needs to be removed.

Once that requirement is removed, though, various other alternatives suggest
themselves, such  as using  SNMP to  get the information  from the  MIBs, or
having a special "trace packet" that accumulates the path information inside
itself, and  then returns the entire trace  in one packet back  to the user.
It would be useful  to see some discussion of why the  proposal in the draft
is better than these alternatives.  (Note  that I'm not saying that it isn't
better than these alternatives.) 

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

Can you articulate this layer violation?  

Delivery-date: Fri, 02 Mar 2001 07:34:54 -0800
From: "terry martin" <[email-masked]>
To: <[email-masked]>, "Bora Akyol" <[email-masked]>, "Vishal Sharma" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: Standards for IP stats collection? (corrected)
Date: Fri, 2 Mar 2001 07:30:32 -0800

RMON is the only protocol standard that dictates information collection
requirements.  That is the only IP service that is structured to collect
trend stats.  I think it is also 15 minute intervals for 3-5 days depending
on how much memory you get in the unit.

There are structure requirements for collection, type of traffic collected
and how it is presented.

Need sources- let me know

Terry Martin MS Telecommunication Engineering
Senior Consultant
[email-masked]
503-612-4422

----- Original Message -----
From: "Manohar Naidu Ellanti" <[email-masked]>
To: "Bora Akyol" <[email-masked]>; "Vishal Sharma"
<[email-masked]>
Cc: "[email-masked]'" <[email-masked]>; "[email-masked]'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, March 01, 2001 9:14 PM
Subject: RE: Standards for IP stats collection? (corrected)

> It will be interesting to see if there is a need for TDM world operational
> features to be carried into MPLS world.
>
> I think the reason for 15 minutes etc PM counters for things like Severely
> Errored Seconds etc was to deduce the quality of transmission line and use
> this to feed into link cost. For instance realiability metric could be
based
> on such information for the link.
>
> For LSPs does it really make sense ? to have TDM world operational
features.
> There is not even CRC or any header information to determine if MPLS
packet
> was received correctly. It is more at lower layers. It would be nice to
see
> some useful features carried forward and avoid unnecessary requirements
from
> GR-XXX.
>
> -Manohar
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
> Akyol
> Sent: Thursday, March 01, 2001 8:57 PM
> To: Vishal Sharma
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: Re: Standards for IP stats collection? (corrected)
>
>
> Vishal
>
> I don't think that there are such standards for routers. I know that some
> routers store such data on flash cards for later retrieval and some on
> hard disks.
>
> I would be curious to see how people are storing this data and for how
> long?
>
> Bora
>
>
> On Thu, 1 Mar 2001, Vishal Sharma wrote:
>
> > Hello All,
> >
> > For the TDM world, GR-253 lays out strict standards for
> > the length of time that a carrier-class box should collect
> > and store statistics on-board, for retrieval later. The
> > number is something like 15-min intervals for 3 days.
> > The purpose supposedly is that if the connection to the EMS
> > dies, the box at least should allow the provider to recover
> > statistics data from it.
> >
> > My question is: what are similar standards (or existing
> > best practices) in the IP carrier community today? How much
> > statistics-related information do carriers like to have from
> > IP boxes?
> > What would carriers like to have?
> >
> > (The only reference I could find on this was Blain Christian's
> > draft
> >
>
http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t
> > xt)
> >
> > Are there others?
> > Do people (read carriers) have any thoughts or suggestions or
> > pointers?
> >
> > Thanks,
> >
> > -Vishal
> >
>
>

Delivery-date: Thu, 01 Mar 2001 20:58:34 -0800
Date: Thu, 1 Mar 2001 20:56:33 -0800 (PST)
From: Bora Akyol <[email-masked]>
To: Vishal Sharma <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Standards for IP stats collection? (corrected)

Vishal

I don't think that there are such standards for routers. I know that some
routers store such data on flash cards for later retrieval and some on
hard disks.

I would be curious to see how people are storing this data and for how
long?

Bora

On Thu, 1 Mar 2001, Vishal Sharma wrote:

> Hello All,
> 
> For the TDM world, GR-253 lays out strict standards for
> the length of time that a carrier-class box should collect
> and store statistics on-board, for retrieval later. The
> number is something like 15-min intervals for 3 days.
> The purpose supposedly is that if the connection to the EMS
> dies, the box at least should allow the provider to recover
> statistics data from it.
> 
> My question is: what are similar standards (or existing
> best practices) in the IP carrier community today? How much
> statistics-related information do carriers like to have from
> IP boxes?
> What would carriers like to have?
> 
> (The only reference I could find on this was Blain Christian's
> draft 
> http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t
> xt)
> 
> Are there others? 
> Do people (read carriers) have any thoughts or suggestions or
> pointers?
> 
> Thanks,
> 
> -Vishal
> 

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Mar 2001 14:31:05 -0800
Date: Thu, 1 Mar 2001 14:27:31 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-walker-ccamp-req-00.txt]

>          Would it be worth splitting this document into
> two documents which can be tracked separately: requirements
> and framework?

Excellent point, Tom.

Kireeti.

Delivery-date: Thu, 01 Mar 2001 14:21:16 -0800
Date: Thu, 01 Mar 2001 17:21:54 -0500
To: [email-masked], CCAMP WG <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-walker-ccamp-req-00.txt]

         Would it be worth splitting this document into
two documents which can be tracked separately: requirements
and framework?

         --Tom

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Common Control and Measurement Plane Framework and
>                           Requirements
>         Author(s)       : D. Walker et al.
>         Filename        : draft-walker-ccamp-req-00.txt
>         Pages           : 33
>         Date            : 26-Feb-01
>
>This document describes architectural and protocol requirements for
>the Common Control and Measurement Plane.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-walker-ccamp-req-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-walker-ccamp-req-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-walker-ccamp-req-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-walker-ccamp-req-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-walker-ccamp-req-00.txt>

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Mar 2001 12:28:27 -0800
Date: Thu, 1 Mar 2001 12:24:28 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: CCAMP agenda -- general remarks

Thanks to all of you who have submitted drafts and indicated their
interest in speaking at the CCAMP WG in the upcoming IETF.  Vijay
and I will try really hard to accommodate all those requests that
we feel belong in CCAMP.  We'll send out the agenda as soon as we
can.

Since there are a lot of requests, it seems appropriate to waft in
your direction a friendly reminder (as Vijay and I have ourselves
been reminded by friendly folks on the IESG).  IETF veterans, please
indulge us.

1) Please do not make presentations.  Time slots will be short;
   assume that attendees have read the draft.  If this is a first
   draft, hit the highlights.  If this has been discussed before,
   emphasize the deltas.
2) Keep the talk technical.  Focus on those aspects that are hard
   to get across with the written word.  Draw pictures, wave hands,
   give the big picture.
3) If issues have been raised on the mailing list, address them.  If
   new issues come up, follow up on the mailing list.
4) Leave time for questions/discussion.

For those attending, PLEASE read the drafts.  Yes, there are a
lot of them out there.  However, it will greatly increase your
understanding, appreciation, blah, blah, blah.  Okay, no nagging.
Just read the drafts.  (Lou, no comments please :-))

Kireeti.

Delivery-date: Thu, 01 Mar 2001 07:08:35 -0800
To: Ron Bonica <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: FW: Questions about tunneltrace 
Date: Thu, 01 Mar 2001 07:05:30 -0800
From: Yakov Rekhter <[email-masked]>

Ron,

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

Well, you do have a choice - use the mechanism described in
draft-bonica-icmp-mpls-02.txt. This mechanisms does trace through the
user-plane (aka data-plane).

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

As "we are trying to avoid" layer violation, we need to keep in
mind the problem that we are trying to solve. So, what is exactly
the problem that we are trying to solve ?

Yakov.