>From: Tony Li [mailto:[EMAIL PROTECTED] >Hi Lan, >|> If we go down the path of map-&-encap, we're effectively deciding to
>|> run on top of a connection oriented infrastructure. >| >|Could you clarify your last sentence? It's unclear to me how map-&- >|encap and connection-oriented infrastructure are related here ... > >In a map-&-encap system, you basically end up with a series of tunnels >(connections) between xTR's that form the connection-oriented infrastructure. >You're then running your packet switching on top of it and you can >no longer do native layer packet switching. I'm not following this part of your insight, Tony. I suspect that you are using "connection oriented" incorrectly. Map-and-encaps introduce an intermediate source and destination that comprise a tunnel. Entities that use that tunnel view the potentially multi-hop tunnel as being a single hop. Connectionless packet switching indeed occurs across these tunnels but it also can occur within them as well (e.g., ESP in tunnel mode, IP-IP, GRE, military COMSEC). By contrast, people of our generation who went through numerous circuit switching-versus-packet switching wars find the term "connection-oriented architecture" very emotive. Are you trying to play off of that emotion in this instance? Regardless, true connection-oriented architectures always historically did resource reservation and path establishment before a session is created. In this case, however, sessions don't exist at all (unless they were created by other means (e.g., HIP)). True, it does have (partial) path establishment but definitely not resource reservation. Lacking sessions it can't be a connection-oriented system in my book. Rather, it is something else entirely: a "worm hole" within a connectionless world. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
