Draft: draft-ietf-detnet-mpls-over-udp-ip

Commentary: Based on 06.17 discussions . F - lables(s ) to Fig1 and text fixed . Adding procedures sections . Multiple notes for clarifications . Adding controller plane section . 
 reviewed in Jun 24 meeting
Paragraph (version A):
This document builds on the specification of MPLS over UDP and IP
defined in RFC7510.  It replaces the F-Label(s) used in I-D.ietf-
detnet-mpls with UDP and IP headers.  The UDP and IP header
information is used to identify DetNet flows, including member flows,
per I-D.ietf-detnet-ip.  The resulting encapsulation is shown in IP-
encap-dn.
Paragraph (version B):
This document builds on the specification of MPLS over UDP and IP
defined in RFC7510.  It may replace partly or entirely the F-Label(s)
used in I-D.ietf-detnet-mpls with UDP and IP headers.  The UDP and IP
header information is used to identify DetNet flows, including member
flows, per I-D.ietf-detnet-ip.  The resulting encapsulation is shown
in IP-encap-dn.  There may be zero or more F-label(s) between the
S-label and the UDP header.
Paragraph (version A):
To support outgoing DetNet MPLS over IP, an implementation MUST
support the provisioning of IP/UDP header information in place of
sets of F-Labels.  Note that multiple sets of F-Labels can be
provisioned to support PRF on transmitted DetNet flows and therefore,
when PRF is supported, multiple IP/UDP headers MAY be provisioned.
When multiple IP/UDP headers are provisioned for a particular
outgoing DetNet IP flow, a copy of the outgoing packet, including the
pushed S-Label, MUST be made for each.  The headers for each outgoing
packet MUST be based on the configuration information and as defined
in RFC7510, with one exception.  The one exception is that the UDP
Source Port value MUST be set to uniquely identify the DetNet
(forwarding sub-layer) flow.  The packet MUST then be handed as a
DetNet IP packet, per I-D.ietf-detnet-ip.
Paragraph (version A):
To support receive processing an implementation MUST also support the
provisioning of received IP/UDP header information.  When S-Labels
are taken from platform label space, all that is required is to
provision that receiving IP/UDP encapsulated DetNet MPLS packets is
permitted.  Once the IP/UDP header is stripped, the S-label uniquely
identifies the app-flow.  When S-Labels are not taken from platform
label space, IP/UDP header information MUST be provisioned.  The
provisioned information MUST then be used to identify incoming app-
flows based on the combination of S-Label and incoming IP/UDP header.
Normal receive processing, including PEOF can then take place.
Paragraph (version B):
To support outgoing DetNet MPLS over UDP/IP, an implementation MUST
support the provisioning of UDP/IP header information in addition or
in place of sets of F-Label(s).  Note that multiple sets of F-Labels
can be provisioned to support PRF on transmitted DetNet MPLS flows
and therefore, when PRF is supported, multiple UDP/IP headers MAY be
provisioned.
Paragraph (version B):
When multiple UDP/IP headers are provisioned for a particular
outgoing DetNet IP flow, a copy of the outgoing packet, including the
pushed S-Label (and optional F-label(s)), MUST be made for each.  The
headers for each outgoing packet MUST be based on the configuration
information and as defined in RFC7510, with one exception.  The one
exception is that the UDP Source Port value MUST be set to uniquely
identify the DetNet (forwarding sub-layer) flow.  The packet MUST
then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip.
Paragraph (version B):
To support receive processing an implementation MUST also support the
provisioning of received UDP/IP header information.
Paragraph (version B):
When S-Labels are taken from platform label space, all that is
required is to provision that receiving UDP/IP encapsulated DetNet
MPLS packets is permitted.  Once the UDP/IP header is stripped, the
S-label uniquely identifies the app-flow.  When S-Labels are not
taken from platform label space, UDP/IP header information MUST be
provisioned.  The provisioned information MUST then be used to
identify incoming app-flows based on the combination of S-Label and
incoming IP/UDP header.  Normal receive processing, including PEOF
can then take place.
Paragraph (version B):
IPv4 and IPv6 source address field.
Paragraph (version B):
IPv4 and IPv6 source address prefix length, where a zero (0) value
effectively means that the address field is ignored.
Paragraph (version B):
IPv4 and IPv6 destination address field.
Paragraph (version B):
IPv4 and IPv6 destination address prefix length, where a zero (0)
effectively means that the address field is ignored.
Paragraph (version B):
IPv4 protocol field.  Only UDP is allowed, and the ability to
ignore this field, e.g., via configuration of the value zero (0),
is desirable.
Paragraph (version B):
IPv6 next header field.  Only UDP is allowed, and the ability to
ignore this field, e.g., via configuration of the value zero (0),
is desirable.
Paragraph (version B):
IPv4 Type of Service and IPv6 Traffic Class Fields.
Paragraph (version B):
IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
zero (0) effectively means that theses fields are ignored.
Paragraph (version B):
UDP Source Port.  Exact and wildcard matching is required.  Port
ranges can optionally be used.
Paragraph (version B):
This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller or management plane.
Paragraph (version B):
Information identifying a DetNet flow is ordered and implementations
use the first match.  This can, for example, be used to provide a
DetNet service for a specific UDP flow, with unique Source and
Destination Port field values, while providing a different service
for the aggregate of all other flows with that same UDP Destination
Port value.
Paragraph (version B):
It is the responsibility of the DetNet controller plane to properly
provision both flow identification information and the flow specific
resources needed to provided the traffic treatment needed to meet
each flow's service requirements.  This applies for aggregated and
individual flows.