Dear all,
The draft below has been submitted to the Softwire WG.
Comments are most welcome.
Regards,
RD
Début du message réexpédié :
De : IETF I-D Submission Tool <[email protected]>
Date : 26 octobre 2009 20:53:37 GMT+01:00
À : [email protected]
Objet : New Version Notification for draft-despres-softwire-mesh-
sam-01
A new version of I-D, draft-despres-softwire-mesh-sam-01.txt has
been successfuly submitted by Remi Despres and posted to the IETF
repository.
Filename: draft-despres-softwire-mesh-sam
Revision: 01
Title: Stateless Address Mapping (SAM) - Mesh Softwires without e-
BGP
Creation_date: 2009-10-26
WG ID: Independent Submission
Number_of_pages: 28
Abstract:
SAM is a generic and simple mechanism for packets having addresses in
a family IPvX to traverse routing domains where this address family
is not directly routed.
SAM topological scenarios are those of Mesh Softwire, i.e. with point
to multipoint tunnels between border nodes of interior routing
domains. In the mesh-softwire context, SAM differs from RFC 5565 in
that SAM uses no protocol between border nodes of the domain, and in
that customer border nodes don't need to maintain states for all
other border nodes. (RFC 5565 is based on an Exterior Border-Gateway
Protocol e-BGP between border nodes, with dynamic routing tables to
be maintained in all of them). SAM's address mappings are stateless,
based on only a few domain parameters. SAM is thus suitable to small
to medium enterprises, and small to medium ISPs, that cannot afford
e-BGP in all their border nodes. All combinations of IPv4 and IPv6,
global or private, are supported. Also, to mitigate consequences of
the IPv4 address shortage, SAM supports port-extended IPv4 addresses
(A+P).
The IETF Secretariat.
Table of Contents
1.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example
Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
2.1. A small ISP lacking enough global IPv4
addresses . . . . . 5
2.2. A small customer site having only a port-restricted
IPv4
address . . . . . . . . . . . . . . . . . . . . . . . 7
3. The SAM Model and its
Terminology . . . . . . . . . . . . . . 9
4. SAM functional sub-modules and their
parameters . . . . . . . 10
5. Mapping between SAM Interior Addresses and SAM interior
IDs . 13
5.1. SAM-interior-address
Formats . . . . . . . . . . . . . . . 13
5.2. SAM Interior Addresses and SAM Interior IDs in
IPv6 . . . 14
5.3. SAM Interior Addresses and SAM Interior IDs in
IPv4 . . . 15
6. SAM Prefixes and SAM Raw
Prefixes . . . . . . . . . . . . . . 16
7. Derivation of Sub-delegated prefixes from Delegated
Prefixes and Interior
IDs . . . . . . . . . . . . . . . . . . 19
8. Mapping from Source and Destination Endpoint Locators to
Source and Destination Interior
Addresses . . . . . . . . . . 20
8.1. Encapsulation
Function . . . . . . . . . . . . . . . . . . 20
8.2. Decapsulation
Function . . . . . . . . . . . . . . . . . . 21
9. Detailed Prefixes for the Example
Scenarios . . . . . . . . . 22
10. Applicability to other
scenarios . . . . . . . . . . . . . . . 24
11. Security
considerations . . . . . . . . . . . . . . . . . . . 24
12. IANA
Considerations . . . . . . . . . . . . . . . . . . . . . 24
13.
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
14.
References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative
References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative
References . . . . . . . . . . . . . . . . . . 25
Author's
Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
