Subject: [Softwires] Fwd: New Version Notification for draft-despres-softwire-mesh-sam-01

From: Rémi Després <[email-masked]>
Date: Tue, 27 Oct 2009 09:26:05 +0100

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-masked]>
> Date : 26 octobre 2009 20:53:37 GMT+01:00
> À : [email-masked]
> 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