160 likes | 167 Views
NAT State Synchronization using SCSP draft-xu-behave-nat-state-sync-01. Dean Cheng (chengd@huawei.com) Xiaohu Xu (xuxh@huawei.com) Joel Halpern (Joel.Halpern@ericsson.com) Mohamed Boucadair (mohamed.boucadair@orange-ftgroup.com) IETF77, Anaheim. Changes made in 01.
E N D
NAT State Synchronization using SCSPdraft-xu-behave-nat-state-sync-01 Dean Cheng (chengd@huawei.com) Xiaohu Xu (xuxh@huawei.com) Joel Halpern (Joel.Halpern@ericsson.com) Mohamed Boucadair (mohamed.boucadair@orange-ftgroup.com) IETF77, Anaheim
Changes made in 01 • Added a paragraph in Section 1.2 to emphasize the use of the link state based algorithm • Added an editor’s note in Section 2.1 regarding the inclusion/exclusion of NAT44 • Minor editorial changes
SCSP – A Protocol for Data Cache Synchronization • Server Cache Synchronization Protocol (SCSP - RFC2334) solves a general server synchronization/cache-replication problem for distributed databases. • SCSP uses link-state based algorithm to reliably flood database entries among participating servers. • SCSP defines application-independent protocol mechanisms and requires applications to define their own formats for cache records, called Cache State Advertisement (CSA). • This document specifies a method of using SCSP to achieve NAT state synchronization among NAT devices in a redundancy group including associated CSA format.
Requirements for NAT Devices Deployed with Redundancy • Toachieve hot-standby, data synchronization is a MUST. • Reliability and robustness are very much desired during data synchronization process. • Stateful contents in data cache maintained by the primary NAT MUST be synchronized on all participating NAT devices in a redundancy group. • When a primary NAT device in a redundancy group fails, all existing NAT sessions must survive without any perceived impact on the traffic (e.g., severe delay, loss, etc.)
Use SCSP to Sync NAT Database • Multiple NAT devices deployed on the border between two IP domains form a redundancy group which, possibly along with other redundancy groups, belong to a SCSP Server Group (SG), identified by SGID. • Within a redundancy group, there is a primary and one or more backup devices. When the primary NAT device fails, a new primary NAT device will be elected. • For each NAT type, a separate SCSP Protocol ID (PID) is assigned by IANA. • Currently NAT type includes NAT44, NAT64, and NAT46. • The method described is applicable to stateful NAT only.
NAT State Refreshment Mechanism • Only the primary NAT device can create new cache entries. • NAT database entries are aged. The primary device is responsible to re-originate and re-flood them before aging out for active entries. • After a switchover, the newly elected primary NAT device MUST re-originate all cache entries that were originated by the previous primary NAT device, with NAT contents remain the same followed by a reliable flooding defined by SCSP.
Should NAT Synchronization be standardized? • There are some who believe there is no need to… • There have been proprietary implementations deployed. • But there are others who like to see a standard based synchronization mechanism for NAT. • These include some carriers too… • We feel that… • There will be more networks that need to deploy NAT in the next few years, where a standard based synchronization would be useful. • There are examples for co-existence of standards based protocols and proprietary protocols both deployed.
Should this draft include NAT44? • There are some who believe there is no need to… • There have been many proprietary handling for NAT44 synchronization. • But there are others (including some carriers) who like to see NAT44 synchronization also be standardized • There will be more NAT44 (e.g., DS-Lite) to be deployed… • We feel that… • It makes sense to include NAT44 if some that will deploy it. • But otherwise, we can take NAT44 out
Has SCSP been deployed? • It is true that there are not many applications that are based on SCSP today • There have been many proprietary handling for NAT44 synchronization. • But SCSP uses exact the same link state algorithm and mechanisms as in routing protocols including OSPF, IS-IS, which have been widely deployed… • …and the proposed NAT synchronization protocol uses the same algorithm and mechanism.
The Next … • If the WG thinks standardizing the NAT sync mechanism is useful, let’s add this work to the WG charter.
SCSP Message Mandatory Common Part • 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | Server Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender ID Len | Recvr ID Len | Number of Records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Sender ID (Variable Length) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Receiver ID (Variable Length) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values for the SCSP “Mandatory Common Part” • Protocol ID = TBD • There is a separate Protocol ID for NAT44, NAT64, and NAT46, assigned by IANA. • Server Group ID = NAT device redundancy group ID • Sender ID Len • = 4, if IPv4 address is used • =16, if IPv6 address is used. • Per RFC2334, an identifier assigned to a server (in this case, a NAT device), might be the protocol address of the sending server. • Recvr ID Len • = 4, if IPv4 address is used • =16, if IPv6 address is used. • Per RFC2334, an identifier assigned to a server (in this case, a NAT device), might be the protocol address of the receiving server.
Values for the SCSP “CSAS Record” • Cache Key Len = 4 • This 4-byte opaque string is generated by the NAT device that originates the CSAS. • Originator ID Len • = 4, if IPv4 address is used • = 16, if IPv6 address is used. • Per RFC2334, an identifier assigned to a server (in this case, a NAT device) might be the protocol address of the server.
NAT Specific CSA • 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Option Length | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Mapped from | Port Mapped to | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Address Mapped from (Specific to NAT type) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Address Mapped to (Specific to NAT type) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / TLV Options (Variable Length) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+