draft-ietf-detnet-mpls-07.txt | draft-ietf-detnet-mpls-08.txt | |||
---|---|---|---|---|
DetNet B. Varga, Ed. | DetNet B. Varga, Ed. | |||
Internet-Draft J. Farkas | Internet-Draft J. Farkas | |||
Intended status: Standards Track Ericsson | Intended status: Standards Track Ericsson | |||
Expires: December 10, 2020 L. Berger | Expires: January 7, 2021 L. Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
A. Malis | A. Malis | |||
Malis Consulting | Malis Consulting | |||
S. Bryant | S. Bryant | |||
Futurewei Technologies | Futurewei Technologies | |||
J. Korhonen | J. Korhonen | |||
June 8, 2020 | July 6, 2020 | |||
DetNet Data Plane: MPLS | DetNet Data Plane: MPLS | |||
draft-ietf-detnet-mpls-07 | draft-ietf-detnet-mpls-08 | |||
Abstract | Abstract | |||
This document specifies the Deterministic Networking data plane when | This document specifies the Deterministic Networking data plane when | |||
operating over an MPLS Packet Switched Networks. | operating over an MPLS Packet Switched Networks. | |||
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. | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
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 December 10, 2020. | This Internet-Draft will expire on January 7, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 | 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 | |||
3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 | 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 | |||
3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 | 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 | |||
4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 | 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 | |||
4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 | 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 | |||
4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 | 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 | |||
4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 | 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 | |||
4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 | 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 16 | 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 | |||
4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 | 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 | |||
4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 | 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 | |||
4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 | 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 | |||
4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 | 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 | |||
4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 | 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 | |||
4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 | 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 | |||
4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 | 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 | |||
4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 | 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 | |||
4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 20 | 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 | |||
5. Management and Control Information Summary . . . . . . . . . 21 | 5. Management and Control Information Summary . . . . . . . . . 21 | |||
5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 | 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 | |||
5.1.1. Service Aggregation Information Summary . . . . . . . 23 | 5.1.1. Service Aggregation Information Summary . . . . . . . 23 | |||
5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 | 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 27 | 10.2. Informative References . . . . . . . . . . . . . . . . . 27 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
1. Introduction | 1. Introduction | |||
Deterministic Networking (DetNet) is a service that can be offered by | Deterministic Networking (DetNet) is a service that can be offered by | |||
a network to DetNet flows. DetNet provides these flows extremely low | a network to DetNet flows. DetNet provides these flows extremely low | |||
packet loss rates and assured maximum end-to-end delivery latency. | packet loss rates and assured maximum end-to-end delivery latency. | |||
General background and concepts of DetNet can be found in [RFC8655]. | General background and concepts of DetNet can be found in [RFC8655]. | |||
The DetNet Architecture models the DetNet related data plane | The DetNet Architecture models the DetNet related data plane | |||
functions decomposed into two sub-layers: a service sub-layer and a | functions decomposed into two sub-layers: a service sub-layer and a | |||
skipping to change at page 3, line 46 ¶ | skipping to change at page 3, line 46 ¶ | |||
Background information common to all data planes for DetNet can be | Background information common to all data planes for DetNet can be | |||
found in the DetNet Data Plane Framework | found in the DetNet Data Plane Framework | |||
[I-D.ietf-detnet-data-plane-framework]. | [I-D.ietf-detnet-data-plane-framework]. | |||
2. Terminology | 2. Terminology | |||
2.1. Terms Used in This Document | 2.1. Terms Used in This Document | |||
This document uses the terminology established in the DetNet | This document uses the terminology established in the DetNet | |||
architecture [RFC8655] and the the DetNet Data Plane Framework | architecture [RFC8655] and the DetNet Data Plane Framework | |||
[I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be | [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be | |||
familiar with these documents, any terminology defined therein and | familiar with these documents, any terminology defined therein and | |||
basic MPLS related terminologies in [RFC3031]. | basic MPLS related terminologies in [RFC3031]. | |||
The following terminology is introduced in this document: | The following terminology is introduced in this document: | |||
F-Label A Detnet "forwarding" label that identifies the LSP | F-Label A Detnet "forwarding" label that identifies the LSP | |||
used to forward a DetNet flow across an MPLS PSN, e.g., | used to forward a DetNet flow across an MPLS PSN, e.g., | |||
a hop-by-hop label used between label switching routers | a hop-by-hop label used between label switching routers | |||
(LSR). | (LSR). | |||
S-Label A DetNet "service" label that is used between DetNet | S-Label A DetNet "service" label that is used between DetNet | |||
nodes that implement also the DetNet service sub-layer | nodes that implement also the DetNet service sub-layer | |||
functions. An S-Label is also used to identify a | functions. An S-Label is also used to identify a | |||
DetNet flow at DetNet service sub-layer. | DetNet flow at DetNet service sub-layer at a receiving | |||
DetNet node. | ||||
A-Label A special case of an S-Label, whose aggregation | A-Label A special case of an S-Label, whose aggregation | |||
properties are known only at the aggregation and | properties are known only at the aggregation and | |||
deaggregation end-points. | deaggregation end-points. | |||
d-CW A DetNet Control Word (d-CW) is used for sequencing | d-CW A DetNet Control Word (d-CW) is used for sequencing | |||
information of a DetNet flow at the DetNet service sub- | information of a DetNet flow at the DetNet service sub- | |||
layer. | layer. | |||
2.2. Abbreviations | 2.2. Abbreviations | |||
skipping to change at page 6, line 6 ¶ | skipping to change at page 6, line 6 ¶ | |||
| Service | d-CW, S-Label (A-Label) | | Service | d-CW, S-Label (A-Label) | |||
+------------+ | +------------+ | |||
| Forwarding | F-Label(s) | | Forwarding | F-Label(s) | |||
+------------+ | +------------+ | |||
Top of Stack . | Top of Stack . | |||
(outer label) . | (outer label) . | |||
Figure 1: DetNet Adaptation to MPLS Data Plane | Figure 1: DetNet Adaptation to MPLS Data Plane | |||
The DetNet MPLS data plane representation is illustrated in Figure 1. | The DetNet MPLS data plane representation is illustrated in Figure 1. | |||
The service sub-layer includes a DetNet control word (d-CW) and a | The service sub-layer includes a DetNet control word (d-CW) and an | |||
identifying service label (S-Label). The DetNet control word (d-CW) | identifying service label (S-Label). The DetNet control word (d-CW) | |||
conforms to the Generic PW MPLS Control Word (PWMCW) defined in | conforms to the Generic PW MPLS Control Word (PWMCW) defined in | |||
[RFC4385]. An aggregation label (A-Label) is a special case of | [RFC4385]. An aggregation label (A-Label) is a special case of | |||
S-Label used for aggregation. | S-Label used for aggregation. | |||
A node operating on a DetNet flow in the Detnet service sub-layer, | A node operating on a received DetNet flow at the Detnet service sub- | |||
uses the local context associated with that S-Label, provided by a | layer uses the local context associated with a received S-Label, | |||
received F-Label, to determine what local DetNet operation(s) are | i.e., a received F-Label, to determine which local DetNet | |||
applied to that packet. An S-Label may be taken from the platform | operation(s) are applied to that packet. An S-Label may be taken | |||
label space [RFC3031], making it unique, enabling DetNet flow | from the platform label space [RFC3031], making it unique, enabling | |||
identification regardless of which input interface or LSP the packet | DetNet flow identification regardless of which input interface or LSP | |||
arrives on. | the packet arrives on. It is important to note that S-Label values | |||
are driven by the receiver, not the sender. | ||||
The DetNet forwarding sub-layer is supported by zero or more | The DetNet forwarding sub-layer is supported by zero or more | |||
forwarding labels (F-Labels). MPLS Traffic Engineering | forwarding labels (F-Labels). MPLS Traffic Engineering | |||
encapsulations and mechanisms can be utilized to provide a forwarding | encapsulations and mechanisms can be utilized to provide a forwarding | |||
sub-layer that is responsible for providing resource allocation and | sub-layer that is responsible for providing resource allocation and | |||
explicit routes. | explicit routes. | |||
3.2. DetNet MPLS Data Plane Scenarios | 3.2. DetNet MPLS Data Plane Scenarios | |||
DetNet MPLS Relay Transit Relay DetNet MPLS | DetNet MPLS Relay Transit Relay DetNet MPLS | |||
skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 7 ¶ | |||
|<----------------- DetNet MPLS --------------------->| | |<----------------- DetNet MPLS --------------------->| | |||
Figure 2: A DetNet MPLS Network | Figure 2: A DetNet MPLS Network | |||
Figure 2 illustrates a hypothetical DetNet MPLS-only network composed | Figure 2 illustrates a hypothetical DetNet MPLS-only network composed | |||
of DetNet aware MPLS enabled end systems, operating over a DetNet | of DetNet aware MPLS enabled end systems, operating over a DetNet | |||
aware MPLS network. In this figure, the relay nodes are PE devices | aware MPLS network. In this figure, the relay nodes are PE devices | |||
that define the MPLS LSP boundaries and the transit nodes are LSRs. | that define the MPLS LSP boundaries and the transit nodes are LSRs. | |||
DetNet end system and relay nodes understand the particular needs of | DetNet end systems and relay nodes understand the particular needs of | |||
DetNet flows and provide both DetNet service and forwarding sub-layer | DetNet flows and provide both DetNet service and forwarding sub-layer | |||
functions. In the case of MPLS, DetNet service-aware nodes add, | functions. In the case of MPLS, DetNet service-aware nodes add, | |||
remove and process d-CWs, S-Labels and F-labels as needed. DetNet | remove and process d-CWs, S-Labels and F-labels as needed. DetNet | |||
MPLS nodes provide functionality analogous to T-PEs when they sit at | MPLS nodes provide functionality analogous to T-PEs when they sit at | |||
the edge of an MPLS domain, and S-PEs when they are in the middle of | the edge of an MPLS domain, and S-PEs when they are in the middle of | |||
an MPLS domain, see [RFC6073]. | an MPLS domain, see [RFC6073]. | |||
In a DetNet MPLS network, transit nodes may be DetNet service aware | In a DetNet MPLS network, transit nodes may be DetNet service aware | |||
or may be DetNet unaware MPLS Label Switching Routers (LSRs). In | or may be DetNet unaware MPLS Label Switching Routers (LSRs). In | |||
this latter case, such LSRs would be unaware of the special | this latter case, such LSRs would be unaware of the special | |||
skipping to change at page 8, line 50 ¶ | skipping to change at page 8, line 50 ¶ | |||
3. A method of distinguishing DetNet OAM packets from DetNet data | 3. A method of distinguishing DetNet OAM packets from DetNet data | |||
packets. | packets. | |||
4. A method of carrying the DetNet sequence number. | 4. A method of carrying the DetNet sequence number. | |||
5. A suitable LSP to deliver the packet to the egress PE. | 5. A suitable LSP to deliver the packet to the egress PE. | |||
6. A method of carrying queuing and forwarding indication. | 6. A method of carrying queuing and forwarding indication. | |||
In this design an MPLS service label (the S-Label), similar to a | In this design an MPLS service label (the S-Label), is similar to a | |||
pseudowire (PW) label [RFC3985], is used to identify both the DetNet | pseudowire (PW) label [RFC3985], and is used to identify both the | |||
flow identity and the payload MPLS payload type satisfying (1) and | DetNet flow identity and the payload MPLS payload type satisfying (1) | |||
(2) in the list above. OAM traffic discrimination happens through | and (2) in the list above. OAM traffic discrimination happens | |||
the use of the Associated Channel method described in [RFC4385]. The | through the use of the Associated Channel method described in | |||
DetNet sequence number is carried in the DetNet Control word which | [RFC4385]. The DetNet sequence number is carried in the DetNet | |||
carries the Data/OAM discriminator. To simplify implementation and | Control word which carries the Data/OAM discriminator. To simplify | |||
to maximize interoperability two sequence number sizes are supported: | implementation and to maximize interoperability two sequence number | |||
a 16 bit sequence number and a 28 bit sequence number. The 16 bit | sizes are supported: a 16 bit sequence number and a 28 bit sequence | |||
sequence number is needed to support some types of legacy clients. | number. The 16 bit sequence number is needed to support some types | |||
The 28 bit sequence number is used in situations where it is | of legacy clients. The 28 bit sequence number is used in situations | |||
necessary ensure that in high speed networks the sequence number | where it is necessary ensure that in high speed networks the sequence | |||
space does not wrap whilst packets are in flight. | number space does not wrap whilst packets are in flight. | |||
The LSP used to forward the DetNet packet is not restricted regarding | The LSP used to forward the DetNet packet is not restricted regarding | |||
any method used for establishing that LSP (for example, MPLS-LDP, | any method used for establishing that LSP (for example, MPLS-LDP, | |||
MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP | MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP | |||
(F-Label) label and/or the S-Label may be used to indicate the queue | (F-Label) label(s) and/or the S-Label may be used to indicate the | |||
processing as well as the forwarding parameters. Note that the | required queue processing as well as the forwarding parameters. Note | |||
possible use of Penultimate Hop Popping (PHP) means that the S-Label | that the possible use of Penultimate Hop Popping (PHP) means that the | |||
may be the only label received at the terminating DetNet service. | S-Label may be the only label received at the terminating DetNet | |||
service. | ||||
4.2. MPLS Data Plane Encapsulation | 4.2. MPLS Data Plane Encapsulation | |||
Figure 4 illustrates a DetNet data plane MPLS encapsulation. The | Figure 4 illustrates a DetNet data plane MPLS encapsulation. The | |||
MPLS-based encapsulation of the DetNet flows is well suited for the | MPLS-based encapsulation of the DetNet flows is well suited for the | |||
scenarios described in [I-D.ietf-detnet-data-plane-framework]. | scenarios described in [I-D.ietf-detnet-data-plane-framework]. | |||
Furthermore, an end to end DetNet service i.e., native DetNet | Furthermore, an end to end DetNet service i.e., native DetNet | |||
deployment (see Section 3.2) is also possible if DetNet end systems | deployment (see Section 3.2) is also possible if DetNet end systems | |||
are capable of initiating and termination MPLS encapsulated packets. | are capable of initiating and termination MPLS encapsulated packets. | |||
skipping to change at page 9, line 43 ¶ | skipping to change at page 9, line 44 ¶ | |||
o DetNet control word (d-CW) containing sequencing information for | o DetNet control word (d-CW) containing sequencing information for | |||
packet replication and duplicate elimination purposes, and the OAM | packet replication and duplicate elimination purposes, and the OAM | |||
indicator. | indicator. | |||
o DetNet service Label (S-Label) that identifies a DetNet flow at | o DetNet service Label (S-Label) that identifies a DetNet flow at | |||
the receiving DetNet service sub-layer processing node. | the receiving DetNet service sub-layer processing node. | |||
o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to | o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to | |||
direct the packet along the label switched path (LSP) to the next | direct the packet along the label switched path (LSP) to the next | |||
service sub-layer processing node along the path. When | DetNet service sub-layer processing node along the path. When | |||
Penultimate Hop Popping is in use there may be no label F-Label in | Penultimate Hop Popping is in use there may be no label F-Label in | |||
the protocol stack on the final hop. | the protocol stack on the final hop. | |||
o The necessary data-link encapsulation is then applied prior to | o The necessary data-link encapsulation is then applied prior to | |||
transmission over the physical media. | transmission over the physical media. | |||
DetNet MPLS-based encapsulation | DetNet MPLS-based encapsulation | |||
+---------------------------------+ | +---------------------------------+ | |||
| | | | | | |||
skipping to change at page 11, line 6 ¶ | skipping to change at page 11, line 6 ¶ | |||
(bits 0 to 3) | (bits 0 to 3) | |||
Per [RFC4385], MUST be set to zero (0). | Per [RFC4385], MUST be set to zero (0). | |||
Sequence Number (bits 4 to 31) | Sequence Number (bits 4 to 31) | |||
An unsigned value implementing the DetNet sequence number. The | An unsigned value implementing the DetNet sequence number. The | |||
sequence number space is a circular one. | sequence number space is a circular one. | |||
A separate sequence number space MUST be maintained by the node that | A separate sequence number space MUST be maintained by the node that | |||
adds the d-CW for each DetNet app-flow. The following sequence | adds the d-CW for each DetNet app-flow, i.e., DetNet service. The | |||
number field lengths MUST be supported: | following sequence number field lengths MUST be supported: | |||
0 bits | 0 bits | |||
16 bits | 16 bits | |||
28 bits | 28 bits | |||
The sequence number length MUST be provisioned on a per app-flow | The sequence number length MUST be provisioned on a per Detnet | |||
basis via configuration, i.e., via the controller plane described in | service basis via configuration, i.e., via the controller plane | |||
[I-D.ietf-detnet-data-plane-framework]. | described in [I-D.ietf-detnet-data-plane-framework]. | |||
A 0 bit sequence number field length indicates that there is no | A 0 bit sequence number field length indicates that there is no | |||
DetNet sequence number used for the flow. When the length is zero, | DetNet sequence number used for the flow. When the length is zero, | |||
the sequence number field MUST be set to zero (0) on all packets sent | the sequence number field MUST be set to zero (0) on all packets sent | |||
for the flow. | for the flow. | |||
When the sequence number field length is 16 or 28 bits for a flow, | When the sequence number field length is 16 or 28 bits for a flow, | |||
the sequence number MUST be incremented by one for each new app-flow | the sequence number MUST be incremented by one for each new app-flow | |||
packet sent. When the field length is 16 bits, d-CW bits 4 to 15 | packet sent. When the field length is 16 bits, d-CW bits 4 to 15 | |||
MUST be set to zero (0). The values carried in this field can wrap | MUST be set to zero (0). The values carried in this field can wrap | |||
and it is important to note that zero (0) is a valid field value. | and it is important to note that zero (0) is a valid field value. | |||
For example, were the sequence number size is 16 bits, the sequence | For example, were the sequence number size is 16 bits, the sequence | |||
will contain: 65535, 0, 1, where zero (0) is an ordinary sequence | will contain: 65535, 0, 1, where zero (0) is an ordinary sequence | |||
number. | number. | |||
It is important to note that this document differs from [RFC4448] | It is important to note that this document differs from [RFC4448] | |||
where a sequence number of zero (0) is used to indicate that the | where a sequence number of zero (0) is used to indicate that the | |||
sequence number check algorithm is not used. | sequence number check algorithm is not used. | |||
The sequence number is optionally used during receive processing as | The sequence number is optionally used during receive processing as | |||
described below in Section 4.2.2.1 and Section 4.2.2.2. | described below in Section 4.2.2.2 and Section 4.2.2.3. | |||
4.2.2. S-Labels | 4.2.2. S-Labels | |||
App-flow identification at a DetNet service sub-layer is realized by | A DetNet flow at the DetNet service sub-layer is identified by an | |||
an S-Label. MPLS-aware DetNet end systems and edge nodes, which are | S-Label. MPLS-aware DetNet end systems and edge nodes, which are by | |||
by definition MPLS ingress and egress nodes, MUST add and remove an | definition MPLS ingress and egress nodes, MUST add (push) and remove | |||
app-flow specific d-CW and S-Label. Relay nodes MAY swap S-Label | (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY | |||
values when processing an app-flow. | swap S-Label values when processing a DetNet flow, i.e., incoming and | |||
outgoing S-Labels of a DetNet flow can be different. | ||||
The S-Label value MUST be provisioned per app-flow via configuration, | S-Label values MUST be provisioned per DetNet service via | |||
e.g., via the controller plane described in | configuration, e.g., via the controller plane described in | |||
[I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide | [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide | |||
app-flow identification at the downstream DetNet service sub-layer | identification at the downstream DetNet service sub-layer receiver, | |||
receiver, not the sender. As such, S-Labels MUST be allocated by the | not the sender. As such, S-Labels MUST be allocated by the entity | |||
entity that controls the service sub-layer receiving node's label | that controls the service sub-layer receiving node's label space, and | |||
space, and MAY be allocated from the platform label space [RFC3031]. | MAY be allocated from the platform label space [RFC3031]. Because | |||
Because S-Labels are local to each node rather than being a global | S-Labels are local to each node rather than being a global identifier | |||
identifier within a domain, they must be advertised to their upstream | within a domain, they must be advertised to their upstream DetNet | |||
DetNet service-aware peer nodes (e.g., a DetNet MPLS End System or a | service-aware peer nodes (e.g., a DetNet MPLS End System or a DetNet | |||
DetNet Relay or Edge Node and interpreted in the context of their | Relay or Edge Node) and interpreted in the context of their received | |||
received F-Label. | F-Label(s). | |||
The S-Label will normally be at the bottom of the label stack once | An S-Label will normally be at the bottom of the label stack once the | |||
the last F-Label is removed, immediately preceding the d-CW. To | last F-Label is removed, immediately preceding the d-CW. To support | |||
support service sub-layer level OAM, an OAM Associated Channel Header | service sub-layer level OAM, an OAM Associated Channel Header (ACH) | |||
(ACH) [RFC4385] together with a Generic Associated Channel Label | [RFC4385] together with a Generic Associated Channel Label (GAL) | |||
(GAL) [RFC5586] MAY be used in place of a d-CW. | [RFC5586] MAY be used in place of a d-CW. | |||
Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) | Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) | |||
[RFC6790] MAY be carried below the S-Label in the label stack in | [RFC6790] MAY be carried below the S-Label in the label stack in | |||
networks where DetNet flows would otherwise received ECMP treatment. | networks where DetNet flows would otherwise received ECMP treatment. | |||
When ELs are used, the same EL value SHOULD be used for all of the | When ELs are used, the same EL value SHOULD be used for all of the | |||
packets sent using a specific S-Label to force the flow to follow the | packets sent using a specific S-Label to force the flow to follow the | |||
same path. However, as outlines in | same path. However, as outlines in | |||
[I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet | [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet | |||
flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows | flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows | |||
within a DetNet domain. | within a DetNet domain. | |||
When receiving a DetNet MPLS flow, an implementation MUST identify | When receiving a DetNet MPLS packet, an implementation MUST identify | |||
the app-flow associated with the incoming packet based on the | the DetNet service associated with the incoming packet based on the | |||
S-Label. When a node is using platform labels for S-Labels, no | S-Label. When a node is using platform labels for S-Labels, no | |||
additional information is needed as the S-label uniquely identifies | additional information is needed as the S-label uniquely identifies | |||
the app-flow. In the case where platform labels are not used, zero | the DetNet service. In the case where platform labels are not used, | |||
or more F-Labels and optionally, the incoming interface, proceeding | zero or more F-Labels and optionally, the incoming interface, | |||
the S-Label MUST be used together with the S-Label to uniquely | proceeding the S-Label MUST be used together with the S-Label to | |||
identify the app-flows associated with a received packet. The | uniquely identify the DetNet service associated with a received | |||
incoming interface MAY also be used to together with any present | packet. The incoming interface MAY also be used together with any | |||
F-Label(s) and the S-Label to uniquely identify an incoming app- | present F-Label(s) and the S-Label to uniquely identify an incoming | |||
flows, for example, to in the case where PHP is used. Note that | DetNet service, for example, in the case where PHP is used. Note | |||
choice to use platform label space for S-Label or S-Label plus one or | that choice to use platform label space for S-Label or S-Label plus | |||
more F-Labels to identify app flows is a local implementation choice, | one or more F-Labels to identify DetNet services is a local | |||
with one caveat. When one or more F-labels, or incoming interface, | implementation choice, with one caveat. When one or more F-labels, | |||
is needed together with an S-Label to uniquely identify, the | or incoming interface, is needed together with an S-Label to uniquely | |||
controller plane MUST ensure that incoming DetNet MPLS packets arrive | identify a service, the controller plane must ensure that incoming | |||
with the needed information (F-label(s) and/or incoming interface); | DetNet MPLS packets arrive with the needed information (F-label(s) | |||
the details of such are outside the scope of this document. | and/or incoming interface) and provision the needed information. The | |||
provisioned information MUST then be used to identify incoming DetNet | ||||
service based on the combination of S-Label and F-Label(s) or | ||||
incoming interface. | ||||
The use of platform labels for S-Labels matches other pseudowire | The use of platform labels for S-Labels matches other pseudowire | |||
encapsulations for consistency but there is no hard requirement in | encapsulations for consistency but there is no hard requirement in | |||
this regard. | this regard. | |||
4.2.2.1. Packet Elimination Function Processing | 4.2.2.1. Packet Replication Function Processing | |||
The Packet Replication Function (PRF) function MAY be supported by an | ||||
implementation for outgoing DetNet flows. The use of the PRF for a | ||||
particular DetNet service MUST be provisioned via configuration, | ||||
e.g., via the controller plane described in | ||||
[I-D.ietf-detnet-data-plane-framework]. When replication is | ||||
configure, the same app-flow data will be sent over multiple outgoing | ||||
DetNet member flows using forwarding sub-layer LSPs. The same d-CW | ||||
field value MUST be used on all outgoing member flows for each | ||||
replicated MPLS packet. | ||||
4.2.2.2. Packet Elimination Function Processing | ||||
Implementations MAY support the Packet Elimination Function (PEF) for | Implementations MAY support the Packet Elimination Function (PEF) for | |||
received DetNet MPLS flows. When supported, use of the PEF for a | received DetNet MPLS flows. When supported, use of the PEF for a | |||
particular app-flow MUST be provisioned via configuration, e.g., via | particular DetNet service MUST be provisioned via configuration, | |||
the controller plane described in | e.g., via the controller plane described in | |||
[I-D.ietf-detnet-data-plane-framework]. | [I-D.ietf-detnet-data-plane-framework]. | |||
After an app-flow is identified for a received DetNet MPLS packet, as | After a DetNet service is identified for a received DetNet MPLS | |||
described above, an implementation MUST check if PEF is configured | packet, as described above, an implementation MUST check if PEF is | |||
for that app-flow. When configured, the implementation MUST track | configured for that DetNet service. When configured, the | |||
the sequence number contained in received d-CWs and MUST ensure that | implementation MUST track the sequence number contained in received | |||
duplicate (replicated) instances of a particular sequence number are | d-CWs and MUST ensure that duplicate (replicated) instances of a | |||
discarded. The specific mechanisms used for an implementation to | particular sequence number are discarded. The specific mechanisms | |||
identify which received packets are duplicates and which are new is | used for an implementation to identify which received packets are | |||
an implementation choice. Note that per Section 4.2.1 the sequence | duplicates and which are new is an implementation choice. Note that | |||
number field length may be 16 or 28 bits, and the field value can | per Section 4.2.1 the sequence number field length may be 16 or 28 | |||
wrap. | bits, and the field value can wrap. PEF MUST NOT be used with DetNet | |||
flows configured with a d-CW sequence number field length of 0 bits. | ||||
Note that an implementation MAY wish to constrain the maximum number | Note that an implementation MAY wish to constrain the maximum number | |||
sequence numbers that are tracked, on platform-wide or per flow | sequence numbers that are tracked, on platform-wide or per flow | |||
basis. Some implementations MAY support the provisioning of the | basis. Some implementations MAY support the provisioning of the | |||
maximum number sequence numbers that are tracked number on either a | maximum number sequence numbers that are tracked number on either a | |||
platform-wide or per flow basis. | platform-wide or per flow basis. | |||
4.2.2.2. Packet Ordering Function Processing | 4.2.2.3. Packet Ordering Function Processing | |||
A function that is related to in-order delivery is the Packet | A function that is related to in-order delivery is the Packet | |||
Ordering Function (POF). Implementations MAY support POF. When | Ordering Function (POF). Implementations MAY support POF. When | |||
supported, use of the POF for a particular app-flow MUST be | supported, use of the POF for a particular DetNet service MUST be | |||
provisioned via configuration, e.g., via the controller plane | provisioned via configuration, e.g., via the controller plane | |||
described by [I-D.ietf-detnet-data-plane-framework]. Implementations | described by [I-D.ietf-detnet-data-plane-framework]. Implementations | |||
MAY required that PEF and POF be used in combination. There is no | MAY required that PEF and POF be used in combination. There is no | |||
requirement related to the order of execution of the Packet | requirement related to the order of execution of the Packet | |||
Elimination and Ordering Functions in an implementation. | Elimination and Ordering Functions in an implementation. | |||
After an app-flow is identified for a received DetNet MPLS packet, as | After a DetNet service is identified for a received DetNet MPLS | |||
described above, an implementation MUST check if POF is configured | packet, as described above, an implementation MUST check if POF is | |||
for that app-flow. When configured, the implementation MUST track | configured for that DetNet service. When configured, the | |||
the sequence number contained in received d-CWs and MUST ensure that | implementation MUST track the sequence number contained in received | |||
packets are processed in the order indicated in the received d-CW | d-CWs and MUST ensure that packets are processed in the order | |||
sequence number field, which may not be in the order the packets are | indicated in the received d-CW sequence number field, which may not | |||
received. As defined in Section 4.2.1 the sequence number field | be in the order the packets are received. As defined in | |||
length may be 16 or 28 bits, is incremented by one (1) for each new | Section 4.2.1 the sequence number field length may be 16 or 28 bits, | |||
app-flow packet sent, and the field value can wrap. The specific | is incremented by one (1) for each new MPLS packet sent for a | |||
mechanisms used for an implementation to identify the order of | particular DetNet service, and the field value can wrap. The | |||
received packets is an implementation choice. | specific mechanisms used for an implementation to identify the order | |||
of received packets is an implementation choice. | ||||
Note that an implementation MAY wish to constrain the maximum number | Note that an implementation MAY wish to constrain the maximum number | |||
of out of order packets that can be processed, on platform-wide or | of out of order packets that can be processed, on platform-wide or | |||
per flow basis. Some implementations MAY support the provisioning of | per flow basis. Some implementations MAY support the provisioning of | |||
this number on either a platform-wide or per flow basis. The number | this number on either a platform-wide or per flow basis. The number | |||
of out of order packets that can be processed also impacts the | of out of order packets that can be processed also impacts the | |||
latency of a flow. | latency of a flow. | |||
4.2.3. F-Labels | 4.2.3. F-Labels | |||
F-Labels are supported the DetNet forwarding sub-layer. F-Labels are | F-Labels are supported the DetNet forwarding sub-layer. F-Labels are | |||
used to provide LSP-based connectivity between DetNet service sub- | used to provide LSP-based connectivity between DetNet service sub- | |||
layer processing nodes. | layer processing nodes. | |||
4.2.3.1. Service Sub-Layer and Packet Replication Function Processing | 4.2.3.1. Service Sub-Layer Related Processing | |||
DetNet MPLS end systems, edge nodes and relay nodes may operate at | DetNet MPLS end systems, edge nodes and relay nodes may operate at | |||
the DetNet service sub-layer with understand of app-flows and their | the DetNet service sub-layer with understanding of DetNet services | |||
requirements. As mentioned earlier, when operating at this layer | and their requirements. As mentioned earlier, when operating at this | |||
such nodes can push, pop or swap (pop then push) S-Labels. In all | layer such nodes can push, pop or swap (pop then push) S-Labels. In | |||
cases, the F-Labels used for the app-flow are always replaced and the | all cases, the F-Label(s) used for a DetNet service are always | |||
following procedures apply. | replaced and the following procedures apply. | |||
When sending a DetNet flow, zero or more F-Labels MAY be pushed on | When sending a DetNet flow, zero or more F-Labels MAY be pushed on | |||
top of an S-Label by the node pushing an S-Label. The F-Labels to be | top of an S-Label by the node pushing an S-Label. The F-Label(s) to | |||
pushed when sending a particular app-flow MUST be provisioned per | be pushed when sending a particular DetNet service MUST be | |||
app-flow via configuration, e.g., via the controller plane discussed | provisioned per DetNet service via configuration, e.g., via the | |||
in [I-D.ietf-detnet-data-plane-framework]. F-Labels can also provide | controller plane discussed in [I-D.ietf-detnet-data-plane-framework]. | |||
context for an S-Label. To allow for the omission of F-Labels, an | F-Label(s) can also provide context for an S-Label. To allow for the | |||
implementation SHOULD also allow an outgoing interface to be used. | omission of F-Label(s), an implementation SHOULD also allow an | |||
outgoing interface to be configured. | ||||
The Packet Replication Function (PRF) function MAY be supported by an | When PRF is supported, the same app-flow data will be sent over | |||
implementation for outgoing DetNet flows. When replication is | multiple outgoing DetNet member flows using forwarding sub-layer | |||
supported, the same app-flow data will be sent over multiple outgoing | LSPs. To support PRF an implementation MUST support the setting of | |||
forwarding sub-layer LSPs. To support PRF an implementation MUST | different sets of F-Labels per DetNet member flow. To allow for the | |||
support the setting of different sets of F-Labels. To allow for the | ||||
omission of F-Labels, an implementation SHOULD also allow multiple | omission of F-Labels, an implementation SHOULD also allow multiple | |||
outgoing interfaces to be provisioned. PRF MUST NOT be used with | outgoing interfaces to be provisioned. | |||
app-flows configured with a d-CW sequence number field length of 0 | ||||
bits. | ||||
When a single set of F-Labels is provisioned for a particular | When a single set of F-Labels is provisioned for a particular | |||
outgoing app-flow, that set of F-labels MUST be pushed after the | outgoing S-Label, that set of F-labels MUST be pushed after the | |||
S-Label is pushed. The outgoing packet is then forwarded as | S-Label is pushed. The outgoing packet is then forwarded as | |||
described below in Section 4.2.3.2. When a single outgoing interface | described below in Section 4.2.3.2. When a single outgoing interface | |||
is provisioned, the outgoing packet is then forwarded as described | is provisioned, the outgoing packet is then forwarded as described | |||
below in Section 4.2.3.2. | below in Section 4.2.3.2. | |||
When multiple sets of F-Labels or interfaces are provisioned for a | When multiple sets of outgoing F-Labels or interfaces are provisioned | |||
particular outgoing app-flow, a copy of the outgoing packet, | for a particular DetNet service, a copy of the outgoing packet, | |||
including the pushed S-Label, MUST be made per F-label set and | including the pushed S-Label, MUST be made per F-label set and | |||
outgoing interface. Each set of provisioned F-Labels are then pushed | outgoing interface. Each set of provisioned F-Labels are then pushed | |||
onto a copy of the packet. Each copy is then forwarded as described | onto a copy of the packet. Each copy is then forwarded as described | |||
below in Section 4.2.3.2. | below in Section 4.2.3.2. | |||
As described in the previous section, when receiving a DetNet MPLS | As described in the previous section, when receiving a DetNet MPLS | |||
flow, an implementation identifies the app-flow associated with the | flow, an implementation identifies the DetNet service associated with | |||
incoming packet based on the S-Label. When a node is using platform | the incoming packet based on the S-Label. When a node is using | |||
labels for S-Labels, any F-Labels can be popped and the S-label | platform labels for S-Labels, any F-Labels can be popped and the | |||
uniquely identifies the app-flow. In the case where platform labels | S-label uniquely identifies the DetNet service. In the case where | |||
are not used, F-Label(s) and, optionally, the incoming interface MUST | platform labels are not used, incoming F-Label(s) and, optionally, | |||
also be provisioned for incoming app-flows. The provisioned | the incoming interface MUST also be provisioned for a DetNet service. | |||
information MUST then be used to identify incoming app-flows based on | ||||
the combination of S-Label and F-Label(s) or incoming interface. | ||||
4.2.3.2. Common F-Label Processing | 4.2.3.2. Common F-Label Processing | |||
All DetNet aware MPLS nodes process F-Labels as needed to meet the | All DetNet aware MPLS nodes process F-Labels as needed to meet the | |||
service requirements of the DetNet flow or flows carried in the LSPs | service requirements of the DetNet flow or flows carried in the LSPs | |||
represented by the F-Labels. This includes normal push, pop and swap | represented by the F-Labels. This includes normal push, pop and swap | |||
operations. Such processing is essentially the same type of | operations. Such processing is essentially the same type of | |||
processing provided for TE LSPs, although the specific service | processing provided for TE LSPs, although the specific service | |||
parameters, or traffic specification, can differ. When the DetNet | parameters, or traffic specification, can differ. When the DetNet | |||
service parameters of the app-flow or flows carried in an LSP | service parameters of the DetNet flow or flows carried in an LSP | |||
represented by an F-Label can be met by an exiting TE mechanism, the | represented by an F-Label can be met by an existing TE mechanism, the | |||
forwarding sub-layer processing node MAY be a DetNet unaware, i.e., | forwarding sub-layer processing node MAY be a DetNet unaware, i.e., | |||
standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service | standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service | |||
as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], | as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], | |||
[RFC3473], [RFC4875], [RFC5440], and [RFC8306]. | [RFC3473], [RFC4875], [RFC5440], and [RFC8306]. | |||
More specifically, as mentioned above, the DetNet forwarding sub- | More specifically, as mentioned above, the DetNet forwarding sub- | |||
layer provides explicit routes and allocated resources, and F-Labels | layer provides explicit routes and allocated resources, and F-Labels | |||
are used to map to each. Explicit routes are supported based on the | are used to map to each. Explicit routes are supported based on the | |||
topmost (outermost) F-Label that is pushed or swapped and the LSP | topmost (outermost) F-Label that is pushed or swapped and the LSP | |||
that corresponds to this label. This topmost (outgoing) label MUST | that corresponds to this label. This topmost (outgoing) label MUST | |||
skipping to change at page 17, line 4 ¶ | skipping to change at page 17, line 17 ¶ | |||
4.3. OAM Indication | 4.3. OAM Indication | |||
OAM follows the procedures set out in [RFC5085] with the restriction | OAM follows the procedures set out in [RFC5085] with the restriction | |||
that only Virtual Circuit Connectivity Verification (VCCV) type 1 is | that only Virtual Circuit Connectivity Verification (VCCV) type 1 is | |||
supported. | supported. | |||
As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW | As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW | |||
is 0x0 the payload following the d-CW is normal user data. However, | is 0x0 the payload following the d-CW is normal user data. However, | |||
when the first nibble of the d-CW is 0X1, the payload that follows | when the first nibble of the d-CW is 0X1, the payload that follows | |||
the d-DW is an OAM payload with the OAM type indicated by the value | the d-CW is an OAM payload with the OAM type indicated by the value | |||
in the d-CW Channel Type field. | in the d-CW Channel Type field. | |||
The reader is referred to [RFC5085] for a more detailed description | The reader is referred to [RFC5085] for a more detailed description | |||
of the Associated Channel mechanism, and to the DetNet work on OAM | of the Associated Channel mechanism, and to the DetNet work on OAM | |||
for more information DetNet OAM. | for more information DetNet OAM. | |||
Additional considerations on DetNet-specific OAM are subjects for | Additional considerations on DetNet-specific OAM are subjects for | |||
further study. | further study. | |||
4.4. Flow Aggregation | 4.4. Flow Aggregation | |||
skipping to change at page 18, line 44 ¶ | skipping to change at page 19, line 5 ¶ | |||
Both the aggregation label, which is referred to as an A-Label, and | Both the aggregation label, which is referred to as an A-Label, and | |||
the individual flow's S-Label have their MPLS S bit set indicating | the individual flow's S-Label have their MPLS S bit set indicating | |||
bottom of stack, and the d-CW allows the PREOF to work. An A-Label | bottom of stack, and the d-CW allows the PREOF to work. An A-Label | |||
is a special case of an S-Label, whose properties are known only at | is a special case of an S-Label, whose properties are known only at | |||
the aggregation and deaggregation end-points. | the aggregation and deaggregation end-points. | |||
It is a property of the A-Label that what follows is a d-CW followed | It is a property of the A-Label that what follows is a d-CW followed | |||
by an MPLS label stack. A relay node processing the A-Label would | by an MPLS label stack. A relay node processing the A-Label would | |||
not know the underlying payload type, and the A-Label would be | not know the underlying payload type, and the A-Label would be | |||
process as a normal S-Label. This would only be known to a node that | processed as a normal S-Label. This would only be known to a node | |||
was a peer of the node imposing the S-Label. However there is no | that was a peer of the node imposing the S-Label. However there is | |||
real need for it to know the payload type during aggregation | no real need for it to know the payload type during aggregation | |||
processing. | processing. | |||
As in the previous section, nodes supporting this type of aggregation | As in the previous section, nodes supporting this type of aggregation | |||
will need to ensure that individual and aggregated flows receive the | will need to ensure that individual and aggregated flows receive the | |||
traffic treatment required to ensure the required DetNet service is | traffic treatment required to ensure the required DetNet service is | |||
preserved. Also, it is the controller plane's responsibility to to | preserved. Also, it is the controller plane's responsibility to to | |||
ensure that the service required on the aggregate flow are properly | ensure that the service required on the aggregate flow are properly | |||
provisioned. | provisioned. | |||
4.5. Service Sub-Layer Considerations | 4.5. Service Sub-Layer Considerations | |||
skipping to change at page 19, line 25 ¶ | skipping to change at page 19, line 35 ¶ | |||
receive such packets the replication function would make the loop | receive such packets the replication function would make the loop | |||
more destructive of bandwidth than a conventional unicast loop. | more destructive of bandwidth than a conventional unicast loop. | |||
Ultimately the TTL in the S-Label will cause the packet to die during | Ultimately the TTL in the S-Label will cause the packet to die during | |||
a transient loop, but given the sensitivity of applications to packet | a transient loop, but given the sensitivity of applications to packet | |||
latency the impact on the DetNet application would be severe. To | latency the impact on the DetNet application would be severe. To | |||
avoid the problem of a transient forwarding loop, changes to an LSP | avoid the problem of a transient forwarding loop, changes to an LSP | |||
supporting DetNet MUST be loop-free. | supporting DetNet MUST be loop-free. | |||
4.5.1. Edge Node Processing | 4.5.1. Edge Node Processing | |||
An edge node is responsible for matching ingress packets to the | A DetNet Edge node operates in the DetNet forwarding sub-layer and | |||
service they require and encapsulating them accordingly. An edge | service sub-layer. An edge node is responsible for matching incoming | |||
node may participate in the packet replication and duplicate packet | packets to the service they require and encapsulating them | |||
elimination. | accordingly. An edge node may perform PRF, PEF, and or POF. Details | |||
on encapsulation can be found in Section 4.2; details on PRF can be | ||||
The DetNet-aware forwarder selects the egress DetNet member flow | found in Section 4.2.2.1; details on PEF can be found in | |||
segment based on the flow identification. The mapping of ingress | Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3. | |||
DetNet member flow segment to egress DetNet member flow segment may | ||||
be statically or dynamically configured. Additionally the DetNet- | ||||
aware forwarder does duplicate frame elimination based on the flow | ||||
identification and the sequence number combination. The packet | ||||
replication is also done within the DetNet-aware forwarder. | ||||
4.5.2. Relay Node Processing | 4.5.2. Relay Node Processing | |||
A DetNet Relay node operates in the DetNet forwarding sub-layer and | A DetNet Relay node operates in the DetNet forwarding sub-layer and | |||
service sub-layer. For DetNet using MPLS forwarding related | service sub-layer. For DetNet using MPLS forwarding related | |||
processing is performed on the F-Label. This processing is done | processing is performed on the F-Label. This processing is done | |||
within an extended forwarder function. Whether an ingress DetNet | within an extended forwarder function. Whether an incoming DetNet | |||
member flow receives DetNet specific processing depends on how the | flow receives DetNet specific processing depends on how the | |||
forwarding is programmed. Some relay nodes may be DetNet service | forwarding is programmed. Some relay nodes may be DetNet service | |||
aware for certain DetNet services, while for other DetNet services | aware for certain DetNet services, while for other DetNet services | |||
these nodes may perform as unmodified LSRs that only understand how | these nodes may perform as unmodified LSRs that only understand how | |||
to switch MPLS-TE LSPs, i.e., as a transit nodes, see Section 4.4. | to switch MPLS-TE LSPs, i.e., as a transit node, see Section 4.4. | |||
Again, this is entirely up to how the forwarding has been programmed. | Again, this is entirely up to how the forwarding has been programmed. | |||
During the elimination and replication process the sequence number of | During the elimination and replication process the sequence number of | |||
the ingress DetNet member flow MUST be preserved and copied to the | an incoming DetNet packet MUST be preserved and carried in the | |||
corresponding egress DetNet member flow. Specifically, a relay node | corresponding outgoing DetNet packet. For example, a relay node that | |||
sends the same sequence number in an outgoing packet of a DetNet | performs both PEF and PRF first performs PEF on incoming packets to | |||
member flow that is received in the corresponding incoming packet of | create a compound flow. It then performs PRF and copies the app-flow | |||
a DetNet compound flow. This is true whether or not PREOF is | data and the d-CW into packets for each outgoing DetNet member flow. | |||
performed at the relay node. | ||||
The internal design of a relay node is out of scope of this document. | The internal design of a relay node is out of scope of this document. | |||
However the reader's attention is drawn to the need to make any PREOF | However the reader's attention is drawn to the need to make any PREOF | |||
state available to the packet processor(s) dealing with packets to | state available to the packet processor(s) dealing with packets to | |||
which the PREOF functions must be applied, and to maintain that state | which the PREOF functions must be applied, and to maintain that state | |||
is such away that it is available to the packet processor operation | is such a way that it is available to the packet processor operation | |||
on the next packet in the DetNet flow (which may be a duplicate, a | on the next packet in the DetNet flow (which may be a duplicate, a | |||
late packet, or the next packet in sequence. | late packet, or the next packet in sequence). | |||
4.6. Forwarding Sub-Layer Considerations | 4.6. Forwarding Sub-Layer Considerations | |||
4.6.1. Class of Service | 4.6.1. Class of Service | |||
Class and quality of service, i.e., CoS and QoS, are terms that are | Class and quality of service, i.e., CoS and QoS, are terms that are | |||
often used interchangeably and confused with each other. In the | often used interchangeably and confused with each other. In the | |||
context of DetNet, CoS is used to refer to mechanisms that provide | context of DetNet, CoS is used to refer to mechanisms that provide | |||
traffic forwarding treatment based on aggregate group basis and QoS | traffic forwarding treatment based on aggregate group basis and QoS | |||
is used to refer to mechanisms that provide traffic forwarding | is used to refer to mechanisms that provide traffic forwarding | |||
skipping to change at page 22, line 8 ¶ | skipping to change at page 22, line 15 ¶ | |||
both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., | both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., | |||
and hybrid combinations of the two. The details of the controller | and hybrid combinations of the two. The details of the controller | |||
plane solution required for the label distribution and the management | plane solution required for the label distribution and the management | |||
of the label number space are out of scope of this document. There | of the label number space are out of scope of this document. There | |||
are particular DetNet considerations and requirements that are | are particular DetNet considerations and requirements that are | |||
discussed in [I-D.ietf-detnet-data-plane-framework]. | discussed in [I-D.ietf-detnet-data-plane-framework]. | |||
5.1. Service Sub-Layer Information Summary | 5.1. Service Sub-Layer Information Summary | |||
The following summarizes the information that is needed on service | The following summarizes the information that is needed on service | |||
sub-layer aware nodes that send DetNet MPLS traffic, on a per service | sub-layer aware nodes that transmit DetNet MPLS traffic, on a per | |||
basis: | service basis: | |||
o App-Flow identification information, e.g., an incoming service on | o App-Flow identification information, e.g., IP information as | |||
a relay node or IP information as defined in | defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information | |||
[I-D.ietf-detnet-ip-over-mpls]. | is not needed on DetNet relay nodes. | |||
o The sequence number length to be used for the service. Valid | o The sequence number length to be used for the service. Valid | |||
values included 0, 16 and 28 bits. 0 bits cannot be used when PRF | values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | |||
is configured for the service. | or POF is configured for the service. | |||
o The S-Label for the service. | o The outgoing S-Label for the service. | |||
o If PRF is to be provided for the service. | o If PRF is to be provided for the service. | |||
o The forwarding sub-layer information associated with the output of | o The forwarding sub-layer information associated with the output of | |||
the service sub-layer. Note that when the PRF function is | the service sub-layer. Note that when the PRF function is | |||
provisioned, this information is per DetNet member flow. | provisioned, this information is per DetNet member flow. | |||
Logically the forwarding sub-layer information is a pointer to | Logically the forwarding sub-layer information is a pointer to | |||
further details of transmission of Detnet flows at the forwarding | further details of transmission of Detnet flows at the forwarding | |||
sub-layer. | sub-layer. | |||
The following summarizes the information that is needed on service | The following summarizes the information that is needed on service | |||
sub-layer aware nodes that receives DetNet MPLS traffic, on a per | sub-layer aware nodes that receive DetNet MPLS traffic, on a per | |||
service basis: | service basis: | |||
o The forwarding sub-layer information associated with the input of | o The forwarding sub-layer information associated with the input of | |||
the service sub-layer. Note that when the PEF function is | the service sub-layer. Note that when the PEF function is | |||
provisioned, this information is per DetNet member flow. | provisioned, this information is per DetNet member flow. | |||
Logically the forwarding sub-layer information is a pointer to | Logically the forwarding sub-layer information is a pointer to | |||
further details of the reception of Detnet flows at the forwarding | further details of the reception of Detnet flows at the forwarding | |||
sub-layer or A-Label. | sub-layer or A-Label. | |||
o The S-Label for the received service. | o The incoming S-Label for the service. | |||
o If PEF or POF is to be provided for the service. | o If PEF or POF is to be provided for the service. | |||
o The sequence number length to be used for the service. Valid | o The sequence number length to be used for the service. Valid | |||
values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | |||
or POF are configured for the service. | or POF are configured for the service. | |||
o App-Flow identification information, e.g., IP information as | ||||
defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information | ||||
is not needed on DetNet relay nodes. | ||||
5.1.1. Service Aggregation Information Summary | 5.1.1. Service Aggregation Information Summary | |||
Nodes performing aggregation using A-Labels, per | Nodes performing aggregation using A-Labels, per | |||
Section Section 4.4.2, require the additional information summarized | Section Section 4.4.2, require the additional information summarized | |||
in this section. | in this section. | |||
The following summarizes the information that is needed on a node | The following summarizes the additional information that is needed on | |||
that sends aggregated flows using A-Labels: | a node that sends aggregated flows using A-Labels: | |||
o The S-Labels or F-Labels that are to be carried over each | o The S-Labels or F-Labels that are to be carried over each | |||
aggregated service. | aggregated service. | |||
o The A-Label associated with each aggregated service. | o The A-Label associated with each aggregated service. | |||
o The other S-Label information summarized above. | o The other S-Label information summarized above. | |||
On the receiving node, the A-Label provides the forwarding context of | On the receiving node, the A-Label provides the forwarding context of | |||
an incoming interface or an F-Label and is used in subsequent service | an incoming interface or an F-Label and is used in subsequent service | |||
skipping to change at page 25, line 21 ¶ | skipping to change at page 25, line 32 ¶ | |||
domain. | domain. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document makes no IANA requests. | This document makes no IANA requests. | |||
8. Acknowledgements | 8. Acknowledgements | |||
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, | The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, | |||
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David | David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David | |||
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. | Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo | |||
Bernardos for their various contributions to this work. | and Carlos J. Bernardos for their various contributions to this | |||
work. | ||||
9. Contributors | 9. Contributors | |||
RFC7322 limits the number of authors listed on the front page of a | RFC7322 limits the number of authors listed on the front page of a | |||
draft to a maximum of 5. The editor wishes to thank and acknowledge | draft to a maximum of 5. The editor wishes to thank and acknowledge | |||
the follow author for contributing text to this draft. | the follow author for contributing text to this draft. | |||
Don Fedyk | Don Fedyk | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
Email: dfedyk@labn.net | Email: dfedyk@labn.net | |||
skipping to change at page 27, line 32 ¶ | skipping to change at page 27, line 48 ¶ | |||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-detnet-data-plane-framework] | [I-D.ietf-detnet-data-plane-framework] | |||
Varga, B., Farkas, J., Berger, L., Malis, A., and S. | Varga, B., Farkas, J., Berger, L., Malis, A., and S. | |||
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- | Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- | |||
data-plane-framework-06 (work in progress), May 2020. | data-plane-framework-06 (work in progress), May 2020. | |||
[I-D.ietf-detnet-ip] | [I-D.ietf-detnet-ip] | |||
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. | Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. | |||
Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 | Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 | |||
(work in progress), April 2020. | (work in progress), July 2020. | |||
[I-D.ietf-detnet-ip-over-mpls] | [I-D.ietf-detnet-ip-over-mpls] | |||
Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. | Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. | |||
Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- | Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- | |||
detnet-ip-over-mpls-06 (work in progress), May 2020. | detnet-ip-over-mpls-06 (work in progress), May 2020. | |||
[I-D.ietf-detnet-mpls-over-tsn] | [I-D.ietf-detnet-mpls-over-tsn] | |||
Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet | Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet | |||
Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking | Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking | |||
(TSN)", draft-ietf-detnet-mpls-over-tsn-02 (work in | (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in | |||
progress), March 2020. | progress), June 2020. | |||
[I-D.ietf-detnet-security] | [I-D.ietf-detnet-security] | |||
Mizrahi, T. and E. Grossman, "Deterministic Networking | Mizrahi, T. and E. Grossman, "Deterministic Networking | |||
(DetNet) Security Considerations", draft-ietf-detnet- | (DetNet) Security Considerations", draft-ietf-detnet- | |||
security-10 (work in progress), May 2020. | security-10 (work in progress), May 2020. | |||
[IEEE802.1AE-2018] | [IEEE802.1AE-2018] | |||
IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC | IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC | |||
Security (MACsec)", 2018, | Security (MACsec)", 2018, | |||
<https://ieeexplore.ieee.org/document/8585421>. | <https://ieeexplore.ieee.org/document/8585421>. | |||
End of changes. 58 change blocks. | ||||
183 lines changed or deleted | 199 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/ |