RFC 7226
Requirements for Advanced Multipath in MPLS Networks
RFC 7226: Requirements for Advanced Multipath in MPLS Networks ✨
Okay bestie, let's get into it 🦋 This one is an Informational RFC from May 2014, and it's part of the IETF's official paper trail (ISSN 2070-1721). The authors are C. Villamizar (Ed.) from OCCNC, LLC, D. McDysan (Ed.) from Verizon, S. Ning from Tata Communications, A. Malis from Huawei, and L. Yong from Huawei USA. The title block doesn't list anything it obsoletes or updates, so it's a fresh one 💅
Abstract ✨
Okay so this document gives us a set of requirements for Advanced Multipath in MPLS networks 🌸
Advanced Multipath is basically a formal version of the multipath techniques already running in IP and MPLS networks, plus some new extensions added onto those existing techniques. It's giving "upgrade your current setup" energy 🔥
Status of This Memo 💅
This document is not an Internet Standards Track specification. It's published for informational purposes, so it's more of a "here's what we know" than a "you must do this" 🎀
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧚
If you want the current status, any errata, or a place to send feedback, head to http://www.rfc-editor.org/info/rfc7226 💜
Copyright Notice 🌈
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stood on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 151. Introduction 🦋
Okay so there's often a need for big aggregates of bandwidth, and those are usually best served by parallel links between routers or by sending traffic over multiple MPLS Label Switched Paths (LSPs). In core networks, there's often no real alternative, because the total capacity of core networks today way outstrips a single physical link or a single packet-processing element 😭
Parallel links are main character energy, but each one might be made of multiple layers, and that brings in extra requirements 💖 Some services might benefit from being limited to a subset of the component links, or to one specific component link, especially when things like latency differ between them ✨ Some services need an LSP to be treated as atomic and to avoid reordering. Other services only need reordering to not happen within a flow, which is what people already do today 🫶
There are lots of multipath flavours out there already, including MPLS Link Bundling [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and different kinds of Equal Cost Multipath (ECMP) like OSPF ECMP, IS-IS ECMP, and BGP ECMP. If you want a tour of the existing techniques and a pile of references, check out the appendices in [USE-CASES] 📚
So the goal of this document is to clearly list out the requirements for the protocols and mechanisms that deliver MPLS-based Advanced Multipath 👑 The plan is to start with functional requirements in Section 3, which are kept as independent as possible from any particular protocol spec. Then Section 4 covers general protocol requirements, and Section 5 covers network management requirements 🌸
1.1. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yes, these are the capital-letter keywords with real weight, so pay attention 👀
Any statement that asks a solution to support some new functionality through [RFC2119] keywords should be interpreted like this. The implementation either MUST or SHOULD support the new functionality, depending on whether the requirements statement uses MUST or SHOULD 🔥 The implementation SHOULD, in most or all cases, allow any new functionality to be individually enabled or disabled through configuration 💅 A service provider or other deployment MAY enable or disable any feature in their network, subject to implementation limits on which features can be disabled ✨
2. Definitions 📖✨
okay bestie, let's get into the vocab, because these terms are the foundation of everything else in this doc 🧚 each one gets a little bolded name and then the explanation. ready? 💅
Multipath
So "multipath" is the umbrella term for all the techniques where:
- Traffic can take more than one path from one node to a destination. 🛣️
- Individual packets take one path only. Packets are not subdivided and reassembled at the receiving end. 📦
- Packets are not resequenced at the receiving end. 🙅♀️
- The paths may be:
- a. parallel links between two nodes,
- b. specific paths across a network to a destination node, or
- c. links or paths to an intermediate node used to reach a common destination.
The paths don't need equal capacity 🪞, and they may or may not have equal cost in a routing protocol. It's giving flexible 💖
Advanced Multipath
Advanced Multipath is basically a formal version of multipath techniques that meets the requirements defined in this document ✨ The key capability here is supporting non-homogeneous component links, which is a whole main character energy feature 👑
Advanced Multipath Group (AMG)
An AMG is a collection of component links where Advanced Multipath techniques are applied 🎀
Composite Link
Okay, tea time ☕. "Composite link" used to be a registered trademark of Avici Systems, but they abandoned it in 2007, so it's free to use now 🦋 The term is now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition includes multipath as defined here, PLUS inverse multiplexing, which is explicitly excluded from the definition of multipath 🙈
Inverse Multiplexing
Inverse multiplexing is another way of sending traffic over multiple links 🌈 It either transmits whole packets and resequences them at the receiving end, or it subdivides packets and reassembles them at the receiving end. It requires that all packets be handled by a common egress packet processing element, so it's not useful for very high-bandwidth applications 💀
Component Link
The ITU-T definition of composite link in [ITU-T.G.800] and the IETF definition of link bundling in [RFC4201] both call an individual link inside a composite link or link bundle a component link 💜 The term "component link" applies to all forms of multipath. The IEEE says "member" instead of "component link" in Ethernet Link Aggregation [IEEE-802.1AX], so if you see that word, it means the same thing 🫶
Client Layer
A client layer is the layer immediately above a server layer 🧁
Server Layer
A server layer is the layer immediately below a client layer 🍓
Higher Layers
Relative to a particular layer, a client layer and any layer above it is considered a higher layer. "Upper layer" means the exact same thing as "higher layer" 🪜
Lower Layers
Relative to a particular layer, a server layer and any layer below it is considered a lower layer 🌸
Client LSP
A client LSP is an LSP that has been set up over one or more lower layers 🧩 In the context of this discussion, one type of client LSP is an LSP that has been set up over an AMG.
Flow
A flow is a sequence of packets that should be transferred in order on one component link of a multipath 💌
Flow Identification
This is the label stack plus other info that uniquely identifies a flow 🔍 The other info can include an IP header, a pseudowire (PW) control word, an Ethernet Media Access Control (MAC) address, and so on. Note that a client LSP may contain one or more flows, or a client LSP may be equivalent to a flow. Flow identification is used to locally select a component link or a path through the network toward the destination 🎯
Load Balance
Load split, load balance, and load distribution all mean subdividing traffic over a set of component links so that the load is fairly evenly spread across that set, and certain packet ordering requirements are met ⚖️ Some existing techniques hit these goals better than others, lowkey 👀
Performance Objective
These are numerical values for performance measures, mainly availability, latency, and delay variation 📊 Performance objectives may be related to Service Level Agreements (SLAs) as defined in [RFC2475], or they may be strictly internal. They may span links from edge to edge or from end to end, and they may span one provider or multiple providers 🌍
A component link may be a point-to-point physical link (where a "physical link" includes one or more link layers, plus a physical layer), or a logical link that preserves ordering in the steady state 🪡 A component link may have transient out-of-order events, but such events must not exceed the network's performance objectives. For example, a component link may be made up of any supportable combination of link layers over a physical layer or over logical sub-layers, including those providing physical-layer emulation, or over an MPLS server-layer LSP 🧃
The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not take part in the signaling of any clients of the client LSP. So, in general, multipath endpoints can't figure out what the clients of a client LSP need by joining in on their signaling 🙃
This document doesn't say whether Advanced Multipath is itself a layer, or whether an instance of AMG is itself a layer. This is to avoid long and pointless debates about what counts as a proper layer 🙄🫠
The term "Advanced Multipath" is meant to be used within the context described in this document and related documents, for example [USE-CASES] and [FRAMEWORK]. Other Advanced Multipath techniques may show up in the future. If the capabilities defined here become commonplace, they would no longer be considered "advanced" 🕰️ If you use the term "advanced multipath" outside this document and mean the definition here, you should point to Advanced Multipath as defined by this document and cite the current document name. If you're using a different definition of "advanced multipath", documents may optionally clarify that they are not using the term as defined by this document, if that clarification is deemed helpful 🪧
3. Functional Requirements 📝🫶
The functional requirements in this section are grouped into subsections, starting with the highest priority. Ranking first, obviously 🥇
3.1. Availability, Stability, and Transient Response 🌤️
Staying stable is a must, but limiting how long things are unavailable after failures or transient events is extremely important too 😭
- FR#1 The transient period between some service-disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by performance objective values. 🕐
- FR#2 An AMG MAY be announced along with detailed parameters about its component links, such as bandwidth and latency. The AMG SHALL behave as a single IGP adjacency. 🤝
- FR#3 The solution SHALL provide a means to summarize some routing advertisements about the characteristics of an AMG, so that the updated protocol mechanisms keep convergence times within the time frame needed to meet, or not significantly exceed, existing performance objectives for convergence on the same network or on a network with a similar topology. 📣
- FR#4 The solution SHALL ensure that restoration operations happen within the time frame needed to meet existing performance objectives for restoration time on the same network or on a network with a similar topology. 🔄
- FR#5 The solution shall provide a mechanism to select a set of paths for an LSP across a network, in such a way that flows within the LSP are distributed across the set of paths, while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques, except as necessary to accommodate Advanced Multipath requirements. 🛤️
- FR#6 If extensions to existing protocols are specified and/or new protocols are defined, then the solution SHOULD provide a means for a network operator to migrate an existing deployment in a minimally disruptive manner. 🧳
- FR#7 Any load-balancing solutions MUST NOT oscillate. Some change in path MAY occur. The solution MUST ensure that path stability and traffic reordering continue to meet performance objectives on the same network or on a network with a similar topology. Since oscillation may cause reordering, there MUST be means to control the frequency of changing the component link over which a flow is placed. 🌀🚫
- FR#8 Management and diagnostic protocols MUST be able to operate over AMGs. 🔧
Existing scaling techniques used in MPLS networks apply to MPLS networks that support Advanced Multipath. Scalability and stability are covered in more detail in [FRAMEWORK] 📈
3.2. Component Links Provided by Lower-Layer Networks 🏗️
A component link may be supported by a lower-layer network. For example, the lower layer may be a circuit-switched network or another MPLS network (e.g., MPLS Transport Profile (MPLS-TP)). The lower-layer network may change the latency (and/or other performance parameters) that the client layer sees. Right now, there's no protocol for the lower-layer network to tell the higher-layer network about a change in a performance parameter 🙅♀️ Communicating the latency performance parameter is a very important requirement. Communicating other performance parameters (e.g., delay variation) is desirable 🫧
- FR#9 The solution SHALL specify a protocol means to allow a server-layer network to communicate latency to the client-layer network. 📡
- FR#10 The precision of latency reporting SHOULD be configurable. A reasonable default SHOULD be provided. Implementations SHOULD support precision of at least 10% of the one-way latencies for latency of 1 msec or more. 🎚️
The goal is to measure the predominant latency in uncongested service-provider networks, where geographic delay dominates and is on the order of milliseconds or more 🌏 The argument for including queuing delay is that it reflects the delay applications actually experience. The argument against including queuing delay is that if it's used in routing decisions, it can cause routing instability 🌊 This trade-off is discussed in detail in [FRAMEWORK] 🧠💅
3.3. Component Links with Different Characteristics ✨
okay so, high availability is a whole vibe, and one way network operators get it is by building an MPLS network topology out of lower-layer networks with some diversity down there. Loads of techniques exist to spread flows across component links that connect the same pair of nodes or end up at a common destination. It's giving smart redundancy 💅
FR#11 bestie, in the requirements below, the word "indicate" is used wherever the info might come from either the link state IGP advertisement combined with MPLS LSP signaling, or from management plane protocols. In later documents that cover the framework and protocol definitions, both signaling and management plane mechanisms MUST be defined. 🔥
FR#12 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with the minimum-latency value. This is how minimum latency performance objectives for flows inside the client LSP can be supported 🌸
FR#13 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable latency value, as specified by protocol. This is how bounded latency performance objectives for flows inside the client LSP can be supported ⏱️✨
FR#14 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable delay variation value, as specified by protocol. 🦋
Ngl these apply to component links with different characteristics no matter how they show up: parallel physical links between nodes, or sets of paths across a network provided by a server-layer LSP. Same rules, different costume 🎀
Letting multipath include component links with different characteristics can improve overall load balance, and you can still meet the stricter needs of a subset of client LSPs while doing it. Main character balancing energy 👑
3.4. Considerations for Bidirectional Client LSP 💜
Some client LSPs MAY require a path bound to a specific set of component links. This is most likely with a bidirectional client LSP that carries time synchronization protocols like the Precision Time Protocol (PTP) or the Network Time Protocol (NTP), or in any other case where symmetric delay is highly desirable. There may be other uses for this capability too 🕰️
Other client LSPs only need the LSP to serve the same set of nodes in both directions. This matters when protocols use the reverse direction of the LSP as a back channel, like Operations, Administration, and Maintenance (OAM) protocols that rely on IPv4 Time to Live (TTL) or IPv4 Hop Limit to monitor or diagnose the underlying path. There may be other uses for this one as well 🔍
FR#15 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP be bound to a particular component link within an AMG. If this option isn't used, a client LSP carried over an AMG may be bound to any component link, or set of component links, that matches all the other signaled requirements. Different directions of a bidirectional client LSP can also be bound to different component links 🙈
FR#16 The solution MUST support a means for the client layer to indicate a requirement that, for a specific co-routed bidirectional client LSP, both directions of that LSP MUST be bound to the same set of nodes. 🫶
FR#17 A client LSP that is bound to a specific component link SHOULD NOT exceed the capacity of a single component link. This comes from the assumption that a network SHOULD NOT operate in a congested state when congestion can be avoided 💀
For some large bidirectional client LSPs, binding the LSP to a common set of component links might not be necessary, or even possible given the LSP's capacity. But it may still be necessary or desirable to constrain the path so both directions go through the same set of nodes. Without an entirely new and highly dynamic protocol, you can't really constrain such a bidirectional client LSP from taking multiple paths and coordinating load balance on each side to keep both directions of its flows on common paths. Not me trying to make that work without a whole new protocol 😭
3.5. Multipath Load-Balancing Dynamics 🌈
Multipath load balancing tries to keep traffic levels on every component link below congestion levels when possible, and ideally well balanced. The balancing is minimally disruptive (see the discussion below this section's list of requirements). How sensitive a specific client LSP is to these minimal disruptions to its traffic flows needs to be considered ⭐
FR#18 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP MUST NOT be split across multiple component links. 🙅♀️
FR#19 The solution SHALL provide a means local to a node that automatically distributes flows across the component links in the AMG so that performance objectives are met, as described in the earlier requirements in Section 3.3. 🧚
FR#20 The solution SHALL measure traffic flows, or groups of traffic flows, and dynamically select the component link to place that traffic on, so the load is balanced and no component link in the AMG between a pair of nodes is overloaded. 📊
FR#21 When a traffic flow is moved from one component link to another in the same AMG between a set of nodes, it MUST be done in a minimally disruptive manner. 🦋
FR#22 Load balancing MAY be used during sustained low-traffic periods to reduce the number of active component links for the purpose of power reduction. 🔋
FR#23 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP contains traffic whose frequency of component link change due to load balancing needs to be bounded by a specific value. The solution MUST provide a means to bound the frequency of component link changes due to load balancing for subsets of traffic flow on AMGs. ⏳
FR#24 The solution SHALL provide a means to distribute traffic flows from a single client LSP across multiple component links, to handle at least the case where the traffic carried in a client LSP exceeds that of any component link in the AMG. 🌊
FR#25 The solution SHOULD support the use case where an AMG itself is a component link for a higher order AMG. For example, an AMG made of MPLS-TP bidirectional tunnels viewed as logical links could then be used as a component link in yet another AMG that connects MPLS routers. Nesting doll energy 🪆
FR#26 If the total demand offered by traffic flows exceeds the capacity of the AMG, the solution SHOULD define a means to cause some client LSPs to move to an alternate set of paths that are not congested. These "preempted LSPs" may not be restored if there is no uncongested path in the network. 🫠
A minimally disruptive change means as little disruption as is practical. Such a change can be achieved with zero packet loss. A delay discontinuity may occur, and that counts as a minimally disruptive event for most services as long as it's rare enough. A delay discontinuity is an example of minimally disruptive behavior that matches current techniques ✨
A delay discontinuity is an isolated event that can greatly exceed the normal delay variation (jitter). Here's what it does: when a flow moves from a current link to a target link with lower latency, reordering can happen. When a flow moves to a target link with higher latency, a time gap can happen. Some flows, like timing distribution and PW circuit emulation, are super sensitive to this 😤 A delay discontinuity can also cause a jitter buffer underrun or overrun, which hurts user experience in real-time voice services (think an audible click 🎙️). These sensitivities may be written into a performance objective.
As with any load-balancing change, a change made for power reduction may be minimally disruptive. Usually the disruption is limited to a change in delay characteristics and maybe a very brief window of traffic reordering. When a network operator configures power reduction, they should weigh the benefit of saving power against the cost of that minimal disruption 🍓
4. General Requirements for Protocol Solutions 🧠
This section defines requirements for protocol specifications used to meet the functional requirements from Section 3, so it's basically the rulebook for the rulebook 📖
GR#1 The solution SHOULD extend existing protocols wherever possible, and only develop a new protocol when doing so adds a significant set of capabilities. 🔧
GR#2 A solution SHOULD extend LDP capabilities to meet functional requirements. This MUST be accomplished without defining LDP Traffic Engineering (TE) methods, as decided in [RFC3468]. 🚫
GR#3 Coexistence of LDP- and RSVP-TE-signaled LSPs MUST be supported on an AMG. Functional requirements SHOULD, where possible, be accommodated in a way that supports LDP-signaled LSPs, RSVP-signaled LSPs, and LSP setup using management plane mechanisms. 🤝
GR#4 When the nodes connected via an AMG are in the same routing domain, the solution MAY define extensions to the IGP. 🌐
GR#5 When the nodes connected via an AMG are in different MPLS network topologies, the solution SHALL NOT rely on extensions to the IGP. 🙅♀️
GR#6 The solution SHOULD support AMG IGP advertisement that results in better convergence time than advertising the individual component links. The solution SHALL be designed so that it represents the range of capabilities of the individual component links, such that functional requirements are met, and it also minimizes how often advertisement updates happen that could trigger IGP convergence. 📡
Advertisement-update-triggering events to consider include: client LSP establishment or release, changes in component-link characteristics (e.g., latency and up/down state), and/or bandwidth utilization. 👀
GR#7 When a worst-case failure scenario occurs, the number of RSVP-TE client LSPs to be resignaled will cause a period of unavailability as users perceive it. The resignaling time of the solution MUST support protocol mechanisms that meet existing provider performance objectives for the duration of that unavailability, without significantly relaxing those existing objectives for the same network or for networks with similar topology. For example, the processing load due to IGP readvertisement MUST NOT increase significantly, and the resignaling time of the solution MUST NOT increase significantly compared with current methods. 🚨💖
5. Management Requirements 🎀
okay bestie, now we're talking about the management plane 💅 these are the requirements it has to meet:
MR#1The Management Plane MUST support polling of the status and configuration of an AMG and its individual component links, and it MUST support notification of status change. 📊MR#2The Management Plane MUST be able to activate or deactivate any component link in an AMG so operators can do maintenance tasks 🔧 The routers at each end of an AMG MUST redistribute traffic, moving it off a deactivated link onto other component links based on the traffic flow TE criteria. It's giving smooth transitions 🦋MR#3The Management Plane MUST be able to configure a client LSP over an AMG, and it MUST be able to select a component link for that client LSP. 🎯MR#4The Management Plane MUST be able to trace which component link a client LSP is assigned to, and it MUST be able to monitor the performance of individual component links and of the AMG. 🔍MR#5The Management Plane MUST be able to verify connectivity over each individual component link within an AMG. ✅MR#6Component link fault notification MUST be sent to the management plane. 🚨MR#7AMG fault notification MUST be sent to the management plane, and MUST be distributed via a link state message in the IGP. 📣MR#8The Management Plane SHOULD provide the means for an operator to initiate an optimization process. ⭐MR#9An operator-initiated optimization MUST be performed in a minimally disruptive manner, as described in Section 3.5. 🫶
6. Acknowledgements 🫶
Frederic Jounay of France Telecom and Yuji Kamite of NTT Communications Corporation coauthored an earlier version of this document. 🌸
A rewrite of this document happened after the IETF 77 meeting, and Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG Chairs John Scuder and Alex Zinin, the current WG Chair Alia Atlas, and others gave super valuable guidance before and during the IETF 77 RTGWG meeting. 👑
Tony Li and John Drake left a lot of valuable comments on the RTGWG mailing list, and those comments show up in the versions that came after the IETF 77 meeting. 💜
Iftekhar Hussain and Kireeti Kompella commented on the RTGWG mailing list after the IETF 82 meeting, and they pointed out a new requirement. Iftekhar Hussain also left many valuable comments on the mailing list that made the document a lot clearer. 🧚
For full disclosure of affiliations and to give credit to sponsors, here are the past affiliations of the authors. Much of the work done by Ning So and Andrew Malis happened while they were at Verizon. Much of the work done by Curtis Villamizar happened while he was at Infinera. 🏢
Tom Yu and Francis Dupont did the SecDir and GenArt reviews, respectively, and both reviews had useful comments. The current wording of the security section is based on suggested wording from Tom Yu. Lou Berger did the RtgDir review, which led to the document being renamed and to a big clarification of terminology and wording, especially in the Abstract, Introduction, and Definitions sections. 🔥
7. Security Considerations 🔒
okay this one is serious bestie, so pay attention 😭
The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941]. This document does not impact the security of MPLS, GMPLS, or MPLS-TP. 🛡️
The additional information this document requires does not give an attacker much extra value beyond what's already typically available from attacking a routing or signaling protocol. If the requirements of this document are met by extending an existing routing or signaling protocol, the security considerations of the protocol being extended apply. If the requirements of this document are met by specifying a new protocol, the security considerations of that new protocol should include an evaluation of what level of protection is required by the additional information specified in this document, such as data origin authentication. 🔐
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.8.2. Informative References
[FRAMEWORK]
Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Advanced Multipath Framework in MPLS", Work
in Progress, July 2013.
[IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>.
[ITU-T.G.800]
ITU-T, "Unified functional architecture of transport
networks", ITU-T Recommendation G.800, February 2012,
<http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013.
[USE-CASES]
Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Advanced Multipath Use Cases and Design
Considerations", Work in Progress, November 2013.Authors' Addresses 💌
Curtis Villamizar (editor)
OCCNC, LLC
EMail: curtis@occnc.com
Dave McDysan (editor)
Verizon
22001 Loudoun County PKWY
Ashburn, VA 20147
USA
EMail: dave.mcdysan@verizon.com
So Ning
Tata Communications
EMail: ning.so@tatacommunications.com
Andrew G. Malis
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: agmalis@gmail.com
Lucy Yong
Huawei USA
5340 Legacy Dr.
Plano, TX 75025
USA
Phone: +1 469-277-5837
EMail: lucy.yong@huawei.com📦 where this page comes from
- ietf: rfc7226 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms