[RRG] RE: [RAM] application endpoint identifiers in map-and-encaps schemes

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Louise,

Thanks for this, and you are certainly correct that an address
is ultimately assigned to an *interface*; not an application, or
a node, or etc. That point doesn't come across well in the text,
but I think I see a way clear to fix it and your feedback has
helped.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: louise.burness@bt.com [mailto:louise.burness@bt.com] 
> Sent: Monday, March 19, 2007 10:28 AM
> To: Templin, Fred L; rrg@psg.com; ram@iab.org
> Subject: RE: [RAM] application endpoint identifiers in 
> map-and-encaps schemes
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Mon 19/03/2007 14:03
> To: rrg; ram@iab.org
> Subject: [RAM] application endpoint identifiers in 
> map-and-encaps schemes
>  
> During the RRG meeting on Saturday, Lixia presented a slide
> suggesting that not only locators and identifiers are desired,
> but also a possible separation in the identifer in terms of
> what the physical interface of the end node sees and what the
> *application endpoint* within the end node sees. 
> 
> [alb]i see that node, network and interfaces all might have 
> identifiers and locators. it seems that some people also see 
> separate spaces depending on role as "edge" or "user". These 
> all could have global or local scope, be transient or 
> intransient. The trick is to decide the minimal set that you 
> can get away with. I think a lot of proposals on loc/id split 
> often have a node id that is used as an application 
> endpoint,and that is intransient (doesn't need to change to 
> keep the network running) and a locator that maps to the 
> physical presence on the net - the interface locator, or an 
> end network that can then recah the device. 
> 
> I interpret
> this as follows:
> 
>  - let locators be assigned to the tunnel interfaces of
>    ingress/egress tunnel routers
>  - let *node* identifiers be assigned to the physical
>    interfaces of end systems
>  - let *application* identifiers be assigned to virtual
>    interfaces (e.g., loopback interfaces) within end
>    systems
> 
> This could allow for the Ethernet-to-WiFi handoff Lixia referred
> to in her slide with no need to readdress the application endpoint
> identifiers, since only the node identifier changes.
> 
> [alb] careful of terminology as you will ofetn find node id 
> used to mean application endpoint id in much of the literature
> 
> The following text from (IPvLX, Section 3) speaks to this:
> 
> "3.  Addressing and Routing Assumptions
> 
>    While IPv4 addresses in the current Internet are typically assigned
>    to devices, IPvLX assumes that IPv6 addresses will also be assigned
>    to application endpoints and data objects [NAME].  This new model
>    would provide greater flexibility such that each end-node 
> might host
>    many different IPv6 application endpoints and data 
> objects, and that
>    those entities could migrate to other end-nodes.  In this 
> model, each
>    IPv6 addressable entity would access other endpoints via an IPv6
>    router."
> 
> [alb] I think an IP address actually is assigned to the 
> interface to a node.An ethernet address can be considered the 
> ID of that interface. at a local level that ID can be used to 
> discover a path.
> 
> Fred
> fred.l.templin@boeing.com
> 
> _______________________________________________
> RAM mailing list
> RAM@iab.org
> https://www1.ietf.org/mailman/listinfo/ram
> 
> 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg