Issue comes from colip-BoF (new protocol)

[Hiroshi Esaki <[e-mail]>]

Hi all, 

The following the breif discussion about a new protocol 
associatd with efficient pakcket transport over the connection 
oriented data-link platform. 
  

** When this issue is just a noise for you, please ignore this 
** mail and please let me say sorry to you. 


  (3) New protocol associated with the efficient interaction 
      between transport/network layer and connection-oriented 
      data-link platform (e.g. Frame Relay or ATM).
          --> related with int-serv, rolc and ipoveratm 


The followings are the benefits of having a routers (conventional 
model and RFC1577 model), compared to large cloud data-link without 
router.  Of course, the large cloud networks without router can 
be interconencetd by the routers. 

  (a) Soft-state path (dynamic path changing during a session) 
       --> router can easily change the packet forwarding path 
  (b) QoS/Flow-spec changing during a session 
       --> router can easily change the corresponding data-link pipe 
           that the packet flow uses 
  (c) Flow aggregation 
       --> how to aggregate IP packet flows into a data-link pipe 
           can be router's decision  
  (d) Scalable soft-state (i.e. RSVP-type) multicast 
       --> merging (aggregation) of control messages
  (e) Security (e.g. fire-wall) function 

When we can provide a cut-thru routers using data-link level 
pipe identifier, we will be able to obtain the further benefits from the 
cut-thru routers. 
Here, the meaning of the data-link level pipe identifier corerspnds 
to time-slot in TDM (telephone networks) networks or VPI/VCI in ATM networks. 

  (i) High performanced packet forwarding 
         By the bypassing the examination of IP packet header to forward 
         the packets, we could obtain high performanced packet forwarding. 
  (ii) IP address encrypted packet forwarding 
         For the cut-thru-ed packet flow, IP addresses in the packet header
         is basically meaningless from the view point of packet forwarding. 
         Therefore, we could encypt the IP header field, when we use 
         cut-thru packet forwarding.  
         On example is the packet transmission between the certain sites. 
         In some cases, we do not want to allow to be able to see the 
         IP addresses of the individual packets between the sites, through 
         we can allow the packets are exchanged between the sites.  This 
         is the resolution level of packet exchange.
  (iii) High performed firewall function 
         When we introduce resource reservation oriented packet flow, 
         some flows will require security check only when the pakcet flow is 
         established (not packet-by-packet security check).  
         For these flows, the cut-thru router provide a high performed 
         packet transmission. 

Additional protocol and messages are neede to provide a efficient 
cut-thru router effectively.  
When the neighbor router knows the informatin how to the packet flows 
are mapped into the data-link pipes, the neighbor router will easily 
optimize the packet forwarding.
For example, when the up-stream router aggregate the IP packet flows whose 
QOS class is the same into a single data-link pipe and the down-stream 
router (having multi-processors) knows it, the down-stream router 
can easily dispatch the received packets based on data-link level 
pipe identifier (not by IP pakcet header). This is one example of 
optimizatin.   
Or, for exmaple, when the up-stream router aggregate the IP packet 
flows based on the destinatin addresses (e.g. having the same destination 
subnet), the down-stream router can foward the aggregated packet flows 
by cut-thru (without seeing the IP pakcet header). 

Typical and easiest configuration would be ; 
   (a) ATM transmission over digital link (SONET). 
   (b) FR transmission over digital link (SONET). 
The data-link clouds using ATM or FR are interconnected 
by the digital links (SONET pipes).  In this case, how to use 
data-link pipe identifier is completely free (depend on router's 
decision). 


As a result, I want to discuss whether the protocol to provide a 
optimization chance for the router, when the data-link platform 
is connection oriented, is worth to be defined.  
If people think it is worth to be defined, let's discuss this. 
I beleive that this protocol is useful when the data-link platform 
is connection oriented and whether data-link is large cloud or 
small cloud is not the issue.   


Best regards, 

Hiroshi Esaki 
c/o CTR, Columbia Univ.