about draft-ietf-shim6-arch-00.txt
marcelo bagnulo braun <marcelo@it.uc3m.es> Thu, 22 September 2005 08:51 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Thu, 22 Sep 2005 08:51:26 +0000
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <2e827f49823a060e73e10d586b35e4db@it.uc3m.es>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
To: shim6 <shim6@psg.com>
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: about draft-ietf-shim6-arch-00.txt
Date: Thu, 22 Sep 2005 10:51:28 +0200
Hi, I know this draft is waiting for the solution to be more mature, but i would like to make some comments about some issues that may be interesting to address in later versions of this draft Section 2. Summary of Shim6 it is stated that The intention of this approach is to minimise the amount of change required to support dynamic locator agility in the protocol stack, and support dynamic locator agility as a negotiated endpoint-to- endpoint capability. An application can initiate a session with a remote host by using an entirely conventional lookup of the host's domain name in the DNS, and open up a session with the remote endpoint using one of its addresses as the destination address. The application can continue to exchange packets with this remote host for the duration of the session by continuing to use this destination address. If the local host subsequently opens up a new session with the same remote host, the same destination address may be used, or if the local host passes a reference to a third party as a referral, the same destination address may be used. In terms of semantics and functionality this represented no change to the use of addresses as endpoint identifiers in the IPv6 architecture. I think that after this paragraph and before the next one, it should be stated somehow that the shim association is established using some form of signaling handshake. I mean, in this paragraph it is stated that the communication is established as a regular IP communication and in the next paragraph it is described bow the shim processes the packets, changing the identifiers per locators and the other way round. I think that it would be clarifying to state that at some point in time, some heuristics (TBD) trigger the establishment of the shim association, so that the ongoing application session can benefit from the multihoming capabilities. This results in the shim handshake performance and the creation in each of the endpoints of the necessary shim state and so on. The next paragraph states that: Shim6 operates as a per-host header address mapping function. I am not sure what do you mean by per-host here... I think that one of the issues along the document is that a per host-pair granularity of the shim state is assumed. I think this is not so, and that the shim state granularity would be per ULID-pair. IMHO this is a consequence of the design choice that any address can be used as ULID. Because of that, any application can select any of the available addresses to be used as ULIDs for a communication. This results that two communications between the same pair of endpoints can use different ULIDs and this would imply having two different shim associations and their respective shim state. The difficulty with this point is even more clear at the last section, so i will comment more on this later. Then the paragraph continues with When the Shim6 locator mapping function is activated for a remote endpoint packets passed from the IP endpoint sub-layer to the shim sub-layer have the packet's headers source and destination addresses rewritten with the currently selected locator pair. Incoming packets passed from the IP Routing sub-layer undergo a similar lookup using the locator pair. The locator pair is not enough imho and a demux tag is needed The packet header is rewritten with the mapped endpoint identifier pair is there is an active mapping entry. This functionality is indicated in Figure 2. Here the endpoint identities are referred to as Upper Layer Identifiers (ULIDs), and the packet header addresses are referred to as Locators (L). The Shim6 element contains a context state, associating a ULID pair (in this case the pair [ULID(A),ULID(B)] and a context tag i guess with a set of locators for A and a set of locators for B. The shim elements are synchronised such that then in section 4. Functional Decomposition 4.1 Establishing Session State ... In this case the selected source address, as seen by the upper level protocol stack element is the ULID of the stored state associated with the destination ULID. Otherwise the selected source address is a selected IP address from the set of addresses associated with the particular host interface that will be used to send the packet, as happens in a conventional IPv6 protocol stack. I would add "following the rules defined in RFC 3484" Later on... The local host to performs a name-to-address DNS lookup to obtain a set of locators (recorded in the DNS using AAAA resource records). The host then performs a selection from this set of locators I would add "following the rules defined in RFC 3484" and uses the selected address as the identification of the remote host. later on... Does the identity protocol element need to create a mapping from the upper level protocol's local and remote identity tokens into an identity token that identifies the session? If so, then is this translation performed before or after the initial session packet exchange handshake? This is an interesting question... I think that the demux tag or context tag would serve as a name for the association... depending on whether the the context tag is unique or is unique within those two ULIDs or two nodes, it maybe part of a name for the session. I mean, if the demux tag is unique, imho this is a name for the session, while if what is unique is the ULIDs, context tag, then it is part of the name of the session. In any case, imho the context tag plays a role in here. later on... The session initiator determines the ability of the remote end to support the Shim6 protocol via explicit negotiation. The Shim6 protocol will continue to operate in a conventional mode if the capability negotiation fails for Shim6 support. The nature of the communication exchange to determine the capability to use Shim6 support is not described in [ID.SHIM6]. this is described to some detail in the ID.FUNC reference. then... The initial choice of source and destination locators matches the initial choice of upper level identifiers, namely the initial addresses used as the upper level identifiers. The remote address is obtained using conventional DNS lookup. I would state that the DNS returns a list of locators and the node selects one of them using RFC3484 (i mean, since in the following phrase it is specified that RFC3484 is used for selecting the source address, i guess this should be here too) The local address is based on an address selection from the addresses associated with the outbound interface, using the procedure described in [RFC3484]. Then In section 4.2... The Shim6 documentation covers a number of options, but does not provide definitive answers to this question. The [ID.FAIL] notes four approaches: namely positive feedback from the upper level sessions, i would say "lack of positive feedback from the upper level sessions" negative feedback from the upper level sessions, explicit reachability tests i would say "failure of explicit reachability tests" and ICMP error messages. From the discussion in this draft it appears that negative feedback from upper layer transport sessions in the form of ACK timeouts is the preferred locator change trigger mechanism. funny how things change, but my current understanding is that people would prefer lack of positive feedback, rather than negative feedback (i guess this is why the completion of this doc should be left for when the work is almost finnish i guess :-) Later on... What triggers can be used to indicate the direction of the failed path in order to trigger the appropriate locator repair function? The [ID.FAIL] description does not provide a description of detection of the failed path. The Shim6 approach attempts to treat path failure as a failure of the locator pair, rather than failure of a single locator, so the direction of the failure is not necessarily critical information in the search for a new functional pair. I think that this changes with different failure detection mechanisms. I mean with FBD, the direction that failed is determined by the nature of the mechanism (i.e. the failure is always in the incoming direction of the node that detects the failure) An issue that i think that is relevant and it is related to this is the relationship between which endpoint detects the failure and which endpoint has to do something to repair it. I mean, in FBD, a node detects a failure in its incoming path, so the one that needs to do something to repair it is the peer. So, in this case, we need in addition, a reliable mechanism to communicate the existence of a failure from the peer that has detected the failure to the peer that can do something to repair it. Later on in section 4.3... Must a change of an egress site exit router be accompanied by a change in source and / or destination locators? This appears to be an area for further study. The situation is not explicitly addressed in the Shim6 documentation. I think that while this is an area for further study, as mentioned here, it is clear that for now, the design of the shim assumes that a change in the locator pair used implies a change in parts of the path used, so that changing the locator pair may result in using an alternative working path. I think that it is good to note that this assumption relies in very different mechanisms for the source and the destination addresses. For destination address, this assumption is based on the usage of PA addresses, so changing the destination address would result in changing the ingress ISP to the destination. In the case of the source address, this assumption is based in that the ingress filtering compatibility must be provided somehow, which implies that a packet with a source address of a given ISP will be forwarded through that ISP (to guarantee ingress filtering compatibility), so that changing the source address results in changing the exit isp. So, i agree that the actual mechanisms are not defined yet, but i would say that the shim is assuming that some mechanisms will be i place to make sure that changing the src/dst address would result in different exit/ingress paths Later on in section 4.4... The preconditions necessary is that there has been a successful establishment of packets between the two hosts, Shim6 capabilities have been successfully negotiated and locator sets have been exchanged, and there is an explicit trigger for a locator change that has been generated by an active transport session. IN addition reception of a packet where the locator par is a member of the locator set for this host pair implies a remotely-triggered locator change. I am not sure this so straight forward. I mean, how would this behaviour affect the case of unidirectional path availability. I mean, consider the case where only two different unidirectional paths are available (so that packets in one direction must carry different locators that packets in the other direction). If this behaviour is used, then this communication would fail, since peers would always be changing of locator pair, upon the reception of a packet from the other end having a different locator pair Then... How can the locator change be confirmed by both ends? I think i don't understand this question... The approach proposed here is by using a return reachability test, where a host searches through locator pair selections until it receives an explicit acknowledgement of a poll. But the reachability exchange is not used to confirm that both nodes can use a give locator pair, but to confirm that packets sent by one peer are received by the other. I mean, we are considering the possibility that the different endpoints use different locator pairs in the different directions of the communication... but perhaps i am missing something In Section 5. It may also be useful to allow the upper level protocol to explicitly indicate that any form of L3 functionality should not be applied to this session. The implication of this functionality is that incoming packets need to provide some form of positive indication that the incoming locator pair should be mapped to an equivalent ULID pair, while packets without this indication should be processed in a conventional fashion with any Shim6 packet header mapping. The Shim6 documentation suggests that some form of explicit tagging should be performed in the IPv6 Flow Id field, but further details have not been provided. I think that there are, at least, three different issues addressed here: - first we have the context tag issue i.e. the need for a context tag that allows to demux shim packets having the same locators but belonging to different shim contexts - second we have "the shim bit" which is a bit to differentiate shim data packets from non-shim data packets. this is not clear that is needed (my understanding is that this is basically needed when we want to be able to detect context loss). The possibility for this is to use a virtual bit defining new extension headers values - third, the need to have some packets or some communications not to use the shim or parts of the shim. For this, i think that, if we want that two apps use the same address pair and one uses the shim and the other don't, then we may need the shim bit... But in any case, i think that these are three different issues that may be good to explicitly differentiate. Later on... The potential use of unreachable ULIDs as the initial choice of ULIDs and the consequent requirement to undertake a reachable locator search, capability negotiation and establishment of a Shim6 mapping state is mentioned in the Shim6 documents, but at a relatively abstract level. This requires further consideration in terms of the potential failures, and the appropriate signalling to be passed back to the ULP in such cases. I think that an issue that is somehow related with this and that it may be interesting to discuss, is what happens when the initial address that is supposed to be used as ULID and as locator for initial packets is unreachable. We have so far discussed two possibilities for dealing with this: let the application retry, or let the shim deal with this (this last thing is what would be needed if we want to support ULAs as ULIDs) later on... The issue of ambiguity of demultiplexing may require further consideration. If there are multiple AAAA resource records in the DNS, or the resource records change over the lifetime of active communication, it is possible to have multiple Shim6 states set up for the same remote host, with distinct ULIDs for the remote host. Well, as i understand this can happen for other reasons than changes in the DNS records. As i mentioned earlier, imho this can happen simply because the different apps running between two nodes choose different address pairs as ULIDs for a given communication. In this case, we would end up having multiple shim sessions between the same two hosts, each one with different ULIDs pairs. The underlying point here imho is that the shim session granularity would be per ULID pair rather than per host pair. An incoming packet with a given locator pair will, according to the Shim6 documentation, need to use the locator pair as a lookup key I guess that the locator pair is not enough in this scenario to work as a key. I guess that the context tag is also needed in this. into the Shim6 state information to establish the associated ULID pair. In the case of multiple active ULIDs for the same remote host this lookup will result in multiple ULIDs. The treatment of trigger conditions for locator change also requires further consideration. As noted in [ID.ARCH], different upper level transports may have different sensitivity requirements to locator triggers. When the mapping is performed on a host-by-host basis Imho mapping would be in a ULID pair basis, rather than in host basis. This won't solve this particular issue, but anyway... In addition, perhaps a comment about possible ways for detecting the loss of shim state by one of the peers may be relevant here.... Editorial Section: Notes The document provides am architectural description of the approach, using the framework described in the multi-homing architecture document. s/am/an Section 2. Summary of Shim6 The shim layer provider a set of associations between endpoint identity pairs and locator sets. s/provider/provides Section 2. The packet header is rewritten with the mapped endpoint identifier pair is there is an active mapping entry. ^^ s/is/if Section 2. At this level of the protocol stack there is no information to indicate wither this packet is a single datagram, or the start of an extended packet exchange with a remote entity. s/wither/whether Section 4.4. IN addition reception of a packet where the locator par is a member s/IN/In Section 5 The signalling interface between the Shim6 and the upper layers pf the protocol stack requires further consideration. s/pf/of References [ID.FAIL] Arkko, J., "", Work in progress: Internet Drafts draft-arkko-multi6dt-failure-detection-00.txt, January 2005. The tittle is missing Regards, marcelo
- about draft-ietf-shim6-arch-00.txt marcelo bagnulo braun