Subject: GMPLS - Lable request information

From: Heiles Juergen <[email-masked]>
Date: Mon, 11 Dec 2000 13:07:50 +0100

Hi,

I hope you have a nice time in San Diego. I will not be at the meeting, however I will provide some input for the discussion on label request information.

LSP Encoding:
I am not sure if it we really have to differentiate between the different technologies as the characteristic information field (see below) already provides this information.

Link Protection Flags:
A request for a specific protection scheme for each link is not very usefull (independent 1+1 potections over each will result in single points of failure at each LSR), instead the specific service class (availability) requested for the end-to-end LSP should be indicated. How this service class is implemented depends on the specific network/operator.

Generalized PID:
Similary to the signal lable in SDH/Sonet. the paylaod type is usefull during the selection of the correct endpoints (e.g. for a phone call I dial the number of the telephone, for  fax the number of the fax machine and for a data connnection the modem number). a end system taht supports several paylaod types can select the correct one base on this information.

Bandwidth Encoding and SDH/Sonet specifc fields (Requested Grouping Type/Transparency/Number of Components => Characterisitc Information):
It identifies the characterisitc information of the LSP. In our view it is confusing and not required to introduce the additional SDH/Sonet fields as they depend on each other and on the bandwidth. They leave room for mis-configuration. The bandwidth endcoding is also not clear on the SDH/Sonet formats. STM-1 or STM-16 is not enough. What is needed is the specific characterisitc information for the LSP. This can be encoded in one field and includes the tranparency and concatenation information as shown below:

Type     Characteristic information     Comment                                                 
P0:      64 kbit/s
P11s:    DS-1 framed 1,554 Mbit/s
P11x:    1,554 Mbit/s transparent       doesn't care about the specific frame strucutur
P12s:    PDH framed 2,048 Mbit/s (E1)
P12x:    2,048 Mbit/s transparent       doesn't care about the specific frame strucutur)
P21e:    DS-2 framed 6,312 Mbit/s
P21x:    6,312 Mbit/s transparent       doesn't care about the specific frame strucutur)
P22e:    PDH framed 8,448 Mbit/s (E2)
P22x:    8,448 Mbit/s transparent       doesn't care about the specific frame strucutur)
P31e:    PDH framed 34 Mbit/s (E3)
P31x:    34 Mbit/s transparent          doesn't care about the specific frame strucutur)
P31s:    SDH framed 34 Mbit/s
P32e:    DS-3 framed 45 Mbit/s
P32x:    45 Mbit/s transparent          doesn't care about the specific frame strucutur)
P4e:     PDH framed 140 Mbit/s (E4)
P4x:     140 Mbit/s transparent         doesn't care about the specific frame strucutur)
P4s:     SDH framed 140 Mbit/s

VC-11:   SDH VC-11/Sonet VT1.5-SPE
VC-12:   SDH VC-12/Sonet VT2-SPE
VC-2:    SDH VC-2/Sonet VT6-SPE
VC-3:    SDH VC-3/Sonet STS-1-SPE
VC-4:    SDH VC-4/Sonet STS3c-SPE
VC-4-nc: contiguous concateantion of n VC-4/STS-3c-SPE
VC-4-nv: vitual concatenation of n VC-4/STS-3c-SPE  
MSn:     STM-n Multiplex Section/STS-3n Line     RS/Section OH can be terminated
RSn:     STM-n Regenerator Section/STS-3n Section   Transparent for whole STM-n signal

ODU1:    2.5 Gbit/S ODU signal
ODU2:    10 Gbit/s ODU Signal
ODU3:    40 Gbit/s ODU Signal

OChx:    Transparent Optical Channel of bandwidth x
Note: add the end of section 3.1 of the document it says that "photonic encoding" doesn't need knowledge about speed and modulation. This is not fully true. Even the "photoic" transport needs informatin about the bandwidth of the signal in order to fit into the wavlength slots with a certain bandwidth. The bandwidth is defined by the signal speed and modulation.
OMSn:    Bundle of n Optical Channels
10MbE:   10 Mbit/s Ethernet
100MbE:  100 Mbit/s Ethernet
1GbE:	   1 Gbit/s Ethernet
10GbEL:  10 Gbit/s Ethernet LAN
10GbEW:  10 Gbit/s Ethernet WAN   only requried if differetn from VC-4-64c 

The addition of new signals (characteristic information) is easy and doesn't require additonal fields.

Regards

Juergen

---

