CCAMP WG, IETF 76th, Hiroshima, Japan draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt LMP extensions for G.709 Optical Transport Networks 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 ) Old device = device that support G 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: TS1 TS2 TS3 TS4 TS1 TS2 TS3 TS4 TS5 TS6 TS7 TS8 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 Not support ODUflex Port that supports ODUflex Port 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 A LinkSummaryAck A LinkSummary: (1) the TS type that A supports (2) the LO ODU types that A supports B Negotiating… X Different capability from A LinkSummaryNack: (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 | 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 C Not support ODUflex Port that supports ODUflex Port 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