+++ /dev/null
-Network Working Group D. Lewis
-Internet-Draft Cisco Systems, Inc.
-Intended status: Informational P. Agarwal
-Expires: January 5, 2015 Broadcom
- L. Kreeger
- F. Maino
- P. Quinn
- M. Smith
- N. Yadav
- Cisco Systems, Inc.
- July 4, 2014
-
-
- LISP Generic Protocol Extension
- draft-lewis-lisp-gpe-02.txt
-
-Abstract
-
- This draft describes extending the Locator/ID Separation Protocol
- (LISP) [RFC6830], via changes to the LISP header, with three new
- capabilities: support for multi-protocol encapsulation, operations,
- administration and management (OAM) signaling, and explicit
- versioning.
-
-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 http://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 January 5, 2015.
-
-Copyright Notice
-
- Copyright (c) 2014 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
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 1]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
- (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 4
- 3. Generic Protocol Extension for LISP (LISP-gpe) . . . . . . . . 5
- 3.1. Multi Protocol Support . . . . . . . . . . . . . . . . . . 5
- 3.2. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. Version Bits . . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
- 4.1. LISP-gpe Routers to (legacy) LISP Routers . . . . . . . . 8
- 4.2. (legacy) LISP Routers to LISP-gpe Routers . . . . . . . . 8
- 4.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 8
- 4.4. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 8
- 5. LISP-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 2]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-1. Introduction
-
- LISP [RFC6830] defines an encapsulation format that carries IPv4 or
- IPv6 (henceforth referred to as IP) packets in a LISP header and
- outer UDP/IP transport.
-
- The LISP header does not specify the protocol being encapsulated and
- therefore is currently limited to encapsulating only IP packet
- payloads. Other protocols, most notably VXLAN [VXLAN] (which defines
- a similar header format to LISP), are used to encapsulate L2
- protocols such as Ethernet. LISP [RFC6830] can be extended to
- indicate the inner protocol, enabling the encapsulation of Ethernet,
- IP or any other desired protocol all the while ensuring compatibility
- with existing LISP [RFC6830] deployments.
-
- As LISP is deployed, there's also the need to provide increased
- visibility and diagnostic capabilities within the overlay.
-
- This document describes extending LISP ([RFC6830]) via the following
- changes:
-
- Next Protocol Bit (P bit): A reserved flag bit is allocated, and set
- in the LISP-gpe header to indicate that a next protocol field is
- present.
-
- OAM Flag Bit (O bit): A reserved flag bit is allocated, and set in
- the LISP-gpe header, to indicate that the packet is an OAM packet.
-
- Version: Two reserved bits are allocated, and set in the LISP-gpe
- header, to indicate LISP-gpe protocol version.
-
- Next protocol: An 8 bit next protocol field is present in the LISP-
- gpe header.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 3]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-2. LISP Header Without Protocol Extensions
-
- As described in the introduction, the LISP header has no protocol
- identifier that indicates the type of payload being carried by LISP.
- Because of this, LISP is limited to an IP payload. Furthermore, the
- LISP header has no mechanism to signal OAM packets.
-
- The LISP header contains flags (some defined, some reserved), a
- Nonce/Map-version field and an instance ID/Locator-status-bit field.
- The flags provide flexibility to define how the reserved bits can be
- used to change the definition of the LISP header.
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|flags| Nonce/Map-Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Figure 1: LISP Header
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 4]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-3. Generic Protocol Extension for LISP (LISP-gpe)
-
-3.1. Multi Protocol Support
-
- This draft defines the following changes to the LISP header in order
- to support multi-protocol encapsulation.
-
- P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit
- MUST be set to 1 to indicate the presence of the 8 bit next
- protocol field.
-
- P = 0 indicates that the payload MUST conform to LISP as defined
- in [RFC6830].
-
- Flag bit 5 was chosen as the P bit because this flag bit is
- currently unallocated in LISP [RFC6830].
-
- Next Protocol Field: The lower 8 bits of the first word are used to
- carry a next protocol. This next protocol field contains the
- protocol of the encapsulated payload packet.
-
- LISP [RFC6830] uses the lower 16 bits of the first word for either
- a nonce, an echo-nonce ([RFC6830]) or to support map-versioning
- ([RFC6834]). These are all optional capabilities that are
- indicated by setting the N, E, and the V bit respectively.
-
- To maintain the desired data plane compatibility, when the P bit
- is set, the N, E, and V bits MUST be set to zero.
-
- A new protocol registry will be requested from IANA for the Next
- Protocol field. This draft defines the following Next Protocol
- values:
-
- 0x1 : IPv4
-
- 0x2 : IPv6
-
- 0x3 : Ethernet
-
- 0x4: Network Service Header
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 5]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|P|R|R| Reserved | Next Protocol |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 2: LISP-gpe Next Protocol (P=1)
-
-3.2. OAM Support
-
- Flag bit 7 is defined as the O bit. When the O bit is set to 1, the
- packet is an OAM packet and OAM processing MUST occur. The OAM
- protocol details are out of scope for this document. As with the
- P-bit, bit 7 is currently a reserved flag in [RFC6830].
-
-
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|P|R|O| Reserved | Next Protocol |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 3: LISP-gpe OAM bit (P=1)
-
-3.3. Version Bits
-
- LISP-gpe bits8 and 9 are defined as version bits. The version field
- is used to ensure backward compatibility going forward with future
- LISP-gpe updates.
-
- The initial version for LISP-gpe is 0.
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 6]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|P|R|O|Ver| Reserved | Next Protocol |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 4: LISP-gpe Version bits (P=1)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 7]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-4. Backward Compatibility
-
- Undefined (in RFC6830) flag bits 5 and 7, LISP-gpe P and O bits, were
- selected to ensure compatibility with existing LISP [RFC6830]
- deployments.
-
- Similarly, using P = 0 to indicate that the format of the header and
- payload conforms to [RFC6830] ensures compatibility with existing
- LISP hardware forwarding platforms.
-
-4.1. LISP-gpe Routers to (legacy) LISP Routers
-
- A LISP-gpe router MUST not encapsulate non-IP packet nor OAM packets
- to a LISP router. A method for determining the capabilities of a
- LISP router (gpe or "legacy") is out of the scope of this draft.
-
- When encapsulating IP packets to a LISP router the P bit SHOULD be
- set to 1 and the UDP port MUST be set to 4341. OAM bit MUST be set
- to 0. The Next Protocol field SHOULD be 0x1 (IPv4) or 0x2 (IPv6).
- The (legacy) LISP router will ignore the P bit and the protocol type
- field. The (legacy) LISP router will treat the packet as a LISP
- packet and inspect the first nibble of the payload to determine the
- IP version.
-
- When the P bit is set, the N, E, and V bits MUST be set to zero. The
- receiving (legacy) LISP router will ignore N, E and V bits, when the
- P bit is set.
-
-4.2. (legacy) LISP Routers to LISP-gpe Routers
-
- When a LISP-gpe router receives a packet from a (legacy) LISP router,
- the P bit MUST not be set and the UDP port MUST be 4341. The payload
- MUST be IP, and the LISP-gpe router will inspect the first nibble of
- the payload to determine IP version.
-
-4.3. Type of Service
-
- When a LISP-gpe router performs Ethernet encapsulation, the inner
- 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from
- the encapsulated frame to the Type of Service field in the outer IPv4
- header, or in the case of IPv6 the 'Traffic Class' field.
-
-4.4. VLAN Identifier (VID)
-
- When a LISP-gpe router performs Ethernet encapsulation, the inner
- header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or
- used to determine the LISP Instance ID field.
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 8]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-5. LISP-gpe Examples
-
- This section provides two examples of IP protocols, and one example
- of Ethernet encapsulated LISP-gpe using the generic extension
- described in this document.
-
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv4 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Original IPv4 Packet |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 5: IPv4 and LISP-gpe
-
-
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Original IPv6 Packet |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 6: IPv6 and LISP-gpe
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 9]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |N|L|E|V|I|1|0|0|0| Reserved | NP = Ethernet |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Instance ID/Locator-Status-Bits |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Original Ethernet Frame |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
- Figure 7: Ethernet and LISP-gpe
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 10]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-6. Security Considerations
-
- LISP-gpe security considerations are similar to the LISP security
- considerations documented at length in LISP [RFC6830]. With LISP-
- gpe, issues such as dataplane spoofing, flooding, and traffic
- redirection are dependent on the particular protocol payload
- encapsulated.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 11]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-7. Acknowledgments
-
- A special thank you goes to Dino Farinacci for his guidance and
- detailed review.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 12]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-8. IANA Considerations
-
- IANA is requested to set up a registry of "Next Protocol". These are
- 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in
- this draft. New values are assigned via Standards Action [RFC5226].
-
- +---------------+-------------+---------------+
- | Next Protocol | Description | Reference |
- +---------------+-------------+---------------+
- | 0 | Reserved | This document |
- | | | |
- | 1 | IPv4 | This document |
- | | | |
- | 2 | IPv6 | This document |
- | | | |
- | 3 | Ethernet | This document |
- | | | |
- | 4 | NSH | This document |
- | | | |
- | 5..253 | Unassigned | |
- +---------------+-------------+---------------+
-
- Table 1
-
- There are ten bits at the beginning of the LISP-gpe header. New
- bits are assigned via Standards Action [RFC5226].
-
- Bits 0-3 - Assigned by LISP [RFC6830]
- Bit 4 - Instance ID (I bit)
- Bit 5 - Next Protocol (P bit)
- Bit 6 - Reserved
- Bit 7 - OAM (O bit)
- Bits 8-9 - Version
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 13]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-9. References
-
-9.1. Normative References
-
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- August 1980.
-
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
- May 2008.
-
-9.2. Informative References
-
- [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012,
- <http://www.iana.org/assignments/ieee-802-numbers/
- ieee-802-numbers.xml>.
-
- [IEEE8021Q]
- The IEEE Computer Society, "Media Access Control (MAC)
- Bridges and Virtual Bridge Local Area Networks", August
- 2012, <http://standards.ieee.org/getieee802/download/
- 802.1Q-2011.pdf>.
-
- [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
- October 1994.
-
- [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
- Locator/ID Separation Protocol (LISP)", RFC 6830,
- January 2013.
-
- [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
- Separation Protocol (LISP) Map-Versioning", RFC 6834,
- January 2013.
-
- [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger,
- L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
- Framework for Overlaying Virtualized Layer 2 Networks over
- Layer 3 Networks", 2013.
-
-
-
-
-
-
-
-Lewis, et al. Expires January 5, 2015 [Page 14]
-
-Internet-Draft LISP Generic Protocol Extension July 2014
-
-
-Authors' Addresses
-
- Darrel Lewis
- Cisco Systems, Inc.
-
- Email: darlewis@cisco.com
-
-
- Puneet Agarwal
- Broadcom
-
- Email: pagarwal@broadcom.com
-
-
- Larry Kreeger
- Cisco Systems, Inc.
-
- Email: kreeger@cisco.com
-
-
- Fabio Maino
- Cisco Systems, Inc.
-
- Email: fmaino@cisco.com
-
-
- Paul Quinn
- Cisco Systems, Inc.
-
- Email: paulq@cisco.com
-
-
- Michael Smith
- Cisco Systems, Inc.
-
- Email: michsmit@cisco.com
-
-
- Navindra Yadav
- Cisco Systems, Inc.
-
- Email: nyadav@cisco.com
Code Review / vpp.git / blobdiff