Subject: Re: [CCAMP] OTN signalling drafts status

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 4 Jul 2011 10:56:37 +0000

Hi Jonathan,

Pls see inline with tag [KP,AK]

Thanks
Khuzema and Ashok.

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 7:56 PM
To: Khuzema Pithewan; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Cc: Biao Lu; Ping Pan; Mohit Misra; Ashok Kunjidhapatham; Rajan Rao; Radhakrishna Valiveti
Subject: RE: OTN signalling drafts status

Hi Khuzema.

See inline for my comments, marked with [JS].

Jonathan Sadler

-->8 SNIP 8<--

I've looked at your interpretation of how the requirements you've stated below are satisfied/not satisfied by the two drafts under consideration and would like to ask you about two of your conclusions:

Requirement

Draft-Zhang

Draft-Khuzema

R2

Supported using H-LSPs for each HO-ODU layers

Supported without H-LSPs. Achieves scalability and better restoration performance.

You state that "better" scalability and restoration performance is achieved in Draft-Khuzema - I interpret your statement this assuming that under the H-LSP approach, any change of a service layer LSP requires a change to both the service LSP as well as the lower layer LSP.  Please validate my interpretation.

KP: Better scalability comes from the fact that, we do not have to advertise H-LSP as FAs , hence reducing number of TE-Links in the network. Better restoration performance comes, as you correctly understood, we do not have to create lower layer LSP, saving signaling time.

[JS] I understand there is a reduction of routing information that comes from not advertising the H-LSPs, though your assertion this helps scalability seems to be assuming a specific routing approach (e.g. distributed path computation dependent on a replicated distributed topology database).  Other routing approaches (e.g. PCE) are not adversely affected.

[KP, AK]: Well it depends on number of such links in the network and CPU horsepower, available memory etc of network elements. Since system parameters are playing a role, it's hardly justifying the flooding of information which can be avoided.

[JS] Independent of this, the choice to not advertise the fact that a lower layer connection was established to support higher layer connections leads to stranded capacity.  This has significant operational (and cost) impact to network operators.  Under the H-LSP approach, the operator has the choice to advertise or not for each H-LSP, thereby allowing for the operator to better trade-off scalability concerns and resource utilization.

[KP, AK] If operator wants to plan single hop H-LSPs and create them before signaling service ODUj LSP, he can do so. Multi-stage label approach is replacing "induced" single hop H-LSPs. Whether a service layer ODUj is inducing single hop H-LSP or using multi-stage label, both comes with same risk of leaving stranded capacity, as it depends on the resource allocation algorithm.

Please also validate my understanding of the solution proposed in draft-khuzema: it seems the solution proposed requires separate signaling for each of the service LSPs to perform restoration.  In the case of an ODU3 full of ODU0s, this would be 32 LSPs with 32 separate signaling actions when restoration is required.

Under the H-LSP solution in draft-zhang, the same scenario of an ODU3 full of ODU0s would require 33 LSPs (32 for the ODU0s and 1 for the ODU3). However, explicitly signaling the ODU3 LSP makes it possible to have restoration performed on the ODU3, benefiting all of the ODU0 LSPs with one signaling action.  I therefore would expect the H-LSP solution to have better restoration performance.

KP: The Multi-stage label removes the necessity of single hop H-LSP. Multi-stage label construct works in conjunction with H-LSP for the cases when Lower layer ODU layer is required to be setup for multiple hops. That is requirement# R6.

Hence I assume when you are comparing multi-stage and H-LSP, you are talking about single hop H-LSP. Since it is a single hop H-LSP, it has only one link between 2 interfaces and hence there is no way it can restore, if link has gone down. Now those 32 LSPs has to restore, and depending on the path they find, it may involve mulit-stage or H-LSPs.

