Internet DRAFT - draft-dong-mpls-mna-encaps
draft-dong-mpls-mna-encaps
MPLS Working Group J. Dong
Internet-Draft T. Zhou
Intended status: Standards Track Huawei Technologies
Expires: 25 January 2023 24 July 2022
Encapsulation of MPLS Network Actions and associated Data
draft-dong-mpls-mna-encaps-00
Abstract
This document specifies a solution for carrying MPLS network actions
and the associated data either in the MPLS label stack or after the
MPLS label stack.
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 of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents 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 25 January 2023.
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Dong & Zhou Expires 25 January 2023 [Page 1]
Internet-Draft MNA Solution July 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 3
3. MNA Indicator . . . . . . . . . . . . . . . . . . . . . . . . 3
4. In-stack Network Actions without Data . . . . . . . . . . . . 4
5. In-stack Network Actions Identifier . . . . . . . . . . . . . 5
6. Post-stack Network Actions with Data . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The use cases and requirements to carry additional network
instructions and the associated data in data packets in MPLS
networks, i.e., MPLS Network Actions (MNA), are described in
[I-D.ietf-mpls-mna-usecases] and [I-D.ietf-mpls-mna-requirements]
respectively. [I-D.andersson-mpls-mna-fwk] introduces a framework of
MNA, in which the In-stack Data (ISD) and Post-Stack Data (PSD) are
considered as two possible mechanisms to carry the MPLS network
actions and the optional data associated with the actions.
This document specifies a general solution for carrying MPLS network
actions and the optional data associated with the network actions
either in the MPLS label stack or after the MPLS label stack. The
specification of specific type of network action and the associated
data is out of the scope of this document.
1.1. 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.
Dong & Zhou Expires 25 January 2023 [Page 2]
Internet-Draft MNA Solution July 2022
2. Design Principles
The MPLS architecture as specified in [RFC3031] provides a mechanism
for forwarding packets through a network without requiring any
analysis of the packet payload's network layer header by intermediate
nodes (Label Switching Routers - LSRs). The encoding of MPLS label
stack is specified in [RFC3032].
Section 3.1 of [I-D.ietf-mpls-mna-requirements] provides the general
requirements on the MNA solution. Specifically, it is required that
any solution must maintain the properties of MPLS: extensibility,
flexibility and efficiency by using control plane context combined
with a simple data plane mechanism to allow the network to make
forwarding decisions about a packet.
The proposed solution in this document aims to meet the requirements
in [I-D.ietf-mpls-mna-requirements] with the following design
principles:
* Minimize the length of MNA information carried as ISD in the MPLS
label stack. When ISD is needed, an ISD design with fixed length
is RECOMMENDED.
* Carry the MNA information with large and/or variable length and
possibly flexible structure as PSD in the post-stack extension
headers as defined in [I-D.song-mpls-extension-header].
3. MNA Indicator
The MNA Indicator is introduced to indicate the presence of any MNA
information in the packet. It can be used to indicate the existence
of MNA actions and the optional associated data in the ISD, or the
PSD or both. Since this indicator is generic for all types of MPLS
network actions, it is reasonable to allocate a basic Special Purpose
MPLS label (bSPL) for it. The TC and TTL fields of the MNA Indicator
are redefined as flags.
The format of the MNA Indicator is shown as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Indicator=SPL (TBA) |H|I|P|S|ISF| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The format of MNA Indicator
Where:
Dong & Zhou Expires 25 January 2023 [Page 3]
Internet-Draft MNA Solution July 2022
* MNA Indicator label: A new bSPL, the value is TBA by IANA.
* H (Hop-by-Hop processing) flag: When set, it indicates that the
MNA information in the packet needs to be processed hop-by-hop.
* I (In-stack MNA information) flag: When set, it indicates the next
label entry is used to carry the MNA information.
* P (Post-stack MNA information) flag: When set, it indicates there
is post-stack data following the MPLS label stack.
* S: Bottom of Stack. The value of the S bit depends on the
position of the MNA indicator in the label stack.
* ISF (In-stack data Format): The first 2-bit of the original TTL
field. When the I bit is set, the ISF field is used to indicate
the format of the in-stack MNA information in the following label
stack.The following ISF values are defined in this document.
- ISF = 00: There is no in-stack MNA information. When the I
flag is 0, the value of the ISF field MUST be set to 0 on
transmit and MUST be ignored on receipt.
- ISF = 01: The following label stack entry is used to carry a
list of network actions without any associated data.
- ISF = 10: The following label stack entry is used to carry a
domain significant label value which could be used by the
network nodes to determine the set of network actions based on
local policy.
- ISF = 11: Reserved. It could be used to indicate other format
of the in-stack MNA information.
* RSV: The rest 6 bits in the original TTL field are reserved for
future use. They MUST be set to 0 on transmit and MUST be ignored
on receipt.
4. In-stack Network Actions without Data
When the I flag in the MNA Indicator is set, and the ISF field is set
to 01, the MPLS label stack entry which follows the MNA indicator is
encoded as a list of flags of network actions which do not require
any associated action data to be carried in the packet.
The format of the In-stack network actions without data is shown as
below:
Dong & Zhou Expires 25 January 2023 [Page 4]
Internet-Draft MNA Solution July 2022
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-stack action flags w/o data | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The format of In-stack action flags without Data
Where:
* Label field: The 20-bit label field is used to encode the in-stack
network actions which do not require any associated data.
* TC field: The value of the TC field SHOULD be set to zero. It be
may be redefined for future use.
* TTL field: The value of TTL field SHOULD be set to 0. This is to
ensure that it is not used inadvertently for forwarding. It may
be redefined for future use.
5. In-stack Network Actions Identifier
When the I flag in the MNA Indicator is set, and the ISF field is set
to 10, the MPLS label stack entry which follows the MNA indicator is
encoded as a domain significant label value which could be used by
the network nodes to determine the set of network actions to be
performed based on local policy. This label serves as an implicit
identifier of the in-stack network actions. The encoding and
functionality is the same as the Reference Forwarding Value (RFV) as
defined in[I-D.raszuk-mpls-raf-fwk].
The format of in-stack network actions identifier is shown as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RFV | TC |S| TTL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. The format of In-stack Network Actions Identifier
Where:
* RFV (Referenced Forwarding Value), this is defined in
[I-D.raszuk-mpls-raf-fwk].
* TC: The value of the TC field SHOULD be set to zero. It be may be
redefined for future use.
* S: Bottom of Stack.
Dong & Zhou Expires 25 January 2023 [Page 5]
Internet-Draft MNA Solution July 2022
* TTL: The value of the TTL field SHOULD be set to 0. It may be
redefined for future use.
6. Post-stack Network Actions with Data
When the P flag in the MNA Indicator is set, it indicates there is
post-stack data (PSD) carried after the MPLS label stack. The
encoding of post-stack network actions and the optional associated
data is based on the MPLS post-stack extension headers as defined in
[I-D.song-mpls-extension-header].
7. IANA Considerations
IANA is requested to allocate a new value for the MNA Indicator label
from the "Base Special-Purpose MPLS Label Values" registry.
IANA is requested to create a new registry for the bit positions of
the In-stack network action flags without data.
8. Security Considerations
TBD
9. Acknowledgements
The authors would like to thank XXX for the review and discussion.
10. References
10.1. Normative 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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", DOI 10.17487/RFC3031,
RFC 3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", DOI 10.17487/RFC3032, RFC 3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
Dong & Zhou Expires 25 January 2023 [Page 6]
Internet-Draft MNA Solution July 2022
[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>.
10.2. Informative References
[I-D.andersson-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions Framework", Work in Progress, Internet-
Draft, draft-andersson-mpls-mna-fwk-04, 27 June 2022,
<https://www.ietf.org/archive/id/draft-andersson-mpls-mna-
fwk-04.txt>.
[I-D.ietf-mpls-mna-requirements]
Bocci, M., Bryant, S., and J. Drake, "Requirements for
MPLS Network Action Indicators and MPLS Ancillary Data",
Work in Progress, Internet-Draft, draft-ietf-mpls-mna-
requirements-01, 21 June 2022,
<https://www.ietf.org/archive/id/draft-ietf-mpls-mna-
requirements-01.txt>.
[I-D.ietf-mpls-mna-usecases]
Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use
Cases for MPLS Network Action Indicators and MPLS
Ancillary Data", Work in Progress, Internet-Draft, draft-
ietf-mpls-mna-usecases-00, 19 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-mpls-mna-
usecases-00.txt>.
[I-D.raszuk-mpls-raf-fwk]
Raszuk, R., "Framework of MPLS Reference Augmented
Forwarding", Work in Progress, Internet-Draft, draft-
raszuk-mpls-raf-fwk-00, 25 April 2022,
<https://www.ietf.org/archive/id/draft-raszuk-mpls-raf-
fwk-00.txt>.
[I-D.song-mpls-extension-header]
Song, H., Li, Z., Zhou, T., Andersson, L., Zhang, Z.,
Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "MPLS
Post-Stack Extension Header", Work in Progress, Internet-
Draft, draft-song-mpls-extension-header-07, July 2022,
<https://www.ietf.org/archive/id/draft-song-mpls-
extension-header-07.txt>.
Authors' Addresses
Dong & Zhou Expires 25 January 2023 [Page 7]
Internet-Draft MNA Solution July 2022
Jie Dong
Huawei Technologies
Beijing
China
Email: jie.dong@huawei.com
Tianran Zhou
Huawei Technologies
Beijing
China
Email: zhoutianran@huawei.com
Dong & Zhou Expires 25 January 2023 [Page 8]
