MPLS - 73nd IETF Minneaplis1 Composite Transport Group (CTG) Framework and Requirements draft-so-yong-mpls-ctg-framework-requirement-00.txt draft-so-yong-mpls-ctg-framework-requirement-00.txt Ning So Andrew Malis Dave McDysan Lucy Yong

MPLS - 73nd IETF Minneaplis2 Motivation Issues when deploying multiple parallel links in MPLS backbone Aggregated link utilization is not efficient Some links many be congested while others stay near empty Operators do not have enough ability to control the traffic flows under this network environment Inefficiency/Inflexibility of Logical Interface Bandwidth Allocation Ship-in-the-night mode when using multiple logically-separated routing instances in single physical router Draft provides: Problem statement in today’s IP/MPLS network Composite Transport Group Framework Composite Transport Group Requirments Objective: Develop an aggregated traffic transport method over multilink trunk to resolve the problems today’s MPLS enabled network

MPLS - 73nd IETF Minneaplis3 Issue when using multi parallel links Hashing Assume network transporting large amount of micro flows with similar bandwidth requirements It does not work under the following operating conditions Large portion of the customer traffic are encrypted so the in coming flows cannot be broken down into micro flows Some machine-to-machine traffic flows are at ultra-high rate Multiple parallel trunks have different bandwidth, interface types, and/or latencies Assigning individual LSPs to links using planning tool Bypass tunnel bandwidth for LSPs are often set to near 0 to free up backbone bandwidth for other traffic During the network failure congestion may happen on some of the parallel trunks while others are almost empty Facility Protection Require a dedicated link for protection. No protection sharing when using multiple links and unwanted link performance degradation

MPLS - 73nd IETF Minneaplis4 Issue when using multi parallel links (2) Existing technology leads to poor link utilization or poor performance. Without per-flow TE information, LDP network has even more problem utilizing multiple parallel backbone trunk efficiently Carriers forced to deploy single higher capacity link, which is more expensive, and often not widely available. Multiple logically-separate routing instances in a single physical router Sharing common parallel backbone when aggregated traffic exceeds a single link becomes impossible due to the ship-in-the- night operating condition Delicate physical link for each routing instance is not efficient Delicate link capacity for each routing instance limits carrying a high rate of flows

MPLS - 73nd IETF Minneaplis5 Composite Transport Group (CTG) CTG is the method to transport aggregated traffic over a composite link Composite Link is defined in ITU-T Q12 G.800 Contain multiple component links supported by separate server layer trails Transport over a composite link may not preserve the symbol sequence CTG is a local traffic engineering and transport selection technology Give traffic engineering among component links Provide component link recovery Auto flow measurement

MPLS - 73nd IETF Minneaplis6 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 IP 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, IP R1R2 Note: To reduce auto BW measurement burden, it is expected that LDP and IP traffic is in small amount.

MPLS - 73nd IETF Minneaplis7 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 The CTG SHALL support a policy based preemption capability such as the signaled or configured preemption and holding parameters For RSVP-TE LSP(s), signal the router that the TE-LSP has been preempted. For 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 IP traffic without MPLS labels, indicate congestion to the router or block IP traffic. CTG Transport Resilience

MPLS - 73nd IETF Minneaplis8 Next Steps Seeking input/comments from other carriers on the problem statement, framework and requirements Determine what aspects are relevant to IETF standards Determine what aspects are relevant to an informational IETF RFC Seeking carriers and vendors to work on a CTG solution draft in parallel with refinement of requirements. What is the best IETF working group(s) to discuss this draft in the next meeting(s)? Is there a re-chartering necessary in these group(s)?

MPLS - 73nd IETF Minneaplis9 Acknowledgement Many Thanks to: Frederic Jounay from France Telecom Adrian Farrel from Olddog Ron Bonica from Juniper For the reviews and great suggestions. Feedbacks and comments are welcome