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

Commentary: import IP over MPLS scenarios from mpls - dp doc , carify non - DetNet IP
The path could be used a distributed control plane such as RFC2205
or RSVP-TE RFC3473 extended to support DetNet IP flows.
This information MUST be provisioned per DetNet flow via
configuration and the controller plane, see m-cp-considerations.
This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller plane described in m-cp-
considerations.
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.
This section defines how IP encapsulated flows are carried over a
DetNet MPLS data plane as defined in I-D.ietf-detnet-dp-sol-mpls.  As
Non-DetNet and DetNet IP packets are identical on the wire, this
section is applicable to any node that supports IP over DetNet MPLS,
and this section refers to both cases as DetNet IP over DetNet MPLS.
This section provides example uses of IP over DetNet MPLS for
illustrative purposes.
fig_dn_ip_mpls_detnet illustrates DetNet enabled End Systems (hosts),
connected to DetNet (DN) enabled IP networks, operating over a DetNet
aware MPLS network.  In this figure, Relay nodes sit at the boundary
of the MPLS domain since the non-MPLS domain is DetNet aware.  This
figure is very similar to the DetNet MPLS Network figure in I-D.ietf-
detnet-dp-sol-mpls.  The primary difference is that the Relay nodes
are at the edges of the MPLS domain and therefore function as T-PEs,
and that service sub-layer functions are not provided over the DetNet
IP network.  The transit node functions show above are identical to
those described in I-D.ietf-detnet-dp-sol-mpls.
fig_ip_pw_detnet illustrates how relay nodes can provide service
protection over an MPLS domain.  In this case, CE1 and CE2 are IP
DetNet end systems which are interconnected via a MPLS domain such as
described in I-D.ietf-detnet-dp-sol-mpls.  Note that R1 and R3 sit at
the edges of an MPLS domain and therefore are similar to T-PEs, while
R2 sits in the middle of the domain and is therefore similar to an
S-PE.
fig_ip_mpls_detnet illustrates non-DetNet enabled End Systems
(hosts), connected to DetNet (DN) enabled MPLS network.  It differs
from fig_dn_ip_mpls_detnet in that the hosts and edge IP networks are
not DetNet aware.  In this case, edge nodes sit at the boundary of
the MPLS domain since it is also a DetNet domain boundary.  The edge
nodes provide DetNet service proxies for the end applications by
initiating and terminating DetNet service for the application's IP
flows.  While the node types differ, there is essentially no
difference in data plane processing between relay and edges.  There
are likely to be differences in controller plane operation,
particularly when distributed control plane protocols are used.
fig_pw_detnet2 illustrates how it is still possible to provided
DetNet service protection for non-DetNet aware end systems.  This
figures is basically the same as fig_ip_pw_detnet, with the exception
that CE1 and CE2 are non-DetNet aware end systems and E1 and E3 are
edge nodes that replace the relay nodes R1 and R3.
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.
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 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, e.g.,
via the controller plane described in 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.
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.  Note that such
configuration MAY include support from PEOF on the incoming DetNet
MPLS flow.