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

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 07:03:07 -0700

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. 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.

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."

Fred
[email-masked]

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: <[email-masked]>
Date: Mon, 19 Mar 2007 17:28:15 -0000

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]]
Sent: Mon 19/03/2007 14:03
To: rrg; [email-masked]
Subject: [RAM] application endpoint identifiers in map-and-encaps schemes
 
*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:

[alb] careful of terminology as you will ofetn find node id used to mean application endpoint id in much of the literature

[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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 10:40:33 -0700

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 10:28 AM
> To: Templin, Fred L; [email-masked]; [email-masked]
> Subject: RE: [RAM] application endpoint identifiers in 
> map-and-encaps schemes
> 
> 
> 
> 
> 
> [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:
> 
> [alb] careful of terminology as you will ofetn find node id 
> used to mean application endpoint id in much of the literature
> 
> [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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Mar 2007 20:24:48 +0100

> identifiers, since only the node identifier changes.

Hm, applications have their own ideas on identification. For  
instance, the HTTP protocol carries a hostname in-band. This has  
several nice properties, including the one that you can run several  
HTTP servers on a single IP address / port number combination.  
Another is that the application identifier is exchanged once per  
session  rather than once per packet. It's important to limit what's  
in packets to what actually needs to be there. And that's basically  
only demultiplexing information. From that, session state can be  
recovered, which can include several identifiers per layer of the  
stack if desired.

And is it just me or does it look like we're slowly but surely trying  
to reinvent CLNP? There your address (oh wait: NSAP) isn't tied to a  
single interface but rather to the host in general. This does of  
course mean that even local communication requires a router and you  
need a host-to-router routing protocol.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Mar 2007 14:04:12 -0700

Iljitsch, 
  
> single interface but rather to the host in general.

Umm - no. I specifically want that addresses be assigned to
*interfaces* (not nodes, file systems, data bases, etc) as
I said in my message to Louise. The text will be fixed.

Fred

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Mar 2007 12:14:00 +1100

At 06:24 AM 20/03/2007, Iljitsch van Beijnum wrote:
>Hm, applications have their own ideas on identification.

When you start to consider "identifiers" in a general sense there is 
the appreciation that we have managed to devise "identities" almost 
everywhere: multi-party applications, application agents, rendezvous 
protocols, DNS indirection and referral, mobility protocols, SHIM6, 
SCTP, HIP,  TCP, etc

There is no single 'identity" - there are a plethora of such 
identities today groupd within a large set of 'realms' of identity, 
and I believe that they are an enduring aspect of this environment. 
This does not lead me to a "we are heading to a CNLP-liker 
destination" conclusion, as there is no single useful encompassing 
identifier here, nor do I see any use of value in trying to construct 
such a beast! As far as I can see there are, and will be, many forms 
of identity and are, and will be, many ways to map between various 
identity realms at various levels in the protocol stack.

regards,

     Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 20 Mar 2007 13:22:30 +0100

I agree with Fred on having addresses associated to interfaces.

Identifier need just to indentifity the host. The demultiplexing in  
upper layers, toward the application, should be an issue tackle in  
that layers.

nevertheless, a node (i.e. an ID) can be reached through several  
interfaces (if the general case where a node is multihomed)

what if we use a relation between ID, interface and IP address,  
something like:

ID @ interface = IP address

Meaning that the ID and the interface, through which we want to reach  
the ID, gives us an IP address, or viceversa, an IP address gives us  
the ID and the interface (kind of reverse lookup).

  Regards

Luigi

Le 20-mars-07 à 02:14, Geoff Huston a écrit :

> When you start to consider "identifiers" in a general sense there  
> is the appreciation that we have managed to devise "identities"  
> almost everywhere: multi-party applications, application agents,  
> rendezvous protocols, DNS indirection and referral, mobility  
> protocols, SHIM6, SCTP, HIP,  TCP, etc
>
> identifier here, nor do I see any use of value in trying to  
> construct such a beast! As far as I can see there are, and will be,  
> many forms of identity and are, and will be, many ways to map  
> between various identity realms at various levels in the protocol  
> stack.
>
> regards,
>
>     Geoff
>
>
>
>
>