draft-ietf-mpls-sfc-encapsulation-01.txt | draft-ietf-mpls-sfc-encapsulation-02.txt | |||
---|---|---|---|---|
MPLS Working Group A. Malis | MPLS Working Group A. Malis | |||
Internet-Draft S. Bryant | Internet-Draft S. Bryant | |||
Intended status: Informational Huawei Technologies | Intended status: Informational Huawei Technologies | |||
Expires: June 7, 2019 J. Halpern | Expires: June 14, 2019 J. Halpern | |||
Ericsson | Ericsson | |||
W. Henderickx | W. Henderickx | |||
Nokia | Nokia | |||
December 04, 2018 | December 11, 2018 | |||
MPLS Encapsulation for SFC NSH | MPLS Encapsulation For The SFC NSH | |||
draft-ietf-mpls-sfc-encapsulation-01 | draft-ietf-mpls-sfc-encapsulation-02 | |||
Abstract | Abstract | |||
This document describes how to use a Service Function Forwarder (SFF) | This document describes how to use a Service Function Forwarder (SFF) | |||
Label (similar to a pseudowire label or VPN label) to indicate the | Label (similar to a pseudowire label or VPN label) to indicate the | |||
presence of a Service Function Chaining (SFC) Network Service Header | presence of a Service Function Chaining (SFC) Network Service Header | |||
(NSH) between an MPLS label stack and the packet payload. This | (NSH) between an MPLS label stack and the packet payload. This | |||
allows SFC packets using the NSH to be forwarded between SFFs over an | allows SFC packets using the NSH to be forwarded between SFFs over an | |||
MPLS network, and the selection between multiple SFFs in the | MPLS network, and to select one of multiple SFFs in the destination | |||
destination MPLS node. | MPLS node. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 June 7, 2019. | This Internet-Draft will expire on June 14, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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 2, line 19 ¶ | skipping to change at page 2, line 19 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. MPLS Encapsulation Using an SFF Label . . . . . . . . . . . . 3 | 2. MPLS Encapsulation Using an SFF Label . . . . . . . . . . . . 3 | |||
2.1. MPLS Label Stack Construction at the Sending Node . . . . 3 | 2.1. MPLS Label Stack Construction at the Sending Node . . . . 3 | |||
2.2. SFF Label Processing at the Destination Node . . . . . . 4 | 2.2. SFF Label Processing at the Destination Node . . . . . . 4 | |||
3. Equal Cost Multipath (ECMP) Considerations . . . . . . . . . 4 | 3. Equal Cost Multipath (ECMP) Considerations . . . . . . . . . 4 | |||
4. Operations, Administration, and Maintenance (OAM) | 4. Operations, Administration, and Maintenance (OAM) | |||
Considerations . . . . . . . . . . . . . . . . . . . . . . . 4 | Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 6 | 8.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1. Introduction | 1. Introduction | |||
As discussed in [RFC8300], a number of transport encapsulations for | As discussed in [RFC8300], a number of transport encapsulations for | |||
the Service Function Chaining (SFC) Network Service Header (NSH) | the Service Function Chaining (SFC) Network Service Header (NSH) | |||
already exist, such as Ethernet, UDP, GRE, and others. | already exist, such as Ethernet, UDP, GRE, and others. | |||
This document describes an MPLS transport encapsulation for the NSH, | This document describes an MPLS transport encapsulation for the NSH | |||
and also describes how to use a Service Function Forwarder (SFF) | and how to use a Service Function Forwarder (SFF) [RFC7665] Label to | |||
[RFC7665] Label to indicate the presence of the NSH in the MPLS | indicate the presence of the NSH in the MPLS packet payload. This | |||
packet payload. This allows SFC packets using the NSH to be | allows SFC packets using the NSH to be forwarded between SFFs in an | |||
forwarded between SFFs in an MPLS transport network, where MPLS is | MPLS transport network, where MPLS is used to interconnect the | |||
used to interconnect the network nodes that contain one or more SFFs. | network nodes that contain one or more SFFs. The label is also used | |||
The label is also used to select between multiple SFFs in the | to select between multiple SFFs in the destination MPLS node. | |||
destination MPLS node. | ||||
SFF Labels are similar to other service labels at the bottom of an | SFF Labels are similar to other service labels at the bottom of an | |||
MPLS label stack that denote the contents of the MPLS payload being | MPLS label stack that denote the contents of the MPLS payload being | |||
other than IP, such as a layer 2 pseudowire, an IP packet that is | other than IP, such as a layer 2 pseudowire, an IP packet that is | |||
routed in a VPN context with a private address, or an Ethernet | routed in a VPN context with a private address, or an Ethernet | |||
virtual private wire service. | virtual private wire service. | |||
This informational document follows well-established MPLS procedures | This informational document follows well-established MPLS procedures | |||
and does not require any actions by IANA or any new protocol | and does not require any actions by IANA or any new protocol | |||
extensions. | extensions. | |||
Note that using the MPLS label stack as a replacement for the SFC | ||||
NSH, covering use cases that do not require per-packet metadata, is | ||||
described elsewhere [I-D.ietf-mpls-sfc]. | ||||
2. MPLS Encapsulation Using an SFF Label | 2. MPLS Encapsulation Using an SFF Label | |||
The encapsulation is a standard MPLS label stack [RFC3032] with an | The encapsulation is a standard MPLS label stack [RFC3032] with an | |||
SFF Label at the bottom of the stack, followed by a NSH as defined by | SFF Label at the bottom of the stack, followed by a NSH as defined by | |||
[RFC8300] and the NSH payload. | [RFC8300] and the NSH payload. | |||
Much like a pseudowire label, an SFF Label is allocated by the | Much like a pseudowire label, an SFF Label is allocated by the | |||
downstream receiver of the NSH from its per-platform label space. | downstream receiver of the NSH from its per-platform label space. | |||
If a receiving node supports more than one SFF (i.e, more than one | If a receiving node supports more than one SFF (i.e, more than one | |||
skipping to change at page 3, line 31 ¶ | skipping to change at page 3, line 35 ¶ | |||
That said, a number of methods are possible, such as via a protocol | That said, a number of methods are possible, such as via a protocol | |||
exchange, or via a controller that manages both the sender and the | exchange, or via a controller that manages both the sender and the | |||
receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as | receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as | |||
possible examples and not to constrain the future definition of such | possible examples and not to constrain the future definition of such | |||
advertisement methods. | advertisement methods. | |||
While the SFF label will usually be at the bottom of the label stack, | While the SFF label will usually be at the bottom of the label stack, | |||
there may be cases where there are additional label stack entries | there may be cases where there are additional label stack entries | |||
beneath it. For example, when an ACH is carried that applies to the | beneath it. For example, when an ACH is carried that applies to the | |||
SFF, a GAL [RFC5586] will be in the label stack below the SFF. | SFF, a GAL [RFC5586] will be in the label stack below the SFF. | |||
Similarly, an ELI/EL [RFC6790] may be carried below the SFF in the | Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) | |||
label stack. This is identical to the situation with VPN labels. | [RFC6790] may be carried below the SFF in the label stack. This is | |||
identical to the situation with VPN labels. | ||||
2.1. MPLS Label Stack Construction at the Sending Node | 2.1. MPLS Label Stack Construction at the Sending Node | |||
When one SFF wishes to send an SFC packet with the NSH to another SFF | When one SFF wishes to send an SFC packet with a NSH to another SFF | |||
over an MPLS transport network, a label stack needs to be constructed | over an MPLS transport network, a label stack needs to be constructed | |||
by the MPLS node that contains the sending SFF in order to transport | by the MPLS node that contains the sending SFF in order to transport | |||
the packet to the destination MPLS node that contains the receiving | the packet to the destination MPLS node that contains the receiving | |||
SFF. The label can be constructed as follows: | SFF. The label stack is constructed as follows: | |||
1. Push on zero or more labels that are interpreted by the | 1. Push zero or more labels that are interpreted by the destination | |||
destination MPLS node, such as the Generic Associated Channel | MPLS node on to the packet, such as the Generic Associated | |||
[RFC5586] label (see OAM Considerations below). | Channel [RFC5586] label (see Section 4). | |||
2. Push on the SFF Label to identify the desired SFF in the | 2. Push the SFF Label to identify the desired SFF in the receiving | |||
receiving MPLS node. | MPLS node. | |||
3. Push on zero or more additional labels such that (a) the | 3. Push zero or more additional labels such that (a) the resulting | |||
resulting label stack will cause the packet to be transported to | label stack will cause the packet to be transported to the | |||
the destination MPLS node, and (b) when the packet arrives at the | destination MPLS node, and (b) when the packet arrives at the | |||
destination node, either: | destination node, either: | |||
* the SFF Label will be at the top of the label stack, or | * the SFF Label will be at the top of the label stack (this is | |||
typically the case when penultimate hop popping is used at the | ||||
penultimate node, or the source and destination nodes are | ||||
direct neighbors), or | ||||
* the SFF Label will rise to the top of the label stack before | * as a part of normal MPLS processing, the SFF Label becomes the | |||
the packet is forwarded to another node and before the packet | top label in the stack before the packet is forwarded to | |||
is dispatched to a higher layer. | another node and before the packet is dispatched to a higher | |||
layer. | ||||
2.2. SFF Label Processing at the Destination Node | 2.2. SFF Label Processing at the Destination Node | |||
The destination MPLS node performs a lookup on the SFF label to | The destination MPLS node performs a lookup on the SFF label to | |||
retrieve the next-hop context between the SFF and SF, e.g. to | retrieve the next-hop context between the SFF and SF, e.g. to | |||
retrieve the destination MAC address in the case where native | retrieve the destination MAC address in the case where native | |||
Ethernet encapsulation is used between SFF and SF. How the next-hop | Ethernet encapsulation is used between SFF and SF. How the next-hop | |||
context is populated is out of the scope of this document. | context is populated is out of the scope of this document. | |||
The receiving MPLS node then pops the SFF Label (and any labels | The receiving MPLS node then pops the SFF Label (and any labels | |||
skipping to change at page 4, line 37 ¶ | skipping to change at page 4, line 46 ¶ | |||
Many existing routers use deep packet inspection to examine the | Many existing routers use deep packet inspection to examine the | |||
payload of an MPLS packet, and if the first nibble of the payload is | payload of an MPLS packet, and if the first nibble of the payload is | |||
equal to 0x4 or 0x6, these routers (sometimes incorrectly, as | equal to 0x4 or 0x6, these routers (sometimes incorrectly, as | |||
discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 | discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 | |||
respectively, and as a result, perform ECMP load balancing based on | respectively, and as a result, perform ECMP load balancing based on | |||
(presumed) information present in IP/TCP/UDP payload headers or in a | (presumed) information present in IP/TCP/UDP payload headers or in a | |||
combination of MPLS label stack and (presumed) IP/TCP/UDP payload | combination of MPLS label stack and (presumed) IP/TCP/UDP payload | |||
headers in the packet. | headers in the packet. | |||
For SFC, ECMP may or may not be desirable. To prevent unintended | For SFC, ECMP may or may not be desirable. To prevent ECMP when it | |||
ECMP when it is not desired, the NSH Base Header was carefully | is not desired, the NSH Base Header was carefully constructed so that | |||
constructed so that the NSH could not look like IPv4 or IPv6 based on | the NSH could not look like IPv4 or IPv6 based on its first nibble. | |||
its first nibble. See Section 2.2 of [RFC8300] for further details. | See Section 2.2 of [RFC8300] for further details. | |||
If ECMP is desired when SFC is used with an MPLS transport network, | If ECMP is desired when SFC is used with an MPLS transport network, | |||
there are two possible options, Entropy [RFC6790] and Flow-Aware | there are two possible options, Entropy [RFC6790] and Flow-Aware | |||
Transport [RFC6391] labels. A recommendation between these options, | Transport [RFC6391] labels. A recommendation between these options, | |||
and their proper placement in the label stack, is for future study. | and their proper placement in the label stack, is for future study. | |||
4. Operations, Administration, and Maintenance (OAM) Considerations | 4. Operations, Administration, and Maintenance (OAM) Considerations | |||
OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. | OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. | |||
However, OAM may be required at the MPLS transport layer. If so, | However, OAM may be required at the MPLS transport layer. If so, | |||
skipping to change at page 5, line 49 ¶ | skipping to change at page 6, line 10 ¶ | |||
MPLS-encapsulated NSH packets would require insider knowledge of the | MPLS-encapsulated NSH packets would require insider knowledge of the | |||
network's control and management planes and a way to inject packets | network's control and management planes and a way to inject packets | |||
into internal interfaces. This is compared to, for example, NSH over | into internal interfaces. This is compared to, for example, NSH over | |||
UDP over IP, which could be injected into any external interface in a | UDP over IP, which could be injected into any external interface in a | |||
network that was not properly configured to filter out such packets | network that was not properly configured to filter out such packets | |||
at the ingress. | at the ingress. | |||
7. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank Jim Guichard, Eric Rosen, Med | The authors would like to thank Jim Guichard, Eric Rosen, Med | |||
Boucadair, Sasha Vainshtein, and Jeff Tantsura for their reviews and | Boucadair, Sasha Vainshtein, Jeff Tantsura, Anoop Ghanwani, John | |||
comments. | Drake, and Loa Andersson for their reviews and comments. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | |||
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | |||
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, | Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, | |||
<https://www.rfc-editor.org/info/rfc3032>. | <https://www.rfc-editor.org/info/rfc3032>. | |||
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
"Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
DOI 10.17487/RFC8300, January 2018, | DOI 10.17487/RFC8300, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8300>. | <https://www.rfc-editor.org/info/rfc8300>. | |||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-mpls-sfc] | ||||
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based | ||||
Forwarding Plane for Service Function Chaining", draft- | ||||
ietf-mpls-sfc-04 (work in progress), November 2018. | ||||
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal | |||
Cost Multipath Treatment in MPLS Networks", BCP 128, | Cost Multipath Treatment in MPLS Networks", BCP 128, | |||
RFC 4928, DOI 10.17487/RFC4928, June 2007, | RFC 4928, DOI 10.17487/RFC4928, June 2007, | |||
<https://www.rfc-editor.org/info/rfc4928>. | <https://www.rfc-editor.org/info/rfc4928>. | |||
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., | [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., | |||
"MPLS Generic Associated Channel", RFC 5586, | "MPLS Generic Associated Channel", RFC 5586, | |||
DOI 10.17487/RFC5586, June 2009, | DOI 10.17487/RFC5586, June 2009, | |||
<https://www.rfc-editor.org/info/rfc5586>. | <https://www.rfc-editor.org/info/rfc5586>. | |||
End of changes. 20 change blocks. | ||||
39 lines changed or deleted | 52 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |