Locator/ID Separation Protocol
|Document||Proposed charter||Locator/ID Separation Protocol WG (lisp)|
|Title||Locator/ID Separation Protocol|
|State||Internal review Rechartering|
|IESG||Responsible AD||Deborah Brungard|
|Charter Edit AD||Deborah Brungard|
Has a BLOCK. Has enough positions to pass once BLOCK positions are resolved.
|Send notices to||(None)|
The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol (LISP). LISP supports a routing architecture which decouples the routing locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The scope of the LISP technology is recognized to range from unicast and multicast overlays at Layer 2 as well as at Layer 3, including NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM), hence being applicable in both Data Centers and public Internet environments. The LISP WG is chartered to continue work on the LISP base protocol with the main objective to develop a standard solution based on the completed Experimental RFCs and the experience gained from early deployments. The work will include reviewing the existing set of Experimental RFCs and doing the necessary enhancements to support a base set of standards track RFCs. The group will review the current set of Working Group documents to identify potential standards-track documents and do the necessary enhancements to support standards-track. It is recognized that some of the work will continue on the experimental track, though the group is encouraged to move the documents to standards track in support of network use, whereas the work previously was scoped to experimental documents. Besides this main focus, the LISP WG may work on the following items: - Multi-protocol support: Specifying the required extensions to support multi-protocol encapsulation (e.g., L2 or NSH (Network Service Headers). Rather than developing new encapsulations the work will aim at using existing well-established encapsulations or emerging from other Working Groups such as NVO3 and SFC. - Alternative Mapping System Design: By extending LISP with new protocols to support, it is also necessary to develop the required mapping function and control plane extensions to operate LISP map-assisted networks (which may include Hierarchical Pull, Publish/Subscribe, or Push models, independent mapping systems interconnection, security extensions, or alternative transports of the LISP control protocol). - Mobility: Some LISP deployment scenarios include mobile nodes (in mobile environments) or Virtual Machines (VMs in data centers), hence support needs to be provided in order to achieve seamless connectivity. - Multicast: Support for overlay multicast by means of replication as well as interfacing with existing underlay multicast support. - Data-Plane Encryption: In some scenarios, it may be desirable to encrypt LISP encapsulated traffic. In this case, the data-plane encryption mechanism itself and support for control-plane security information exchange needs to be specified. - NAT-Traversal: Support for a NAT-traversal solution in deployments where a LISP xTR is separated from correspondent xTR(s) by a NAT (e.g., LISP mobile node). - Management models: Support for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components.
No milestones for charter found.