draft-ietf-lisp-01.txt   draft-ietf-lisp-02.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: November 29, 2009 D. Lewis Expires: January 10, 2010 D. Lewis
cisco Systems cisco Systems
May 28, 2009 July 9, 2009
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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 34 skipping to change at page 1, line 34
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."
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 29, 2009. This Internet-Draft will expire on January 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 20 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 21 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 21
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 23 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 23
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 31 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 31
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 32 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 32
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 35 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 35
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 37
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 38 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 38
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 39
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 39 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 39
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 39 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 40
7. Router Performance Considerations . . . . . . . . . . . . . . 41 7. Router Performance Considerations . . . . . . . . . . . . . . 42
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 43
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 43 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 44
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 44
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 44 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 45
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 45 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 46
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 47
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 47
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 46 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 47
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 48 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 48 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 49
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 49
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 50 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 51
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 51
12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 53
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53 12. Security Considerations . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . . 56 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14.2. Informative References . . . . . . . . . . . . . . . . . . 57 14.1. Normative References . . . . . . . . . . . . . . . . . . . 58
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 60 14.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Requirements Notation 1. Requirements Notation
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Many years of discussion about the current IP routing and addressing Many years of discussion about the current IP routing and addressing
skipping to change at page 5, line 51 skipping to change at page 5, line 51
a different point in the network topology either retaining its a different point in the network topology either retaining its
home-based address or acquiring a new address based on the new home-based address or acquiring a new address based on the new
network location. A new network location could be a physically network location. A new network location could be a physically
different point in the network topology or the same physical different point in the network topology or the same physical
point of the topology with a different provider. point of the topology with a different provider.
This draft describes protocol mechanisms to achieve the desired This draft describes protocol mechanisms to achieve the desired
functional separation. For flexibility, the mechanism used for functional separation. For flexibility, the mechanism used for
forwarding packets is decoupled from that used to determine EID to forwarding packets is decoupled from that used to determine EID to
RLOC mappings. This document covers the former. For the later, see RLOC mappings. This document covers the former. For the later, see
[CONS], [ALT], [RPMD], and [NERD]. This work is in response to and [CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response
intended to address the problem statement that came out of the RAWS to and intended to address the problem statement that came out of the
effort [RFC4984]. RAWS effort [RFC4984].
The Routing and Addressing problem statement can be found in [RADIR]. The Routing and Addressing problem statement can be found in [RADIR].
This draft focuses on a router-based solution. Building the solution This draft focuses on a router-based solution. Building the solution
into the network will facilitate incremental deployment of the into the network will facilitate incremental deployment of the
technology on the Internet. Note that while the detailed protocol technology on the Internet. Note that while the detailed protocol
specification and examples in this document assume IP version 4 specification and examples in this document assume IP version 4
(IPv4), there is nothing in the design that precludes use of the same (IPv4), there is nothing in the design that precludes use of the same
techniques and mechanisms for IPv6. It should be possible for IPv4 techniques and mechanisms for IPv6. It should be possible for IPv4
packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
skipping to change at page 17, line 24 skipping to change at page 17, line 24
OH | Time to Live | Protocol = 17 | Header Checksum | OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator | | | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator | \ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |S| Locator Reach Bits | L / | Locator Reach Bits |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S \ | Nonce | S \ |S|E| rsvd-flags| Nonce |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID | | | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID | \ | Destination EID |
skipping to change at page 18, line 34 skipping to change at page 18, line 34
| | | |
^ + Destination Routing Locator + ^ + Destination Routing Locator +
| | | | | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |S| Locator Reach Bits | L / | Locator Reach Bits |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S \ | Nonce | S \ |S|E| rsvd-flags| Nonce |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label | / |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit | / | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
I + + I + +
n | | n | |
n + Source EID + n + Source EID +
e | | e | |
skipping to change at page 19, line 44 skipping to change at page 19, line 44
do a checksum computation. do a checksum computation.
UDP Length: for an IPv4 encapsulated packet, the inner header Total UDP Length: for an IPv4 encapsulated packet, the inner header Total
Length plus the UDP and LISP header lengths are used. For an IPv6 Length plus the UDP and LISP header lengths are used. For an IPv6
encapsulated packet, the inner header Payload Length plus the size encapsulated packet, the inner header Payload Length plus the size
of the IPv6 header (40 bytes) plus the size of the UDP and LISP of the IPv6 header (40 bytes) plus the size of the UDP and LISP
headers are used. The UDP header length is 8 bytes. The LISP headers are used. The UDP header length is 8 bytes. The LISP
header length is 8 bytes when no loc-reach-bit header extensions header length is 8 bytes when no loc-reach-bit header extensions
are used. are used.
S: this is the Solicit-Map-Request (SMR) bit. See section
Section 6.5.2 for details.
LISP Locator Reach Bits: in the LISP header are set by an ITR to LISP Locator Reach Bits: in the LISP header are set by an ITR to
indicate to an ETR the reachability of the Locators in the source indicate to an ETR the reachability of the Locators in the source
site. Each RLOC in a Map-Reply is assigned an ordinal value from site. Each RLOC in a Map-Reply is assigned an ordinal value from
0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator
Reach Bits are numbered from 0 to n-1 from the right significant Reach Bits are numbered from 0 to n-1 from the right significant
bit of the 31-bit field. When a bit is set to 1, the ITR is bit of the 32-bit field. When a bit is set to 1, the ITR is
indicating to the ETR the RLOC associated with the bit ordinal is indicating to the ETR the RLOC associated with the bit ordinal is
reachable. See Section 6.3 for details on how an ITR can reachable. See Section 6.3 for details on how an ITR can
determine other ITRs at the site are reachable. When a site has determine other ITRs at the site are reachable. When a site has
multiple EID-prefixes which result in multiple mappings (where multiple EID-prefixes which result in multiple mappings (where
each could have a different locator-set), the Locator Reach Bits each could have a different locator-set), the Locator Reach Bits
setting in an encapsulated packet MUST reflect the mapping for the setting in an encapsulated packet MUST reflect the mapping for the
EID-prefix that the inner-header source EID address matches. EID-prefix that the inner-header source EID address matches.
LISP Nonce: is a 32-bit value that is randomly generated by an ITR. S: this is the Solicit-Map-Request (SMR) bit. See section
Section 6.5.2 for details.
E: this is the echo-nonce-request bit. See section Section 6.3.1 for
details.
rsvd-flags: this 6-bit field is reserved for future flag use. It is
set to 0 on transmit and ignored on receipt.
LISP Nonce: is a 24-bit value that is randomly generated by an ITR.
It is used to test route-returnability when xTRs exchange It is used to test route-returnability when xTRs exchange
encapsulated data packets with the SMR bit set, Data-Probe, Map- encapsulated data packets with the SMR bit set, Data-Probe, Map-
Request, or Map-Reply messages. Request, or Map-Reply messages.
When doing Recursive Tunneling: When doing Recursive Tunneling or ITR/PTR encapsulation:
o The OH header Time to Live field (or Hop Limit field, in case of o The OH header Time to Live field (or Hop Limit field, in case of
IPv6) MUST be copied from the IH header Time to Live field. IPv6) MUST be copied from the IH header Time to Live field.
o The OH header Type of Service field (or the Traffic Class field, o The OH header Type of Service field (or the Traffic Class field,
in the case of IPv6) SHOULD be copied from the IH header Type of in the case of IPv6) SHOULD be copied from the IH header Type of
Service field (with one caveat, see below). Service field (with one caveat, see below).
When doing Re-encapsulated Tunneling: When doing Re-encapsulated Tunneling:
skipping to change at page 20, line 42 skipping to change at page 20, line 48
o The new OH header Type of Service field SHOULD be copied from the o The new OH header Type of Service field SHOULD be copied from the
stripped OH header Type of Service field (with one caveat, see stripped OH header Type of Service field (with one caveat, see
below).. below)..
Copying the TTL serves two purposes: first, it preserves the distance Copying the TTL serves two purposes: first, it preserves the distance
the host intended the packet to travel; second, and more importantly, the host intended the packet to travel; second, and more importantly,
it provides for suppression of looping packets in the event there is it provides for suppression of looping packets in the event there is
a loop of concatenated tunnels due to misconfiguration. a loop of concatenated tunnels due to misconfiguration.
When the Type of Service code-points indicate the use of ECN The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
according to [RFC3168], the full-functionality option for simple field and the IPv6 Traffic Class field [RFC3168]. The ECN field
tunnels will be used when ITR encapsulating and ETR decapsulating. requires special treatment in order to avoid discarding indications
Therefore, the Congestion Experience (CE) bit will be preserved when of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN
a packet traveres a LISP tunnel. field from the inner header to the outer header. Re-encapsulation
MUST copy the 2-bit ECN field from the stripped outer header to the
new outer header. If the ECN field contains a congestion indication
codepoint (the value is '11', the Congestion Experienced (CE)
codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
the stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve
Congestion Experienced (CE) indications when a packet that uses ECN
traverses a LISP tunnel and becomes marked with a CE indication due
to congestion between the tunnel endpoints.
5.4. Dealing with Large Encapsulated Packets 5.4. Dealing with Large Encapsulated Packets
In the event that the MTU issues mentioned above prove to be more In the event that the MTU issues mentioned above prove to be more
serious than expected, this section proposes 2 simple mechanisms to serious than expected, this section proposes 2 simple mechanisms to
deal with large packets. One is stateless using IP fragmentation and deal with large packets. One is stateless using IP fragmentation and
the other is stateful using Path MTU Discovery [RFC1191]. the other is stateful using Path MTU Discovery [RFC1191].
It is left to the implementor to decide if the stateless or stateful It is left to the implementor to decide if the stateless or stateful
mechanism should be implemented. Both or neither can be decided as mechanism should be implemented. Both or neither can be decided as
skipping to change at page 25, line 24 skipping to change at page 25, line 24
LISP-CONS Open Message: 8 b'1000' LISP-CONS Open Message: 8 b'1000'
LISP-CONS Push-Add Message: 9 b'1001' LISP-CONS Push-Add Message: 9 b'1001'
LISP-CONS Push-Delete Message: 10 b'1010' LISP-CONS Push-Delete Message: 10 b'1010'
LISP-CONS Unreachable Message 11 b'1011' LISP-CONS Unreachable Message 11 b'1011'
6.1.2. Map-Request Message Format 6.1.2. Map-Request Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Locator Reach Bits | | Locator Reach Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|R| Reserved | Record Count | |Type=1 |A|R|P|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | ITR-AFI | | Source-EID-AFI | ITR-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID Address ... | | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating ITR RLOC Address ... | | Originating ITR RLOC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-prefix-AFI | / | Reserved | EID mask-len | EID-prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-prefix ... | \ | EID-prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
S: This is the SMR bit. See Section 6.5.2 for details.
Locator Reach Bits: These bits MUST be set to 0 on transmission and Locator Reach Bits: These bits MUST be set to 0 on transmission and
ignored on receipt. They cannot be used for indicating ignored on receipt. They cannot be used for indicating
reachability because the Map-Request does not have the EID-prefix reachability because the Map-Request does not have the EID-prefix
for the sending site so the receiver of the Map-Request cannot for the sending site so the receiver of the Map-Request cannot
know what mapping entry to associate the reachability with. know what mapping entry to associate the reachability with.
However, when Mapping Data is provided in the Map-Reply Record However, when Mapping Data is provided in the Map-Reply Record
field, and the receiver of the Map-Request is configured to accept field, and the receiver of the Map-Request is configured to accept
the mapping data, the R-bit per locator entry in the EID-prefix the mapping data, the R-bit per locator entry in the EID-prefix
record is used to denote reachability. record is used to denote reachability.
skipping to change at page 26, line 29 skipping to change at page 26, line 27
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. See other control-specific documents Requests sent by an ITR. See other control-specific documents
[CONS] for TCP-based Map-Requests. [CONS] for TCP-based Map-Requests.
R: When set, it indicates a Map-Reply Record segment is included in R: When set, it indicates a Map-Reply Record segment is included in
the Map-Request. the Map-Request.
P: Indicates that a Map-Request should be treated as a "piggyback"
locator reachability probe. The receiver should respond with a
Map-Reply with the P bit set and the nonce copied from the Map-
Request. Details on this usage will be provided in a future
version of this draft.
S: This is the SMR bit. See Section 6.5.2 for details.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this request message. A Record Count: The number of records in this request message. A
record is comprised of the portion of the packet is labeled 'Rec' record is comprised of the portion of the packet is labeled 'Rec'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Source-EID-AFI: Address family of the "Source EID Address" field. Source-EID-AFI: Address family of the "Source EID Address" field.
ITR-AFI: Address family of the "Originating ITR RLOC Address" field. ITR-AFI: Address family of the "Originating ITR RLOC Address" field.
skipping to change at page 28, line 10 skipping to change at page 28, line 10
in [LISP-MS]. in [LISP-MS].
Map-Requests MUST be rate-limited. It is recommended that a Map- Map-Requests MUST be rate-limited. It is recommended that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
6.1.4. Map-Reply Message Format 6.1.4. Map-Reply Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| Locator Reach Bits | | Locator Reach Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 | Reserved | Record Count | |Type=2 |P| Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| ACT | Reserved | R | Locator Count | EID mask-len |A| ACT | Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Reserved | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc-AFI | | o | Unused Flags |R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
x: Set to 0 on transmission and ignored on receipt.
Locator Reach Bits: Refer to Section 5.3. This field MUST be set to Locator Reach Bits: Refer to Section 5.3. This field MUST be set to
0 on transmission and ignored on receipt. The locator 0 on transmission and ignored on receipt. The locator
reachability is encoded as the R-bit in each locator entry of each reachability is encoded as the R-bit in each locator entry of each
EID-prefix record. EID-prefix record.
Nonce: A 4-byte value set in a Data-Probe packet or a Map-Request Nonce: A 4-byte value set in a Data-Probe packet or a Map-Request
that is echoed here in the Map-Reply. that is echoed here in the Map-Reply.
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: Indicates that the Map-Reply is in response to a "piggyback"
locator reachability Map-Request. The nonce field should contain
a copy of the nonce value from the original Map-Request. Details
on this usage will be provided in a future version of this draft.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this reply message. A record Record Count: The number of records in this reply message. A record
is comprised of that portion of the packet labeled 'Record' above is comprised of that portion of the packet labeled 'Record' above
and occurs the number of times equal to Record count. and occurs the number of times equal to Record count.
Record TTL: The time in minutes the recipient of the Map-Reply will Record TTL: The time in minutes the recipient of the Map-Reply will
store the mapping. If the TTL is 0, the entry should be removed store the mapping. If the TTL is 0, the entry should be removed
from the cache immediately. If the value is 0xffffffff, the from the cache immediately. If the value is 0xffffffff, the
recipient can decide locally how long to store the mapping. recipient can decide locally how long to store the mapping.
skipping to change at page 33, line 8 skipping to change at page 33, line 8
The Next Header field is set to UDP. The SPI field is set to 0 The Next Header field is set to UDP. The SPI field is set to 0
(since no Security Association or Key Exchange protocol is being (since no Security Association or Key Exchange protocol is being
used). The Sequence Number is a randomly chosen value by the sender. used). The Sequence Number is a randomly chosen value by the sender.
The Authentication Data is 16 bytes and holds a MD5 HMAC. The Authentication Data is 16 bytes and holds a MD5 HMAC.
The Map-Register message format is: The Map-Register message format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| Locator Reach Bits | | Locator Reach Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved | Record Count | |Type=3 |P| Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| ACT | Reserved | R | Locator Count | EID mask-len |A| ACT | Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Reserved | EID-AFI |
skipping to change at page 33, line 31 skipping to change at page 33, line 31
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc-AFI | | o | Unused Flags |R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
x: Set to 0 on transmission and ignored on receipt.
Locator Reach Bits: Refer to Section 5.3. This field MUST be set to Locator Reach Bits: Refer to Section 5.3. This field MUST be set to
0 on transmission and ignored on receipt. The locator 0 on transmission and ignored on receipt. The locator
reachability is encoded as the R-bit in each locator entry of each reachability is encoded as the R-bit in each locator entry of each
EID-prefix record. EID-prefix record.
Nonce: The Nonce field is set to 0 in Map-Register messages. Nonce: The Nonce field is set to 0 in Map-Register messages.
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the Proxy-Map-Reply bit. When set to 1, the ETR sending a P: Set to 1 by an ETR which sends a Map-Register message requesting
Map-Register is asking the Map-Server to send non-authoritative for the Map-Server to proxy Map-Reply. The Map-Server will send
Map-Replies on behalf of the ETR. non-authoritative Map-Replies on behalf of the ETR. Details on
this usage will be provided in a future version of this draft.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
skipping to change at page 37, line 15 skipping to change at page 37, line 15
Locator has been determined to be unreachable, it is not used for Locator has been determined to be unreachable, it is not used for
active traffic; this is the same as if it were listed in a Map-Reply active traffic; this is the same as if it were listed in a Map-Reply
with priority 255. with priority 255.
The ITR can test the reachability of the unreachable Locator by The ITR can test the reachability of the unreachable Locator by
sending periodic Requests. Both Requests and Replies MUST be rate- sending periodic Requests. Both Requests and Replies MUST be rate-
limited. Locator reachability testing is never done with data limited. Locator reachability testing is never done with data
packets since that increases the risk of packet loss for end-to-end packets since that increases the risk of packet loss for end-to-end
sessions. sessions.
When an ETR is decapsulating packets, it can be sure that the path When an ETR decapsulates a packet, it knows that it is reachable from
from the encapsulating ITR is available. The ETR can assume the path the encapsulating ITR because that is how the packet arrived. In
from the ETR to the ITR is also reachable. Even if there is most cases, the ETR can also reach the ITR but cannot assume this to
asymmetric routing in the core, the first-hop and last-hop ASes will be true due to the possibility of path assymetry. In the presence of
be the same for both directions of traffic since the locator unidirectional traffic flow from an ITR to an ETR, the ITR should not
addresses are out of the PA blocks of each. However, the assumption use the lack of return traffic as an indication that the ETR is
may not always be valid, so this mechanism should be used as a best- unreachable. Instead, it must use an alternate mechanisms to
effort indication that a working path exists between the sites. In
the event of unidirectional traffic from an ITR to an ETR, an ITR
should not conclude that a locator is unreachable since it is not
receiving packets, but use alternate mechanisms described above to
determine reachability. determine reachability.
6.3.1. Echo Nonce Algorithm
When there is bidirectional data flow between a pair of locators, a
simple mechanism called "nonce echoing" can be used to determine
reachability between an ITR and ETR. When an ITR wants to solicit a
nonce echo, it sets the E-bit and places a 24-bit nonce in the LISP
header of the next encapsulated data packet.
When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR next sends a data packet to the
ITR, it includes the nonce received earlier. The ITR sees this "echo
nonce reply" and knows the path to and from the ETR is up.
The time the ITR waits for the echoed nonce before it determines the
path is down is variable and a choice left for the implementation.
If the ITR is receiving packets from the ETR but does not see the
nonce echoed, then the path to the ETR is down. This decision may be
overridden by other locator reachability algorithms. Once the ITR
determines the path to the ETR is down it can switch to another
locator for that EID-prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices must
be implementing both ITR and ETR functionality for the echo nonce
mechanism to operate.
The ITR and ETR may both go into echo-nonce-request state at the same
time. The number of packets sent or the time during which echo nonce
requests are sent is an implementation specific setting. However,
when an ITR is in echo-nonce-request state, it can echo the ETR's
nonce in the next packet that it encapsulates and then subsequently,
continue sending echo-nonce-request packets.
This mechanism does not completely solve the forward path
reachability problem as traffic may be unidirectional. That is, the
ETR receiving traffic at a site may not may not be the same device as
an ITR which transmits traffic from that site or the site to site
traffic is unidirectional so there is no ITR returning traffic.
Note that other locator reachability mechanisms are being researched.
6.4. Routing Locator Hashing 6.4. Routing Locator Hashing
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
a requesting ITR, the locator-set for the EID-prefix may contain a requesting ITR, the locator-set for the EID-prefix may contain
different priority values for each locator address. When more than different priority values for each locator address. When more than
one best priority locator exists, the ITR can decide how to load one best priority locator exists, the ITR can decide how to load
share traffic against the corresponding locators. share traffic against the corresponding locators.
The following hash algorithm may be used by an ITR to select a The following hash algorithm may be used by an ITR to select a
locator for a packet destined to an EID for the EID-to-RLOC mapping: locator for a packet destined to an EID for the EID-to-RLOC mapping:
skipping to change at page 51, line 5 skipping to change at page 51, line 45
If mobile networks become a more common occurrence, it may be useful If mobile networks become a more common occurrence, it may be useful
to revisit the design of the mapping service and allow for dynamic to revisit the design of the mapping service and allow for dynamic
updates of the database. updates of the database.
The issue of interactions between mobility and LISP needs to be The issue of interactions between mobility and LISP needs to be
explored further. Specific improvements to the entire system will explored further. Specific improvements to the entire system will
depend on the details of mapping mechanisms. Mapping mechanisms depend on the details of mapping mechanisms. Mapping mechanisms
should be evaluated on how well they support session continuity for should be evaluated on how well they support session continuity for
mobile nodes. mobile nodes.
10.5. LISP Mobile Node Mobility
An mobile device can use the LISP infrastructure to achieve mobility
by implementing the LISP encapsulation and decapsulation functions
and acting as a simple ITR/ETR. By doing this, such a "LISP mobile
node" can use topologically-independent EID IP addresses that are not
advertised into and do not impose a cost on the global routing
system. These EIDs are maintained at the edges of the mapping system
(in LISP Map-Servers and Map-Resolvers) and are provided on demand to
only the correspondents of the LISP mobile node.
Refer to the LISP Mobility Architecture specification [LISP-MN] for
more details.
11. Multicast Considerations 11. Multicast Considerations
A multicast group address, as defined in the original Internet A multicast group address, as defined in the original Internet
architecture is an identifier of a grouping of topologically architecture is an identifier of a grouping of topologically
independent receiver host locations. The address encoding itself independent receiver host locations. The address encoding itself
does not determine the location of the receiver(s). The multicast does not determine the location of the receiver(s). The multicast
routing protocol, and the network-based state the protocol creates, routing protocol, and the network-based state the protocol creates,
determines where the receivers are located. determines where the receivers are located.
In the context of LISP, a multicast group address is both an EID and In the context of LISP, a multicast group address is both an EID and
skipping to change at page 53, line 49 skipping to change at page 55, line 49
beginning of 2009. beginning of 2009.
2. Continue pilot deployment using LISP-ALT as the database mapping 2. Continue pilot deployment using LISP-ALT as the database mapping
mechanism. mechanism.
3. Continue prototyping and studying other database lookup schemes, 3. Continue prototyping and studying other database lookup schemes,
be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.
4. Implement the LISP Multicast draft [MLISP]. 4. Implement the LISP Multicast draft [MLISP].
5. Research more on how policy affects what gets returned in a Map- 5. Implement the LISP Mobile Node draft [LISP-MN].
6. Research more on how policy affects what gets returned in a Map-
Reply from an ETR. Reply from an ETR.
6. Continue to experiment with mixed locator-sets to understand how 7. Continue to experiment with mixed locator-sets to understand how
LISP can help the IPv4 to IPv6 transition. LISP can help the IPv4 to IPv6 transition.
7. Add more robustness to locator reachability between LISP sites. 8. Add more robustness to locator reachability between LISP sites.
As of this writing the following accomplishments have been achieved: As of this writing the following accomplishments have been achieved:
1. A unit- and system-tested software switching implementation has 1. A unit- and system-tested software switching implementation has
been completed on cisco NX-OS for this draft for both IPv4 and been completed on cisco NX-OS for this draft for both IPv4 and
IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.
2. A unit- and system-tested software switching implementation on 2. A unit- and system-tested software switching implementation on
cisco NX-OS has been completed for draft [ALT]. cisco NX-OS has been completed for draft [ALT].
skipping to change at page 55, line 15 skipping to change at page 57, line 15
10. A cisco IOS implementation is underway which currently supports 10. A cisco IOS implementation is underway which currently supports
IPv4 encapsulation and decapsulation features. IPv4 encapsulation and decapsulation features.
11. A LISP router based LIG implementation is supported, deployed, 11. A LISP router based LIG implementation is supported, deployed,
and used daily to debug and test the LISP pilot network. See and used daily to debug and test the LISP pilot network. See
[LIG] for details. [LIG] for details.
12. A Linux implementation of LIG has been made available and 12. A Linux implementation of LIG has been made available and
supported by Dave Meyer. It can be run on any Linux system supported by Dave Meyer. It can be run on any Linux system
which resides in either a LISP site or non-LISP site. See [LIG] which resides in either a LISP site or non-LISP site. See [LIG]
for details. for details. Public domain code can be downloaded from
http://github.com/davidmeyer/lig/tree/master.
13. An experimental implementation has been written for three
locator reachability algorithms. One is called echo-noncing,
which is documented in this specification. The other two are
called TCP-counts and RLOC-probing, which will be documented in
future drafts.
If interested in writing a LISP implementation, testing any of the If interested in writing a LISP implementation, testing any of the
LISP implementations, or want to be part of the LISP pilot program, LISP implementations, or want to be part of the LISP pilot program,
please contact lisp@ietf.org. please contact lisp@ietf.org.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
skipping to change at page 57, line 33 skipping to change at page 59, line 33
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-03.txt (work in progress), draft-meyer-lisp-cons-03.txt (work in progress),
November 2007. November 2007.
[DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
Algorithms for DHTs: Some Open Questions", PDF Algorithms for DHTs: Some Open Questions", PDF
file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00.txt (work in progress),
November 2007.
[GSE] "GSE - An Alternate Addressing Architecture for IPv6", [GSE] "GSE - An Alternate Addressing Architecture for IPv6",
draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.
[INTERWORK] [INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-00.txt (work in progress), draft-ietf-lisp-interworking-00.txt (work in progress),
January 2009. January 2009.
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
skipping to change at page 58, line 7 skipping to change at page 60, line 12
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-MAIN] [LISP-MAIN]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress), draft-farinacci-lisp-12.txt (work in progress),
March 2009. March 2009.
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
in progress), July 2009.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-01.txt (work in progress), May 2009. draft-ietf-lisp-ms-01.txt (work in progress), May 2009.
[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP1) [Routable ID "Locator/ID Separation Protocol (LISP1) [Routable ID
Version]", Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
October 2006. October 2006.
[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
 End of changes. 37 change blocks. 
77 lines changed or deleted 172 lines changed or added

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