[JS] Actually, I was considering the single hop case and signaling restoration of traffic to a different link between two neighboring nodes (the link could be within a bundle or otherwise).  Restoration certainly can be done for the lower layer LSP as long as it goes between the same to fabrics being connected by the original link.  And the upper layer LSPs don't need to move as they all benefit from the restoration of the lower layer LSP.

[JS] Your discussion above though points out another benefit of the H-LSP approach.  When restoration of a single-hop LSP requires going to a multi-hop path, the H-LSP can again facilitate the reroute action with a single signaling exchange between the nodes involved in the lower layer LSP.  The use of multi-stage labels requires separate signaling exchanges between the same nodes, which can be a significantly higher number of messages.

[KP, AK]: All your above discussion about ability to restore a single hop H-LSP assumes that operator wants to and has the alternate restoration path for the link. But there are other possibilities

*         What if the link is protected (1+1, 1:n), then the H-LSP need not restore and use of multi-stage is ok.

*         What if there is no alternate path of the link, then the ODUj service layer LSP has to restore end-to-end.
The point is, the operator can still use multi-stage wherever required. If operator don't want to use multi-stage, s/he can go ahead and plan H-LSPs in these cases.

Requirement

Draft-Zhang

Draft-Khuzema

R5

Not Supported

Supported

R5 states a requirement for egress interface control, and your conclusions above state it isn't possible to support this in draft-zhang and can be supported in draft-khuzema.

There are solutions that allow for egress control to be satisfied using draft-zhang (e.g. assigning ifIndexes to potential H-LSPs defining the intermediate ODUj - these can then be specified in an ERO).  This approach has the advantage of working with un-bundled as well as bundled egress links, including bundles made up of links using different lower layer speed/technologies (e.g. a bundle of OTU3 and ODU4)

KP: draft-khuzema does it in single lsp setup (through signaling of course) and hence avoid multiple manual steps to create those H-LSPs. Whatever can be done through signaling can also be done manually. Draft-zhang relies on manual steps, that's the reason of marking that requirement as Not supported.

[JS] I'm not certain I understand the manual steps you are citing.  The only thing required is the assignment of ifIndexes to the potential H-LSPs and the establishment of the lower layer connections .  This can be done automatically by equipment.

[KP, AK]: How system will know about creating a certain multiplexing hierarchy and assign the interface indices to each layer i.e. service layer and all the lower layers?

Can you explain how the solution specified in draft-khuzema can handle bundle links where different lower layer speeds are in use?

KP: In the multi-stage label construct, we are not talking about links, the construct is to identify data plane layer and their time slots. Bundling or no-bundling, doesn't have any impact.

[JS]  I disagree.  Egress label control requires the egress label format to be known.  If the egress link has multiple links in a bundle of different type (e.g. a bundle of OTU3 and OTU4), under the multi-stage label proposal, the label format ends up changing if a resource is being specified on the OTU3 link vs the OTU4 link.  Its inherent due to the different "time slot" (sic) structure of the egress link.

[KP, AK] :  For bundled links, Label is applicable to a component in a bundle. So whether it is single stage or multi-stage, the talk of label will start only after you have identified the component in the bundle.  Even for BUNDLE_SCOPE labels (RFC 4201, sec 2.3), the label is applicable for all the components in the bundle. So In your example whether it is OTU3 component or OTU4 component, the IF_ID TLV will identify the right component  and label needs to be interpreted in the conjunction with the same.

Thanks,

Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Monday, June 27, 2011 11:23 PM
To: GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); 'CCAMP'
Subject: Re: [CCAMP] OTN signalling drafts status

Thanks Pietro and Sergio for starting this off.

Hi CCampers,

We would like to provide more context to multi-stage label approach for better understanding.  OTN is inherently a hierarchical network, and there are/will be cases where service ODU has to go through mandatory creation of more than one layer because of various technical/economic reasons. We are listing here requirements for supporting services over hierarchical OTN network.

1.      [R1] Support signaling mechanism to instantiate ODUj service layer on a ODUk link via single stage muxing.

