LMP extensions for G.709 Optical Transport Networks

1. LMP extensions for G.709 Optical Transport Networks CCAMP WG, IETF 76th, Hiroshima, Japan draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt Fatai Zhang Dan Li Daniele Ceccarelli Diego Caviglia Guoying Zhang Pietro Grandi Sergio Belotti <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>

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

3. Requirement (1): Correlating of TS granularity • Data plane backward compatibility: Path TS1 TS2 TS3 TS4 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS8 Node B should work in the 2.5G TS Mode Node A (Old Node) Node B (New Node) 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

4. Requirement (2): Correlating of supported LO ODUs • 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 B Port that supports ODUflex Port that doesn’t support ODUflex Support ODUflex Support ODUflex A C D Not support ODUflex Not support ODUflex

5. Extensions to the LMP (1) A B LinkSummary: (1) the TS type that A supports (2) the LO ODU types that A supports Negotiating… The same capability as A LinkSummaryAck A B LinkSummary: (1) the TS type that A supports (2) the LO ODU types that A supports Negotiating… X Different capability from A LinkSummaryNack: (1) the TS type that both ends support (2) the LO ODU types that both ends support

6. Extensions to the LMP (2) • 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • 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

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

8. Port that supports ODUflex Port that doesn’t support ODUflex Open Discussions (2) • Routing VS LMP (Routing can replace LMP?) • 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, EVERYNODE 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” OSPF: link A-C support ODUflex OSPF: link A-C NOT support ODUflex B A C Not support ODUflex

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