| < draft-mahalingam-dutt-dcops-vxlan-08.txt | draft-mahalingam-dutt-dcops-vxlan-09.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force M. Mahalingam | Internet Engineering Task Force M. Mahalingam | |||
| Internet Draft Storvisor | Internet Draft Storvisor | |||
| Intended Status: Experimental D. Dutt | Intended Status: Informational D. Dutt | |||
| Expires: August 3, 2014 Cumulus Networks | Expires: October 10, 2014 Cumulus Networks | |||
| K. Duda | K. Duda | |||
| Arista | Arista | |||
| P. Agarwal | P. Agarwal | |||
| Broadcom | Broadcom | |||
| L. Kreeger | L. Kreeger | |||
| Cisco | Cisco | |||
| T. Sridhar | T. Sridhar | |||
| VMware | VMware | |||
| M. Bursell | M. Bursell | |||
| Citrix | Citrix | |||
| C. Wright | C. Wright | |||
| Red Hat | Red Hat | |||
| February 3, 2014 | April 10, 2014 | |||
| VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over | VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over | |||
| Layer 3 Networks | Layer 3 Networks | |||
| draft-mahalingam-dutt-dcops-vxlan-08.txt | draft-mahalingam-dutt-dcops-vxlan-09.txt | |||
| 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 | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
| at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
| reference material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| This Internet-Draft will expire on November 8, 2013. | This Internet-Draft will expire on October 10, 2014. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2014 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
| carefully, as they describe your rights and restrictions with | carefully, as they describe your rights and restrictions with | |||
| respect to this document. | respect to this document. | |||
| Abstract | Abstract | |||
| This document describes Virtual eXtensible Local Area Network | This document describes Virtual eXtensible Local Area Network | |||
| (VXLAN), which is used to address the need for overlay networks | (VXLAN), which is used to address the need for overlay networks | |||
| within virtualized data centers accommodating multiple tenants. The | within virtualized data centers accommodating multiple tenants. The | |||
| scheme and the related protocols can be used in cloud service | scheme and the related protocols can be used in cloud service | |||
| provider and enterprise data center networks. This memo documents the | provider and enterprise data center networks. This memo documents the | |||
| deployed VXLAN protocol for the benefit of the IETF community. The | deployed VXLAN protocol for the benefit of the IETF community. | |||
| IETF consensus on this RFC represents consensus to publish this memo, | ||||
| and not consensus on the text itself. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction...................................................3 | 1. Introduction...................................................3 | |||
| 1.1. Acronyms & Definitions....................................4 | 1.1. Acronyms & Definitions....................................4 | |||
| 2. Conventions used in this document..............................5 | 2. Conventions used in this document..............................5 | |||
| 3. VXLAN Problem Statement........................................5 | 3. VXLAN Problem Statement........................................5 | |||
| 3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5 | 3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5 | |||
| 3.2. Multitenant Environments..................................6 | 3.2. Multitenant Environments..................................6 | |||
| 3.3. Inadequate Table Sizes at ToR Switch......................7 | 3.3. Inadequate Table Sizes at ToR Switch......................6 | |||
| 4. Virtual eXtensible Local Area Network (VXLAN)..................7 | 4. Virtual eXtensible Local Area Network (VXLAN)..................7 | |||
| 4.1. Unicast VM to VM communication............................8 | 4.1. Unicast VM to VM communication............................8 | |||
| 4.2. Broadcast Communication and Mapping to Multicast..........9 | 4.2. Broadcast Communication and Mapping to Multicast..........9 | |||
| 4.3. Physical Infrastructure Requirements.....................10 | 4.3. Physical Infrastructure Requirements.....................10 | |||
| 5. VXLAN Frame Format............................................11 | 5. VXLAN Frame Format............................................10 | |||
| 6. VXLAN Deployment Scenarios....................................16 | 6. VXLAN Deployment Scenarios....................................16 | |||
| 6.1. Inner VLAN Tag Handling..................................19 | 6.1. Inner VLAN Tag Handling..................................19 | |||
| 7. Security Considerations.......................................19 | 7. Security Considerations.......................................19 | |||
| 8. IANA Considerations...........................................21 | 8. IANA Considerations...........................................21 | |||
| 9. References....................................................21 | 9. References....................................................21 | |||
| 9.1. Normative References.....................................21 | 9.1. Normative References.....................................21 | |||
| 9.2. Informative References...................................21 | 9.2. Informative References...................................21 | |||
| 10. Acknowledgments..............................................22 | 10. Acknowledgments..............................................22 | |||
| 1. Introduction | 1. Introduction | |||
| Server virtualization has placed increased demands on the physical | Server virtualization has placed increased demands on the physical | |||
| network infrastructure. A physical server now has multiple virtual | network infrastructure. A physical server now has multiple virtual | |||
| machines (VMs) each with its own MAC address. This requires larger | machines (VMs) each with its own MAC address. This requires larger | |||
| MAC address tables in the switched Ethernet network due to potential | MAC address tables in the switched Ethernet network due to potential | |||
| attachment of and communication among hundreds of thousands of VMs. | attachment of and communication among hundreds of thousands of VMs. | |||
| In the case when the VMs in a data center are grouped according to | In the case when the VMs in a data center are grouped according to | |||
| their Virtual LAN (VLAN, one might need thousands of VLANs to | their Virtual LAN (VLAN, one might need thousands of VLANs to | |||
| partition the traffic according to the specific group that the VM | partition the traffic according to the specific group that the VM | |||
| may belong to. The current VLAN limit of 4094 is inadequate in such | may belong to. The current VLAN limit of 4094 is inadequate in such | |||
| situations. | situations. | |||
| Another type of demand that is being placed on data centers is the | Data centers are often required to host multiple tenants, each with | |||
| need to host multiple tenants, each with their own isolated network | their own isolated network domain. Since it is not economical to | |||
| domain. This is not economical to realize with dedicated | realize this with dedicated infrastructure, network administrators | |||
| infrastructure, so network administrators opt to implement this over | opt to implement isolation over a shared network. In such scenarios, | |||
| a shared network. A common problem is that each tenant may | a common problem is that each tenant may independently assign MAC | |||
| independently assign MAC addresses and VLAN IDs leading to potential | addresses and VLAN IDs leading to potential duplication of these on | |||
| duplication of these on the physical network. | the physical network. | |||
| Another requirement for virtualized environments using a Layer 2 | An important requirement for virtualized environments using a Layer | |||
| physical infrastructure is having the Layer 2 network scale across | 2 physical infrastructure is having the Layer 2 network scale across | |||
| the entire data center or even between data centers for efficient | the entire data center or even between data centers for efficient | |||
| allocation of compute, network and storage resources. In such | allocation of compute, network and storage resources. In such | |||
| networks, using traditional approaches like the Spanning Tree | networks, using traditional approaches like the Spanning Tree | |||
| Protocol (STP) for a loop free topology can result in a large number | Protocol (STP) for a loop free topology can result in a large number | |||
| of disabled links. | of disabled links. | |||
| The last scenario is the case where the network operator prefers to | The last scenario is the case where the network operator prefers to | |||
| use IP for interconnection of the physical infrastructure (e.g. to | use IP for interconnection of the physical infrastructure (e.g. to | |||
| achieve multipath scalability through Equal Cost Multipath (ECMP), | achieve multipath scalability through Equal Cost Multipath (ECMP), | |||
| thus avoiding disabled links). Even in such environments, there is a | thus avoiding disabled links). Even in such environments, there is a | |||
| need to preserve the Layer 2 model for inter-VM communication. | need to preserve the Layer 2 model for inter-VM communication. | |||
| The scenarios described above lead to a requirement for an overlay | The scenarios described above lead to a requirement for an overlay | |||
| network. This overlay is used to carry the MAC traffic from the | network. This overlay is used to carry the MAC traffic from the | |||
| individual VMs in an encapsulated format over a logical "tunnel". | individual VMs in an encapsulated format over a logical "tunnel". | |||
| This document details a framework termed Virtual eXtensible Local | This document details a framework termed Virtual eXtensible Local | |||
| Area Network (VXLAN) which provides such an encapsulation scheme to | Area Network (VXLAN) which provides such an encapsulation scheme to | |||
| address the various requirements specified above. This memo | address the various requirements specified above. This memo | |||
| documents the deployed VXLAN protocol for the benefit of the IETF | documents the deployed VXLAN protocol for the benefit of the IETF | |||
| community. The IETF consensus on this RFC represents consensus to | community. | |||
| publish this memo, and not consensus on the text itself. | ||||
| 1.1. Acronyms & Definitions | 1.1. Acronyms & Definitions | |||
| ACL - Access Control List | ACL - Access Control List | |||
| ECMP - Equal Cost Multipath | ECMP - Equal Cost Multipath | |||
| IGMP - Internet Group Management Protocol | IGMP - Internet Group Management Protocol | |||
| MTU - Maximum Transmission Unit | MTU - Maximum Transmission Unit | |||
| skipping to change at page 4, line 42 ¶ | skipping to change at page 4, line 37 ¶ | |||
| ToR - Top of Rack | ToR - Top of Rack | |||
| TRILL - Transparent Interconnection of Lots of Links | TRILL - Transparent Interconnection of Lots of Links | |||
| VXLAN - Virtual eXtensible Local Area Network | VXLAN - Virtual eXtensible Local Area Network | |||
| VXLAN Segment - VXLAN Layer 2 overlay network over which VMs | VXLAN Segment - VXLAN Layer 2 overlay network over which VMs | |||
| communicate | communicate | |||
| VXLAN Overlay Network - another term for VXLAN Segment | VXLAN Overlay Network - VXLAN Segment | |||
| VXLAN Gateway - an entity which forwards traffic between VXLAN | VXLAN Gateway - an entity which forwards traffic between VXLAN | |||
| and non-VXLAN environments | and non-VXLAN environments | |||
| VTEP - VXLAN Tunnel End Point - an entity which originates | VTEP - VXLAN Tunnel End Point - an entity which originates | |||
| and/or terminates VXLAN tunnels | and/or terminates VXLAN tunnels | |||
| VLAN - Virtual Local Area Network | VLAN - Virtual Local Area Network | |||
| VM - Virtual Machine | VM - Virtual Machine | |||
| VNI - VXLAN Network Identifier (or VXLAN Segment ID) | VNI - VXLAN Network Identifier (or VXLAN Segment ID) | |||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC-2119 [RFC2119]. | document are to be interpreted as described in RFC-2119 [RFC2119]. | |||
| skipping to change at page 5, line 43 ¶ | skipping to change at page 5, line 37 ¶ | |||
| more ports and links than they can really use. In addition, | more ports and links than they can really use. In addition, | |||
| resiliency due to multipathing is not available with the STP model. | resiliency due to multipathing is not available with the STP model. | |||
| Newer initiatives such as TRILL [RFC6325] and SPB[802.1aq]) have | Newer initiatives such as TRILL [RFC6325] and SPB[802.1aq]) have | |||
| been proposed to help with multipathing and thus surmount some of | been proposed to help with multipathing and thus surmount some of | |||
| the problems with STP. STP limitations may also be avoided by | the problems with STP. STP limitations may also be avoided by | |||
| configuring servers within a rack to be on the same Layer 3 network | configuring servers within a rack to be on the same Layer 3 network | |||
| with switching happening at Layer 3 both within the rack and between | with switching happening at Layer 3 both within the rack and between | |||
| racks. However, this is incompatible with a Layer 2 model for inter- | racks. However, this is incompatible with a Layer 2 model for inter- | |||
| VM communication. | VM communication. | |||
| Another characteristic of Layer 2 data center networks is their use | A key characteristic of Layer 2 data center networks is their use of | |||
| of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit | Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit VLAN | |||
| VLAN ID is used in the Ethernet data frames to divide the larger | ID is used in the Ethernet data frames to divide the larger Layer 2 | |||
| Layer 2 network into multiple broadcast domains. This has served | network into multiple broadcast domains. This has served well for | |||
| well for several data centers which require fewer than 4094 VLANs. | several data centers which require fewer than 4094 VLANs. With the | |||
| With the growing adoption of virtualization, this upper limit is | growing adoption of virtualization, this upper limit is seeing | |||
| seeing pressure. Moreover, due to STP, several data centers limit | pressure. Moreover, due to STP, several data centers limit the | |||
| the number of VLANs that could be used. In addition, requirements | number of VLANs that could be used. In addition, requirements for | |||
| for multitenant environments accelerate the need for larger VLAN | multitenant environments accelerate the need for larger VLAN limits, | |||
| limits, as discussed in Section 3.3. | as discussed in Section 3.3. | |||
| 3.2. Multitenant Environments | 3.2. Multitenant Environments | |||
| Cloud computing involves on demand elastic provisioning of resources | Cloud computing involves on demand elastic provisioning of resources | |||
| for multi-tenant environments. The most common example of cloud | for multi-tenant environments. The most common example of cloud | |||
| computing is the public cloud, where a cloud service provider offers | computing is the public cloud, where a cloud service provider offers | |||
| these elastic services to multiple customers/tenants over the same | these elastic services to multiple customers/tenants over the same | |||
| physical infrastructure. | physical infrastructure. | |||
| Isolation of network traffic by tenant could be done via Layer 2 or | Isolation of network traffic by tenant could be done via Layer 2 or | |||
| Layer 3 networks. For Layer 2 networks, VLANs are often used to | Layer 3 networks. For Layer 2 networks, VLANs are often used to | |||
| segregate traffic - so a tenant could be identified by its own VLAN, | segregate traffic - so a tenant could be identified by its own VLAN, | |||
| for example. Due to the large number of tenants that a cloud | for example. Due to the large number of tenants that a cloud | |||
| provider might service, the 4094 VLAN limit is often inadequate. In | provider might service, the 4094 VLAN limit is often inadequate. In | |||
| addition, there is often a need for multiple VLANs per tenant, which | addition, there is often a need for multiple VLANs per tenant, which | |||
| exacerbates the issue. | exacerbates the issue. | |||
| Another use case is cross pod expansion. A pod typically consists of | A related use case is cross pod expansion. A pod typically consists | |||
| one or more racks of servers with associated network and storage | of one or more racks of servers with associated network and storage | |||
| connectivity. Tenants may start off on a pod and, due to expansion, | connectivity. Tenants may start off on a pod and, due to expansion, | |||
| require servers/VMs on other pods, especially in the case when | require servers/VMs on other pods, especially in the case when | |||
| tenants on the other pods are not fully utilizing all their | tenants on the other pods are not fully utilizing all their | |||
| resources. This use case requires a "stretched" Layer 2 environment | resources. This use case requires a "stretched" Layer 2 environment | |||
| connecting the individual servers/VMs. | connecting the individual servers/VMs. | |||
| Layer 3 networks are not a comprehensive solution for multi tenancy | Layer 3 networks are not a comprehensive solution for multi tenancy | |||
| either. Two tenants might use the same set of Layer 3 addresses | either. Two tenants might use the same set of Layer 3 addresses | |||
| within their networks which requires the cloud provider to provide | within their networks which requires the cloud provider to provide | |||
| isolation in some other form. Further, requiring all tenants to use | isolation in some other form. Further, requiring all tenants to use | |||
| skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 7 ¶ | |||
| packets, a protocol like PIM-bidir (see [RFC5015]) would be more | packets, a protocol like PIM-bidir (see [RFC5015]) would be more | |||
| efficient. | efficient. | |||
| The destination VM sends a standard ARP response using IP unicast. | The destination VM sends a standard ARP response using IP unicast. | |||
| This frame will be encapsulated back to the VTEP connecting the | This frame will be encapsulated back to the VTEP connecting the | |||
| originating VM using IP unicast VXLAN encapsulation. This is | originating VM using IP unicast VXLAN encapsulation. This is | |||
| possible since the mapping of the ARP response's destination MAC to | possible since the mapping of the ARP response's destination MAC to | |||
| the VXLAN tunnel end point IP was learned earlier through the ARP | the VXLAN tunnel end point IP was learned earlier through the ARP | |||
| request. | request. | |||
| Another point to note is that multicast frames and "unknown MAC | Note that multicast frames and "unknown MAC destination" frames are | |||
| destination" frames are also sent using the multicast tree, similar | also sent using the multicast tree, similar to the broadcast frames. | |||
| to the broadcast frames. | ||||
| 4.3. Physical Infrastructure Requirements | 4.3. Physical Infrastructure Requirements | |||
| When IP multicast is used within the network infrastructure, a | When IP multicast is used within the network infrastructure, a | |||
| multicast routing protocol like PIM-SM can be used by the individual | multicast routing protocol like PIM-SM can be used by the individual | |||
| Layer 3 IP routers/switches within the network. This is used to | Layer 3 IP routers/switches within the network. This is used to | |||
| build efficient multicast forwarding trees so that multicast frames | build efficient multicast forwarding trees so that multicast frames | |||
| are only sent to those hosts which have requested to receive them. | are only sent to those hosts which have requested to receive them. | |||
| Similarly, there is no requirement that the actual network | Similarly, there is no requirement that the actual network | |||
| connecting the source VM and destination VM should be a Layer 3 | connecting the source VM and destination VM should be a Layer 3 | |||
| network - VXLAN can also work over Layer 2 networks. In either case, | network - VXLAN can also work over Layer 2 networks. In either case, | |||
| efficient multicast replication within the Layer 2 network can be | efficient multicast replication within the Layer 2 network can be | |||
| achieved using IGMP snooping. | achieved using IGMP snooping. | |||
| VTEPs MUST not fragment VXLAN packets. Intermediate routers may | VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may | |||
| fragment encapsulated VXLAN packets due to the larger frame size. | fragment encapsulated VXLAN packets due to the larger frame size. | |||
| The destination VTEP MAY silently discard such VXLAN fragments. To | The destination VTEP MAY silently discard such VXLAN fragments. To | |||
| ensure end to end traffic delivery without fragmentation, it is | ensure end to end traffic delivery without fragmentation, it is | |||
| RECOMMENDED that the MTUs (Maximum Transmission Units) across the | RECOMMENDED that the MTUs (Maximum Transmission Units) across the | |||
| physical network infrastructure be set to a value that accommodates | physical network infrastructure be set to a value that accommodates | |||
| the larger frame size due to the encapsulation. Other techniques | the larger frame size due to the encapsulation. Other techniques | |||
| like Path MTU discovery (see [RFC1191 and [RFC1981]) MAY be used to | like Path MTU discovery (see [RFC1191] and [RFC1981]) MAY be used to | |||
| address this requirement as well. | address this requirement as well. | |||
| 5. VXLAN Frame Format | 5. VXLAN Frame Format | |||
| The VXLAN frame format is shown below. Parsing this from the bottom | The VXLAN frame format is shown below. Parsing this from the bottom | |||
| of the frame - above the outer frame check sequence (FCS), there is | of the frame - above the outer frame check sequence (FCS), there is | |||
| an inner MAC frame with its own Ethernet header with source, | an inner MAC frame with its own Ethernet header with source, | |||
| destination MAC addresses along with the Ethernet type plus an | destination MAC addresses along with the Ethernet type plus an | |||
| optional VLAN. See Section 6 for further details of inner VLAN tag | optional VLAN. See Section 6 for further details of inner VLAN tag | |||
| handling. | handling. | |||
| skipping to change at page 11, line 39 ¶ | skipping to change at page 11, line 27 ¶ | |||
| o Reserved fields (24 bits and 8 bits) - MUST be set to zero on | o Reserved fields (24 bits and 8 bits) - MUST be set to zero on | |||
| transmit and ignored on receive. | transmit and ignored on receive. | |||
| O Outer UDP Header: This is the outer UDP header with a source | O Outer UDP Header: This is the outer UDP header with a source | |||
| port provided by the VTEP and the destination port being a well- | port provided by the VTEP and the destination port being a well- | |||
| known UDP port. IANA has assigned the value 4789 for the VXLAN UDP | known UDP port. IANA has assigned the value 4789 for the VXLAN UDP | |||
| port and this value SHOULD be used by default as the destination UDP | port and this value SHOULD be used by default as the destination UDP | |||
| port. Some early implementations of VXLAN have used other values | port. Some early implementations of VXLAN have used other values | |||
| for the destination port. To enable interoperability with these | for the destination port. To enable interoperability with these | |||
| implementations, the destination port SHOULD be configurable. It is | implementations, the destination port SHOULD be configurable. It is | |||
| recommended that the source port number be calculated using a hash | recommended that the UDP source port number be calculated using a | |||
| of fields from the inner packet - one example being a hash of the | hash of fields from the inner packet - one example being a hash of | |||
| inner Ethernet frame`s headers. This is to enable a level of entropy | the inner Ethernet frame`s headers. This is to enable a level of | |||
| for ECMP/load balancing of the VM to VM traffic across the VXLAN | entropy for ECMP/load balancing of the VM to VM traffic across the | |||
| overlay. | VXLAN overlay. When calculating the UDP source port number in this | |||
| manner, it is RECOMMENDED that the value be in the dynamic/private | ||||
| port range 49152-65535 [RFC6335]. | ||||
| The UDP checksum field SHOULD be transmitted as zero. When a packet | The UDP checksum field SHOULD be transmitted as zero. When a packet | |||
| is received with a UDP checksum of zero, it MUST be accepted for | is received with a UDP checksum of zero, it MUST be accepted for | |||
| decapsulation. Optionally, if the encapsulating endpoint includes a | decapsulation. Optionally, if the encapsulating endpoint includes a | |||
| non-zero UDP checksum, it MUST be correctly calculated across the | non-zero UDP checksum, it MUST be correctly calculated across the | |||
| entire packet including the IP header, UDP header, VXLAN header and | entire packet including the IP header, UDP header, VXLAN header and | |||
| encapsulated MAC frame. When a decapsulating endpoint receives a | encapsulated MAC frame. When a decapsulating endpoint receives a | |||
| packet with a non-zero checksum it MAY choose to verify the checksum | packet with a non-zero checksum it MAY choose to verify the checksum | |||
| value. If it chooses to perform such verification, and the | value. If it chooses to perform such verification, and the | |||
| verification fails, the packet MUST be dropped. If the | verification fails, the packet MUST be dropped. If the | |||
| skipping to change at page 18, line 6 ¶ | skipping to change at page 18, line 6 ¶ | |||
| | |VM2-3 | |VM2-4 | | | | |VM2-3 | |VM2-4 | | | |||
| | |VNI 98 | |VNI 22 | | | | |VNI 98 | |VNI 22 | | | |||
| | | | | | | | | | | | | | | |||
| | +---------+ +---------+ | | | +---------+ +---------+ | | |||
| | Hypervisor VTEP (IP2) | | | Hypervisor VTEP (IP2) | | |||
| +--------------------------+ | +--------------------------+ | |||
| Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network | Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network | |||
| One deployment scenario is where the tunnel termination point is a | One deployment scenario is where the tunnel termination point is a | |||
| physical server which understands VXLAN. Another scenario is where | physical server which understands VXLAN. An alternate scenario is | |||
| nodes on a VXLAN overlay network need to communicate with nodes on | where nodes on a VXLAN overlay network need to communicate with | |||
| legacy networks which could be VLAN based. These nodes may be | nodes on legacy networks which could be VLAN based. These nodes may | |||
| physical nodes or virtual machines. To enable this communication, a | be physical nodes or virtual machines. To enable this communication, | |||
| network can include VXLAN gateways (see Figure 4 below with a switch | a network can include VXLAN gateways (see Figure 4 below with a | |||
| acting as a VXLAN gateway) which forward traffic between VXLAN and | switch acting as a VXLAN gateway) which forward traffic between | |||
| non-VXLAN environments. | VXLAN and non-VXLAN environments. | |||
| Consider Figure 4 for the following discussion. For incoming frames | Consider Figure 4 for the following discussion. For incoming frames | |||
| on the VXLAN connected interface, the gateway strips out the VXLAN | on the VXLAN connected interface, the gateway strips out the VXLAN | |||
| header and forwards to a physical port based on the destination MAC | header and forwards to a physical port based on the destination MAC | |||
| address of the inner Ethernet frame. Decapsulated frames with the | address of the inner Ethernet frame. Decapsulated frames with the | |||
| inner VLAN ID SHOULD be discarded unless configured explicitly to be | inner VLAN ID SHOULD be discarded unless configured explicitly to be | |||
| passed on to the non-VXLAN interface. In the reverse direction, | passed on to the non-VXLAN interface. In the reverse direction, | |||
| incoming frames for the non-VXLAN interfaces are mapped to a | incoming frames for the non-VXLAN interfaces are mapped to a | |||
| specific VXLAN overlay network based on the VLAN ID in the frame. | specific VXLAN overlay network based on the VLAN ID in the frame. | |||
| Unless configured explicitly to be passed on in the encapsulated | Unless configured explicitly to be passed on in the encapsulated | |||
| skipping to change at page 22, line 8 ¶ | skipping to change at page 22, line 8 ¶ | |||
| [802.1aq] "Standard for Local and Metropolitan Area Networks / | [802.1aq] "Standard for Local and Metropolitan Area Networks / | |||
| Virtual Bridged Local Area Networks / Amendment20: Shortest | Virtual Bridged Local Area Networks / Amendment20: Shortest | |||
| Path Bridging, IEEE P802.1aq-2012". | Path Bridging, IEEE P802.1aq-2012". | |||
| [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191, | [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191, | |||
| November 1990. | November 1990. | |||
| [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | |||
| for IP version 6", RFC 1981, August 1996. | for IP version 6", RFC 1981, August 1996. | |||
| [RFC6335] Cotton, M, Eggert, L., Touch, J., Westerlund, M., and | ||||
| Cheshire, S., "Internet Assigned Numbers Authority (IANA) Procedures | ||||
| for the Management of the Service Name and Transport Protocol Port | ||||
| Number Registry", RFC 6335, August 2011. | ||||
| 10. Acknowledgments | 10. Acknowledgments | |||
| The authors wish to thank Ajit Sanzgiri for contributions to the | The authors wish to thank Ajit Sanzgiri for contributions to the | |||
| Security Considerations section and editorial inputs, Joseph Cheng, | Security Considerations section and editorial inputs, Joseph Cheng, | |||
| Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva | Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva | |||
| Kollipara for their editorial reviews, inputs and comments. | Kollipara for their editorial reviews, inputs and comments. | |||
| Authors' Addresses | Authors' Addresses | |||
| Mallik Mahalingam | Mallik Mahalingam | |||
| skipping to change at page 23, line 4 ¶ | skipping to change at page 23, line 7 ¶ | |||
| Santa Clara, CA 95054 | Santa Clara, CA 95054 | |||
| Email: kduda@aristanetworks.com | Email: kduda@aristanetworks.com | |||
| Puneet Agarwal | Puneet Agarwal | |||
| Broadcom Corporation | Broadcom Corporation | |||
| 3151 Zanker Road | 3151 Zanker Road | |||
| San Jose, CA 95134 | San Jose, CA 95134 | |||
| Email: pagarwal@broadcom.com | Email: pagarwal@broadcom.com | |||
| Lawrence Kreeger | Lawrence Kreeger | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 170 W. Tasman Avenue | 170 W. Tasman Avenue | |||
| Palo Alto, CA 94304 | San Jose, CA 95134 | |||
| Email: kreeger@cisco.com | Email: kreeger@cisco.com | |||
| T. Sridhar | T. Sridhar | |||
| VMware Inc. | VMware Inc. | |||
| 3401 Hillview | 3401 Hillview | |||
| Palo Alto, CA 94304 | Palo Alto, CA 94304 | |||
| Email: tsridhar@vmware.com | Email: tsridhar@vmware.com | |||
| End of changes. 24 change blocks. | ||||
| 55 lines changed or deleted | 58 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||