aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--openbsc/src/gprs/gtphub.c69
1 files changed, 0 insertions, 69 deletions
diff --git a/openbsc/src/gprs/gtphub.c b/openbsc/src/gprs/gtphub.c
index 95bf7f79..f21eb98d 100644
--- a/openbsc/src/gprs/gtphub.c
+++ b/openbsc/src/gprs/gtphub.c
@@ -1017,75 +1017,6 @@ static void gtphub_map_restart_counter(struct gtphub *hub,
/* TODO */
}
-/* gtphub_map_ie_teis() and gtphub_unmap_header_tei():
- *
- * TEI mapping must happen symmetrically. An SGSN contacts gtphub instead of N
- * GGSNs, and a GGSN replies to gtphub for N SGSNs. From either end, TEIs may
- * collide: two GGSNs picking the same TEIs, or two SGSNs picking the same
- * TEIs. Since the opposite side sees the sender address being gtphub's
- * address, TEIs among the SGSNs, and among the GGSNs, must not overlap. If a
- * peer sends a TEI already sent before from a peer of the same side, gtphub
- * replaces it with a TEI not yet seen from that side and remembers the
- * mapping.
- *
- * Consider two SGSNs A and B contacting two GGSNs C and D thru gtphub.
- *
- * A: Create PDP Ctx, I have TEI 1.
- * ---> gtphub: A has TEI 1, sending 1 for C.
- * ---> C: gtphub has TEI 1.
- * <--- C: Response to TEI 1: I have TEI 11.
- * <--- gtphub: ok, telling A: 11.
- * A: gtphub's first TEI is 11. (1)
- *
- * B: Create PDP Ctx, I have TEIs 1.
- * ---> gtphub: 1 already taken for C, sending 2 for B. (map)
- * ---> C: gtphub also has 2.
- * <--- C: Response to TEI 2: I have TEI 12.
- * <--- gtphub: ok, TEI 2 is actually B with TEI 1. (unmap)
- * B: gtphub's first TEI is 12, as far as I can tell.
- *
- * Now the second GGSN comes into play:
- *
- * A: Create PDP Ctx, I have TEI 2.
- * ---> gtphub: A also has TEI 2, but for D, sending 1. (2)
- * ---> D: gtphub has 1.
- * <--- D: Response to TEI 1: I have TEI 11.
- * <--- gtphub: from D, 1 is A. 11 already taken by C, sending 13. (3)
- * A: gtphub also has TEI 13. (4)
- *
- * And some messages routed through:
- *
- * A: message to TEI 11, see (1).
- * ---> gtphub: ok, telling C with TEI 11.
- * ---> C: I see, 11 means reply with 1.
- * <--- C: Response to TEI 1
- * <--- gtphub: 1 from C is actually for A with TEI 1.
- * A: ah, my TEI 1, thanks!
- *
- * A: message to TEI 13, see (4).
- * ---> gtphub: ok, but not 13, D wanted TEI 11 instead, see (3).
- * ---> D: I see, 11 means reply with 1.
- * <--- D: Response to TEI 1
- * <--- gtphub: 1 from D is actually for A with TEI 2, see (2).
- * A: ah, my TEI 2, thanks!
- *
- * What if a GGSN initiates a request:
- *
- * <--- D: Request to gtphub TEI 1
- * <--- gtphub: 1 from D is for A with 2, see (2).
- * A: my TEI 2 means reply with 13.
- * ---> gtphub: 13 was D with 11, see (3).
- * ---> D: 11 from gtphub: a reply to my request for TEI 1.
- *
- * Note that usually, it's the sequence numbers that route a response back to
- * the requesting peer. Nevertheless, the TEI mappings must be carried out to
- * replace the TEIs in the GTP packet that is relayed.
- *
- * Also note: the TEI in the GTP header is "reversed" from the TEI in the IEs:
- * the TEI in the header is used to send something *to* a peer, while the TEI
- * in e.g. a Create PDP Context Request's IE is for routing messages *back*
- * later. */
-
static int gtphub_unmap_header_tei(struct gtphub_peer_port **to_port_p,
struct gtphub *hub,
struct gtp_packet_desc *p,