Draft: draft-ietf-detnet-dp-sol-ip-02

Commentary: Also revised travis - show txt and diff in travis log
fig_ip_detnet illustrates a variant of fig_ip_detnet_simple, with an
MPLS based DetNet network as a sub-network between the relay nodes.
It shows a more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs.  The end systems still
originate IP encapsulated traffic that is identified as DetNet flows.
The relay nodes follow procedures defined in I-D.ietf-detnet-dp-sol-
mpls to map each DetNet flow to MPLS LSPs.  While not shown, relay
nodes can provide service sub-layer functions such as PREOF using
DetNet over MPLS, and this is indicated by the solid line for the
MPLS facing portion of the Service component.  Note that the Transit
node is MPLS (TE) LSP aware and performs switching based on MPLS
labels, and need not have any specific knowledge of the DetNet
service or the corresponding DetNet flow identification.  See I-
D.ietf-detnet-dp-sol-mpls for details on the mapping of IP flows to
MPLS as well as general support for DetNet services using MPLS.
fig_ip_detnet illustrates a variant of fig_ip_detnet_simple, with an
MPLS based DetNet network as a sub-network between the relay nodes.
It shows a more complex DetNet enabled IP network where an IP flow is
mapped to one or more PWs and MPLS (TE) LSPs.  The end systems still
originate IP encapsulated traffic that is identified as DetNet flows.
The relay nodes follow procedures defined in ip-over-mpls to map each
DetNet flow to MPLS LSPs.  While not shown, relay nodes can provide
service sub-layer functions such as PREOF using DetNet over MPLS, and
this is indicated by the solid line for the MPLS facing portion of
the Service component.  Note that the Transit node is MPLS (TE) LSP
aware and performs switching based on MPLS labels, and need not have
any specific knowledge of the DetNet service or the corresponding
DetNet flow identification.  See ip-over-mpls for details on the
mapping of IP flows to MPLS, and I-D.ietf-detnet-dp-sol-mpls for
general support of DetNet services using MPLS.
L3 (IP) end systems may use any of these connection types.  DetNet
domain MUST allow communication between any end-systems using the
same encapsulation format, independent of their connection type and
DetNet capability.  DN attached end systems have no knowledge about
the DetNet domain and its encapsulation format.  See fig_es_con_types
for L3 end system connection scenarios.
L3 (IP) end systems may use any of these connection types.  DetNet
domain allows communication between any end-systems using the same
encapsulation format, independent of their connection type and DetNet
capability.  DN attached end systems have no knowledge about the
DetNet domain and its encapsulation format.  See fig_es_con_types for
L3 end system connection scenarios.
The DetNet Service Flow MUST be mapped to the link / sub-network
specific resources using an underlying system specific means.  This
implies each DetNet aware node on path MUST look into the forwarded
DetNet Service Flow packet and utilize e.g., a 5- (or 6-) tuple to
find out the required mapping within a node.
The DetNet Service Flow is mapped to the link / sub-network specific
resources using an underlying system specific means.  This implies
each DetNet aware node on path looks into the forwarded DetNet
Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out
the required mapping within a node.
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mapping is sub-network technology specific.
The mapping of IP DetNet Flows to MPLS is covered I-D.ietf-detnet-dp-
sol-mpls.  The mapping of IP DetNet Flows to IEEE 802.1 TSN is
covered in mapping-tsn.
DetNet routers ensure that detnet service requirements are met per
hop by allocating local resources, both receive and transmit, and by
mapping the service requirements of each flow to appropriate sub-
network mechanisms.  Such mapping is sub-network technology specific.
The mapping of IP DetNet Flows to MPLS is covered ip-over-mpls.  The
mapping of IP DetNet Flows to IEEE 802.1 TSN is covered in mapping-
tsn.
aggregation and agg-con discuss the use of flow aggregation in
DetNet.  Flow aggregation can be accomplished using any of the
6-tuple fields defined in ip-flow-id, using a DSCP identified traffic
class or other field.  It will be the responsibility of the DetNet
controller plane to be able to properly provision the use of these
aggregation mechanisms.  These requirements are included in control-
management-requirements.
aggregation and ip-agg discuss the use of flow aggregation in DetNet.
Flow aggregation can be accomplished using any of the 6-tuple fields
defined in ip-flow-id, using a DSCP identified traffic class or other
field.  It will be the responsibility of the DetNet controller plane
to be able to properly provision the use of these aggregation
mechanisms.  These requirements are included in control-management-
requirements.
Note: using IP multicast destination address is also allowed.
Note: any IP address value is allowed, including IP multicast
destination address.
This information MUST be provisioned per DetNet flow via
configuration and the controller plane, see m-cp-considerations.
The use of multiple paths or links, e.g., ECMP, to support a single
DetNet flow will generally be avoided in order to meet DetNet service
requirements.
The use of multiple paths or links, e.g., ECMP, to support a single
DetNet flow is NOT RECOMMENDED.  ECMP MAY be used for non-DetNet
flows within a DetNet domain.
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
management and control functions, e.g., via [YANG-REF-TBD].  General
information on DetNet service can be found in I-D.ietf-detnet-flow-
information-model.  Typical mechanisms used to provide different
treatment to different flows includes the allocation of system
resources (such as queues and buffers) and provisioning or related
parameters (such as shaping, and policing).  Support can also be
provided via an underlying network technology such as MPLS I-D.ietf-
detnet-dp-sol-mpls and IEEE802.1 TSN mapping-tsn.  Other than in the
TSN case, the specific mechanisms used by a DetNet node to ensure
DetNet service delivery requirements are met for supported DetNet
flows is outside the scope of this document.
Implementations if this document MUST ensure that a DetNet flow
receives the traffic treatment that is provisioned for it via
configuration or the controller plane, e.g., via [YANG-REF-TBD].
General information on DetNet service can be found in I-D.ietf-
detnet-flow-information-model.  Typical mechanisms used to provide
different treatment to different flows includes the allocation of
system resources (such as queues and buffers) and provisioning or
related parameters (such as shaping, and policing).  Support can also
be provided via an underlying network technology such as MPLS ip-
over-mpls and IEEE802.1 TSN mapping-tsn.  Other than in the TSN case,
the specific mechanisms used by a DetNet node to ensure DetNet
service delivery requirements are met for supported DetNet flows is
outside the scope of this document.
This section defines how IP encapsulated DetNet flows are carried
over a DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-
mpls.  The basic encapsulation approach is to treat a DetNet IP flow
as an app flow from the DetNet MPLS app perspective.  The
corresponding example DetNet Sub-Network format is shown in
fig_dn_ip_mpls_sn_ex.
In the figure, "IP App-Flow" indicates the payload carried by the
DetNet IP data plane.  "IP" and "NProto" indicate the fields
described in ip-hdr and nxt-proto, respectively.  "MPLS App-Flow"
indicates that an individual DetNet IP flow is the payload from the
perspective of the DetNet MPLS data plane defined in I-D.ietf-detnet-
dp-sol-mpls.
Per I-D.ietf-detnet-dp-sol-mpls, the DetNet MPLS data plane uses a
single S-Label to support a single app flow. ip-flow-id states that a
single DetNet flow is identified based on IP, and next level
protocol, header information.  It also defines that aggregation is
supported (ip-agg) through the use of prefixes, wildcards, bimasks,
and port ranges.  Collectively, this results in the fairly straight
forward procedures defined in this section.
As shown in fig_ip_detnet, DetNet relay nodes are responsible for the
mapping of a DetNet flow, at the service sub-layer, from the IP to
MPLS DetNet data planes and back again.  Their related DetNet IP over
DetNet MPLS data plane operation is comprised of two sets of
procedures: the mapping of flow identifiers; and ensuring proper
traffic treatment.
A relay node that sends a DetNet IP flows over a DetNet MPLS network
MUST map a single DetNet IP flow into a single app-flow and MUST
process that app-flow in accordance to the procedures defined in I-
D.ietf-detnet-dp-sol-mpls Section 6.2.  PRF MAY be supported for
DetNet IP flows sent over an DetNet MPLS network.  Aggregation as
defined in ip-agg MAY be used to identify an individual DetNet IP
flow.  The provisioning of the mapping of DetNet IP flows to DetNet
MPLS app flow information MUST be supported via configuration and the
controller plane, see m-cp-considerations.
A relay node MAY be provisioned to handle packets received via the
DetNet MPLS data plane as DetNet IP flows.  A single incoming MPLS
app flow MAY be treated as a single DetNet IP flow, without
examination of IP headers.  Alternatively, packets received via the
DetNet MPLS data plane MAY follow the normal DetNet IP flow
identification procedures defined in ip-flow-id.  An implementation
MUST support the provisioning of handling of received DetNet MPLS
data plane as DetNet IP flows via configuration and the controller
plane, see m-cp-considerations.  Note that such configuration MAY
include support from PEOF on the incoming DetNet MPLS flow.
The traffic treatment required for a particular DetNet IP flow is
provisioned via configuration or the controller plane.  When an
DetNet IP flow is sent over DetNet MPLS a relay node MUST ensure that
the provisioned DetNet IP traffic treatment is provided at the
forwarding sub-layer as described in I-D.ietf-detnet-dp-sol-mpls
Section 6.2.  Note that the PRF function can also be used when
sending over MPLS.
Traffic treatment for DetNet IP flows received over the DetNet MPLS
data plane MUST follow ip-svc.