Paper Title Here
Hiroshi Fujinoki
Department of Computer Science
Southern Illinois University Edwardsville
Edwardsville, IL 62026-1656
E-mail: hfujino@siue.edu
Voice: +1-618-650-3727, Fax: +1-618-650-2555
Abstract
In this paper, we present our new designs of interdomain SDN in the Internet to optimize the flow of
network traffic by improving the utilization of the
unused transmission bandwidth at tier-2 and 3
providers (the reality issues in the existing Internet).
Address the problem of “beyond right” issue in the
peering of tier-2 and 3 ISPs. A solution for the
beyond right issue. Assessment the potential of the
proposed solution.
Categories and Subject Descriptors
C.2.6 [Internetworking]: Routing protocols;
C.2.6 [Internetworking]: Standards;
Keywords
Inter-domain routing, network traffic optimization,
software defined networks, Border Gateway Protocol
(BGP), routing in the Internet
1. Introduction
(1) Why is “inter-domain routing” an important
problem?
Optimizing network traffic, such as optimizing
network traffic load (i.e., transmission rate),
transmission delay, and especially hardware resource
utilization, has huge financial impact.
(2) Why is inter-domain routing a difficult research
problem?
The structure in the Internet has continuously
changed ever since its prototype was built in the late
60’s as ARPANET. Since ARPANET, the structure
of the Internet had been quite much like a tree
structure with the inter-connections of tier-1 ISP's at
its root until the mid 90s. In the tree structure,
network traffic generated by an Internet user first
climbs up to a tier-1 ISP through a tier-2, where the
traffic is switched to another tier-1 ISP. Then, it goes
down to the destination through a tier-2 ISP.
The recent popular adoptions of multi-homing and
peering among tier-2 and even tier-3 ISP's have made
the Internet more like a layered mesh structure [0].
The recent structural evolutions from a simple tree
structure to a layered mesh structure has significantly
increased opportunities for network traffic
optimization [0].
Despite the increase in the inter-connectivity
among tier-2 and 3 providers, network traffic flow
between two domains in the Internet is still regulated
based on their relationship, such as providercustomer, peer-to-peer, and sibling relationships [a].
Especially in peering tier-2 and 3 ISP’s, most of them
do not offer beyond rights by not advertising their
BGP paths to their peers because offering beyond
rights to other peers will not directly contribute to
own profit unless other incentives are provided.
No beyond rights in tier-2 and 3 peering
relationships cause sub-optimal utilization of
available link bandwidth as follows. Figure 1 (a)
shows an example of AS (autonomous system)
interconnections, where AS 1, 2, and 3 are tier-1 ISPs
and 4, 5, 6, 7 are tier-2 ISPs. The three tier-1 ISPs
are fully connected, while AS 4 and 5, and 6 and 7
are connected by peer relationship.
We defined “beyond rights” by the following two
rules:
(1) Non-tier1 ISPs: on an outgoing link at an AS if
incoming network traffic is not destined to local
customers (local customers include those who are
downstream of directly connected intermediate
ISPs).
(2) Tier1 ISPs: since tier-1 ISPs do not pay to any
other ISPs (a. k. a., “settlement-free”), it depends
on each tier-1 ISP. If a tier-1 ISP announces a
particular BGP path, any traffic flowing to its
downstream is not considered a violation of
beyond right principle. Otherwise, they follow
rule (1) for non-tier1 ISPs.
Based on the two rules, when user W transmits a
payload traffic to Z, his traffic goes through AS 4, 1,
3, and 7. However, if AS-1 is down (or unavailable
due to over traffic), W’s traffic can not go through
link 5-2 and 2-3 (assuming that AS 2 does not
advertise a BGP path of 2-3-7 to AS 1), because of
“no beyond right” over AS 5 (Figure 1 (b)). AS 4
will not even see the path because AS 5 will not
advertise its BGP path (5-2-3-7) to AS 4.
- peer-peer
- provider-customer
 - violation of “beyond right”
- unavailable link
1
Tier-1 ISPs
2
1
3
2

3

Tier-2 ISPs
4
Users
W
5
6
7
4
X
Y
Z
W
(a) AS-1 up
5
6
7
X
Y
Z
(b) AS-1 down
Figure 1 - an example of AS (autonomous system)
interconnections
Simply forcing AS 5 to announce its BGP path to
reach AS 7 (5-2-3-7) to AS 4 may cause penalty from
AS 2 for increased traffic load from AS 4 when any
customers of AS 4 do not pay to AS 5. While interconnections of tier 2 and 3 ISPs by peering are
expected to increase in the future [b], banned beyond
rights among the tier-2 and 3 ISPs will significantly
limit the opportunities offered by their peer-to-peer
interconnections.
The rest of this paper is organized as follows.
Section 2 presents the major existing work. In
Section 3, we present our design of ________ (using
a mechanism of monetary insensitive to encourage
beyond rights). Section 4 presents our assessments of
how much the proposed ______ can contribute to
utilize tier-2 and 3 inter-connections in the current
Internet. Section 5 describes the conclusions and the
planned future work, followed by references.
2. Existing Work
 BGP [0].
 Inter-domain Traffic engineering (TE) [0, 0, 0, 0].
 Traffic-load
optimization
between
two
neighboring ASs [c].
 Inter-domain traffic engineering by GMPLS [d].
 Inter-domain traffic engineering SDN [e].
 E-payment systems [0].
 Internet structure [0].
SDN is an emerging network traffic managing
technique, which was initially developed for intradomain network traffic [0]. SDN provides a higher
level of controls MPLS and over-lay networking do
and it has several advantages:
 SDN provides logically centralized control over
network traffic, which usually produces better
results compared to a distributed approach.
 Because of its centralized nature, SDN does not
require complex procedures to reflect the routing
decisions to the controlled routers. For example,
disseminating route updates has been a major issue
in most of the distributed routing protocols,
including the existing BGP, since their long
convergence delay caused routing loops [0, 0, 0].
 SDN is more flexible than MPLS and over-lay
networking in that SDN can use more diverse input
parameters in making routing decisions, even
including' business logics each domain prefer [0].
(c) Electronic payment systems
A taxonomy of electric payment systems
3. Proposed inter-domain SDN for optimizing
network traffic in global Internet
There are three major functional components in the
proposed ____: disseminations of BGP path under
beyond rights, signaling of path establishment, and
traffic accounting.
Disseminations of BGP path beyond rights: BGP
paths are disseminated with an extension of the
existing BGP path announcements. Each path in a
BGP routing table is represented by an entry that
consists of Network, Next Hop, Metric, LocPref,
Weight and Path fields. Each BGP path with beyond
right is represented with the extensions of “Total
Cost”, “Link Cost”, “Transmission Rate”, “Available
Time Window”, and “Expiration Time”.
 Total Cost: it represents currency amount for
transmitting 1MB of payload through the BGP path
with beyond right. It is attached to Network field
(which is a destination domain address in CIDR
format).
 Link Cost: it represents currency amount for
transmitting 1MB of payload on a particular BGP
link through the BGP path with beyond right. It is
attached to each intermediate AS number in “Path”.
If Link Cost is free on a particular link, Link Cost
can be omitted. The sum of the Link Cost for all
links on a BGP path sums up to Total Cost.
 Transmission Rate: it represents the transmission
rate a BGP path with beyond right may accept.
The rate of transmission is not guaranteed until a
session of BGP path with beyond right is approved
by all the intermediate ASs on a BGP path that
perform BGP routing with beyond right. It is a
new field in a BGP routing table.
 Available Time Window: it represents the time in
a day when BGP path with beyond right may be
available. It represents guessed time BGP path
with beyond right is available. The time window is
expressed using Greenwich Mean Time.
 Expiration Time: it represents the time the
announced BGP path with beyond right expires. It
is expected that the BGP path be re-announced by
its Expiration Time, if the path should remain
available. A BGP path with beyond right can be
disabled by explicitly invalidating the path or by
implicitly omitting re-announcement.
Disseminations of BGP path beyond right is
initiated by the last AS (the one close to the
destination) that performs BGP routing with beyond
right. In Figure 1 (b), it is AS 2 who initiates the path
of 5-2-3-7. At AS 2, the BGP path (without using
beyond right) of 3-7 should have been advertised by
AS 3. AS 2 announces the path information to AS 5
(Link Cost is assumed to be 0.1$, other fields are
omitted for simplicity):
81.16.101.0/24<0.1> 10.1.13.3 2<0.1> 3 7
Then, AS 5 announces the path information to AS 4
(Link Cost is assumed to be 0.3$):
81.16.101.0/24<0.4> 21.5.11.0 5<0.3> 2 <0.1> 3 7
If AS 5 is not willing perform BGP path with
beyond right, the path announcement from AS 2 is
dropped by AS 5. For the other three fields
(Transmission Rate, Available Time Window, and
Expiration Time), if AS 5 enforces a tighter
restriction (e.g., 3MB for Transmission Rate), it
updates each such field before the announcement
message is forwarded to AS 4. If an existing BGP
router (one that is not a BR-BGP router), it drops the
BGP announcement, preventing the BGP path
announcement from being propagated beyond the
non BR-BGP router.
It is possible for a BR-BGP router to have multiple
BGP paths with beyond rights. For example, AS 2 in
Figure 1 can have two BR-BGP paths (5-2-3 and 5-26-7) for network traffic from user W to Z, which
consist of different BR-BGP links (Figure 3 (a)). The
proposed BR-BGP routing can cope with failure of
the destination-side tier-1 ISP (e.g., AS 3) as shown
in Figure 3 (b). For the two BR-BGP paths in Figure
3 (a), AS 4 is the origin AS, while AS 1 is the origin
AS for the BR-BGP path in Figure 3 (b).
Figure 3 (c) visualizes a scenario for a failure of an
internet exchange (IX) point, where the three tier-1
ISPs are interconnected (a failure of an IX point will
disable interconnections of all the ISPs there). This
is a scenario for a terrorist attack to a major IX point.
In this scenario, although no through traffic over any
tier-1 ISP is available, the interconnection of the four
tier-2 ISPs will enable through traffic between W and
Z. Having BGP paths using beyond rights ready in
advance will minimize the impact of such attacks to
major IX points. Using the feature of “traffic
accounting” (described after this section), it is
possible to selectively accept network traffic through
BR-BGP paths in such emergency situations, which
is one of the missing features in the existing BGPbased routing today.
 - A BGP link under beyond right
1
2

1
3
2
 
4
W
3

5
6
X
Y

7
4
5
6
Z
W
X
Y
(a) AS-1 down

7
Z
(b) AS-3 down
1
2
3
 
4
W
5
6
X
Y

7
Z
(c) IX point down
Figure 3 – Examples of different scenarios for BGP
routing using “beyond rights”.
Signaling for path establishment and payload
transmissions: Before an origin AS starts using a
BGP path with beyond right, it needs to establish an
active path through the BGP path by signaling each
AS that performs BGP routing with beyond right
(such paths are called “BR-BGP paths”) using three
messages of REQ, ACK, and NACK. Each BR-BGP
path may consist of multiple links, called “BR-BGP
link”. Each BR-BGP link is established between two
BGP routers on a BR-BGP path (they are called “BRBGP routers”). A BR-BGP path can be a part of
BGP path.
After a BR-BGP path is established, payload
transmission starts and payload transmissions are
managed using PALD, PACK, and NPACK. An
existing BG-BGP path is terminated by FIN message
from either a transmitting or a receiving BR-BGP
router. The messages are defined and the procedure
of the proposed _______ using the messages are
described in the following section.
REQ: it is initiated by an origin AS (e.g., AS 4 in
Figure 1 (b)) and propagated to each of the BR-BGP
routers (AS 5 and 2) in a path. Each REQ message
consists of:
 Requesting AS (ASR): it is the AS number who is
requesting a BR-BGP link.
 BGP AS list (I): the list of all the AS on the path
(e.g., “5 2 3 7”) in Figure 1 (b)).
 Requested Transmission Rate (R): the
transmission rate (in Bps) requested by the origin
AS.
 Requested Time Duration (T): duration of the
time this origin AS uses the BGP path with beyond
right.
 Transferring AS’s nonce (X): a number randomly
generated by a BR-BGP router.
 Transferring AS’s salt (): a number randomly
generated by a BR-BGP router.
 Requested Message Window Size (D): the
number of payload packets that carry the same
transferring AS’s nonce (X), salt (), the receiving
AS’s nonce (Y), and salt ().
ACK: a message used by a receiving BR-BGP router
to approve a request for approving BR-BGP link
establishment. The message contains the following
attributes:
 Approving AS (ASA): it is the AS number who is
approving the requested BR-BGP link.
 BGP AS list (I): it is a copy of field “I” in the
approved REQ message.
 Requested Transmission Rate (R): it is a copy of
field “R” in the approved REQ message.
 Requested Time Duration (T): it is a copy of field
“T” in the approved REQ message.
 Requesting AS’s nonce (X’): the approving AS
calculates X’ = X + 1.
 Approving AS’s nonce (Y): a number randomly
generated by a BR-BGP router.
 Approving AS’s salt (): a number randomly
generated by a BR-BGP router.
 Approved Message Window Size (D): it is a copy
of field “D” in the approved REQ message.
 Link Label (L): The approving BR-BGP router
assigns a label for the approved BR-BGP link and
notifies it the requesting BR-BGP router.
NACK: if a receiving BR-BGP router denies a
request for BR-BGP link, the receiving BR-BGP
router responds to a REQ by a NACK, which consists
of the following attributes:
 Denying AS (ASA): it is the AS number who is
denies the requested BR-BGP link.
 BGP AS list (I): it is a copy of field “I” in the
approved REQ message.
 Denial Factor (F): a factor that caused the denial
of a BR-BGP link request (R, T, or X).
 Denied Factor Status: “0” if no resource is
available. If some resource (less than requested by
a REQ message) is available, the amount of
available resource is specified (e.g., “60MBps”,
while “100MBps” is requested for “R” in a REQ).
After all BR-BGP links on a BR-BGP path is
successfully established (i.e., all the BR-BGP routers
on a BR-BGP path approves BR-BGP links), an
origin BR-BGP router can initiate payload
transmissions through the BR-BGP path. Each
payload message contains the PALD message (it is
piggy-backed to each payload packet). Receiving
BR-BGP routers use the information in PALD for
accounting purpose. Each receiving BR-BGP router
acknowledges payload packets using PACK
messages.
PALD (PAyLoaD):
 Transmitting AS number: it is the AS number of
the BR-BGP router who transmits this payload
packet. It is the copy of “ASR” in the REQ for this
BR-BGP link.
 Receiving AS number: it is the AS number of the
BR-BGP router who receives this payload packet.
It is the copy of “ASA” in the ACK for this BRBGP link.
 BGP AS list (I): it is a copy of field “I” in the
approved REQ message.
 Link Label (L): it is the copy of “L” in the ACK
for this BR-BGP link.
 Transferring AS’s nonce (Xi,j): the j-th
transferring AS’s nonce in the i-th round of the
BR-BGP link (described in the next section).
 Receiving AS’s nonce (Yi,j): the j-th transferring
AS’s nonce in the i-th round of the BR-BGP link
(described in the next section).
 Size of the payload (S): it is the size of the
payload contents (the size of a network-layer
packet, including the network-layer packet header)
in bytes.
PACK (Payload ACKnowledge):
 Transmitting AS number, Receiving AS number,
BGP AS list (I), Link Label (L), and Size of the
payload (S): same as they appear in a PALD
message.
 Receiving AS’s nonce (Yi,j): the j-th transferring
AS’s nonce in the i-th round of the BR-BGP link
(described in the next section).
An existing BR-BGP link can be terminated either
a transmitting or a receiving BR-BGP router, by
releasing a FIN message, which consists of the
following attributes:
FIN (FINish):
 Transmitting AS number, Receiving AS number,
BGP AS list (I), and Link Label (L): same as they
appear in a REQ message.
 Transferring AS’s nonce (Xi,j): the j-th
transferring AS’s nonce in the i-th round of the
BR-BGP link (described in the next section).
 Receiving AS’s nonce (Yi,j): the j-th transferring
AS’s nonce in the i-th round of the BR-BGP link
(described in the next section).
The procedure of the BR-BGP path setup, payload
transmissions through an existing BR-BGP path, and
a termination of an existing BR-BGP path is
visualized in Figure 2, while the one for the detailed
payload transmissions is shown in Figure 3. In
Figure 2, a BR-BGP path setup is initiated by an
origin BR-BGP router (a BR-BGP router in AS 4 for
a BR-BGP path of 4-5-2-3 in Figure 1 (b)). The BRBGP router in AS 4 first constructs its REQ message,
and it sends the REQ to the BR-BGP router in AS 5.
If the router in AS 5 rejects the request, it constructs
a NACK message and sends the NACK to the BRBGP router in AS4. Otherwise, it creates an account
for this BR-BGP path, creates a valid BR-BGP link
label (L) and constructs a new REQ message and
sends the REQ message to the BR-BGP router in AS
2 (the BR-BGP router in AS 5 holds its ACK to the
one for AS 4 until it receives an ACK from the one in
AS 2. This procedure repeats until a REQ message
reaches the BR-BGP router in AS 3. If the BR-BGP
router in AS 3 approves the request for its BR-BGP
link, it causes the router to generate an ACK message,
or a NACK message will be released by the router.
All the intermediate BR-BGP routers send either an
ACK or a NACK all the way back to the origin BRBGP router (i,.e., the one in AS 4 in Figure 1 (b)).
AS4
AS2
AS3
AS7


Time


Payload
Transmissions
AS5
Figure 2 - the timeline view of the BR-BGP routing
signaling and payload-transmission procedure
Traffic accounting: The proposed ____ relies on
tier-2 and 3 ISPs who are willing to share the link
bandwidth of their peer links when they are underutilized at the same time the transmission bandwidth
they accepted may cause increase in their payment to
their providers (i.e., tier-1 ISPs for tier-2 or tier-2
ISPs for tier-3 ISPs). Regarding peer-to-peer links,
the freeride of their transmission bandwidth by other
ISPs (other than those from the two ISPs who are the
two ISPs of the edges of a peer-peer link) will
discourage having such peer-peer links from the
beginning.
To facilitate sharing their transmission bandwidth
with peers, we also propose a mechanism of
monetary incentive, which realizes an ecosystem with
network transmission bandwidth and payments as the
two primary factors of the system.
When payload transmissions on a BR-BGP path
start, the amount of the payload traffic must be
confirmed by both transmitting and receiving BRBGP routers on a BR-BGP link. For secure payload
traffic accounting, there are two requirements in
nonrepudiation, which are defined as follows:
(a) Sender repudiation: when a sender sends a
message to a destination and the message is
successfully delivered to the destination, the
sender can not deny to have sent that message to
the destination. This means that if a sender has
transmitted a certain amount of traffic to a BRBGP router through an already-established BRBGP path (and the traffic successfully reached the
router), the sender can not deny the transmission
of the message (thus the BR-BGP router is sure
for the payment for that network traffic).
(b) Sender masquerading by replays: free-riding on
an existing BR-BGP path using replays by a
malicious third party must be prevented. Two
BR-BGP routers on an active BR-BGP path must
uniquely identify each payload packet the
legitimate BR-BGP router transmits for accurate
charging, which can be performed using key
attributes such as secret BR-BGP path ID and
packet sequence number. However, encrypting
these attributes will not prevent such attacks,
since malicious third parties may intercept and
release the copies of them later (the patterns of
sequence number may be identified) for hijacking
existing BR-BGP paths.
The following procedure is used to eliminate the
two risks. When the first BR-BGP router (called “the
origin BR-BGP router, which is a BR-BGP router in
AS 4 in Figure 1(b)) constructs is REQ message, it
randomly generates a number (“Transferring AS’s
nonce (X)”), at least in a way it is hard for anyone to
predict the number. It becomes “X1,1”, which is the
first X in the first __ of ____, as well as another
random number (“Transferring AS’s salt ()”). The
first “” becomes “1”, which is the one for ______.
The parameter “D1” represents the number of a
sequence of “Xi,j” that are generated from “X1,1”.
Then, the whole REQ message is encrypted by the
public key of a receiving BR-BGP router (the one in
AS 5 in Figure 1(b)).
When the receiving BR-BGP router received the
REQ message, it decrypts the message using its
private key. The router generates its pairs of
Approving AS’s nonce (Y) and Approving AS’s salt
() in the same way the transmitting BR-BGP did for
its X and . The first “Y” generated by the receiving
BR-BGP routers becomes “Y1,1” and the first “”
becomes “1”. If the receiving BR-BGP router
agrees with “D1” in the REQ, it simply copies its
value to “D’1” to its ACK. The router adds constant
value 1 to X1.1 in the REQ. The receiving BR-BGP
router constructs an ACK message and encrypts the
whole message using the public key of the
transferring (requesting) BR-BGP router. See Figure
3 for this.
- A parameter generated by a transmitting BR-BGP router
- A parameter generated by a receiving BR-BGP router
Sender
X1,1
1
Receiver
D1
Y1,1
1
D1’
X1,2 = X1,1 + 1
X1,3 = X1,2 + 1
Y1,2 = X1,2 + 1
X1,D-1 = X1,D-2 + 1
Time
X1,D = X1,D-1 + 1
  
  
  
Y1,3 = X1,3 + 1
Y1,D-1 = X1,D-1 + 1
X1,D = X1,D + 1
Figure 3 – the BR-BGP procedure for processing
each payload packet
When the transferring BR-BGP router receives an
ACK from the receiving BR-BGP router, it
constructs a PALD message in the following way.
The router calculates X1,2 by X1,2 = X1,1 + . The
value of Y is updated by Y1,1 + 1. Then, the whole
PALD message is encrypted by the public key of the
receiving BR-BGP router. The transferring BR-BGP
router then transmits the PALD message to the
receiving BR-BGP router as it is piggy-backed to the
first payload message.
When the receiving BR-BGP router receives this
PALD message, it performs the procedure in Figure 4.
Using i, the receiving BR-BGP router can calculates
Xi,j from Xi,(j-1) (since Xi,j = Xi,(j-1) + i) at the same
time the receiving BR-BGP router uses “Yi,(j-1) + 1” in
the PLAD message to verify if this PLAD is from the
transmitting BR-BGP router (but not from anyone
else) since Yi,j in the ACK message is encrypted by
the public key of the transmitting BR-BGP router.
Only the right transferring BR-BGP router can
correctly decrypt Yi,j in the ACK (as a response to a
REQ) and the transferring BR-BGP encrypts Yi,j
using the receiving BR-BGP router’s public key after
Yi,j is increased by the transferring BR-BGP router.
This eliminates the possibility of replay attacks, by
someone who masquerades to be the transferring BRBGP router. The confirmed “Yi.j + 1” (confirmed at
the receiving BR-BGP router) guarantees no
repudiation by the transferring BR-BGP router.
1. Decrypt the PALD message using its private
key.
2. Extract (Xi,j) and (Yi,j-1 + 1) from the PALD
message and compare them with their local
copies. If they match, proceed to 3. Otherwise
simply drop the whole payload message.
3. Compare the actual payload size and the
declared payload size (i.e., the value of “S”
attribute in the PALD message). If they match,
proceed to (4). Otherwise send a NPACK to
the transmitting BR-BGP router.
4. Update the account information (e.g., the total
amount of traffic load that went through the
BR-BGP link for charging purpose).
5. Construct a PACK message in the following
way. First, the router calculates Yi,j by Yi,j =
Xi,j + i (e.g., Y1,2 = X1,2 + 1).
6. Encrypt all the attributes in the PACK using the
public key of the transmitting BR-BGP router.
7. Send the PACK message to the transmitting
BR-BGP router.
Figure 4 When the transferring BR-BGP router receives a
PACK message from the receiving BR-BGP router, it
performs the procedure in Figure 5. Using i, the
transferring BR-BGP outer calculates “Y’i,(j+1)” as
Y’i,(j+1) = Yi,j + i. It decrypts the PACK message
using its private key, extracts Yi,(j+1), and compares
Yi,(j+1) and Y’i,(j+1). This procedure makes sure that
the PACK is from the correct receiving BR-BGP
router.
The values of  and  should be changed once in a
while to prevent any third party from estimating their
values to eliminate a chance of replays. To achieve
this goal, two additional message types of RENEW
and RACK are used. Before the transferring BRBGP router transmits as many as Di payload
messages, it is expected to issue a RENEW message
to the receiving BR-BGP router.
A RENEW
message is inserted between two payload messages
from a transferring to a receiving BR-BGP routers
and the message is authenticated by (Xi,j) and (Yi,j +
k), where k is the k-th message from the beginning of
a new  and  (see Figure 3). The new values of 
and  should be used after as many as Di payload
messages have been transmitted by the transferring
BR-BGP router.
An existing BR-BGP link can be terminated by
either a transferring or a receiving BR-BGP router
using a FIN message.
Each FIN message is
authenticated using Xi,j and Yi,j in the same way each
of PALD message is authenticated.
If an
intermediate receiving BR-BGP router initiates a FIN
message, a chain of FIN messages are propagated in
both directions (i.e., upstream and downstream of the
payload flow), which terminates an entire BR-BGP
path.
1. Decrypt the received PACK message using its
own private key.
2. Extract Yi,(j+1) from the PACK.
3. Locally calculate Y’i,(j+1) as Y’i,(j+1) = Yi,j + i.
4. Compare Yi,(j+1) in PACKi,j and Y’i,(j+1). If they
do no match, proceed to a process of error
recovery. Otherwise terminate this procedure
(success).
We propose a three-layer mechanism to achieve
universal, but less financially efficient, electric
payment system for the proposed ________. The
three layers are (1) payer-payee specific virtual
payment, (2) universal virtual payment, and (3)
payment by real currency (Figure 6) using multiple
layers of payment brokers. A payment broker is a
process that manages payments for BR-BGP traffic.
A group of ASs that often perform BR-BGP
transmissions become the members of a payment
broker, which becomes the lowest level payment
broker (Figure 7). The lowest level payment brokers
are the one who manage payment for BR-BGP traffic
for lowest tier ASs.
Mutual
Payment
Mutual
Payment
Payer-payee
Specific
Virtual
Payment
Universal
Virtual
Payment
Figure 5 –
Payment model
Through network traffic with beyond right will not
directly contribute to the own business of an ISP that
accepts such through network traffic. Such through
traffic can even negatively impact to an ISP’s own
business since handling through traffic consumes
networking resources. It is harmful to own business
even when ISPs have unutilized networking
resources, such as transmission bandwidth, since
sharing unutilized link bandwidth requires their prior
announcements to other ISPs.
Once link bandwidth is announced to other ISPs,
an announcing ISP may receive through network
traffic or BR-BGP path setup requests when it has no
unutilized transmission bandwidth on a peer link. To
encourage sharing link bandwidth and publishing
AS-peer connections to others despite these possible
disadvantages, some incentive is necessary for
encourage BR-BGP routing with beyond right.
Any form of electric payment that is good only for
a specific pair of two ISPs is not flexible enough.
This form of electric payment requires a payee to
convert the electric payment made by a payer. The
electric payment made by a specific payer to a
specific payee can not be used for payment to any
other payee. The electric payment method proposed
by ______ [0, 0, 0] belongs to this category.
If a receiving ISP wants to use the credit for
payment to other ISPs (i.e., if the receiving ISP
becomes a transferring ISP to others), this type of
electric payment is inefficient since each conversion
of virtual currency to real currency causes significant
conversion fee. This conversion fee can be a major
factor that discourage adoption of BR-BGP routing
with beyond rights.
Convert
Convert
Payment
by Real
Currency
Figure 6 – the three-layer payment model
AS connection tree
Payment broker tree
Tier i AS
Tier (i-1) AS
Tier (i-2) AS
Tier (i-3) AS
Figure 7 – Payment broker layers for different levels
of ASs
When an origin BR-BGP router transmits network
traffic through a BR-BGP path, intermediate BRBGP routers charge transmission fee based on the
traffic load. Intermediate BR-BGP routers represent
their ISPs, and charge transmission fee to an origin
BR-BGP ISP on behalf of for their home ISPs.
The ISP of the origin BR-BGP router makes
payment to each such of ISPs as payer-payee specific
virtual payment. The virtual currency in payer-payee
specific virtual payment should be used for mutual
payment between the two ISPs (i.e., if the receiving
ISP becomes the transferring ISP for the first
transferring ISP), which eliminates a need for
converting the virtual currency in payer-payee
specific virtual payment to the one for the universal
virtual payment.
If receiving ISPs do not have a chance to use the
virtual currency in payer-payee specific virtual
payment for transferring through traffic through a
transferring ISP, each of them can convert the virtual
currency in payer-payee specific virtual payment to
the one in the universal virtual payment. Using the
universal virtual currency, the credit for handling a
particular transferring ISP’s through traffic with
beyond right can be used as a mean for payment to
other ISPs, when this receiving ISP becomes a
transferring ISP to other ISPs in the Internet. This
allow ISPs who perform BR-BGP routing to
minimize their needs to convert their universal virtual
currency to real currency, which causes significant
amount of conversion fee.
Payment brokers in the lowest level form a group
and they become members of a payment broker in the
second lowest level, while payment brokers in the
second lowest level become members of a payment
broker in the upper level. A top-level payment
broker is for a tier-1 AS, who manages payments for
any BR-BGP traffic generated by any AS under its
provider-customer relations. Finally, those tier-1
payment brokers form a mesh interconnections to
resolve payments between two ASs that belong to
different tier-1 ASs (Figure 8).
F
R105
B
R11
R1
R3
R102
E
C
R2
R12
R104
A
R101
R14
R103
D
R13
- AS
Universal
Virtual
Payment
- Payment Broker
Figure 8 –
In Figure 8, AS A and B belong to a lowest-level
payment broker, R101. When A makes a payment to B,
the payment is made by a payee-payer specific
payment using R101’s broker-local virtual payment.
After B receives A’s payment, B can use the payment
from A for its payment to other AS (e.g., AS C), first
using R101’s broker-local virtual payment, which is
exchanged to R11 and R102’s broker-local virtual
payment. When C makes a payment to another AS,
D, the payment will be made using the same
procedure, but using the broker-local virtual payment
of R2.
When an AS makes payment to other ASs who
belong to other tier-1 ASs (i.e., those who belong to
other top-level payment brokers), the payment is first
exchanged to the universal virtual currency. For
example, when D makes a payment to E, who
belongs to another top-level payment broker (R3), the
payment by D is first exchanged to the universal
currency at R2 before it is transferred to R3. When R3
receives the payment by D in the universal virtual
currency, the payment is exchanged to the brokerlocal virtual payment of R3, R13, and R104 in that
before E receives the payment from D. Payments by
E to other ASs who belong to different tier-1 ASs
(e.g., F) can be performed in the same way, using the
credit (payment) that originated from A.
Why this mechanism?
The proposed ____ provides a mechanism to
flexibly resolve payment arrangements from a paying
AS to a payee AS in two different ways: direct
payments and proxy payments. Consider a following
case. AS 4 is the origin AS of a BR-BGP
transmission using a BR-BGP path, 4-5-2-3-7, in
which 5-2 and 2-3 are BR-BGP links (Figure 9 (a)).
Direct payment: an origin AS makes payment to
the intermediate ASs that have carried the origin
AS’s BR-BGP traffic (Figure 9 (b)). Then, the origin
AS (i.e., AS 4) makes a request for imbursement to
its provider AS (i.e., AS 1). If the requested amount
of the reimbursement is less than the fee the provider
AS charges to AS 4, AS 1 can reimburse the payment
by subtracting the connection fee 4 usually pays to 1.
Direct payment is performed using the following
procedure. Direct payments are performed using two
messages of Payment Request (PR) and Payment
Confirmation (PC) messages.
First, AS 5 and 2 send a PR (PR5 and PR2
respectively) to 4 for requesting payment. AS 4
responds to each of the PR messages by a PC
message, confirming its willingness for the payment.
Actual payment will be performed by AS 4 after it
issues the PC messages.
Proxy payment: an origin AS makes a proxy
payment request to an AS that is responsible for the
cause of a BR-BGP traffic (Figure 9 (c)). For
example, when AS 5 requests a payment to 4 for 4’s
BR-BGP traffic through it, AS 4 requests AS 1 to
make a payment to AS 5 for AS 4.
If AS 4 requests another AS, typically its provider
(e.g., AS 1), to make a payment for 4 (assuming that
it is AS 1’s failure that necessitates AS 4 to generate
the BR-BGP transmission and that there is a prior
agreement for the payment between AS 1 and 4), on
arrival of a PR message (e.g., PR5), AS 4 forwards
the PR message to AS 1. AS 1 then confirms the
payment to AS 5 on behalf of AS 4 by sending a PC
message to AS 5 (e.g., PC5).
(a) a BR-BGP transmission through a BR-BGP path 4-5-2-3-7
4
2
5
BR-BGP link
BGP peering link
7
3
- Origin AS
-
1
PC2
PR5
PC5
4
2
5
Destination or
intermediate AS
3
PR5
PR2
(b) Direct payment by an origin AS (AS 4)
7
PC5
PC2
PR2
4
2
5
3
PR5
PR2
(c) Proxy payment by a provider AS (AS 1)
7
Figure 9 – Two payment methods of direct and
proxy payments
4. Performance evaluation (“assessment”?)
(a) Theoretical analysis
(b) Prototyping
5. Conclusions and Future Work
 Analysis of the current domain interconnections
in the Internet to assess the effectiveness of the
proposed SDN-based network traffic control.
 Using simulation, the effectiveness of the
proposed SDN-based routing will be studied.
 The overhead of performing the proposed SDNbased routing will be studied.
References
[a] Lixin Gao, “On Inferring Autonomous System
Relationships in the Internet,” IEEE/ACM
Transactions on Networking, vol. 9, no. 6, pp.
733-745, December 2001.
[b] Hiroshi Fujinoki and Andrew Hauck, “Analysis
on the Current and the Future Internet Structure
Regarding Multi-homed and Multi-path Routing,”
Journal of Internet Services and Applications, vol.
2, no. 3, pp. 257-270, November 2011.
[0] RFC 5151
Inter-Domain MPLS & GMPLS
RSVP-TE Extensions February 2008.