Software-defined networking আর NFV

১ · সমস্যা — বাক্সে বন্দি নেটওয়ার্ক

পর্ব ১৫-এ দেখেছেন, প্রতিটি router-এর ভেতরে দুটি কাজ: forwarding (প্রতিটি packet-কে টেবিল দেখে সঠিক port-এ পাঠানো) আর routing (পুরো নেটওয়ার্ক মিলিয়ে সেই টেবিল বানানো)। প্রচলিত নেটওয়ার্কে এই দুটি কাজ একই বাক্সে, একই কোম্পানির বানানো hardware আর software-এ। মডিউল ৪-এর OSPF আর BGP প্রতিটি router-এ আলাদাভাবে চলে, প্রতিবেশীদের সাথে কথা বলে, আর প্রত্যেকে নিজে নিজের টেবিল হিসাব করে। এই নকশা ইন্টারনেটকে টিকিয়ে রেখেছে কয়েক দশক। তবু বড় নেটওয়ার্ক চালানো প্রকৌশলীরা ২০০০-এর দশকে কয়েকটি সমস্যায় আটকে যাচ্ছিলেন।

প্রচলিত নেটওয়ার্কের পাঁচটি ব্যথা

২ · SDN-এর চারটি মূল ধারণা আর স্থাপত্য

বিভিন্ন বই আর গবেষণাপত্র SDN-কে একটু আলাদাভাবে সংজ্ঞায়িত করে, কিন্তু প্রায় সবাই এই চারটি ধারণায় একমত:

স্থাপত্য — তিন স্তর, দুই API

 ┌──────────────────────────────────────────────────────────┐
 │  Network applications: routing │ firewall │ LB │ TE │ ... │
 └──────────────────────────┬───────────────────────────────┘
          northbound API (REST/gRPC, intent) ▲▼
 ┌──────────────────────────┴───────────────────────────────┐
 │  SDN controller (replicated: C1 C2 C3)                   │
 │  topology graph │ host table │ flow rules │ statistics   │
 └──────────────────────────┬───────────────────────────────┘
   southbound API (OpenFlow, P4Runtime, NETCONF/gNMI) ▲▼
 ┌────────┐      ┌────────┐      ┌────────┐      ┌────────┐
 │ switch │──────│ switch │──────│ switch │──────│ switch │
 │ flow   │      │ flow   │      │ flow   │      │ flow   │
 │ table  │      │ table  │      │ table  │      │ table  │
 └────────┘      └────────┘      └────────┘      └────────┘
 ◀───────────── data plane: packets never visit the controller
                (except PACKET_IN) ─────────────────────────▶

• Southbound API — controller আর switch-এর মাঝের ভাষা। সবচেয়ে পরিচিত OpenFlow (সাধারণত TCP port 6653-এ, নিরাপত্তার জন্য TLS-এর ওপর)। P4 দিয়ে বানানো data plane-এর জন্য P4Runtime; আর কনফিগারেশন ও অবস্থা পড়ার জন্য NETCONF (RFC 6241) বা gRPC-ভিত্তিক gNMI, যারা YANG মডেলে লেখা ডেটা বিনিময় করে।
• Controller — নেটওয়ার্কের “operating system”. Switch-এর সাথে সংযোগ রাখে, LLDP জাতীয় বার্তা পাঠিয়ে কোন switch-এর কোন port কোথায় যুক্ত তা খুঁজে topology graph বানায়, host-দের অবস্থান মনে রাখে, counter জমায়। মুক্ত-উৎসের পরিচিত controller-এর মধ্যে আছে ONOS আর OpenDaylight (দুটিই ২০১৩–২০১৪ সালের দিকে শুরু, বড় নেটওয়ার্কের জন্য নকশা করা), আর শেখার জন্য Python-এর ছোট controller যেমন Ryu বা POX. বাণিজ্যিক নেটওয়ার্কে প্রায়ই vendor-এর নিজস্ব controller.
• Northbound API — application আর controller-এর মাঝের ভাষা; সাধারণত REST বা gRPC. এখানে application বলে “h1 থেকে h2-তে একটি পথ চাই” বা “এই subnet থেকে port 23 বন্ধ”, আর controller সেটিকে প্রতিটি switch-এর নিয়মে অনুবাদ করে।
• Application — shortest-path routing, firewall, load balancer, traffic engineering, নজরদারি। একই নেটওয়ার্কে কয়েকটি application একসাথে চললে তাদের নিয়মে সংঘাত হতে পারে — controller-কে সেটিও সামলাতে হয়।

৩ · OpenFlow-এর ভেতরে — flow table, বার্তা আর table-miss

OpenFlow-ধাঁচের switch-এর হৃদয় তার flow table. প্রতিটি সারিকে বলে flow entry, আর তাতে থাকে:

আধুনিক OpenFlow-এ (১.৩ সংস্করণ, যা সবচেয়ে বেশি ব্যবহৃত বলে ধরা হয়) একাধিক টেবিলের একটি pipeline থাকে, আর goto-table দিয়ে packet এক টেবিল থেকে আরেক টেবিলে যায় — যেমন প্রথম টেবিলে ACL, দ্বিতীয়টিতে MAC, তৃতীয়টিতে IP. সাথে আছে group table, যেখানে একটি “fast-failover” group-এ কয়েকটি বিকল্প port রাখা যায় — প্রথমটি নষ্ট হলে switch নিজেই দ্বিতীয়টি নেয়, controller-কে জিজ্ঞেস না করে।

Controller আর switch-এর কথোপকথন

Table-miss: কোনো সারি না মিললে কী হবে? OpenFlow ১.৩-এ এর জন্য একটি বিশেষ সারি রাখা হয় — priority ০, সব ঘর wildcard, action “controller-এ পাঠানো”। এই সারি না থাকলে ১.৩-এ ডিফল্ট আচরণ packet ফেলে দেওয়া (পুরোনো ১.০-তে ডিফল্ট ছিল controller-এ পাঠানো)। তাই সংযোগের শুরুতেই controller সাধারণত এই table-miss সারিটি বসিয়ে দেয়।

নিচের simulator একটি ছোট OpenFlow-ধাঁচের switch: পাঁচটি সারি, ছয়টি packet. যে ঘর m-এ নেই তা wildcard; IP-র ক্ষেত্রে prefix মেলানো হয় (পর্ব ১৫-এর মতো mask দিয়ে)। প্রতিটি packet-এর জন্য ছাপা হয় কোন কোন সারি মিলল, কোনটি জিতল, আর শেষে প্রতিটি সারির counter.

// A tiny OpenFlow-style switch. A field missing from "m" is a wildcard (matches anything).
const table = [
  { id: "F1", prio: 300, m: { ip_proto: "tcp", tp_dst: 23 },        act: "drop" },
  { id: "F2", prio: 200, m: { ipv4_dst: "10.0.2.0/24" },             act: "output:2" },
  { id: "F3", prio: 100, m: { in_port: 1, eth_type: "arp" },          act: "flood" },
  { id: "F4", prio: 50,  m: { ipv4_dst: "10.0.0.0/16", tp_dst: 80 },  act: "set_field:vlan_vid=20, output:3" },
  { id: "MISS", prio: 0, m: {},                                       act: "CONTROLLER (packet-in)" },
].map(e => ({ ...e, pkts: 0, bytes: 0 }));
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
function fieldOk(k, want, pkt) {
  if (pkt[k] === undefined) return false;
  if (k === "ipv4_dst") {
    const [net, len] = want.split("/"), mask = len == 0 ? 0 : (0xffffffff << (32 - len)) >>> 0;
    return ((ip(pkt[k]) & mask) >>> 0) === ((ip(net) & mask) >>> 0);
  }
  return pkt[k] === want;
}
function handle(pkt) {
  const hits = table.filter(e => Object.entries(e.m).every(([k, v]) => fieldOk(k, v, pkt)));
  const e = hits.reduce((a, b) => (b.prio > a.prio ? b : a));   // highest priority wins
  e.pkts += 1; e.bytes += pkt.len;
  const what = pkt.eth_type === "arp" ? "ARP" : `${pkt.ip_proto} ->${pkt.ipv4_dst}:${pkt.tp_dst}`;
  console.log(`in:${pkt.in_port} ${what.padEnd(22)} hits=${hits.map(h => h.id).join(",").padEnd(10)} => ${e.id}: ${e.act}`);
}
[ { in_port: 1, eth_type: "ip", ip_proto: "tcp", ipv4_dst: "10.0.2.9", tp_dst: 23, len: 60 },
  { in_port: 1, eth_type: "ip", ip_proto: "tcp", ipv4_dst: "10.0.2.9", tp_dst: 443, len: 1500 },
  { in_port: 1, eth_type: "arp", len: 42 },
  { in_port: 3, eth_type: "ip", ip_proto: "tcp", ipv4_dst: "10.0.7.7", tp_dst: 80, len: 800 },
  { in_port: 2, eth_type: "ip", ip_proto: "udp", ipv4_dst: "192.0.2.8", tp_dst: 53, len: 70 },
  { in_port: 4, eth_type: "ip", ip_proto: "tcp", ipv4_dst: "10.0.9.1", tp_dst: 23, len: 60 },
].forEach(handle);
console.log("counters: " + table.map(e => `${e.id}=${e.pkts}pkt/${e.bytes}B`).join("  "));

in:1 tcp ->10.0.2.9:23      hits=F1,F2,MISS => F1: drop
in:1 tcp ->10.0.2.9:443     hits=F2,MISS    => F2: output:2
in:1 ARP                    hits=F3,MISS    => F3: flood
in:3 tcp ->10.0.7.7:80      hits=F4,MISS    => F4: set_field:vlan_vid=20, output:3
in:2 udp ->192.0.2.8:53     hits=MISS       => MISS: CONTROLLER (packet-in)
in:4 tcp ->10.0.9.1:23      hits=F1,MISS    => F1: drop
counters: F1=2pkt/120B  F2=1pkt/1500B  F3=1pkt/42B  F4=1pkt/800B  MISS=1pkt/70B

Proactive না reactive — নিয়ম কখন বসবে

হিসাব ১ — controller-এর চাপ: একটি ক্যাম্পাসে ৫০টি edge switch, প্রতিটিতে গড়ে প্রতি সেকেন্ডে ২,০০০টি নতুন flow (প্রতিটি নতুন TCP সংযোগ, DNS প্রশ্ন ইত্যাদি)। পুরো reactive নকশায় controller পায় ৫০ × ২,০০০ = ১,০০,০০০ PACKET_IN প্রতি সেকেন্ডে. ধরুন (উদাহরণের জন্য) একটি controller সার্ভার প্রতি সেকেন্ডে ৫০,০০০ PACKET_IN সামলাতে পারে। তাহলে পুরো ক্ষমতায় চালাতেও ২টি সার্ভার লাগে; অর্ধেক ক্ষমতায় চালাতে চাইলে (ঝাপটা আর একটি সার্ভার নষ্ট হওয়ার জন্য জায়গা রেখে) ৪টি। আর ঝাপটার সময় — সকাল ৯টায় সবাই একসাথে লগইন করলে — সংখ্যাটি কয়েক গুণ হতে পারে।

হিসাব ২ — TCAM-এর সীমা: একটি data center-এ ৩০০টি host. প্রতিটি (উৎস, গন্তব্য) জোড়ার জন্য আলাদা নিখুঁত নিয়ম রাখলে জোড়া = ৩০০ × ২৯৯ = ৮৯,৭০০টি নিয়ম। শুধু গন্তব্য ধরে নিয়ম রাখলে (উৎস wildcard) লাগে মাত্র ৩০০টি। ধরুন switch-এর TCAM-এ ২,০০০টি সারির জায়গা — প্রথম নকশা কখনো আঁটবে না, দ্বিতীয়টি আরামে আঁটে। Wildcard ঠিক এই কারণেই মূল্যবান (TCAM কেন সীমিত আর দামি, পর্ব ১৫)।

৪ · Controller-এর হাতে পথ — প্রথম packet, Dijkstra আর link failure

এবার একটি ছোট নেটওয়ার্ক: পাঁচটি switch, সাতটি link, প্রতিটি link-এর একটি cost. Host h1 (10.0.1.1) যুক্ত S1-এ, host h2 (10.0.4.2) যুক্ত S4-এ। Controller LLDP দিয়ে পুরো topology আগেই জানে, কিন্তু কোনো switch-এ h2-এর জন্য নিয়ম নেই — reactive নকশা।

            1          1
   h1 ── S1 ─────── S2 ─────── S4 ── h2
          │        ╱           │ ╲
        1 │     1 ╱          3 │  ╲ 1
          │      ╱             │   ╲
          S3 ──────────────────┘    S5
           ╲__________1_____________╱
   links: S1-S2 1, S2-S4 1, S1-S3 1, S2-S3 1, S3-S4 3, S3-S5 1, S5-S4 1

এই পুরো যুক্তি এবার কোডে। Controller application একটি সাধারণ JavaScript প্রোগ্রাম: dijkstra() পর্ব ২৪-এর algorithm (প্রতি ধাপে বাকি node-গুলোর মধ্যে সবচেয়ে কাছেরটি চূড়ান্ত), installPath() দূরের switch থেকে শুরু করে FLOW_MOD পাঠায়, আর send() হলো data plane — শুধু টেবিল দেখে hop থেকে hop. তিনটি packet পাঠানোর পর S2-S4 link নষ্ট হয়।

// SDN controller app: on packet-in run Dijkstra and install flow-mods; reroute on link-down.
const links = { "S1-S2": 1, "S2-S4": 1, "S1-S3": 1, "S3-S4": 3, "S2-S3": 1, "S3-S5": 1, "S5-S4": 1 };
const hostAt = { h1: "S1", h2: "S4" }, flows = {};  let pktIns = 0;   // flows[sw][dst] = next hop
const nbrs = u => Object.entries(links).filter(([k]) => k.split("-").includes(u))
  .map(([k, c]) => [k.split("-").find(x => x !== u), c]);
function dijkstra(src, dst) {
  const dist = { [src]: 0 }, prev = {}, done = new Set();
  for (let u = src; u && u !== dst; u = Object.keys(dist).filter(x => !done.has(x)).sort((a, b) => dist[a] - dist[b])[0]) {
    done.add(u);
    for (const [v, c] of nbrs(u)) if (!(v in dist) || dist[u] + c < dist[v]) { dist[v] = dist[u] + c; prev[v] = u; }
  }
  const path = [dst]; while (path[0] !== src) path.unshift(prev[path[0]]);
  return { path, cost: dist[dst] };
}
function installPath(dst) {                                 // controller: compute, then program switches
  const { path, cost } = dijkstra("S1", hostAt[dst]);
  console.log(`  controller: Dijkstra ${path.join(" > ")} (cost ${cost})`);
  for (let i = path.length - 1; i >= 0; i--) {              // far end first, ingress switch last
    const sw = path[i], out = i === path.length - 1 ? dst : path[i + 1], t = (flows[sw] ||= {});
    if (t[dst] === out) { console.log(`  ${sw}: rule already correct, no FLOW_MOD`); continue; }
    console.log(`  FLOW_MOD ${(t[dst] ? "MODIFY" : "ADD").padEnd(6)} ${sw}: ipv4_dst=${dst} => output:to-${out}`); t[dst] = out;
  }
  for (const sw in flows) if (!path.includes(sw) && flows[sw][dst]) {
    delete flows[sw][dst]; console.log(`  FLOW_MOD DELETE ${sw}: stale rule for ${dst}`);
  }
}
function send(dst) {                                        // data plane: switches follow their tables
  let sw = "S1"; const hops = [sw];
  while (flows[sw]?.[dst] && flows[sw][dst] !== dst) hops.push(sw = flows[sw][dst]);
  if (flows[sw]?.[dst]) return console.log(`h1->${dst}: ${hops.join(" > ")} > ${dst}  (packet-ins so far: ${pktIns})`);
  console.log(`h1->${dst}: table-miss at ${sw} -> PACKET_IN #${++pktIns}`);
  installPath(dst); console.log(`  PACKET_OUT ${sw}: release the held packet`);
}
send("h2"); send("h2"); send("h2");
console.log("EVENT: PORT_STATUS - link S2-S4 is down"); delete links["S2-S4"]; installPath("h2"); send("h2");

h1->h2: table-miss at S1 -> PACKET_IN #1
  controller: Dijkstra S1 > S2 > S4 (cost 2)
  FLOW_MOD ADD    S4: ipv4_dst=h2 => output:to-h2
  FLOW_MOD ADD    S2: ipv4_dst=h2 => output:to-S4
  FLOW_MOD ADD    S1: ipv4_dst=h2 => output:to-S2
  PACKET_OUT S1: release the held packet
h1->h2: S1 > S2 > S4 > h2  (packet-ins so far: 1)
h1->h2: S1 > S2 > S4 > h2  (packet-ins so far: 1)
EVENT: PORT_STATUS - link S2-S4 is down
  controller: Dijkstra S1 > S3 > S5 > S4 (cost 3)
  S4: rule already correct, no FLOW_MOD
  FLOW_MOD ADD    S5: ipv4_dst=h2 => output:to-S4
  FLOW_MOD ADD    S3: ipv4_dst=h2 => output:to-S5
  FLOW_MOD MODIFY S1: ipv4_dst=h2 => output:to-S3
  FLOW_MOD DELETE S2: stale rule for h2
h1->h2: S1 > S3 > S5 > S4 > h2  (packet-ins so far: 1)

এই উদাহরণে প্রতিটি switch-এর নিয়ম শুধু গন্তব্যের ওপর নির্ভর করে, ঠিক OSPF-এর মতো। পার্থক্য হলো হিসাবটা একবার, এক জায়গায় হয় — পর্ব ২৪-এ link state-এ প্রতিটি router একই Dijkstra আলাদাভাবে চালাত। তবে controller চাইলে এমন পথও বেছে নিতে পারে যা shortest path নয় — যেমন ভিডিও traffic এক পথে, ব্যাকআপ আরেক পথে। এটিই SDN-এর traffic engineering, যা MPLS-TE (পর্ব ২৬) বিতরণকৃতভাবে করত।

৫ · এক বিমূর্ততা, অনেক যন্ত্র — match-plus-action আর P4

পর্ব ১৫-এ একটি দাবি করেছিলাম: switch, router, firewall আর NAT আসলে একই কাজ করে — কিছু ঘর মেলানো, তারপর একটি কাজ। SDN এই দাবিকে বাস্তবে রূপ দেয়। পাশাপাশি দেখুন:

নিচের কোডে একটিই engine (fits আর priority দিয়ে সারি বাছাই), চারটি আলাদা নিয়মের সেট, আর একই তিনটি packet: p1 — ভেতরের host 10.1.2.7 থেকে বাইরের ওয়েবসাইটে HTTPS; p2 — বাইরে থেকে ফিরতি উত্তর, public ঠিকানা 203.0.113.7-এ; p3 — ভেতরেই আরেক subnet-এ SSH. Learning switch-এর ক্ষেত্রে প্রতিটি packet-এর উৎস MAC দেখে নতুন সারি যোগ হয় — এটি controller-এর একটি ছোট application-এর কাজ।

// One match-plus-action engine, four "devices" - only the rules differ.
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const inPfx = (a, p) => { const [n, l] = p.split("/"), m = l == 0 ? 0 : (0xffffffff << (32 - l)) >>> 0;
  return ((ip(a) & m) >>> 0) === ((ip(n) & m) >>> 0); };
const fits = (m, p) => Object.entries(m).every(([k, v]) => String(v).includes("/") ? inPfx(p[k], v) : p[k] === v);
const devices = {
  "L2 learning switch": [{ prio: 0, m: {}, a: "flood" }],     // rules for eth_dst are learned below
  "IPv4 router": [{ prio: 24, m: { dst: "10.1.9.0/24" }, a: "dec_ttl, output:4" },
    { prio: 24, m: { dst: "203.0.113.0/24" }, a: "dec_ttl, output:1" },
    { prio: 16, m: { dst: "10.1.0.0/16" }, a: "dec_ttl, output:2" }, { prio: 0, m: {}, a: "dec_ttl, output:3" }],
  "stateless firewall": [{ prio: 20, m: { dport: 443 }, a: "output:3" },
    { prio: 20, m: { src: "10.1.0.0/16", dport: 22 }, a: "output:2" }, { prio: 0, m: {}, a: "drop" }],
  "static NAT": [{ prio: 20, m: { dst: "10.1.0.0/16" }, a: "output:2 (no rewrite)" },
    { prio: 10, m: { src: "10.1.2.7" }, a: "set src=203.0.113.7, output:3" },
    { prio: 10, m: { dst: "203.0.113.7" }, a: "set dst=10.1.2.7, output:1" }, { prio: 0, m: {}, a: "drop" }],
};
const pkts = [
  { name: "p1 out ", in: 1, mac_src: "aa", mac_dst: "bb", src: "10.1.2.7", dst: "198.51.100.10", dport: 443 },
  { name: "p2 back", in: 3, mac_src: "bb", mac_dst: "aa", src: "198.51.100.10", dst: "203.0.113.7", dport: 51000 },
  { name: "p3 ssh ", in: 1, mac_src: "aa", mac_dst: "cc", src: "10.1.2.7", dst: "10.1.9.9", dport: 22 },
];
for (const [dev, table] of Object.entries(devices)) {
  console.log(`== ${dev} ==`);
  for (const p of pkts) {
    if (dev.startsWith("L2") && !table.some(e => e.m.mac_dst === p.mac_src))       // learn src MAC -> port
      table.push({ prio: 10, m: { mac_dst: p.mac_src }, a: `output:${p.in}` });
    const e = table.filter(e => fits(e.m, p)).sort((a, b) => b.prio - a.prio)[0];
    const key = dev.startsWith("L2") ? `mac ${p.mac_src}->${p.mac_dst}` : `${p.src}->${p.dst}:${p.dport}`;
    console.log(`  ${p.name} ${key.padEnd(32)} prio ${String(e.prio).padStart(2)} => ${e.a}`);
  }
}

== L2 learning switch ==
  p1 out  mac aa->bb                       prio  0 => flood
  p2 back mac bb->aa                       prio 10 => output:1
  p3 ssh  mac aa->cc                       prio  0 => flood
== IPv4 router ==
  p1 out  10.1.2.7->198.51.100.10:443      prio  0 => dec_ttl, output:3
  p2 back 198.51.100.10->203.0.113.7:51000 prio 24 => dec_ttl, output:1
  p3 ssh  10.1.2.7->10.1.9.9:22            prio 24 => dec_ttl, output:4
== stateless firewall ==
  p1 out  10.1.2.7->198.51.100.10:443      prio 20 => output:3
  p2 back 198.51.100.10->203.0.113.7:51000 prio  0 => drop
  p3 ssh  10.1.2.7->10.1.9.9:22            prio 20 => output:2
== static NAT ==
  p1 out  10.1.2.7->198.51.100.10:443      prio 10 => set src=203.0.113.7, output:3
  p2 back 198.51.100.10->203.0.113.7:51000 prio 10 => set dst=10.1.2.7, output:1
  p3 ssh  10.1.2.7->10.1.9.9:22            prio 20 => output:2 (no rewrite)

P4 — header-ও প্রোগ্রাম করা যায়

OpenFlow-এর একটি সীমা: switch কোন header-এর কোন ঘর চেনে, তা specification-এ বাঁধা। নতুন একটি protocol এলে (যেমন VXLAN-এর মতো নতুন encapsulation) নতুন OpenFlow সংস্করণ আর নতুন chip-এর অপেক্ষা। এই কারণে OpenFlow-এর match-এর ঘরের তালিকা সংস্করণে সংস্করণে বেড়েছে। ২০১৪ সালের একটি প্রবন্ধে (Bosshart ও সহকর্মীরা) প্রস্তাবিত P4 (Programming Protocol-independent Packet Processors) একটি ভাষা, যাতে লেখা যায়: (১) parser — packet-এর কোন byte-এ কোন header, কোন ঘর; (২) match-action টেবিল — কোন ঘর মেলানো হবে; (৩) action — কী করা হবে। এই প্রোগ্রাম compile হয়ে programmable chip-এ বা software switch-এ চলে, আর controller টেবিলের সারি লেখে P4Runtime দিয়ে। অর্থাৎ OpenFlow দেয় “টেবিলের সারি লেখার স্বাধীনতা”, P4 দেয় “টেবিলের নকশা করার স্বাধীনতা”। বাস্তবে programmable chip-এর বাজার আর কোন কোম্পানি তা বানায় তা সময়ের সাথে বদলেছে; ধারণাটি গবেষণা আর কিছু বড় data center-এ জনপ্রিয়, সাধারণ অফিসের নেটওয়ার্কে কম।

