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

Commentary: Based on 06.24 discussions . Also some editorial clean up done .
Paragraph (version A):
These requirements are satisfied by the DetNet over MPLS
Encapsulation described in I-D.ietf-detnet-mpls.
Paragraph (version A):
Control Word.
Paragraph (version A):
A Detnet "forwarding" label that identifies the LSP used to
forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label
used between label switching routers (LSR).
Paragraph (version A):
Label Switching Router.
Paragraph (version B):
A special case of an S-Label, whose properties are known only at
the aggregation and deaggregation end-points.
Paragraph (version B):
A Detnet "forwarding" label that identifies the LSP used to
forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label
used between label switching routers.
Paragraph (version A):
Packet Replication, Elimination and Ordering Functions.
Paragraph (version A):
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 B):
This document builds on the specification of MPLS over UDP 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 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 A):
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 A):
To support receive processing an implementation MUST also support the
provisioning of received UDP/IP header information.
Paragraph (version A):
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 A):
IPv4 and IPv6 source address prefix length, where a zero (0) value
effectively means that the address field is ignored.
Paragraph (version A):
IPv4 and IPv6 destination address prefix length, where a zero (0)
effectively means that the address field is ignored.
Paragraph (version A):
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 A):
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 A):
IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
zero (0) effectively means that theses fields are ignored.
Paragraph (version A):
UDP Source Port.  Exact and wildcard matching is required.  Port
ranges can optionally be used.
Paragraph (version A):
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):
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 F-Label(s).  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 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.  The provisioned
information MUST be used to identify incoming app-flows based on the
combination of S-Label and incoming IP/UDP header.  Normal receive
processing, including PEF and POF can then take place.
Paragraph (version B):
Label information (S-label or F-label) to be mapped to UDP/IP
flow.
Paragraph (version B):
IPv4 protocol field.  Only UDP is allowed.
Paragraph (version B):
IPv6 next header field.  Only UDP is allowed.
Paragraph (version B):
UDP Source Port.
Paragraph (version B):
UDP Destination Port.