draft-ietf-lisp-ms-10.txt   draft-ietf-lisp-ms-11.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: January 8, 2012 July 7, 2011 Expires: March 2, 2012 August 30, 2011
LISP Map Server LISP Map Server
draft-ietf-lisp-ms-10.txt draft-ietf-lisp-ms-11.txt
Abstract Abstract
This draft describes the LISP Map Server (LISP-MS), a computing This draft describes the LISP Map Server (LISP-MS), a computing
system which provides a simplified LISP protocol interface as a system which provides a simplified LISP protocol interface as a
"front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC)
mapping database and associated virtual network of LISP protocol mapping database and associated virtual network of LISP protocol
elements. elements.
The purpose of the Map Server is to reduce implementation and The purpose of the Map Server is to reduce implementation and
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2012. This Internet-Draft will expire on March 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 4, line 46 skipping to change at page 4, line 46
of EID-prefixes to register, the message includes one or more of EID-prefixes to register, the message includes one or more
RLOCs to be be used by the Map Server when forwarding Map-Requests RLOCs to be be used by the Map Server when forwarding Map-Requests
(re-formatted as Encapsulated Map-Requests) received through the (re-formatted as Encapsulated Map-Requests) received through the
database mapping system. An ETR may request that the Map Server database mapping system. An ETR may request that the Map Server
answer Map-Requests on its behalf by setting the "proxy-map-reply" answer Map-Requests on its behalf by setting the "proxy-map-reply"
flag (P-bit) in the message. flag (P-bit) in the message.
Map-Notify message: a LISP message sent by a Map Server to an ETR Map-Notify message: a LISP message sent by a Map Server to an ETR
to confirm that a Map-Register has been received and processed. to confirm that a Map-Register has been received and processed.
An ETR requests that a Map-Notify be returned by setting the An ETR requests that a Map-Notify be returned by setting the
"want-map-notify" or "M" bit in the Map-Register message. "want-map-notify" or "M" bit in the Map-Register message. Unlike
a Map-Reply, a Map-Notify uses UDP port 4342 for both source and
destination.
For definitions of other terms, notably Map-Request, Map-Reply, For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
consult the LISP specification [LISP]. consult the LISP specification [LISP].
3. Basic Overview 3. Basic Overview
A Map Server is a device which publishes EID-prefix information on A Map Server is a device which publishes EID-prefix information on
behalf of ETRs and connects to the LISP distributed mapping database behalf of ETRs and connects to the LISP distributed mapping database
system to help answer LISP Map-Requests seeking the RLOCs for those system to help answer LISP Map-Requests seeking the RLOCs for those
skipping to change at page 9, line 9 skipping to change at page 9, line 9
seconds. This "quick registration" period is limited to five minutes seconds. This "quick registration" period is limited to five minutes
in duration. in duration.
An ETR may request that a Map Server explicitly acknowledge receipt An ETR may request that a Map Server explicitly acknowledge receipt
and processing of a Map-Register message by setting the "want-map- and processing of a Map-Register message by setting the "want-map-
notify" ("M" bit) flag. A Map Server that receives a Map-Register notify" ("M" bit) flag. A Map Server that receives a Map-Register
with this flag set will respond with a Map-Notify message. Typical with this flag set will respond with a Map-Notify message. Typical
use of this flag by an ETR would be to set it for Map-Register use of this flag by an ETR would be to set it for Map-Register
messages sent during the initial "quick registration" with a Map messages sent during the initial "quick registration" with a Map
Server but then set it only occasionally during steady-state Server but then set it only occasionally during steady-state
maintenance of its association with that Map Server. maintenance of its association with that Map Server. Note that the
Map-Notify message is sent to UDP destination port 4342, not to the
source port specified in the original Map-Register message.
Note that a one-minute minimum registration interval during Note that a one-minute minimum registration interval during
maintenance of an ETR-MS association does set a lower-bound on how maintenance of an ETR-MS association does set a lower-bound on how
quickly and how frequently a mapping database entry can be updated. quickly and how frequently a mapping database entry can be updated.
This may have implications for what sorts of mobility can supported This may have implications for what sorts of mobility can supported
directly by the mapping system. For a discussion on one way that directly by the mapping system. For a discussion on one way that
faster mobility may be implemented for individual devices, please see faster mobility may be implemented for individual devices, please see
[LISP-MN]. [LISP-MN].
An ETR may also request, by setting the "proxy-map-reply" flag An ETR may also request, by setting the "proxy-map-reply" flag
skipping to change at page 16, line 15 skipping to change at page 16, line 15
8. References 8. References
8.1. Normative References 8.1. Normative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-07.txt (work in progress), June 2011. draft-ietf-lisp-alt-07.txt (work in progress), June 2011.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-14.txt (work in progress), June 2011. draft-ietf-lisp-15.txt (work in progress), July 2011.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
(work in progress), July 2011.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
skipping to change at page 16, line 49 skipping to change at page 17, line 5
[I-D.white-sobgparchitecture] [I-D.white-sobgparchitecture]
White, R., "Architecture and Deployment Considerations for White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)", Secure Origin BGP (soBGP)",
draft-white-sobgparchitecture-00 (work in progress), draft-white-sobgparchitecture-00 (work in progress),
May 2004. May 2004.
[LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Mobile Node Architecture", draft-meyer-lisp-mn-05.txt Mobile Node Architecture", draft-meyer-lisp-mn-05.txt
(work in progress), May 2011. (work in progress), May 2011.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt
(work in progress), June 2011.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08.txt (work in progress), draft-lear-lisp-nerd-08.txt (work in progress),
March 2010. March 2010.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Greg Schudel, Darrel Lewis, John
 End of changes. 7 change blocks. 
11 lines changed or deleted 15 lines changed or added

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