draft-ietf-rtgwg-cl-requirement-03.txt   draft-ietf-rtgwg-cl-requirement-04.txt 
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft Infinera Corporation Internet-Draft Infinera Corporation
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: July 14, 2011 S. Ning Expires: September 15, 2011 S. Ning
A. Malis A. Malis
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
January 10, 2011 March 14, 2011
Requirements for MPLS Over a Composite Link Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-03 draft-ietf-rtgwg-cl-requirement-04
Abstract Abstract
There is often a need to provide large aggregates of bandwidth that There is often a need to provide large aggregates of bandwidth that
are best provided using parallel links between routers or MPLS LSR. are best provided using parallel links between routers or MPLS LSR.
In core networks there is often no alternative since the aggregate In core networks there is often no alternative since the aggregate
capacities of core networks today far exceed the capacity of a single capacities of core networks today far exceed the capacity of a single
physical link or single packet processing element. physical link or single packet processing element.
The presence of parallel links, with each link potentially comprised The presence of parallel links, with each link potentially comprised
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
9.3. Appendix References . . . . . . . . . . . . . . . . . . . 12 9.3. Appendix References . . . . . . . . . . . . . . . . . . . 12
Appendix A. More Details on Existing Network Operator Appendix A. More Details on Existing Network Operator
Practices and Protocol Usage . . . . . . . . . . . . 13 Practices and Protocol Usage . . . . . . . . . . . . 13
Appendix B. Existing Multipath Standards and Techniques . . . . . 15 Appendix B. Existing Multipath Standards and Techniques . . . . . 15
B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 16 B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 16
B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 17 B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 17
B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 17 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 18
B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 18 B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 18
Appendix C. ITU-T G.800 Composite Link Definitions and Appendix C. ITU-T G.800 Composite Link Definitions and
Terminology . . . . . . . . . . . . . . . . . . . . . 18 Terminology . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The purpose of this document is to describe why network operators The purpose of this document is to describe why network operators
require certain functions in order to solve certain business problems require certain functions in order to solve certain business problems
(Section 2). The intent is to first describe why things need to be (Section 2). The intent is to first describe why things need to be
skipping to change at page 9, line 12 skipping to change at page 9, line 12
section 3, a flow is a sequence of packets that must be section 3, a flow is a sequence of packets that must be
transferred on one component link. transferred on one component link.
FR#20 The solution SHOULD support the use case where a composite FR#20 The solution SHOULD support the use case where a composite
link itself is a component link for a higher order composite link itself is a component link for a higher order composite
link. For example, a composite link comprised of MPLS-TP bi- link. For example, a composite link comprised of MPLS-TP bi-
directional tunnels viewed as logical links could then be used directional tunnels viewed as logical links could then be used
as a component link in yet another composite link that as a component link in yet another composite link that
connects MPLS routers. connects MPLS routers.
FR#21 The solution MUST support an optional means for LSP signaling
to bind an LSP to a particular component link within a
composite link. If this option is applied to a bidirectional
LSP, both directions of the LSP are bound to the component.
If this option is not exercised, then an LSP that is bound to
a composite link may be bound to any component link matching
all other signaled requirements, and different directions of a
bidirectional LSP can be bound to different component links.
5. Derived Requirements 5. Derived Requirements
This section takes the next step and derives high-level requirements This section takes the next step and derives high-level requirements
on protocol specification from the functional requirements. on protocol specification from the functional requirements.
DR#1 The solution SHOULD attempt to extend existing protocols DR#1 The solution SHOULD attempt to extend existing protocols
wherever possible, developing a new protocol only if this adds wherever possible, developing a new protocol only if this adds
a significant set of capabilities. a significant set of capabilities.
The vast majority of network operators have provisioned L3VPN The vast majority of network operators have provisioned L3VPN
 End of changes. 6 change blocks. 
5 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/