DetNet
Internet Engineering Task Force (IETF) B. Varga, Ed.
Internet-Draft
Request for Comments: 9056 Ericsson
Intended status:
Category: Standards Track L. Berger
Expires: April 14, 2021
ISSN: 2070-1721 D. Fedyk
LabN Consulting, L.L.C.
S. Bryant
Futurewei Technologies
J. Korhonen
October 11, 2020
DetNet 2021
Deterministic Networking (DetNet) Data Plane: IP over MPLS
draft-ietf-detnet-ip-over-mpls-09
Abstract
This document specifies the Deterministic Networking data plane when
encapsulating IP over an MPLS packet switched packet-switched network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2021.
https://www.rfc-editor.org/info/rfc9056.
Copyright Notice
Copyright (c) 2020 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Terms Used In in This Document . . . . . . . . . . . . . . . 2
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4
4. DetNet IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 5
4.1. DetNet IP Over over DetNet MPLS Data Plane Scenarios . . . . . . . . 5
4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6
5. DetNet IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8
5.1. DetNet IP over DetNet MPLS Flow Identification and
Aggregation Procedures . . . . . . . . . . . . . . . 8
5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 9
6. Management and Control Information Summary . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1.
9.1. Normative references . . . . . . . . . . . . . . . . . . 11
11.2. References
9.2. Informative references . . . . . . . . . . . . . . . . . 12 References
Acknowledgements
Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides a capability for the
delivery of data flows with extremely low packet loss rates and
bounded end-to-end delivery latency. General background and concepts
of DetNet can be found in the DetNet Architecture architecture [RFC8655].
This document specifies use of the IP DetNet encapsulation over an
MPLS network. It maps the IP data plane encapsulation described in
[I-D.ietf-detnet-ip]
[RFC8939] to the DetNet MPLS data plane defined in
[I-D.ietf-detnet-mpls]. [RFC8964].
2. Terminology
2.1. Terms Used In in This Document
This document uses the terminology and concepts established in the
DetNet architecture [RFC8655] and
[I-D.ietf-detnet-data-plane-framework], the in [RFC8938]. The reader is
assumed to be familiar with these documents and their terminology.
2.2. Abbreviations
This document uses the abbreviations defined in the DetNet
architecture [RFC8655] and [I-D.ietf-detnet-data-plane-framework]. in [RFC8938]. This document uses the
following abbreviations:
CE Customer Edge equipment. (equipment)
d-CW DetNet Control Word. Word
DetNet Deterministic Networking. Networking
DF DetNet Flow. Flow
DN DetNet. DetNet
L2 Layer-2. Layer 2
LSP Label-switched path. Label-Switched Path
MPLS Multiprotocol Label Switching. Switching
PEF Packet Elimination Function. Function
PRF Packet Replication Function. Function
PREOF Packet Replication, Elimination Elimination, and Ordering Functions. Functions
POF Packet Ordering Function. Function
PW Pseudowire. Pseudowire
S-Label DetNet "service" label. Label
S-PE Switching Provider Edge. Edge
T-PE Terminating Provider Edge. Edge
TE Traffic Engineering. Engineering
TSN Time-Sensitive Networking, Networking; TSN is a Task Group of the
IEEE 802.1 Working Group. Group
2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. DetNet IP Data Plane Overview
Figure 1 illustrates an IP DetNet, DetNet with an MPLS based MPLS-based DetNet network
as a sub-network between the relay nodes. An IP flow is mapped to
one or more PWs and MPLS (TE) LSPs. The end systems still originate
IP encapsulated
IP-encapsulated traffic, identified as DetNet flows. The relay nodes
follow procedures defined in Section 4 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 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 labels; it need not have any
specific knowledge of the DetNet service or the corresponding DetNet
flow identification. See Section 4 for details on the mapping of IP
flows to MPLS, and [I-D.ietf-detnet-mpls] [RFC8964] for general support of DetNet services
using MPLS.
DetNet IP Relay Transit Relay DetNet IP
End System Node Node Node End System
+----------+ +----------+
| Appl. |<------------- End to End Service ---------->| Appl. |
+----------+ .....-----+ +-----..... +----------+
| Service |<--: Service |--DetNet flow ---| Service :-->| Service |
| | : |<-DN MPLS flow ->| : | |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
|<---- DetNet MPLS ---->|
|<--------------------- DetNet IP ------------------>|
Figure 1: Architecture: DetNet IP Over over DetNet MPLS Network
4. DetNet IP over DetNet MPLS
This section defines how IP encapsulated IP-encapsulated flows are carried over a
DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. [RFC8964]. Since both Non-DetNet non-
DetNet and DetNet IP packet 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.
4.1. DetNet IP Over over DetNet MPLS Data Plane Scenarios
An example use of DetNet IP over DetNet MPLS is presented here.
Figure 1 illustrates IP DetNet enabled DetNet-enabled End Systems (hosts) connected
to DetNet (DN) enabled DetNet-enabled IP networks, networks (DN IP), operating over a DetNet aware DetNet-aware
MPLS network. In this Figure figure, we have a case where the Relay relay nodes
act as T-PEs and sit at the boundary of the MPLS domain since the
non-MPLS domain is DetNet aware. This case is very similar to the
DetNet MPLS Network Figure (Figure 2 in [I-D.ietf-detnet-mpls]. [RFC8964]). However, in
[I-D.ietf-detnet-mpls] Figure 2, 2 of
[RFC8964], the T-PEs are located at the end system and MPLS spans the
whole DetNet service. The primary difference in this document is
that the Relay relay nodes are at the edges of the MPLS domain and
therefore function as T-PEs, and that MPLS service sub-layer
functions are not provided over the DetNet IP network. The transit
node functions shown above are identical to those described in [I-D.ietf-detnet-mpls].
[RFC8964].
Figure 2 illustrates how relay nodes can provide service protection
over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end
systems which that are interconnected via a an MPLS domain such as that
described in [I-D.ietf-detnet-mpls]. [RFC8964]. 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.
DetNet DetNet
IP Service Transit Transit Service IP
DetNet |<-Tnl->| |<-Tnl->| DetNet
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+
| |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| |
|CE1| | | \ | | X | | / | | |CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| (T-PE) (S-PE) (T-PE) |
| |
|<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->|
| |
|<-------------- End to End DetNet Service --------------->|
-------------------------- Data Flow ------------------------->
X = Service protection (PRF, PREOF, PEF/POF)
DFx = DetNet member flow x over a TE LSP
Figure 2: Service Protection Over over DetNet MPLS Network for DetNet IP
Figure 1 illustrates DetNet enabled End Systems DetNet-enabled end systems connected to DetNet
(DN) DetNet-
enabled (DN) MPLS network. networks. A similar situation occurs when end
systems 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 relays and
edges. There are likely to be differences in controller plane Controller Plane
operation, particularly when distributed control plane protocols are
used.
It is still possible to provide DetNet service protection for non-
DetNet aware
DetNet-aware end systems. This case is basically the same as
Figure 2, with the exception that CE1 and CE2 are non-DetNet aware non-DetNet-aware
end systems and R1 and R3 become edge nodes.
4.2. DetNet IP over DetNet MPLS Encapsulation
The basic encapsulation approach is to treat a DetNet IP flow as an
app-flow
App-flow from the DetNet MPLS perspective. The corresponding example
DetNet Sub-Network Sub-network format is shown in Figure 3.
/-> +------+ +------+ +------+ ^ ^
| | X | | X | | X |<- App-Flow App-flow : :
| +------+ +------+ +------+ : :
App-Flow
App-flow <-+ |NProto| |NProto| |NProto| : :(1)
for MPLS | +------+ +------+ +------+ : :
| | IP | | IP | | IP | : v
\-> +---+======+--+======+--+======+-----+ :
DetNet-MPLS | d-CW | | d-CW | | d-CW | :
+------+ +------+ +------+ :(2)
|Labels| |Labels| |Labels| v
+---+======+--+======+--+======+-----+
Link/Sub-Network
Link/Sub-network | L2 | | TSN | | UDP |
+------+ +------+ +------+
| IP |
+------+
| L2 |
+------+
(1) DetNet IP Flow (or simply IP flow)
(2) DetNet MPLS Flow
Figure 3: Example DetNet IP over MPLS Sub-Network Sub-network Formats
In Figure 3 "App-Flow" 3, "App-flow" indicates the payload carried by the DetNet
IP data plane. "IP" and "NProto" indicate the fields described in
Section 5.1.1.
Sections 5.1.1 (IP Header Information) and Section 5.1.2. 5.1.2 (Other Protocol
Header Information) of [I-D.ietf-detnet-ip], [RFC8939], respectively.
"App-Flow "App-flow for MPLS"
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-mpls]. [RFC8964].
Per Section 5.1 of [I-D.ietf-detnet-mpls], [RFC8964], the DetNet MPLS data plane uses a
single S-Label to support a single app flow. App-flow. DetNet IP Flow
Identification Procedures in Section 4.4 5.1 of [I-D.ietf-detnet-ip] [RFC8939] states that a
single DetNet flow is identified based on IP, IP- and next
level protocol, next-level protocol
header information. Section 4.4. (Aggregation
Considerations) 4.4 of [I-D.ietf-detnet-ip] [RFC8939] (DetNet Flow
Aggregation) defines the ways in which aggregation is supported
through the use of prefixes, wildcards, lists, and port ranges.
Collectively, this results in the fairly straightforward procedures
defined in the next section.
As shown in Figure 2, 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, identifiers and ensuring proper
traffic treatment.
Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP
flows. The six-tuple of IP is mapped to the S-Label in both cases.
The various fields may be mapped or ignored when going from IP to
MPLS.
5. DetNet IP over DetNet MPLS Procedures
The main differences of mapping IP to DetNet MPLS (compared to plain
MPLS) are that (1) there is a mandatory flow identification to make
the forwarding decision (i.e., forwarding is not based on FEC), (2)
the d-CW (DetNet Control Word) is mandatory for the MPLS
encapsulation
encapsulation, and (3) during forwarding over the DetNet MPLS network
DetNet flow specific
network, treatment specific to DetNet flows is needed.
5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation
Procedures
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
DetNet MPLS network MUST map a DetNet IP flow, as identified in
[I-D.ietf-detnet-ip]
[RFC8939], into a single MPLS DetNet flow and MUST process it in
accordance to the procedures defined in [I-D.ietf-detnet-mpls]. [RFC8964]. PRF MAY be
supported at the MPLS level for DetNet IP flows sent over
an a DetNet
MPLS network. Aggregation MAY be supported as defined in
[I-D.ietf-detnet-mpls] Section 4.4. 4.4
of [RFC8964]. Aggregation considerations in
[I-D.ietf-detnet-ip] [RFC8939] MAY be used to
identify an individual DetNet IP flow. The provisioning of the
mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via
configuration, e.g., via the
controller plane. Controller Plane.
A DetNet relay node (egress T-PE) MAY be provisioned to handle
packets received via the DetNet MPLS data plane as DetNet IP flows.
A single incoming DetNet MPLS 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 [I-D.ietf-detnet-ip] Section 5.1. 5.1 of
[RFC8939].
An implementation MUST support the provisioning for handling any
packet flows received via the DetNet MPLS data plane as DetNet IP
flows via configuration. Note that such configuration MAY include
support from PREOF on the incoming DetNet MPLS flow.
| Note: using Layer-4 Using Layer 4 (L4) transport protocols e.g., (e.g., for multipath
| multipath) are out of scope of this document both for a single
| flow and aggregate flows.
5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures
The traffic treatment required for a particular DetNet IP flow is
provisioned via configuration or the controller plane. Controller Plane. When a DetNet
IP flow is sent over DetNet MPLS, a DetNet 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-mpls] Section 5.2. 5.2 of [RFC8964]. Note
that the PRF function MAY be utilized when sending IP over MPLS.
Traffic treatment for DetNet IP flows received over the DetNet MPLS
data plane MUST follow Section 5.3 DetNet of [RFC8939] (DetNet IP Traffic
Treatment
Procedures in [I-D.ietf-detnet-ip]. Procedures).
6. Management and Control Information Summary
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS ingress node:
o
* Each MPLS App-Flow is identified selected from the incoming IP traffic using
the IP flow identification information as defined in [I-D.ietf-detnet-ip]. The [RFC8939]. This
information is summarized in Section 5.1 of that document, document and
includes all wildcards, port ranges ranges, and the ability to ignore
specific IP fields.
o
* The DetNet MPLS service that is to be used to send the matching IP
traffic. This matching information is provided in
[I-D.ietf-detnet-mpls] Section 5.1, 5.1 of
[RFC8964] and includes both service and traffic delivery
information.
The following summarizes the set of information that is needed to
support DetNet IP over DetNet MPLS at the MPLS egress node:
o
* The S-Label values value that are carrying MPLS over IP identifies the encapsulated App-flow
traffic.
o
* For each S-Label, how the received traffic is to be handled. The
traffic may be processed according as any other DetNet IP traffic as defined
in this document or in [I-D.ietf-detnet-ip], [RFC8939], or the traffic may be directly
treated as an MPLS App-flow for additional processing according to [I-D.ietf-detnet-mpls].
[RFC8964].
It is the responsibility of the DetNet controller plane Controller Plane to properly
provision both flow identification information and the flow-specific
resources needed to provide the traffic treatment to meet each flow's
service requirements. This applies for aggregated and individual
flows.
7. Security Considerations
General security considerations for DetNet are described in detail in
[I-D.ietf-detnet-security].
[RFC9055]. DetNet MPLS and DetNet IP security considerations equally
apply to this document and are described in
[I-D.ietf-detnet-mpls] [RFC8964] and [I-D.ietf-detnet-ip]. [RFC8939].
Security aspects which that are unique to DetNet are those whose aim is to
protect the support of specific quality of service quality-of-service aspects of DetNet,
which are primarily to deliver data flows with extremely low packet
loss rates and bounded end-to-end delivery latency.
The primary considerations for the data plane are to maintain
integrity of data and delivery of the associated DetNet service
traversing the DetNet network. Application flows can be protected
through whatever means is provided by the underlying technology. For
example, encryption may be used, such as that provided by IPSec IPsec
[RFC4301] for IP flows and/or by an underlying sub-net using MACSec MACsec
[IEEE802.1AE-2018] for IP over Ethernet (Layer-2) IP-over-Ethernet (Layer 2) flows.
From a data plane perspective perspective, this document does not add or modify
any header information.
At the management and control level level, DetNet flows are identified on a
per-flow basis, which may provide controller plane Controller Plane attackers with
additional information about the data flows (when compared to
controller planes
Controller Planes that do not include per-flow identification). This
is an inherent property of DetNet DetNet, which has security implications
that should be considered when determining if DetNet is a suitable
technology for any given use case.
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS DoS attacks and delay attacks. To
protect against DOS DoS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example example,
through the use of existing mechanism mechanisms such as policing and shaping
applied at the input of a DetNet domain. To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definition definitions can allow for the mitigation of Man-In-The-
Middle attacks, for example man-in-the-
middle attacks (for example, through use of authentication and
authorization of devices within the DetNet domain. domain).
8. IANA Considerations
This document makes has no IANA requests.
11. actions.
9. References
11.1.
9.1. Normative references
[I-D.ietf-detnet-data-plane-framework]
Varga, B., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
data-plane-framework-06 (work in progress), May 2020.
[I-D.ietf-detnet-ip]
Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07
(work in progress), July 2020.
[I-D.ietf-detnet-mpls]
Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
detnet-mpls-12 (work in progress), September 2020.
[I-D.ietf-detnet-security]
Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-12 (work in progress), October 2020. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
11.2.
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane
Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
<https://www.rfc-editor.org/info/rfc8938>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/info/rfc8939>.
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
S., and J. Korhonen, "Deterministic Networking (DetNet)
Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
2021, <https://www.rfc-editor.org/info/rfc8964>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>.
9.2. Informative references References
[IEEE802.1AE-2018]
IEEE Standards Association,
IEEE, "IEEE Std 802.1AE-2018 MAC
Security (MACsec)", Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE
802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
9.
Acknowledgements
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, Andersson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
Mozes, Craig Gunther, George Swallow, Yuanlong Jiang Jiang, and Carlos
J. Bernardos for their various contributions to this work.
10.
Contributors
RFC7322
RFC 7322 limits the number of authors listed on the front page of a
draft to a
maximum of 5. The editor wishes to thank and acknowledge the follow
following authors for contributing text to this draft.
Janos document.
János Farkas
Ericsson
Email: janos.farkas@ericsson.com
Andrew G. Malis
Malis Consulting
Email: agmalis@gmail.com
Janos
János Farkas contributed substantially to the content of this
document.
Authors' Addresses
Balazs
Balázs Varga (editor)
Ericsson
Budapest
Magyar Tudosok krt. 11.
Budapest
1117
Hungary
Email: balazs.a.varga@ericsson.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Don Fedyk
LabN Consulting, L.L.C.
Email: dfedyk@labn.net
Stewart Bryant
Futurewei Technologies
Email: stewart.bryant@gmail.com sb@stewartbryant.com
Jouni Korhonen
Email: jouni.nospam@gmail.com