Subject: RE: Three GMPLS related IDs

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

---

From: Sivakumar Sankaranarayanan <[email-masked]>
Date: Thu, 15 Mar 2001 15:36:39 -0500

Neil,
  I generally agree with your observations, please see below for some specific
comments...

Regards,
Shiva.

> a sensible decision since something larger that 32 bits will surely be

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

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

> changes one protocol one would not want to create backwards compatibility

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

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

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 15 Mar 2001 15:14:06 -0500

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

> several operators have input (requirements) to it and it is not just sourced

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.

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

> 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?
 
> path and reserve resources, so restoration is very fast.  This leads me to

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?

> be the case and we would want to identify trail restoration priority

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?

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

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

> 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

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 15 Mar 2001 15:42:37 -0500

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

> not open the label-request one):

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