A ODUj LSP could involve zero (j=k) or one stage (j<k) multiplexing on a given ODUk link. Here both Control-plane and Data-plane entities are created for the ODUj service layer. ODUk link could be a point-to-point OTUk link or a H-LSP.

2.      [R2] Support signaling mechanism to instantiate one or more intermediate layers on a ODUk link in order to support the ODUj service layer.

A ODUj LSP could involve two or more stage multiplexing on a given ODUk link. These intermediate layers can be implicitly created as a part of ODUj service LSP creation. In this case, both controlplane and dataplane entities will be created for the ODUj service layer. However, intermediate ODU layer(s) (implicitly created) will have dataplane representation only.

3.      [R3] Support signaling mechanism to instantiate ODUj service layer on a ODUk link where one or more intermediate ODU layers may be pre-existing.

A ODUj LSP could involve two or more stage multiplexing on a given ODUk link. These intermediate layers may be pre-existing  as a result of another LSP creation on the same ODU hierarchy or explicitly configured through management interface.

4.      [R4] Support signaling mechanism where ODUj service LSP creation may involve varying mux hierarchies on each hop

An end-to-end ODUj service LSP creation may involve zero or more stage ODU multiplexing on every hop in the path. Basically,the scenarios discussed in R1 to R3 could be associated with any of the hops involved.

5.      [R5] Support signaling mechanism for egress control of OTN interfaces

An egress interface of a ODUj LSP could involve single or multiple stage multiplexing. Egress Label sub-object defined in [RFC-4003] must be used to signal hierarchical multiplexing information pertaining to the egress interface of the LSP.

6.      [R6] Support signaling mechanism when ODUj service LSP creation requires induced or manually created H-LSP.

Based on the above requirements, following is the comparison between two drafts under discussion.

Requirement

Draft-Zhang

Draft-Khuzema

R1

Supported

Supported

R2

Supported using H-LSPs for each HO-ODU layers

Supported without H-LSPs. Achieves scalability and better restoration performance.

R3

Supported using H-LSPs for each non-existing HO-ODU layers

Supported without H-LSPs

R4

Supported using H-LSPs for each HO-ODU layers

Supported without H-LSPs

R5

Not Supported

Supported

R6

Supported using H-LSP

Supported using H-LSP

Would like to hear opinions.

Authors draft-khuzema

From: [email-masked] [mailto:[email-masked]] On Behalf Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Monday, June 27, 2011 6:53 PM
To: 'CCAMP'
Subject: [CCAMP] OTN signalling drafts status

Hello CCampers,

Currently two drafts exist for the signaling of LSPs in OTN technology.
The two drafts, namely draft-zhang-ccamp-gmpls-evolving-g709 and
draft-khuzema-ccamp-gmpls-signaling-g709, contain a lot of similarities
but are fundamentally different with respect to the support of multi-stage technology.

Draft-zhang proposes to deal with multi-stage technology via the usage
of H-LSPs as already defined in RFC6107. With this approach all LSPs
belonging to intermediate layers of a hierarchy are signaled as separate H-LSPs.
Monitoring, protection and restoration functionalities are applicable independently to each LSP.

Draft-khuzema proposes to introduce a new multi-stage label concept so that
a single construct contains labels associated to more then one hierarchical level.
This implies that all level in the OTN  hierarchy with the exclusion of service levels
are not visible as single LSPs.
Each layer cannot be independently monitored.
Only the service layer (the layer with the finest granularity) can be protected or restored.

Advantages and disadvantages of both approaches can be summarized in short, telling that
the H-LSP approach is able to work in any situation while the multi-stage label approach is suitable
on single hops or similar situations (reached signaling before an H-LSP) but, when used,
optimizes processing.

As such we perceive the Draft-khuzema approach as an optimization that could be supported in an optional way.

Before going on with merging of the two drafts we would like to hear opinions from CCampers.

Pietro & Sergio

============================================
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================