[Trigtran] TRIGTRAN protocol principles and considerations

The following is a writeup on TRIGTRAN protocol considerations
and principles that Spencer, Alper and I put together.  It is
a draft writeup that we are looking to include in the TRIGTRAN
framework/requirements internet-draft that I spoke of a few weeks
ago.

Please review over these principles/considerations and please
send out comments/questions to the alias.  Your help is
very much encouraged.  

Thanks....  Carl (for Spencer and Carl)

TRIGTRAN Protocol Principles/Considerations 
=========================================== 

* Transports can request trigger coverage from any access router, 
although only TRIGTRAN-aware access routers will provide trigger coverage. 

* Correspondent hosts must request trigger notifications explicitly (they 
will not be sent without prior arrangement). 

* Trigger coverage requests and notification requests will be piggy-backed 
on existing traffic ("setting a bit"). 

* The trigger notification itself will be injected by a TRIGTRAN-capable 
access router. The exact structure of the notification is TBD. 

* Triggers are per-host-pair over a specified interface - if any 
host's transport requests trigger coverage for any packets destined 
for a correspondent host, and the correspondent host expresses interest 
in receiving triggers, the TRIGTRAN-capable access router will send a 
single notification to the correspondent host. 

* No reliability mechanism for triggers is defined. If a single trigger 
is lost for an event of interest to a transport, the transport will respond 
to the event using end-to-end mechanisms. 

* TRIGTRAN registrations can be installed in one round trip (from the point 
of view of the host adjacent to a TRIGTRAN-capable access router. 

* TRIGTRAN registrations install "soft state". Transports requesting 
trigger coverage must repeat this request periodically, and correspondent 
hosts requesting trigger notifications must repeat this request 
periodically. The periodicity for these requests is TBD, but should be on 
the order of five minutes. The TRIGTRAN-capable access router will expire 
these requests after three request periodicity time periods have elapsed. 

* TRIGTRAN should work even if both ends are served 
by TRIGTRAN routers. Of course, each TRIGTRAN-capable access router 
will send triggers to the "correspondent host" adjacent to the other access 
router. 

* TRIGTRAN is not a substitute for end-to-end mechanisms. TRIGTRAN triggers 
must be advising the correspondent host on SOMEthing! 

* TRIGTRAN is transport independent. With two different transports 
running over some link only one trigger will be sent for a particular
event. 

* TRIGTRAN coverage can be requested by a correspondent node for an IP
multicast 
address. The correspondent host is responsible for any response it makes to 
triggers arriving for multicast IP addresses. 

* Protocol notification message must contain enough information 
to identify per-host-pair. 

* Correspondent hosts may request trigger notification termination 
explicitly. 

* Trigger notifications are injected when a specified event 
is detected by the link-layer by the TRIGTRAN router for 
a specified link. 

* A correspondent node may ignore a notification even though it 
may have requested trigger coverage for a peer. 

* "Soft-state" for a per-host-pair should exist only at the 
adjacent TRIGTRAN router only. 

* When TRIGTRAN notifications and end-to-end mechanisms are 
in conflict the latter will take precedence over notifications. 

* Triggers should be link-layer independent. 

* Each TRIGTRAN notification will carry information for one event 
only. The correspondent node should be able to determine by 
an appropriate identify field what event has taken place.  

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran