Excerpts from Brian E Carpenter on Wed, Feb 18, 2009 01:58:26PM +1300: > Probably useful to state that this is layer 4. I understand that over > at the ITU-T they have changed the meaning of the word 'transport' to > mean layer 2 (presumably in an effort to forget about OSI).
They forgot about OSI years ago. For a good time see http://www.itu.int/rec/T-REC-Y.110/en on roles and "added value", http://www.niven-jenkins.co.uk/An%20introduction%20to%20functional%20architecture.pdf, and http://www.itu.int/rec/T-REC-Y.2611/en for functional architecture. For example in Y.2611 (where "identifier" is a more-generic including both "name" and "address"): Identification is required in each layer network of the NGN transport stratum. A given entity will be assigned one or more identifiers depending on the function of that entity. FPBN layer network identifiers are independent of any client (and any server) layer network identifiers even if they share the same syntax or structure. At the boundary of a layer network, mapping and/or translation mechanisms are required in order to set up relationships between the identifier used by the client layer network and the identifier used by the server layer network. NOTE – Identifiers could be determined from multiple discontinuous fields. The global uniqueness of an identifier may be provided by the context as well as the identifier itself. Whether a given identifier is considered to be a name or an address is dependent on several factors including the perspective (and location) of the entity that is using (or mapping to) that identifier. The same identifier can be considered an address to one entity and a name to a different entity because their perspective is different. > > The consensus of the > > group is that such site renumbering is a completely unacceptable > > requirement and as such, these types of solutions are not of interest > > for further exploration. > > Mild rewrite as > > The consensus of the > group is that such site renumbering is widely unacceptable for > operational reasons and thus, these types of solutions are not of > interest for further exploration in this group. +1 > > 3.1.2. Translation > > Reading further, it occurred to me that this really should > be called Map & Translate I don't see why. Suppose I'm doing GSE. I have a simple algorithm for swapping the upper bits of an address field, and the algorithm is always the same. Is that really mapping? I don't know of any proposals that do actual mapping and then translating. > , and that we should distinguish > stateful and stateless translation. > > Also distinguish reversible and non-reversible translation. Yes > It would be good if this and the following section brought out > the isomorphisms and differences between translation and > encapsulation very clearly. Yes > (NAT is just swapping RLOC and EID, for example, but NAPT is > munging EIDs together before doing the swap.) I don't know what you mean, munging EIDs together. Do you mean that it uses pieces from different headers? Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