From: [email-masked]
Date: Tue, 19 Dec 2000 07:22:57 -0000

Hi Juergen...some observations:
	<snipped>
> LSP Encoding:
> I am not sure if it we really have to differentiate between the different
> technologies as the characteristic information field (see below) already
> provides this information.
> 
> Link Protection Flags:
> A request for a specific protection scheme for each link is not very
> usefull (independent 1+1 potections over each will result in single points
> of failure at each LSR), instead the specific service class (availability)
> requested for the end-to-end LSP should be indicated. How this service
> class is implemented depends on the specific network/operator.
	NH=> Few points.  Its not clear to me that having lots of priorities
(and esp bumping across these) is a good idea.......we tried it some time
ago and won't do it again in a hurry.  Why?  Only time its important is at
high utilisation....but this is exactly the time when its effects are
unpredictable, ie N hits for 1 as the pre-emption bumping ripples
out......and then you have to put the routing back after repair (another N
hits).  Keep it simple is our view and I would focus on 'priority (ie who
gets served 1st) in restoration' without multi-class bumping....though I am
happy with the concept of 'extra traffic'. 
	Note -  One also has to consider the impact due to DiffServ at high
utilisation, but in this case we mutate failures into (skewed) QoS
hits........noting that there is no relationship between a traffic's
survivability needs and its up-state QoS forwarding treatment, eg voice can
be mission critical in one VPN and of no real importance in another, but
both must go EF.  Bad news if one aggregates VPN traffic of the same DS
class.....just how can one state the % topology survivability index for each
VPN now (its also a function of the actual traffic per VPN in effect at the
time of failure)?  Currently I believe most operators over-engineer to hide
this behaviour, but this is not a good/sustainable solution.
	Its also not a good idea to have multiple levels of prot-sw.
Perhaps the best model is to go as high as possible (ie close to
application) and as low as possible (close to duct) and miss out
intermediate levels that do not support a peer-level (external) service
entry point.
	In a switched transport network (eg OTN) one also has to consider
holding-time as a function of the need for adding prot-sw.  That is, the
probability of failure will be some linear function of time and some
non-linear function (in practice if not theory) of trail length (the
environment is actually the major factor here, but is not so easy to model).
So short-holding trails might not warrant any prot-sw resource to be
allocated, even though they are of high priority....and (Kireeti) this is
another reason to decouple priority and prot-sw needs as we discussed last
week.

> Generalized PID:
> Similary to the signal lable in SDH/Sonet. the paylaod type is usefull
> during the selection of the correct endpoints (e.g. for a phone call I
> dial the number of the telephone, for  fax the number of the fax machine
> and for a data connnection the modem number). a end system taht supports
> several paylaod types can select the correct one base on this information.
	NH=> This seems more like the concept of 'names'......and there is a
difference between client layer names (formed from addresses which are
non-routable in the server) and names of external devices which are not
layer networks.  In particular, in the former case one is always dealing
with a double-ended entity (ie the client layer link connection) where one
is using a name/address binding to the server, whilst in the latter case one
has a single-ended entity (at least from the concept of name/address binding
at the time of attachment).

> Bandwidth Encoding and SDH/Sonet specifc fields (Requested Grouping
> Type/Transparency/Number of Components => Characterisitc Information):
> It identifies the characterisitc information of the LSP. In our view it is
> confusing and not required to introduce the additional SDH/Sonet fields as
> they depend on each other and on the bandwidth. They leave room for
> mis-configuration. The bandwidth endcoding is also not clear on the
> SDH/Sonet formats. STM-1 or STM-16 is not enough. What is needed is the
> specific characterisitc information for the LSP. This can be encoded in
> one field and includes the tranparency and concatenation information as
> shown below:
> 
	NH=> Is anyone still using 8M?  If these are not common transport
layers we should remove them....ditto 34M.
> P31e:    PDH framed 34 Mbit/s (E3)
	NH=> There are also 2 varieties of 34M frame.  There is one for the
true PDH, ie client is always 8M, and there is one for a pure ATM client
(G.832 rings a bell but needs checking).  Same applies at 140M, ie true 34M
client or ATM client.
> Note: add the end of section 3.1 of the document it says that "photonic
> encoding" doesn't need knowledge about speed and modulation. This is not
> fully true. Even the "photoic" transport needs informatin about the
> bandwidth of the signal in order to fit into the wavlength slots with a
> certain bandwidth. The bandwidth is defined by the signal speed and
> modulation.