11/18/021 endpoint name resolution protocol presenter: qiaobing xie email: [email protected]...
TRANSCRIPT
11/18/02 1
Endpoint Name Resolution Protocol
<draft-ietf-rserpool-enrp-04.txt>
Presenter: Qiaobing Xie Email: [email protected]
November 18, 2002
11/18/02 2
Changes made btw 03 and 04
allows PU to use TCP for name query and response
created separate msg type space for enrp
brought back the step-fathering mechanism to support auditing added back the three messages to signal a takeover.- PEER_INIT_TAKEOVER 0x7
- PEER_INIT_TAKEOVER_ACK 0x8
- PEER_TAKEOVER_SERVER 0x9
added home server stamp field (server ID) to PE param (in the comm-param draft)
each server now keeps two table: my PEs and others' PEs (not a MUST).
Server "owns" the PE when accepting its (re)-registration.
11/18/02 3
Changes made btw 03 and 04 (cont.)
added a new change-ownership message to say "I am now the new owner of these PE IDs of these pools"
added takeover procedures
after a successful takeover, all peer servers will need to seek out and re-stamp the affected PEs in their database.
added back a notify to PE: I am now your new home server (implicitly by sending a keep-alive to the PE)
added back periodic keep-alives to owe PEs (optional to use)
replaced "action code" in reg and de-reg response with new response message types.
added error msg format and text on handling unrecognized msg and params
11/18/02 4
Changes made btw 03 and 04 (cont.)
added auditing procedures back (pt. 1)
added “download only PE entries that you own” message for re-sync
Added re-sync algorithm: when mismatch with server B is found by server A, A will do:
1. “flag” anything belonging to B in its local database
2. tell B: “please download me a list of all PEs you own”
3. replace the PEs owned by B with the new copy received; and
4. remove the remaining "flagged" PEs.
11/18/02 5
To-do’s and open issues
to add auditing algorithm and procedures back (pt. 2). Randy has already provided base text
open issue: the use of multicast in peer discovery causes some security concerns. What to do with it?
1. Since the use of multicast is optional, we simply make clear(er) that “use multicast at your own risk”
2. Remove multicast entirely
3. Add some mechanisms to plug the security holes