[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NSIS] NSIS applicability mobility
Hello Sung-Hyuck,
after reading version 01 of the mobility applicability draft, I'm having a couple of questions and comments.
General
The document may assume specific scenarios in some cases without mentioning them explicitely:
- "mobility" means roaming, automated handover or
seamless handover?
- "hand over" is resulting in resource reservation
at new AR prior to hand over or after it or both
(make before break, I assume)?
- Multihoming is restricted to the moving MN. A
CN may be multihomed as well.
- Load Balancing is done on a per packet or on a
per flow basis?
- Are reservations unidirectional or bidirectional?
Consequences of new CoA, multihoming and load balancing should be discussed in more detail. There may be multiple CRNs in p- or downstream direction. The CN/HA may be the U/DCRN (MN inter-domain HO with changed CoA and multihomed CN).
Interoperation of NSIS and tunneling protocols may require a separate draft or at least a statement (e.g. reference to a DiffServ and tunnels RFC).
In some instances (e.g. 5.3, 5th section) there seems to be a special message setting up state in some nodes along the new path, but not end to end. Then a refresh is sent. Is there any new refresh mechanism?
The "Ping-Pong" scenario is interesting. The idea to let the old and the new flow share the same reservation for a while may be useful. The known processing and communication delays resulting from coupling of MIP to NSIS should be discussed. Am I right that the MN starts to reserve resources after the binding update? The last element to learn of the binding update seems to be the UCRN and the network elements towards the MN behind it.
The draft mentions SEAMOBY in 5.5. As SEAMOBY could improve HO speed, I'd suggest to have a separate draft on it, but leave it out of this document.
The Security discussion is worrying. Does the author assume that standard NSIS behaviour must be authorised? My perception is, that "service access" is authorised, and reservation modifications may have to be re-authorised. I'm nor convinced whether re-establishing QoS after mobility and path tear are actions requiring authorisation (getting a new CoA must be authorised). The author should assume application signaling to be present.
The release of old resources along a path should use Session ID and old Flow ID. So no new resources are removed. This would mean, that also the NOTIFY message has to carry this information (if created by DCRN).
5.4 discusses an RSN race issue which can't be maintained. The RSN is a bilateral matter only, so one RSN always only refers one message.
Regards, Rüdiger
Rüdiger Geib
T-Systems International GmbH
Senior Expert
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services
Packet based Carrier Transport Networks
Deutsche-Telekom-Allee 7, D-64295 Darmstadt
Fon: +49 6151 937-2138
http://www.t-systems.com
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis