Draft ETSI
TS 100 100 V0.4.6 (2005-05)
Technical Specification
Satellite Earth Stations and Systems (SES); Broadband
Satellite Multimedia Services and Architectures:
Address Management at the SI-SAP
2
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Reference
DTS SES 00100
Keywords
BSM Address Management ARP RARP DHC
Satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute yyyy.
All rights reserved.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members.
TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Contents
Intellectual Property Rights ................................................................................................................................ 4
Foreword............................................................................................................................................................. 4
Introduction ........................................................................................................................................................ 4
1
Scope ........................................................................................................................................................ 5
2
References ................................................................................................................................................ 5
3
Definitions, symbols and abbreviations ................................................................................................... 6
3.1
3.2
4
4.1
4.2
4.2.1
4.2.2
4.2.3
4.3
4.3.1
4.3.2
5
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
6
6.1
6.2
6.3
6.4
6.5
7
7.1
7.2
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
Definitions ......................................................................................................................................................... 6
Abbreviations ..................................................................................................................................................... 7
Scenarios and service requirements ......................................................................................................... 8
Address Management ........................................................................................................................................ 8
Address Management Functions ........................................................................................................................ 8
IP Layer Address Management Functions ................................................................................................... 8
BSM_IDs ..................................................................................................................................................... 9
BSM_ID Routing, Bridging, Host Information .......................................................................................... 10
Service Requirements ...................................................................................................................................... 10
Requirements Context ................................................................................................................................ 10
Requirements Assumptions ........................................................................................................................ 10
Unicast Architecture requirements ......................................................................................................... 11
Management of BSM_IDs in an NCC ....................................................................................................... 12
Relating BSM_IDs to a BSM Network ...................................................................................................... 12
BSM Address Resolution (B-ARP) ............................................................................................................ 13
BSM Reverse address resolution (B-RARP) .............................................................................................. 14
BSM Dynamic Host Resolution Protocol (B-DHC)................................................................................... 15
Network Address Translation (NAT) ......................................................................................................... 16
Definition of functional architecture ...................................................................................................... 17
Provisioning BSM_IDs in the BSM Network .................................................................................................. 17
BSM Address Resolution (B-ARP) ................................................................................................................. 18
BSM Reverse address resolution (B-RARP) ................................................................................................... 18
BSM Dynamic Host Resolution Protocol (B-DHC) ........................................................................................ 18
Network Address Translation (NAT) .............................................................................................................. 18
Functional Architecture .......................................................................................................................... 18
Primitives ......................................................................................................................................................... 18
Messages .......................................................................................................................................................... 18
ST Master DHC to NCC Message ............................................................................................................. 18
ST BSM Network Addresses Message ...................................................................................................... 19
NCC to ST B-ARP Table Message ............................................................................................................ 19
NCC to ST R-ARP Message ...................................................................................................................... 19
NCC to ST B-DHC Message ..................................................................................................................... 19
8
B-ARP Messages and SI-SAP AR Primitives........................................................................................ 19
9
History .................................................................................................................................................... 22
ETSI
4
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee SES to define the protocols
required to enable IP addresses to be mapped into BSM addresses and vice-versa.
Introduction
This document discusses scenarios and architectures to provide address management functions for a BSM.
ETSI
5
1
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Scope
This document concerns the interworking of BSM networks with the Internet. One of the key elements
of such interconnections is address management. Address Management involves the identification of IP
addresses and how to transport them across a BSM network. The system will make use of the BSM_ID
as a key in the system for finding the correct routing. We will discuss here how to create, manage, and
query these BSM_IDs for the purpose of transporting IP packets. In some systems, requesting to pass
traffic across the network also causes reservation of bandwidth. We consider this out of scope and part
of QoS, but we will make some assumptions that a notification will be sent a QOS Manager. We will
consider that ARP and RARP are conventionally used to determine the hardware addresses associated
with a particular destination IP address but we need to define the source of this information. The TCSES has proposed the use of a BSM_ID as an abstraction that will emulate the hardware address that
would normally be used. A modified ARP (B-ARP) will then be able to determine the BSM_ID for a
target IP address that happens to be on the far side of a BSM. The hardware/software implementation
of the BSM then has no effect on the Internet connection as all of its internal functions are hidden from
the Internet.
The task divides into two parts:

address management scenarios and architectures,

unicast address resolution at the SI-SAP,
Lower layer address management is beyond the scope of this document.
This document elaborates the details of the address management functions, notably the address
resolution function, as defined in the SI-SAP specification [TS 102 357]. It also builds on several other
reports:
2

TR 101 374-1, "Survey on Standardization Objectives for Broadband Satellite Multimedia",

TR 101 374-2, "Standardization Objectives for Broadband Satellite Multimedia: The
Standardization Scenario",

TR 101 984, "Services and Architectures".
References
The following documents contain provisions which, through reference in this text, constitute provisions
of the present document.
Referenced documents which are not found to be publicly available in the expected location might be
found at http://docbox.etsi.org/Reference.
[1] ETSI TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
Services and Architectures".
[2] ETSI TR 101 985: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia; IP
over Satellite".
[3] ETSI TS 102 292: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; Functional architecture for IP interworking with BSM networks".
[4] ETSI TS 102 295: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; BSM Traffic Classes".
[5] ETSI TR 102 353 V1.1.1 (2004-11)
[6] Draft ETSI TS on Address Management produced by STF 237 TOR
[7] ETSI TR 102 157 Ref. DTR/SES-00083, “Satellite Equipment and Systems (SES); Broadband
Satellite Multimedia; IP Interworking over Satellite; Availability, Performance and Quality of
Service.”, February 2003.
[8] draft-ietf-ipdvb-arch-xx.txt; scoping issues when several ‘networks’ share the same physical
resource
[9] draft-ietf-ipdvb-ar-xx.txt; reference for Internet Protocol issues
ETSI
6
Draft ETSI TS 100 100 V0.4.6 (2005-05)
[10] IEEE 801 ****
[11] tr_102155v010101p.pdf (IP interworking over satellite; Addressing and routing)
3
Definitions, symbols and abbreviations
3.1
Definitions
For the purposes of the present document, the following terms and definitions apply:
BSM Subnetwork: A BSM subnetwork is the infrastructure that provides transport services between
STs. The boundary of the BSM subnetwork corresponds to the SI-SAP in those STs; hence the BSM
subnetwork includes elements of the STs, the Gateways and the Satellite.
BSM Network: A BSM network is one BSM subnetwork together with the necessary interworking
functions that enable that BSM subnetwork to interwork with one or more attached networks at the
STs.
BSM_IDentity (BSM_ID): SI-SAP address that defines the BSM Subnetwork Point of Attachment
(SNPA)
NOTE: The BSM_ID is divided into BSM Unicast IDs (BSM_UID) and BSM Group IDs (BSM_GID).
BSM Subnetwork Point of Attachment (SNPA): SI-SAP endpoint of the BSM data transport
services
NOTE: The BSM_ID is used to address data sent to and received from the BSM Subnetwork Point of
Attachment.
Queue_IDentifier (QID): SI-SAP parameter that identifies an abstract queue at the SI-SAP
NOTE: The QID is used to identify a specific lower layer resource when sending (submitting) data via
the SI-SAP.
SI-SAP Instance (SAPI): a specific independent instance of the SI-SAP in one ST
NOTE: A single unicast BSM_ID (UID) shall be associated with each instance of the SI-SAP (each
SAPI). In addition one or more group BSM_IDs (GIDs) may be associated with each instance of the
SI-SAP.
BSM Bearer Service: A BSM bearer service is the transport service from one SI-SAP to one other SISAP (unicast service); or from one SI-SAP to one or more SI-SAPs (multicast service); within the
same BSM subnetwork.
NOTE 1: The endpoint of a given BSM bearer service at the sending side is defined by the
combination of two labels: [destination_BSM_ID] + [QID].
NOTE 2: The sending side endpoint implicitly also contains a third label: the source_BSM_UID
since this ID is directly defined as the address of the sending side SI-SAP.
ETSI
7
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Dynamically Assigned: Assigned at a well defined point in an operation, such as at log-in.
Dynamically Assignable: May be reassigned during normal operations.
Packet: A packet is very similar to a datagram as defined in RFC 1594, "a self-contained, independent
entity of data carrying sufficient information to be routed from the source to the destination computer
without reliance on earlier exchanges between this source and destination computer and the
transporting network”.
Routing: The process of moving a packet of data from a source to a destination. The routing process
includes determination of the best path through consulting a routing table.
Satellite Network Operator: owns and is responsible for maintaining, managing, deploying and
operating the Satellite Network (i.e. the BSM network) excluding terminals (STs & GWs).
Network Access Provider: provides transmission resources to the Service Providers (SP) for accessing
their subscribers.
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply:
AM
Address Management
ARP
Address Resolution Protocol
BSM
Broadband Satellite Multimedia
BSM_GID
BSM Group IDentity
BSM_ID
BSM Identity
BSMS
BSM System
BSM_UID
BSM Unicast IDentity
DHC
DHC for IPV6
DHC
Dynamic Host Configuration Protocol
GID
Group ID
ID
IDentity
IP
Internet Protocol
IPv4
Internet Protocol version 4
IPv6
Internet Protocol version 6
MAC
Medium Access Control
NAP
Network Access Provider
NAT
Network Address Translation
NCC
Network Control Centre
ND
Neighbor Discovery
NMS
Network Management System (usually part of an NCC)
QID
Queue IDentifier
QoS
Quality of Service
RARP
Reverse Address Resolution Protocol
RIP
Routing Information Protocol
SAPI
SI-SAP Instance
SD
Satellite Dependent
SDAF
Satellite Dependent Adaptation Functions
SI
Satellite Independent
SIAF
Satellite Independent Adaptation Functions
SI-SAP
Satellite Independent Service Access Point
SNO
Satellite Network Operator
SNPA
BSM SubNetwork Point of Attachment
ST
Satellite Terminal
UID
Unicast ID
ETSI
8
Draft ETSI TS 100 100 V0.4.6 (2005-05)
4
Scenarios and service requirements
4.1
Address Management
By definition [11] a BSM network is transparent to IP packets and provides, as a minimum, the address
management services required to support IP forwarding from source to destination. The aim of this
clause is to specify the IP services required in different scenarios. In a satellite network, IP services are
closely associated with resource management [11] and excessive traffic over the satellite network must
be avoided. AM does not include routing and protocols such as RIP are not considered in this
document.
It is assumed that protocol layers are independent and thus layer 2 addresses are managed
independently of layer 3 addresses.
BSM_IDs are Unicast and Group Identifiers. The BSM Unicast ID (BSM_UID) is used for Unicast IP
addresses while the BSM Group Identifier (BSM_GID) is used for multicast IP addresses; both are
referred to as BSM_IDs. Above the SI-SAP, BSM_IDs are associated with IP (Layer 3) addresses and
below for the SI-SAP BSM_IDs are associated with MAC (Layer 2) addresses.
As shown in Figure 4-1, Address Management is used to coordinate the requirements for transporting
data between the ISP/Customer, Network Access Provider and Satellite Operator.
IP subnet C4
IP subnet C3
IP subnet C2
IP subnet C1
IP subnet A4
IP subnet A3
IP subnet A2
IP subnet A1
ISP &
customer
IP LAYER
IP to IP associations (routing/ bridging tables/NAT)
IP subnet B4
IP subnet B3
IP subnet B2
IP subnet B1
SIAF: IP to BSM_ID association
BSM_IDs
network access
provider
BSM_ID
Subnet 1
BSM_ID
Subnet 2
BSM_ID
Subnet 3
Map
subnet 1
Map
subnet 2
Map
subnet 3
SDAF: BSM_ID to MAC association
satellite network
operator
SATELLITE DEPENDENT IDs (SDIDs)
e.g. MAC_Add; PIDs; Channel_ID
Figure 4-1 BSM Address Management Layer
4.2
Address Management Functions
4.2.1
IP Layer Address Management Functions
Figure 4-2 shows the BSM network in the form of three IP domains (A, B, C). IP domains A and C are
customer premises networks and IP domain B is the BSM Network. The IP domains A and C could be
the Internet, a corporate internet, corporate intranet, a SOHO network or any enterprise network that
needs to use the BSM network as an access network. Address Management will support functions
consistent with IP forwarding to, from and between IP domains A and C via the BSM network.
ETSI
9
Draft ETSI TS 100 100 V0.4.6 (2005-05)
ST1
IP domain A
(LAN- WAN)
ST2
router/
NAT
bridgeA
IP domain B
(BSM)
router/ IP domain C
NAT C bridge
(LAN-WAN)
SIAF
SIAF
SI -SAP
SI-SAP
SDAF
SDAF
KEY
IP function
Adaptation function
SD
function
SD function
Satellite
payload
SD
function
Ethernet/ Other
LAN/ WAN
Ethernet/ Other
BSM NETWORK
LAN/ WAN
Figure 4-2 A BSM Network and Interworking with other IP domains
If the ST has an IP layer and its network and satellite facing interfaces are in different subnets then an
IP routing function will be required to allow packets to be forwarded from one interface to the other. If
both interfaces are in the same subnet a bridging function could also be used.
If the ST does not have an IP layer and the two interfaces are in the same subnet then a bridging
function will be required. If the ST does not have an IP layer and the two interfaces are not in the same
subnet then IP forwarding would not be possible.
Both network and satellite facing interfaces can use routable or non-routable IP addresses. In addition,
the domain attached to an ST is likely to be a stub-domain with non-routable IP addresses. To
accommodate this, NAT may be required. NAT can allow IP domain A and IP domain C to have the
same network addresses and may also be required because of a customer’s privacy requirements as
illustrated by Informative Annex A. There are several potential problems when using NAT as described
in RFC 1631 and they apply in the BSM network.
Thus Address Management IP layer services that may be required are:

Bridging,

ARP

DHC,

NAT.
Later we will look into the infrastructure needed to support these four AM services
4.2.2
BSM_IDs
Each ST in the system will have one BSM_UID and the HUB can have one or more BSM_UIDs. The
BSM_UID will be associated with [at least] one IP address above the SI-SAP and with a MAC address
ETSI
10
Draft ETSI TS 100 100 V0.4.6 (2005-05)
below the SI-SAP. The IP destination address is maintained from hop to hop and the MAC address is
used to identify the next hop.
The SI-SAP also specifies that the BSM_ID shall conform to IEEE 802 address:
The format for the BSM_ID shall be a 48 bit address (6 octets) that conforms to the
IEEE 802 [10] specification for LAN MAC addresses.
4.2.3
BSM_ID Routing, Bridging, Host Information
A BSM network allows a user directly connected to a Terminal or indirectly connected to a Terminal
via a private LAN to:
 Access one Internet Service Providers (ISP) Network, that in turn will provide access to the
Internet,
 Access a Corporate Network using a Private Network.
Subscribers can be either consumers or SOHO’s or SME’s. Table 1 summarises the types of services
that can be offered based on unicast access.
Type of User
Consumer & SOHO’s
Internet Access
Any Internet based services
Corporate
Any Internet based services
Corporate Access
Teleworking
Corporate Intranet access
Central Office access
Corporate Intranet access
Table 1: Types of Services for Consumers and SME/SOHO’s
The network reference architecture is shown on Figure 1 of Annex A. It should be noted that the same
network architecture supports connections to both ISP and Corporate Networks. The central element of
this architecture is an Access Router or Broadband Access Server (BAS) which interconnects the Hub
with external networks. The Satellite Network provides the following access services:
 Routed IP mode
 Bridged mode
 PPPoA router mode
 DHCP router mode
See ‘Annex A (informative) Internet access scenarios’ for detailed examples illustrating this topic.
4.3
Service Requirements
4.3.1
Requirements Context
The task of an ST is to forward IP packets over a BSM network to the next hop hosting the IP address
and ultimately to the Host for which the IP packet is intended. There may be alternative routes over the
satellite network to provide link diversity or to increase the overall capacity of the satellite link.
The unicast scenario concerns a point to point link, either one-way or two way. The BSM Bearer
Service can be a mesh such that two STs exchange user data directly, or a star such that the user data
passes via a gateway. Control and management information, the C and M planes of SI-SAP, would
normally pass through an NCC even if the user data is passed directly between STs. Systems with
distributed control and management systems, i.e. where C and M plane data does not pass through the
NCC, can be built but no examples are known or have been considered in this document.
4.3.2
Requirements Assumptions
It is assumed that:
ETSI
11
Draft ETSI TS 100 100 V0.4.6 (2005-05)

an ST has at least two IP addresses, one facing the customer network and one facing the BSM
Network, Is this also true for the bridging case?

each ST has an IP address facing the customer network that is either routable or non-routable,

the ST satellite facing IP address must be unique within a BSM network or sub-network,

the IP addresses of the ST can be static and fixed through an ST internal configuration or
dynamic and allocated when the ST starts,

a BSM network may exist as a VPN using NAT for address translation (a network within a
network),

NAT may be used in the ST, gateway or both.
5
Unicast Architecture requirements
A common architecture is essential for all BSM STs [7] in order to ensure their interoperability. This
architecture must support the AM services discussed in clause 4.
The architecture requirements include:




the need for AM services to function by passing Address Management Primitives across the
SI-SAP, thus forming an API, and messages between the client and server,
the use of a client server architecture to provide scalability and integration into existing
management structures,
the need to interwork with IP functions dealing with address management at or below the
network layer; this will ensure that the BSM function will evolve with IP protocols,
the need to minimise address management related traffic over the satellite link to avoid
wasting satellite resources and the effects of the satellite link delay.
Unicast includes three solutions to finding next hop destinations via distributed ARP tables:

Host via ST, via BSM Network, to host via gateway,

Host via ST, via BSM Network, to host via ST,

Host via gateway, via BSM Network, to host via ST.
All addresses must be known to the BSM Network for network planning.
In the BSM, a Distributed Address Resolution Table may be required. To support this, the architecture
should provide:

storage of BSM_IDs,

storage of ARP tables,

NAT at each ST,

NAT at each Gateway,

registration of address pools from remote DHC Servers into a B-DHC server for each ST
(static and dynamic),

transfer of ARP tables between the NCC and the STs,

proxying and interception of DHC messages involving IP assignment,
ETSI
12

5.1.1
Draft ETSI TS 100 100 V0.4.6 (2005-05)
proxying and update of NCC ARP messages to ensure transparent next hop behaviour across
the BSM Network.
Management of BSM_IDs in an NCC
The management of BSM_IDs involves at least two entities, an SNO and a NAP. An SNO owns and is
responsible for maintaining, managing, deploying and operating the BSM network excluding STs and
gateways. A NAP provides transmission resources to the Service Providers (SP) for accessing their
subscribers.
Adopting this model the following rules apply:
1.
The SNO shall have responsibility for BSM_ID management over the entire BSM Network
and shall therefore set the policy for allocation of BSM_IDs. In particular, the SNO shall be
responsible for ensuring that the uniqueness rule is met.
2.
The NAP shall be responsible for BSM_ID management over its subset of the BSM Network.
The NAP shall allocate individual BSM_IDs to STs and shall also define the rules for
managing the associated satellite network IP addresses.
5.1.2
Relating BSM_IDs to a BSM Network
Some address management functions could be implemented above, below or both above and below the
SI-SAP. For reference, the BSM protocol stack, reproduced from [4], is shown in Figure 5-1. Address
Resolution primitives pass across the SI-SAP in the C-plane.
ETSI
13
Draft ETSI TS 100 100 V0.4.6 (2005-05)
IPv4 and v6
Satellite Independent
Access Functions
BS
M
Traffic
Manager
IP to
BSM_ID
BS
M
Address
Resolution
BSM SI
QOS Adaptation
and Management
BSM
SI
Management
Traffic
Classes,
QID
IP Packet Forwarding
SI-SAP
SI-U-SAP
SI-C-SAP
SI-M-SAP
Satellite Dependant Access Functions
BSM_ID
to lower layer
address
BSM
Address
Resolution
BSM SD
Resource Management
BSM_ID,
QID=1
BSM
SD
Management
Queue 1
Queue 2
BSM SD
Queue Manager
Queue N
Segmentation/
encapsulation
Figure 5-1 BSM Protocol Stack
5.1.3
BSM Address Resolution (B-ARP)
The means by which an IP packet arrives or leaves the BSM network is not considered here as it is a
routing issue external to the BSM. The BSM Architecture must provide a service where ARP is
supported in the Gateway and STs by a B-ARP Server. Each ST must have an ARP table and the server
must be able to populate this table or be populated by the ST. Having the ARP server at the NCC
supports traffic management, i.e. allowing and denying IP packets access to the BSM network. This TS
assumes that an IP traffic packet is routed to an ST or gateway to be forwarded to a destination on the
other side of a satellite link. Need to discuss the requirements of B-ARP as opposed to ARP.
Address resolution is a ‘a C-plane function’ [5] defined as ‘A function to associate a BSM_ID address
to a given IP address’. Address resolution is required when an IP packet enters a BSM network. A
BSM_ID must be determined for the packet to be forwarded. There are three cases:

star network inbound: all IP addresses resolve to the gateway BSM_ID. The BSM_ID
associated with the gateway is either acquired at ST startup as part of Configuration
Management by the NCC, from the ST to the NCC, or it is pre-programmed (in this case
needs to be pushed into the NCC,

Star network outbound: IP addresses resolve to specific BSM_IDs. IP address resolution may
require policy decisions. An OBP Satellite will need an ARP table that is partially managed by
the NCC,
ETSI
14

Draft ETSI TS 100 100 V0.4.6 (2005-05)
mesh network: IP addresses resolve to specific BSM_IDs. IP address resolution may require
policy decisions. An OBP Satellite will need an ARP table that is partially managed by the
NCC.
In all cases the ARP client sends an address resolution request to a BSM address server whose address
is acquired at authentication or is pre-acquired. This server could, in principle, be located anywhere but
it is realistic to assume that is under the control of the BSM operator since it needs knowledge of the
BSM address space.
The most likely location for the ARP server is in the BSM NCC. If this were not the case then an ARP
server located elsewhere would need a means of obtaining knowledge of the BSM address space.
Need to clarify ARP broadcast, external ARP
ARP
Broadcast
ARP
Broadcast
AR
Cache
Update
End
System
A
Satellite
Terminal
A
Satellite
1
ARP
Broadcast
AR
Cache
Update
NCC
BSM ARP
Server
Satellite
2
Satellite
Terminal
C
End
System
C
Transmission
Bearer
Service
SI-SAP
External
Bearer
Service
SI-SAP
TCP transport services & IP network services
BSM Bearer
Service
Transmission
Bearer
Service
Transmission
Bearer
Service
External
Bearer
Service
Transmission
Bearer
Service
Figure 5-2 BSM ARP Architecture
Although a separate ARP server is used (refer to cache), an ARP function is still required in the SIAF
to determine the BSM_ID as this could change.
5.1.4
BSM Reverse address resolution (B-RARP)
The use of reverse address resolution is to enable an ST to obtain an IP address either routable or nonroutable. If this occurs, it will usually be when an ST starts but may occur at other times as well. An ST
may have a default IP address.
When an ST starts it can have a default address for a BSM-IP address server. A BSM_ID-IP server
could be located anywhere but it is realistic to assume that is part of the BSM since it needs knowledge
of the BSM address space.
The RARP server will be proxied in the NCC to support authorisation of STs to the network..
ETSI
15
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Need to clarify why RARP may be required or whether BOOTP or DHCP would be better. What is the
view of the steering committee?
5.1.5
BSM Dynamic Host Resolution Protocol (B-DHC)
B-DHC is required to dynamically allocate IP addresses to hosts accessing the satellite network and to
discover the addresses of Hosts when required; the equivalent function to DHC in IPv6 is required.
Alternative functions such as ND/SEND in IPv6 may also be required.
B-DHC could generate significant traffic and it would be undesirable for this traffic to pass over a
satellite network. B-DHC proxies at each ST should be used to reduce this traffic.
Potential B-DHC configurations are:

1) Local LAN DHCP – this is used to manage the local LAN IP addresses via an embedded
DHCP server in the ST and hence is invisible to the BSM network
o
The NCC will need to be aware of the pool of IP addresses to be used with this local
B-DHC server. Configuration Management will pass the information from the NCC
NMS to the support B-DHC in the NCC.

2) Distributed Corporate LAN DHCP - this is used to manage LAN IP addresses within a
corporate LAN, but the segments of that LAN are at separate locations (geographically
separate) and connected via a BSM network. Simply using standard DHCP would generate
excessive DHCP traffic over the BSM and hence there is need for DHCP proxy servers and/or
adaptation in each of the separate sites. This is still largely external to BSM and can (in
principle) use standard DHCP proxies [is there an RFC for this?]

3) B-DHC – Is used to manage the satellite facing IP addresses via a DHCP server in the NCC
or in the ISP.
The B-DHCP communication can go directly to the B-DHC proxy server in the NCC or ISP. In this
case the B-DHC information enters the BSM; however it is NOT transparent to the BSM and
information is proxied to the customer's real B-DHC server. The BSM Server will need to store the all
temporary IP address for each given ST in the system. The Traffic Manager is assumed to update the
Forward Link Subsystem and NAT Servers as needed. BSM impact may include a lot of exchanged
information.
All of these B-DHC configurations are permitted and the choice will be manufacturer dependant.
This is illustrated in Figure 5-3 for the case of an access network. In this case it would clearly be
desirable if the B-DHC traffic could be prevented from traversing the satellite network unless of
specific need such as the unavailability of the local B-DHC server.
ETSI
16
DHCP Server 1
Draft ETSI TS 100 100 V0.4.6 (2005-05)
DHCP Server 3
DHCP Server 2
NCC
End
System
A
Satellite
Terminal
A
Satellite
1
Satellite
1
DHCP
Proxy
Satellite
Terminal
C
End
System
C
Transmission
Bearer
Service
SI-SAP
External
Bearer
Service
SI-SAP
TCP transport services & IP network services
BSM Bearer
Service
Transmission
Bearer
Service
Transmission
Bearer
Service
External
Bearer
Service
Transmission
Bearer
Service
Figure 5-3 BSM B-DHC Architecture
Communications between the B-DHC services are relayed to the B-DHC Proxy in the NCC.
5.1.6
Network Address Translation (NAT)
One or more Hosts can be connected to an ST. Hosts can have routable IP addresses, non routable IP
addresses or a combination of both routable and non routable IP addresses. If Hosts with non routable
IP addresses want to send or receive IP packets via the internet then a protocol such as NAT will be
required. Not all applications operate with NAT and non-standard workarounds may be required.
ETSI
17
Draft ETSI TS 100 100 V0.4.6 (2005-05)
NAT
NAT
NCC
End
System
A
Satellite
Terminal
A
Satellite
1
Satellite
1
NAT
Satellite
Terminal
A
End
System
C
Transmission
Bearer
Service
SI-SAP
External
Bearer
Service
SI-SAP
TCP transport services & IP network services
BSM Bearer
Service
Transmission
Bearer
Service
Transmission
Bearer
Service
External
Bearer
Service
Transmission
Bearer
Service
Figure 5-4 NAT and BSM_IDs
Three NAT cases can be considered:
1.
the ST acts as a bridge with NAT. When handling ingress packets, the packets must be
NATed first in order to have globally unique IP address going through the BSM network. For
egress handling, the packet must first be NATed into the next domain IP address and then the
bridge/router functionality must be applied. All packets are dropped that do not match the
routes entered into bridge/router. NAT/bridge/switch is used in current systems at least one
current system,
2.
the ST acts as a router with NAT. For egress processing, the NAT server will change the IP
addresses that are stored in its tables, all other packets will be routed through the ST
transparently,
3.
the ST acts as a bridge without NAT.
NATP is required if multiple STs appear to the BSM internal network to share a single IP address. This
functionality will require the BSM_ID Server to have the ability to associate port numbers as well as IP
addresses. This functionality will only be required once IP encapsulation equipment performs Layer 3
broadcasting. Currently it is only done at layer 2 using the MAC Address. This functionality has to be
closely coordinated with the QoS functionality that may use port number to identify a service.
6
Definition of functional architecture
6.1
Provisioning BSM_IDs in the BSM Network
A message to add, modify, or remove an ST from the BSM Network will be routed to the BSM_ID
Server. However, the details of these messages are out of the scope of this document.
Case 1: Add BSM_ID
ETSI
18
Draft ETSI TS 100 100 V0.4.6 (2005-05)
An actor in the system will request a BSM_ID from the BSM_ID server. The optional information
included in the message could be the satellite facing IP address of the ST.
Case 2: Modify BSM_ID
An actor in the system can request a change a BSM_ID. The BSM_ID can be used as a key to modify
the record.
Case 3: Remove BSM_ID
An actor in the system can remove a BSM_ID. The BSM_ID can be used as a key to remove the
record.
6.2
BSM Address Resolution (B-ARP)
Each ST should have a local ARP table relating IP addresses to BSM_ID addresses. Each ST should
have the address of a default ARP server location in the NCC. This should reduce the number of ARP
messages through the satellite network.
6.3
BSM Reverse address resolution (B-RARP)
A RARP client in an ST sends a message to a B-RARP server at the default address. The message
requests an IP address for an ST that does not have an IP address. Note: Does it have to have a
BSM_ID already?
6.4
BSM Dynamic Host Resolution Protocol (B-DHC)
Several different messages may be required for DHC.
STs could have local DHC servers. A message could be sent from the NCC to the ST to update the
local DHC. This message could contain BSM_IDs and IP addresses.
A message could be sent from the ST to the NCC to inform the BSM of the IP addresses allowed to
traverse the BSM Network. This message could contain the BSM_ID and IP addresses.
6.5
Network Address Translation (NAT)
The BSM_ID server will update the NAT/NAPT servers in the Gateway to support access to the
Internet.
7
Functional Architecture
7.1
Primitives
TBD
7.2
Messages
This clause identifies important messages in the BSM.
7.2.1
ST Master DHC to NCC Message
When the ST has access to a non-BSM DHC server, this message is sent to the NCC to configure the
NAT/NAPT to allow the traffic to pass through the BSM Network.
ETSI
19
7.2.2
Draft ETSI TS 100 100 V0.4.6 (2005-05)
ST BSM Network Addresses Message
This message contains the network addresses to be used when processing data within the BSM
network. This message could cause updates to the local ST NAT/NAPT when addresses in the
subnetwork are not the same as the ST DHC address
7.2.3
NCC to ST B-ARP Table Message
This message from the NCC to the ST contains the BSM_IDs and IP address tuples. This message also
includes a default B-ARP address.
7.2.4
NCC to ST R-ARP Message
This message contains a list of IP addresses that are specifically to be allowed or blocked.
7.2.5
NCC to ST B-DHC Message
This message could contain ST addresses for assignment in the subnetwork attached to the network
facing interface of the ST. These addresses could be used in the NAT with translations applying to the
information in the ST BSM Network Addresses Message.
8
B-ARP Messages and SI-SAP AR Primitives
Question: Should this become a formal specification of B-ARP?
NEED To SPLIT into SIAF, SI-SAP, and SDAF
When a packet enters the BSM network it needs to find its next hop destination, this is done with ARP
from the perspective of the customer premises network. From the perspective of the BSM Network, it
is B-ARP since ARP can use too much satellite resources. B-ARP is a system that enables ARP and
minimizes satellite resource usage.
The B-ARP system requires knowledge of each ST’s routable addresses in the BSM network. This
information is stored centrally in the NCC B-ARP server of the system. Then when a packet enters a
different ST, the B-ARP in the NCC has pre-configured this ST to already have knowledge of the IP
addresses and BSM Network next hop address.
Here is an example:
1.
ST logs into the BSM network
2.
The NCC tells the ST it’s pre-configured local routable addresses for the BSM Network
a.
Optionally the ST notifies the NCC B-ARP Server of all routable addresses for that
ST
3.
If the ST/GW BSM Network local routable addresses are not the same as the customer
premises network, address translation (NAT) must be setup for crossing the BSM Network
and customer premises network boundary.
4.
The NCC configures the GW with the ST BSM_ID, next hop addresses, and routable
addresses
5.
The NCC broadcasts to all STs the ST BSM_ID and routable addresses (optional)
a.
The first packet can next hopped to the GW and then the NCC B-ARP Server can
notify the source ST to use a different next hop address for subsequent packets.
6.
A network device in the customer premises network does an ARP request.
7.
The ARP request is received by the ST/GW.
ETSI
20
8.
9.
Draft ETSI TS 100 100 V0.4.6 (2005-05)
The ST/GW looks up the next hop address in the B-ARP client
a.
If no match is found, it replies with the default NCC next hop address
b.
If a match is found and access is NOT set to deny, it replies with the destination next
hop address
c.
If a match is found and access is set to deny, the ST/GW may respond and will drop
the packet if received in the GW/ST.
The ST/GW will receive the packet, drop it or transmit it to the next hop destination.
10. Once the packet is delivered, the destination ST/GW B-ARP client may notify the NCC BARP server that packets of a certain destination needs to denied access to the system
a.
The NCC B-ARP server will notify ST’s of an address to be denied access to the
BSM network
b.
The NCC B-ARP server can also cancel the blocking of an address.
Thus the ST/GW is required to respond to ARP requests. The ARP requests are only local to the
customer premises network and the ST/GW. The B-ARP is a dynamic configuration management of
known routable addresses that are unique for the entire BSM network and associates then to next hop
BSM_ID addresses in the BSM Network.
The B-ARP server in the NCC will store the BSM_ID and associated IP addresses. These IP addresses
will have a status associated to them of allow or deny access to the BSM Network. The server can be
preconfigured by the Network Operator with allowed IP addresses. Optionally the server can be
dynamically updated with allowed addresses. The ST and GW can dynamically update the B-ARP
server with denied access IP addresses.
Data Stored in the B-ARP Server
1.
BSM_ID
2.
Next hop address
3.
List IP addresses each having
4.
a.
IP addresses
b.
Status (accept/deny)
Login Status (Optional)
Messages/Primitives handled by the B-ARP Service
1.
BSM_ID logged in (optional)
2.
BSM_ID logged out (optional)
3.
Add to B-ARP Server
a.
BSM_ID
b.
ST/GW BSM network routable IP addresses
c.
status(allow/deny)
4.
Response to message 3 (accepted/rejected)
5.
Delete from B-ARP
a.
BSM_IP
ETSI
21
b.
ST/GW BSM network routable IP address
6.
Response to message 5 (accepted/rejected)
7.
Query B-ARP Server
a.
8.
9.
Draft ETSI TS 100 100 V0.4.6 (2005-05)
ST/GW BSM routable IP addresses
Response to message 7 (one of three)
a.
Found and next hop address
b.
Not found and GW next hop address
c.
Found and deny access to BSM Network
Notification from B-ARP client of local BSM Network routable addresses
a.
BSM Network routable IP addresses
10. Response from message 9 (accept/reject)
11. Request from B-ARP Client for ST local BSM Network routable addresses
12. Notify B-ARP client of local BSM Network routable addresses
a.
List of local BSM Network routable IP addresses
13. Response from message 12 (accept/reject)
14. Broadcast to BSM Network
a.
Next hop addresses
b.
ST/GW BSM network routable IP addresses
c.
Status (allow/deny)
The B-ARP client in the ST/GW will have a list of next hop addresses and associated IP addresses. The
IP addresses have a status of allow or deny access to the BSM Network. The B-ARP client will handle
ARP requests and find the nexthop in the BSM network, if applicable. If the customer premises
network addresses are not routable in the BSM Network in the sense they are different from the
assigned BSM Network routable addresses to the ST/GW, addresses translation (NAT) must be done in
ST/GW.
Data Stored in the B-ARP Client
1.
BSM_ID
2.
Next hop address
3.
List IP addresses each having
a.
IP addresses
b.
Status (accept/deny)
Messages handled by B-ARP Client
1.
ARP Request from customer premises network
2.
Respond to message 1 with ARP Response back to customer premises network
3.
Receive B-ARP Server update of (Message 14 from B-ARP Server)
ETSI
22
a.
BSM Network next hop addresses
b.
ST/GW BSM network routable IP addresses
c.
Status (allow/deny)
4.
Request from B-ARP Server get local addresses
5.
Response from B-ARP Server
a.
6.
Draft ETSI TS 100 100 V0.4.6 (2005-05)
Local ST/GW BSM network routable IP addresses
Notify B-ARP Server
9
a.
Local ST/GW BSM network routable IP addresses
b.
Local Status (allow/deny)
History
Document history
044
29-11-2005
Presented to SES BSM #25, Sophia Antipolis
045
16-12-2005
Updated with annexes
046
20-01-2006
Updated in response to further comments
29.11.2005
ETSI