// P4-ধাঁচের ধারণা (সংক্ষিপ্ত উদাহরণ, পূর্ণ প্রোগ্রাম নয়)
table ipv4_lpm {
    key     = { hdr.ipv4.dstAddr : lpm; }      // match: longest prefix
    actions = { ipv4_forward; drop; }           // ipv4_forward(mac, port)
    size    = 1024;
    default_action = drop();
}

৬ · বাস্তবে SDN — B4, data center, SD-WAN আর চ্যালেঞ্জ

চারটি বড় চ্যালেঞ্জ

• Controller যেন single point of failure না হয়: তাই controller চলে ৩ বা ৫টি সার্ভারের cluster-এ, যারা Raft বা Paxos-এর মতো consensus দিয়ে অবস্থা মেলায় (ডেটাবেসের প্রতিলিপির মতো সমস্যা, বিতরণকৃত ডেটাবেস)। Switch প্রতিটি controller-এর সাথে যুক্ত থাকে; OpenFlow-এ একটি master আর বাকিরা slave বা equal ভূমিকায়। সব controller হারালে switch কী করবে, সেটিও ঠিক করা থাকে: “fail secure” মোডে পুরোনো নিয়ম চলতে থাকে (নতুন flow-এর packet ফেলা হয়), “fail standalone” মোডে switch সাধারণ learning switch-এর মতো আচরণ শুরু করে।
• Scalability: অংশ ৩-এর হিসাব — reactive নকশায় PACKET_IN-এর ঝড়, আর TCAM-এর সীমিত জায়গা। সমাধান: proactive নিয়ম, wildcard, স্তরভিত্তিক বা অঞ্চলভিত্তিক controller.
• Controller-এর নিরাপত্তা: Controller-এ ঢুকতে পারলে পুরো নেটওয়ার্ক কারও হাতে — তাই প্রতিরক্ষা কেন্দ্রেও কেন্দ্রীভূত: control channel-এ TLS (পর্ব ৪৮), controller-কে আলাদা management নেটওয়ার্কে রাখা, northbound API-তে শক্ত পরিচয় যাচাই আর ভূমিকাভিত্তিক অনুমতি, প্রতিটি application-এর নিয়মের সীমা, আর সব বদলের লগ। আবার একই কেন্দ্রীয়তা প্রতিরক্ষার হাতিয়ারও: IDS (পর্ব ৫০) কোনো আক্রান্ত যন্ত্র চিহ্নিত করলে controller এক FLOW_MOD-এ তাকে আলাদা করে ফেলতে পারে।
• নিয়ম বদলের সময় অসংগতি: ৫টি switch-এ নিয়ম বদলাতে কয়েক মিলিসেকেন্ড লাগে, আর ঠিক সেই সময়ে পথে থাকা packet হয়তো কিছু switch-এ পুরোনো, কিছুতে নতুন নিয়ম দেখে — loop, black hole, এমনকি firewall-কে পাশ কাটানো পথ তৈরি হতে পারে। অংশ ৪-এ “দূরের switch আগে” কৌশল সরল ক্ষেত্রে কাজ করে; সাধারণ সমাধান হলো two-phase update, ২০১২ সালের দিকে Reitblatt ও সহকর্মীদের “consistent update” ধারণা।

৭ · NFV — বাক্সের কাজ software-এ

SDN প্রশ্ন করেছিল “switch-এর মস্তিষ্ক কোথায় থাকবে?” NFV-র প্রশ্ন আলাদা: “firewall, NAT, load balancer-এর মতো network function কি বিশেষ বাক্সেই চলতে হবে?” টেলিকম অপারেটরদের নেটওয়ার্ক ভর্তি ছিল এমন বাক্সে — প্রতিটি নতুন সেবার জন্য নতুন বাক্স, নতুন vendor, নতুন তার, নতুন প্রশিক্ষণ। ২০১২ সালের শেষ দিকে কয়েকটি বড় টেলিকম অপারেটর একটি white paper-এ প্রস্তাব দেয়: এসব কাজ চলুক সাধারণ (commodity) সার্ভারে, virtual machine বা container-এ, software হিসেবে। এরপর ইউরোপের মান সংস্থা ETSI-তে NFV-র একটি দল এর কাঠামো তৈরি করে।

ETSI-র কাঠামো — তিনটি অংশ

 ┌────────────────────────────────────────┐   ┌──────────────────┐
 │  VNFs:  vFirewall │ vNAT │ vLB │ vEPC   │◀──│ NFV MANO         │
 └────────────────────────────────────────┘   │  NFVO  (সেবা ও   │
 ┌────────────────────────────────────────┐   │        chain)    │
 │  NFVI: virtual compute │ storage │ net │◀──│  VNFM  (প্রতিটি  │
 │        hypervisor / container runtime  │   │        VNF-এর    │
 │        commodity servers, NICs, switch │   │        জীবনচক্র) │
 └────────────────────────────────────────┘   │  VIM   (যেমন     │
                                              │        OpenStack)│
                                              └──────────────────┘

• VNF (Virtualized Network Function): software রূপে একটি network function — virtual firewall, NAT, load balancer, DPI, মোবাইল নেটওয়ার্কের core (4G-র EPC বা 5G core-এর অংশ)।
• NFVI (NFV Infrastructure): সার্ভার, storage, নেটওয়ার্ক আর তার ওপর hypervisor বা container runtime — VNF যেখানে চলে।
• MANO (Management and Orchestration): NFVO পুরো সেবা আর chain সামলায়, VNFM প্রতিটি VNF চালু, বড়-ছোট (scale) আর বন্ধ করে, আর VIM (প্রায়ই OpenStack বা Kubernetes) NFVI-র resource বণ্টন করে। এই নামগুলো ETSI-র নথি থেকে; বাস্তব পণ্যে ভাগাভাগি আলাদা হতে পারে।

Service function chaining

একটি packet-কে প্রায়ই কয়েকটি function পার হতে হয় নির্দিষ্ট ক্রমে — যেমন firewall → NAT → load balancer. বাক্সের যুগে এই ক্রম ঠিক হতো তার জুড়ে; NFV-তে ক্রম ঠিক করে software — virtual switch-এর flow নিয়ম (এখানেই SDN আর NFV মেলে)। এর নাম service function chaining (SFC); IETF-এ এর স্থাপত্য RFC 7665, আর chain-এর তথ্য packet-এ বহন করার একটি header NSH (RFC 8300). নিচের simulator তিনটি VNF-কে তিনটি function হিসেবে সাজায়; load balancer একই 5-tuple-কে সবসময় একই backend-এ পাঠায় (hash দিয়ে), যাতে একটি TCP সংযোগ মাঝপথে অন্য সার্ভারে না যায়।

// Service function chain: three VNFs (software on one server), packet goes firewall -> NAT -> LB.
const backends = ["10.0.0.11", "10.0.0.12", "10.0.0.13"];
const hash = s => [...s].reduce((h, ch) => (h * 31 + ch.charCodeAt(0)) >>> 0, 7);
const vnfs = [
  ["firewall", p => (p.proto === "tcp" && p.dport === 443 ? p : null)],     // allow HTTPS only
  ["NAT", p => (p.dst === "203.0.113.10" ? { ...p, dst: "10.0.0.10" } : p)],  // public VIP -> private VIP
  ["LB", p => {                                                              // same 5-tuple -> same backend
    const key = [p.proto, p.src, p.sport, p.dst, p.dport].join("|");
    return { ...p, dst: backends[hash(key) % backends.length] };
  }],
];
const stats = { firewall: 0, NAT: 0, LB: 0, dropped: 0 };
const show = p => `${p.src}:${p.sport} -> ${p.dst}:${p.dport}`;
function chain(p) {
  let out = `${show(p).padEnd(36)}`;
  for (const [name, fn] of vnfs) {
    stats[name]++; p = fn(p);
    if (!p) { stats.dropped++; return console.log(out + ` | ${name}: DROP`); }
  }
  console.log(out + ` | delivered as ${show(p)}`);
}
[ { proto: "tcp", src: "198.51.100.5", sport: 40001, dst: "203.0.113.10", dport: 443 },
  { proto: "tcp", src: "198.51.100.5", sport: 40002, dst: "203.0.113.10", dport: 443 },
  { proto: "tcp", src: "192.0.2.77", sport: 52000, dst: "203.0.113.10", dport: 443 },
  { proto: "tcp", src: "192.0.2.66", sport: 33333, dst: "203.0.113.10", dport: 23 },
  { proto: "tcp", src: "198.51.100.5", sport: 40001, dst: "203.0.113.10", dport: 443 },
].forEach(chain);
console.log("packets seen per VNF:", JSON.stringify(stats));

198.51.100.5:40001 -> 203.0.113.10:443 | delivered as 198.51.100.5:40001 -> 10.0.0.11:443
198.51.100.5:40002 -> 203.0.113.10:443 | delivered as 198.51.100.5:40002 -> 10.0.0.12:443
192.0.2.77:52000 -> 203.0.113.10:443 | delivered as 192.0.2.77:52000 -> 10.0.0.11:443
192.0.2.66:33333 -> 203.0.113.10:23  | firewall: DROP
198.51.100.5:40001 -> 203.0.113.10:443 | delivered as 198.51.100.5:40001 -> 10.0.0.11:443
packets seen per VNF: {"firewall":5,"NAT":4,"LB":4,"dropped":1}

৮ · SDN বনাম NFV, 5G-র cloud-native core আর network automation

VNF থেকে CNF — আর 5G-র service-based core

প্রথম যুগের VNF ছিল পুরোনো বাক্সের software-কে প্রায় অপরিবর্তিত VM-এ তুলে দেওয়া — একটি বড় VM, হাতে হাতে কনফিগারেশন। পরের ধাপ CNF (cloud-native network function): function-কে ছোট ছোট microservice-এ ভাগ করে container-এ চালানো, Kubernetes দিয়ে স্বয়ংক্রিয়ভাবে বড়-ছোট আর পুনরায় চালু করা (container আর orchestration-এর ভিত্তি অপারেটিং সিস্টেম কোর্সের container পর্বে)। মোবাইল নেটওয়ার্কের 5G core এই চিন্তায় নকশা করা: 3GPP-র নকশায় core-এর প্রতিটি অংশ (যেমন সংযোগ ও চলাচল সামলানো AMF, session সামলানো SMF, ব্যবহারকারীর ডেটা বহনকারী UPF) একটি “network function”, আর তারা একে অপরের সাথে HTTP/2-ভিত্তিক API-তে কথা বলে — একে বলে service-based architecture (SBA). লক্ষ করুন, SMF (নিয়ন্ত্রণ) আর UPF (ডেটা পাঠানো) আলাদা — ঠিক SDN-এর control আর data plane-এর মতো ভাগ। মোবাইল নেটওয়ার্কের বিস্তারিত পর্ব ৫১-এ।

