CCAMP WG, IETF 76th, Hiroshima, Japan

draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt

LMP extensions for G.709 Optical Transport Networks

<zhangfatai@huawei.com>

<danli@huawei.com>

<daniele.ceccarelli@ericsson.com>

<diego.caviglia@ericsson.com>

<zhangguoying@mail.ritt.com.cn>

<pietro_vittorio.grandi@alcatel-lucent.it>

<sergio.belotti@alcatel-lucent.it>

Fatai Zhang

Dan Li

Daniele Ceccarelli

Diego Caviglia

Guoying Zhang

Pietro Grandi

Sergio Belotti

Motivations• With the evolution of G.709, the backward compatibility

problem requires to be considered • In data plane:

– New devices can interwork with old devices• New device = device that support G.709 v3 (consented in 2009.10)• Old device = device that support G.709 2003

• In control plane:– The TS granularity at two ends of a link must be correlated– The LO ODU signal types that the two ends of a link can

support must be correlated

• Objective: to extend the LMP to correlate the properties of an OTU link (including the TS granularity and supported LO ODU types)

Requirement (1): Correlating of TS granularity

• Data plane backward compatibility:

TS1TS2TS3TS4

TS1TS2TS3TS4TS5TS6TS7TS8

Node A

(Old Node)

Node B

(New Node)

Path

Resv

• in order to reserve the correct TSs, control plane must correlate the TS granularity that both ends of a link support

• Example (figure above):– Node B learns that Node A only supports 2.5G TS– Node B itself reserves the TS#i and TS#i+4 (1.25G)– Node B tells Node A to reserve the TS#i (2.5G) via Resv message

Node B should work in the 2.5G TS Mode

Requirement (2): Correlating of supported LO ODUs

A

B

DC

Support ODUflex

Support ODUflex

Not support ODUflex

Not support ODUflex

Port that supports ODUflexPort that doesn’t support ODUflex

• Equipment does not always support all LO ODU types• In order to compute a correct path, node must correlate

which types of LO ODU that both ends of a link can support, and flood this information

• Example (figure below):– To provide one ODUflex service, node A chooses A-B-D

(because link A-C and link C-D don’t support ODUflex)– Avoiding signal crankback at node C

Extensions to the LMP (1)A

LinkSummary: (1) the TS type that A supports (2) the LO ODU types that A supports

B

Negotiating…

The same capability as ALinkSummaryAck

ALinkSummary: (1) the TS type that A supports (2) the LO ODU types that A supports

B

Negotiating…

X Different capability from ALinkSummaryNack: (1) the TS type that both ends support (2) the LO ODU types that both ends support

• Extension to the LMP messages:– A new HO ODU Link Capability subobject is introduced to the

DATA LINK object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |OD(T)Uk| T | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C|D|E|F|G| LO ODU Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extensions to the LMP (2)

• When negotiating at the remote node:– Only if both two ends of a link support 1.25G TS (T=0), the negotiated

granularity of the link is 1.25G– If any one end of the link only supports the old 2.5G TS (T=1), the

negotiated granularity of the link is 2.5G– All the LO ODU types that both two ends can support are extracted,

which are the negotiated LO ODU types that the link can support

Open Discussions (1) Can Data Plane negotiate TS Mode?

• No explicit description to indicate that Data Plane has the mechanism to negotiate TS Mode automatically.

• We can only assume that Data Plane can negotiate TS Mode in the case of bidirectional link. ( e.g., A HO ODU2/3 port supporting 1.25G TSs will start up with PT=21. Then this port receives a HO ODU2/3 signal with a PT=20 (case of bidirectional link), then this port may change its PT=21 to PT=20).

• In fact, Typically the NMS (or CP) is responsible to set the PT to 20 and the corresponding mode (like the above example).

Obviously, it is reasonable to use Control Plane to correlate the TS type

• Either bidirectional link or unidirectional link is OK

• No need of the capability of Data Plane negotiation

• Only software processing is extended

CP Negotiation ---- More flexible, extensible and easy realization

Open Discussions (2) Routing VS LMP (Routing can replace LMP?)

A

B

CNot support

ODUflex

Port that supports ODUflexPort that doesn’t support ODUflex

OSPF:link A-C support ODUflex

OSPF:link A-C NOT support ODUflex

it’s more reasonable to use LMP• IGP advertises a consistent view of both ends of a single direciton of a link• LMP is used to ensure that the information advertised by the IGP is correct• What we do is Link Property Correlation (i.e., link scope), which is

the duty of LMP, NOT routing

Using routing is not a good idea!• Fake routing information is advertised: Node A tell Node B (and other

nodes) that link A-C supports ODUflex, which in fact is WRONG.

• Increase complexity: For each link, EVERY NODE in the network needs to correlate the capability at both ends of the link, and determines the actual link capability.

• Break the general rule: we should advertise the consistent and right TE information through LSA. Let us think about why we need LMP to do “Link Property Correlation”

Next Steps

• Refine it according to the feedback from the meeting or mailing list

• Keep it consistent with the requirements described in [OTN-Ctrl-Fwk] draft

• Comments are always appreciated