draft-ietf-lisp-gpe-13.txt   draft-ietf-lisp-gpe-14.txt 
Internet Engineering Task Force F. Maino, Ed. Internet Engineering Task Force F. Maino, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Lemon Intended status: Standards Track J. Lemon
Expires: July 9, 2020 Broadcom Expires: July 11, 2020 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
D. Lewis D. Lewis
M. Smith M. Smith
Cisco Cisco
January 6, 2020 January 8, 2020
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-13 draft-ietf-lisp-gpe-14
Abstract Abstract
This document describes extentions to the Locator/ID Separation This document describes extentions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation. support multi-protocol encapsulation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2020. This Internet-Draft will expire on July 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 27 skipping to change at page 4, line 27
This document defines two changes to the LISP header in order to This document defines two changes to the LISP header in order to
support multi-protocol encapsulation: the introduction of the P-bit support multi-protocol encapsulation: the introduction of the P-bit
and the definition of a Next Protocol field. This document specifies and the definition of a Next Protocol field. This document specifies
the protocol behavior when the P-bit is set to 1, no changes are the protocol behavior when the P-bit is set to 1, no changes are
introduced when the P-bit is set to 0. The LISP-GPE header is shown introduced when the P-bit is set to 0. The LISP-GPE header is shown
in Figure 2 and described below. in Figure 2 and described below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| Reserved | Next Protocol | |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LISP-GPE Header Figure 2: LISP-GPE Header
P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
set to 1 to indicate the presence of the 8 bit Next Protocol set to 1 to indicate the presence of the 8 bit Next Protocol
field. field.
If the P-bit is clear (0) the LISP header is bit-by-bit equivalent If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
to the definition in [I-D.ietf-lisp-rfc6830bis]. to the definition in [I-D.ietf-lisp-rfc6830bis].
When the P-bit is set to 1, bits N, E, and V MUST be set zero on When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the
'Nonce/Map-Version/Next Protocol' field MUST be set to zero on
transmission and ignored on receipt. Features equivalent to those transmission and ignored on receipt. Features equivalent to those
that were implemented with bits N,E and V in that were implemented with bits N,E and V in
[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map- [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
versioning, can be implemented by defining appropriate LISP-GPE versioning, can be implemented by defining appropriate LISP-GPE
shim headers. shim headers.
Next Protocol: The lower 8 bits of the first 32-bit word are used to When the P-bit is set to 1, the LISP-GPE header is encoded as:
carry a Next Protocol. This Next Protocol field contains the
protocol of the encapsulated payload packet. 0 x 0 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LISP-GPE with P-bit set to 1
Next Protocol: When the P-bit is set to 1, the lower 8 bits of the
first 32-bit word are used to carry a Next Protocol. This Next
Protocol field contains the protocol of the encapsulated payload
packet.
This document defines the following Next Protocol values: This document defines the following Next Protocol values:
0x01 : IPv4 0x01 : IPv4
0x02 : IPv6 0x02 : IPv6
0x03 : Ethernet 0x03 : Ethernet
0x04 : Network Service Header (NSH) [RFC8300] 0x04 : Network Service Header (NSH) [RFC8300]
0x05 to 0x7F: Unassigned 0x05 to 0x7F: Unassigned
0x80 to 0xFF: Unassigned (shim headers) 0x80 to 0xFF: Unassigned (shim headers)
The values are tracked in the IANA LISP-GPE Next Protocol Registry The values are tracked in the IANA LISP-GPE Next Protocol Registry
as described in Section 6.1. as described in Section 6.1.
Next protocol values from Ox80 to 0xFF are assigned to protocols Next protocol values from Ox80 to 0xFF are assigned to protocols
encoded as generic "shim" headers. All shim protocols MUST use the encoded as generic "shim" headers. All shim protocols MUST use the
header structure in Figure 3, which includes a Next Protocol field. header structure in Figure 4, which includes a Next Protocol field.
When a shim header is used with other protocols identified by next When a shim header is used with other protocols identified by next
protocol values from 0x0 to 0x7F, the shim header MUST come before protocol values from 0x0 to 0x7F, the shim header MUST come before
the further protocol, and the next header of the shim will indicate the further protocol, and the next header of the shim will indicate
which protocol follows the shim header. which protocol follows the shim header.
Shim headers can be used to incrementally deploy new GPE features, Shim headers can be used to incrementally deploy new GPE features,
keeping the processing of shim headers known to a given xTR keeping the processing of shim headers known to a given xTR
implementation in the 'fast' path (typically an ASIC), while punting implementation in the 'fast' path (typically an ASIC), while punting
the processing of the remaining new GPE features to the 'slow' path. the processing of the remaining new GPE features to the 'slow' path.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Next Protocol | | Type | Length | Reserved | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Protocol Specific Fields ~ ~ Protocol Specific Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Shim Header Figure 4: Shim Header
Where: Where:
Type: This field identifies the different messages of this protocol. Type: This field identifies the different messages of this protocol.
Length: The length, in 4-octect units, of this protocol message not Length: The length, in 4-octect units, of this protocol message not
including the first 4 octects. including the first 4 octects.
Reserved: The use of this field is reserved to the protocol defined Reserved: The use of this field is reserved to the protocol defined
in this message. in this message.
skipping to change at page 14, line 20 skipping to change at page 14, line 20
Email: jennifer.lemon@broadcom.com Email: jennifer.lemon@broadcom.com
Puneet Agarwal Puneet Agarwal
Innovium Innovium
USA USA
Email: puneet@acm.org Email: puneet@acm.org
Darrel Lewis Darrel Lewis
Cisco Systems Cisco Systems
San Jose, CA 95134
USA
Email: darlewis@cisco.com Email: darlewis@cisco.com
Michael Smith Michael Smith
Cisco Systems Cisco Systems
San Jose, CA 95134
USA
Email: michsmit@cisco.com Email: michsmit@cisco.com
 End of changes. 12 change blocks. 
12 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/