[Detnet] Implementing the discussion at IETF 97 on architecture doc
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 07 March 2017 18:02 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F4129442 for <detnet@ietfa.amsl.com>; Tue, 7 Mar 2017 10:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO5SfPHop6KT for <detnet@ietfa.amsl.com>; Tue, 7 Mar 2017 10:01:58 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC0B12945A for <detnet@ietf.org>; Tue, 7 Mar 2017 10:01:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85430; q=dns/txt; s=iport; t=1488909718; x=1490119318; h=from:to:cc:subject:date:message-id:mime-version; bh=KY9Ls3GKAcL7tdeQ7AktbtsH1VEC9jQbVD6VD/gXT/s=; b=eLVNtzQIHjRZvrPCvfKLARRJbm/8iDprTKmskyZJACAs3sObb9WyB6/z iinVmn16LZZzcyduZIAKe2tvScNceoHTnU71WzhKso3PGkkzqXVK+hguX IN4pZM/PM436B7UgE9cii/99NQPiZ4EQVJkDZtGVCUGaVGVPFsxx17zlp E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CqAwA/9L5Y/51dJa1dGgEBAQECAQEBAQgBAQEBgm5jYYERsleCD4INgkcBg1qCKEEWAQIBAQEBAQEBax0LhTYNBkwSARomAT8XDwEEDg0TiWSyFjqKegEBAQEBAQEDAQEBAQEBAQEBH4ZOjwkfBYkZjF6GOQGKHYgQggSFIooCiEOKdwEmCCmBA1YVhRMdgWOJe4ENAQEB
X-IronPort-AV: E=Sophos;i="5.36,258,1486425600"; d="scan'208,217";a="393806238"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 18:01:57 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v27I1vJF005369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Mar 2017 18:01:57 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Mar 2017 12:01:56 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 7 Mar 2017 12:01:56 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: Implementing the discussion at IETF 97 on architecture doc
Thread-Index: AdKXaaxVJ2Qp+lFeQni37G6Mk1RVbg==
Date: Tue, 07 Mar 2017 18:01:54 +0000
Deferred-Delivery: Tue, 7 Mar 2017 18:01:40 +0000
Message-ID: <772d53cbc39549a889d356f5be511c12@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.3]
Content-Type: multipart/alternative; boundary="_000_772d53cbc39549a889d356f5be511c12XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/jost21FKklFCYmiB9VK3ribk4y0>
Cc: "draft-ietf-detnet-architecture-all@tools.ietf.org" <draft-ietf-detnet-architecture-all@tools.ietf.org>
Subject: [Detnet] Implementing the discussion at IETF 97 on architecture doc
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 18:02:01 -0000
Dear all:
During the detnet meeting at IETF 97 we discussed that some pieces of the service model presented by Balazs and Janos could effectively by added to the architecture, in particular the discussion on service points, models and flow identification.
So we worked together and came up with proposed additions as follows. We would like to publish this by the cutoff date next Monday so if there is an issue with the proposed change please let us discuss it by then.
The proposed additions are as follows:
Adding Janos and Balazs as co-authors, then:
1) adding a section on the reference model:
4.1. DetNet systems . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Network reference model . . . . . . . . . . . . . . . 13
4.1.2. End system . . . . . . . . . . . . . . . . . . . . . 14
2) more on detnet flows:
4.3.1. DetNet flow types . . . . . . . . . . . . . . . . . . 18
And replacing:
4.7. Exporting flow identification . . . . . . . . . . . . . . 20
We now propose:
4.9. Flow identification at technology borders . . . . . . . . 26
4.9.1. Exporting flow identification . . . . . . . . . . . . 26
4.9.2. Flow attribute mapping between layers . . . . . . . . 27
4.9.3. Flow-ID mapping examples . . . . . . . . . . . . . . 29
3) more on
4.5. Service instance . . . . . . . . . . . . . . . . . . . . 21
The changes include this new description of the DetNet Service Reference Model (multi-domain)
DetNet DetNet
end system end system
_ _
/ \ +----DetNet-UNI (U) / \
/App\ | /App\
/-----\ | /-----\
| NIC | v ________ | NIC |
+--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+
| / \__/ \ | |
| / +----+ +----+ \_____ | |
| / | | | | \_______ | |
+--------U PE +----+ P +----+ \ _ v |
| | | | | | | ___/ \ |
| +--+-+ +----+ | +----+ | / \_ |
\ | | | | | / \ |
\ | +----+ +--+-+ +--+PE |---------- U------+
\ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | /
\ +----+__ +----+ DetNet-1 DetNet-2
| \_____/ \___________/ |
| |
| | End-to-End-Service | | | |
<-------------------------------------------------------------------->
| | DetNet-Service | | | |
| <----------------------------------------------------> |
| | | | | |
And text to cover it that provides details on the UNI
The figure above shows the DetNet service related reference points
and main components (Figure 2).
DetNet-UNIs ("U" in Figure 2) are assumed in this document to be
packet-based reference points and provide connectivity over the
packet network. A DetNet-UNI may provide multiple functions, e.g.,
it may add networking technology specific encapsulation to the DetNet
flows if necessary; it may provide status of the availability of the
connection associated to a reservation; it may provide a
synchronization service for the end system; it may carry enough
signaling to place the reservation in a network without a controller,
or if the controller only deals with the network but not the end
points. Internal reference points of end systems (between the
application and the NIC) are more challenging from control
perspective and they may have extra requirements (e.g., in-order
delivery is expected in end system internal reference points, whereas
it is considered optional over the DetNet-UNI), therefore not covered
in this document.
New text also detail what an end system is
The native data flow between the source/destination end systems is
referred to as application-flow (App-flow). The traffic
characteristics of an App-flow can be CBR (constant bit rate) or VBR
(variable bit rate) and can have L1 or L2 or L3 encapsulation (e.g.,
TDM (time-division multiplexing), Ethernet, IP). These
characteristics are considered as input for resource reservation and
might be simplified to ensure determinism during transport (e.g.,
making reservations for the peak rate of VBR traffic, etc.).
An end system may or may not be DetNet transport layer aware or
DetNet service layer aware. That is, an end system may or may not
contain DetNet specific functionality. End systems with DetNet
functionalities may have the same or different transport layer as the
connected DetNet domain. Grouping of end systems are shown in
Figure 3.
End system
|
|
| DetNet aware ?
/ \
+------< >------+
NO | \ / | YES
| v |
DetNet unaware |
End system |
| Service/
| Transport
/ \ aware ?
+--------< >-------------+
t-aware | \ / | s-aware
| v |
| | both |
| | |
DetNet t-aware | DetNet s-aware
End system | End system
v
DetNet st-aware
End system
Figure 3: Grouping of end systems
A new discussion on flow types reads as follows:
4.3.1. DetNet flow types
A DetNet flow can have different formats during while it is
transported between the peer end systems. Therefore, the following
possible types / formats of a DetNet flow are distinguished in this
document:
o App-flow: native format of a DetNet flow. It does not contain any
DetNet related attributes.
o DetNet-t-flow: specific format of a DetNet flow. Only requires
the congestion / latency features provided by the Detnet transport
layer.
o DetNet-s-flow: specific format of a DetNet flow. Only requires
the replication/elimination feature ensured by the DetNet service
layer.
o DetNet-st-flow: specific format of a DetNet flow. It requires
both DetNet Service and Transport layer functions during
forwarding.
Finally we propose to update the flow discussion as follows:
4.9. Flow identification at technology borders
4.9.1. Exporting flow identification
<..>
4.9.2. Flow attribute mapping between layers
Transport of DetNet flows over multiple technology domains may
require that lower layers are aware of specific flows of higher
layers. Such an "exporting of flow identification" is needed each
time when the forwarding paradigm is changed on the transport path
(e.g., two LSRs are interconnected by a L2 bridged domain, etc.).
The three main forwarding methods considered for deterministic
networking are:
o IP routing
o MPLS label switching
o Ethernet bridging
The simplest solution for generalized flow identification could be to
define a unique Flow-ID triplet per DetNet flow (e.g., [IP: "IPv6-
flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet:
"VLAN-ID"+"MAC-address"). This triplet can be used by the DetNet
encoding function of technology border nodes (where forwarding
paradigm changes) to adapt to capabilities of the next hop node. It
means that a packet may contain multiple (forwarding paradigm
specific) Flow-IDs during its transport. Technology border nodes may
add / remove a (forwarding paradigm specific) Flow-ID.
[Note: Seq-num attribute may require a similar functionality at
technology border nodes.]
add/remove add/remove
Eth Flow-ID IP Flow-ID
| |
v v
+-----------------------------------------------------------+
| | | | |
| Eth | MPLS | IP | Application data |
| | | | |
+-----------------------------------------------------------+
^
|
add/remove
MPLS Flow-ID
Figure 7: Packet with multiple Flow-IDs
The additional (domain specific) Flow-ID can be
o created by a domain specific function or
o derived from the Flow-ID added to the App-flow,
so that it must be unique inside the given domain. Note, that the
Flow-ID added to the App-flow is still present in the packet, but
transport nodes may lack the function to recognize it; that's why the
additional Flow-ID is added (pushed).
4.9.3. Flow-ID mapping examples
IP nodes and MPLS nodes are assumed to be configured to push such an
additional (domain specific) Flow-ID when sending traffic to an
Ethernet switch (as shown in the examples below).
Figure 8 shows a scenario where an IP end system ("IP-A") is
connected via two Ethernet switches ("ETH-n") to an IP router ("IP-
1").
IP domain
<-----------------------------------------------
+======+ +======+
|L3-ID | |L3-ID |
+======+ /\ +-----+ +======+
/ \ Forward as | |
/IP-A\ per ETH-ID |IP-1 | Recognize
Push ------> +-+----+ | +---+-+ <----- ETH-ID
ETH-ID | +----+-----+ |
| v v |
| +-----+ +-----+ |
+------+ | | +---------+
+......+ |ETH-1+----+ETH-2| +======+
.L3-ID . +-----+ +-----+ |L3-ID |
+======+ +......+ +======+
|ETH-ID| .L3-ID . |ETH-ID|
+======+ +======+ +------+
|ETH-ID|
+======+
Ethernet domain
<---------------->
Figure 8: IP nodes interconnected by an Ethernet domain
End system "IP-A" uses the original App-flow specific ID ("L3-ID"),
but as it is connected to an Ethernet domain it has to push an
Ethernet-domain specific flow-ID ("VID + multicast MAC address",
referred as "ETH-ID") before sending the packet to "ETH-1" node.
Ethernet switch "ETH-1" can recognize the data flow based on the
"ETH-ID" and it does forwarding toward "ETH-2". "ETH-2" switches the
packet toward the IP router. "IP-1" must be configured to receive
the Ethernet Flow-ID specific multicast stream, but (as it is an L3
node) it decodes the data flow ID based on the "L3-ID" fields of the
received packet.
Figure 9 shows a scenario where MPLS domain nodes ("PE-n" and "P-m")
are connected via two Ethernet switches ("ETH-n").
MPLS domain
<----------------------------------------------->
+=======+ +=======+
|MPLS-ID| |MPLS-ID|
+=======+ +-----+ +-----+ +=======+ +-----+
| | Forward as | | | |
|PE-1 | per ETH-ID | P-2 +-----------+ PE-2|
Push -----> +-+---+ | +---+-+ +-----+
ETH-ID | +-----+----+ | \ Recognize
| v v | +-- ETH-ID
| +-----+ +-----+ |
+---+ | | +----+
+.......+ |ETH-1+----+ETH-2| +=======+
.MPLS-ID. +-----+ +-----+ |MPLS-ID|
+=======+ +=======+
|ETH-ID | +.......+ |ETH-ID |
+=======+ .MPLS-ID. +-------+
+=======+
|ETH-ID |
+=======+
Ethernet domain
<---------------->
Figure 9: MPLS nodes interconnected by an Ethernet domain
"PE-1" uses the MPLS specific ID ("MPLS-ID"), but as it is connected
to an Ethernet domain it has to push an Ethernet-domain specific
flow-ID ("VID + multicast MAC address", referred as "ETH-ID") before
sending the packet to "ETH-1". Ethernet switch "ETH-1" can recognize
the data flow based on the "ETH-ID" and it does forwarding toward
"ETH-2". "ETH-2" switches the packet toward the MPLS node ("P-2").
"P-2" must be configured to receive the Ethernet Flow-ID specific
multicast stream, but (as it is an MPLS node) it decodes the data
flow ID based on the "MPLS-ID" fields of the received packet.
What do you think?
Pascal and Norm
- [Detnet] Implementing the discussion at IETF 97 o… Pascal Thubert (pthubert)
- Re: [Detnet] Implementing the discussion at IETF … Jouni Korhonen
- Re: [Detnet] Implementing the discussion at IETF … Pascal Thubert (pthubert)
- Re: [Detnet] Implementing the discussion at IETF … Lou Berger
- Re: [Detnet] Implementing the discussion at IETF … Pascal Thubert (pthubert)
- Re: [Detnet] Implementing the discussion at IETF … Lou Berger
- Re: [Detnet] Implementing the discussion at IETF … Jouni Korhonen
- Re: [Detnet] Implementing the discussion at IETF … gengxuesong
- Re: [Detnet] Implementing the discussion at IETF … Pascal Thubert (pthubert)