Intent-based networking আর automation — প্রতিদিনের SDN

বেশিরভাগ নেটওয়ার্ক প্রকৌশলী OpenFlow controller লেখেন না। কিন্তু SDN-এর মূল শিক্ষা — “নেটওয়ার্ককে যন্ত্র ধরে ধরে নয়, কোড আর ডেটা দিয়ে চালানো” — আজ প্রায় সবার কাজের অংশ:

• মডেলভিত্তিক কনফিগারেশন: যন্ত্রের অবস্থা আর কনফিগারেশন YANG মডেলে লেখা ডেটা, যা NETCONF, RESTCONF (RFC 8040) বা gNMI দিয়ে পড়া-লেখা হয়। CLI-এর লেখা পার্স করার বদলে কাঠামোবদ্ধ ডেটা; আর NETCONF-এ পুরো পরিবর্তন একসাথে প্রয়োগ বা বাতিল (transaction) করা যায়।
• Automation tool: Ansible-এর মতো tool (যন্ত্রে আলাদা agent লাগে না, সাধারণত SSH বা NETCONF দিয়ে যুক্ত হয়) একই কনফিগারেশন শত যন্ত্রে বসায়; কনফিগারেশন থাকে git-এ, বদলের আগে review — “infrastructure as code”.
• Intent-based networking: প্রকৌশলী লেখেন কী চাই (“অতিথি Wi-Fi থেকে হিসাব বিভাগের সার্ভারে কোনো traffic যাবে না”), ব্যবস্থাটি নিজে ঠিক করে কীভাবে — কোন যন্ত্রে কোন ACL বা VLAN — আর নিয়মিত যাচাই করে নীতিটি এখনো মানা হচ্ছে কি না। শব্দটি কয়েক বছর ধরে vendor-দের বিপণনে খুব জনপ্রিয়, তাই প্রতিটি পণ্যের দাবি আলাদাভাবে যাচাই করা দরকার।

# উদাহরণ: সব শাখার router-এ একই NTP সার্ভার (vendor-নির্দিষ্ট module; অন্য vendor-এ module আলাদা)
- name: Same NTP server on every branch router
  hosts: branch_routers
  gather_facts: false
  tasks:
    - name: Ensure the NTP line exists
      cisco.ios.ios_config:
        lines:
          - ntp server 192.0.2.123
# প্রথমে শুকনো মহড়া: ansible-playbook ntp_branches.yml --check --diff

এখানে cisco.ios.ios_config একটি নির্দিষ্ট vendor-এর module — অন্য vendor-এর যন্ত্রে আলাদা module লাগে, যা AI প্রায়ই গুলিয়ে ফেলে। --check --diff চালালে (যে module এটি সমর্থন করে) কিছু না বদলে দেখায় কী বদলাত। একটি ভুল লাইন শত যন্ত্রে একসাথে চলে যেতে পারে — তাই automation-এ পরীক্ষা, ধাপে ধাপে চালু (প্রথমে একটি শাখা) আর ফিরে যাওয়ার পরিকল্পনা আরও জরুরি।

৯ · AI-এর যুগে SDN আর NFV

“একটি Ryu controller লিখে দিন” বা “আমাদের ৩০০ switch-এ এই VLAN বসানোর Ansible playbook চাই” — AI এসব মুহূর্তে লিখে দেয়। কিন্তু SDN আর automation-এ ভুলের দাম বেশি, কারণ একটি ভুল নিয়ম বা playbook একসাথে পুরো নেটওয়ার্কে ছড়ায়। AI সাধারণত যে ভুলগুলো করে:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• Controller আর switch-এর OpenFlow সংস্করণ মিলিয়েছি, আর AI-এর বলা আচরণ সেই সংস্করণের নথিতে আছে কি না দেখেছি
• Dijkstra-র পথ আর cost নিজে হাতে (বা এই পর্বের simulator-এ) আবার হিসাব করেছি
• Flow নিয়ম আগে Mininet বা VM-এর ল্যাবে বসিয়ে counter আর packet capture দিয়ে যাচাই করেছি
• Automation আগে check/dry-run মোডে, তারপর একটি যন্ত্রে, তারপর বাকিগুলোতে চালিয়েছি; ফিরে যাওয়ার পথ রেখেছি
• Controller-এর channel-এ TLS, ডিফল্ট-deny নীতি আর শুধু অনুমতিপ্রাপ্ত নেটওয়ার্কে পরীক্ষা নিশ্চিত করেছি