MPLS - 74th IETF San Francisco1 Composite Transport Group (CTG) Framework and Requirements draft-so-yong-mpls-ctg-framework-requirement-01.txt draft-so-yong-mpls-ctg-framework-requirement-01.txt Ning Andrew Malis Dave McDysan Lucy Yong Fredric

MPLS - 74th IETF San Francisco2 CTG Framework CTG creates CTG connections on the composite link CTG connection must have assigned BW and is eligible to transport on any component link LSP, LDP or IGP traffic is mapped to CTG connections CTG connection TE can be derived from LSP TE or from auto BW measurement CTG selects one component link to transport an CTG connection based on TE of CTG connections and component link condition The selection may change due to component failure or CTG connection condition changes CTGCTG CTGCTG Composite Link Component Links 5 CTG connections 3 CTG connections 9 CTG connections LSP, LDP, IGP R1R2

MPLS - 74th IETF San Francisco3 Requirements for CTG CTG Appearance as a Routable Virtual Interface Multiple routing instances see a separate "virtual interface" to a shared composite transport group composed of parallel physical links between a pair of routers. The CTG would communicate parameters (e.g., admin cost, available bandwidth, maximum bandwidth, allowable bandwidth) for the "virtual interface" associated with each routing instance. CTG mapping of traffic to Component Links for all connections with and/or without TE information Using TE information from the control planes of the routing instances attached to the virtual interface when available, or Using traffic measurements when it is not. Bandwidth Control for Connections with and without TE information CTG SHALL support a policy based preemption capability such that, in the event of such a "bandwidth shortage", the signaled or configured preemption and holding parameters can be applied to the following treatments to the connections: For a connection that has RSVP-TE LSP(s), signal the router that the LSP has been preempted. CTG SHALL support soft preemption (i.e., notify the preempted LSP source prior to preemption). [Soft Preemption] For a connection that has LDP(s), where the CTG is aware of the LDP signaling involved to the preempted label stack depth, signal release of the label to the router For a connection that has non-re-routable RSVP-TE LSP(s) or non-releasable LDP(s), signal the router or operator that the LSP or LDP has been lost.

MPLS - 74th IETF San Francisco4 Requirements for CTG CTG Transport Resilience Restore impacted traffic over other component links when there are capacity without reconfiguring LSP and LDP Preempt LSP and LDP based on holding priority when composite link does not have resource to carry them Fast recovery and minimized service interruption CTG Operational and Performance CTG requires methods to dampen the frequency of connection bandwidth change and/or connection to component link mapping changes (e.g., for re-optimization). Operator imposed control policy SHALL be allowed. CTG SHALL support latency sensitive traffic. The determination of latency sensitive traffic SHALL be determined by any of the following methods: Use of a pre-defined local policy setting at CTG ingress A manually configured setting at CTG ingress MPLS traffic class in a RSVP-TE signaling message –Pre-set bits in the Payload (e.g., DSCP bits for IP or Ethernet user priority for Ethernet payload) The determination of latency sensitive traffic SHOULD be determined (if possible) by pre-set bits in the Payload (e.g., DSCP bits for IP or Ethernet user priority for Ethernet payload)

MPLS - 74th IETF San Francisco5 Differences between version 0 and version 1 Added requirement to support the following Adding and removing of component links by operator provisioning or in response to signaling from lower layer (GMPLS) time sensitive traffic numbered and un-numbered links Operator assignment of traffic flow to component links soft pre-emption Entropy labels Preemption for non-reroutable RSVP-TE LSP(s) and non-releasable LDP(s) Addressed packet re-ordering concerns by Adding requirements to allow operator control the frequency of CTG path changes and the rate of occurrence for these reordering or inter-packet delay variation events Adding requirements to employ make-before-break when a connection to component link mapping change has to occur Adding the description about the condition under which moving CTG connection without causing packet re-ordering Elaborated the needs for CTG in the MPLS networks

MPLS - 74th IETF San Francisco6 Differences between version 0 and version 1 New author is added Fredric Jounay from France Telecom Acknowledgements Authors would like to thank Nabil Bitar from Verizon and Eric Gray from Ericsson for their reviews and great input

MPLS - 74th IETF San Francisco7 Next Step Request for this draft to become a rtgwg draft.